As an email administrator one of your tasks is ensuring the best possible delivery success rate for the emails your users are sending. It is not uncommon for a local user to complain that their messages are not being delivered and yet when you look into it you find out that the recipient’s email server did accept the message.
Where did the message go?
At this point it would be recommended that the recipient check their Junk E-mail, or Spam folder for the message. Many times this is where the message will be placed by the recipient’s email server. The two big providers we get the most reports of this happening on is GSuite, and Outlook.com. Each of these providers have published information on how to improve your deliverability to their services. I’ve linked these articles below for those interested in reading further.
GSuite: Bulk Senders Guidelines
Outlook.com: Email I send is being blocked, or junked by Outlook.com
If you read this information you’ll notice one common thing. Both of these big providers recommend employing SPF records for your domain, and to take it one step further to employ DKIM and DMARC records.
Not sure what SPF, DKIM, or DMARC is? Below are links to sites I found to be informative on these subjects explained in an easy to understand format. I personally like the Returnpath.com articles.
How To Explain SPF In Plain English
How To Explain DKIM In Plain English
How To Explain DMARC In Plain English
What may not be clear at this point is how to start using SPF, DKIM, and DMARC for your domain. SPF/DKIM/DMARC are TXT records you will enter in your domain’s DNS configuration.
SPF
By far the easiest place to start is with Sender Policy Framework (SPF). SPF is meant to help stop nefarious people from sending emails pretending to be one of your local users. The TXT file lists locations (IP address/range, or DNS record) that emails from your domain can be seen coming from. Below is a simple example of a SPF record and I’ll explain what it all means.
V=spf1 mx ~all
The “v=spf1” portion denotes to an DNS server doing the SPF lookup that this TXT records holds SPF information.
The next portion of the record states “mx”. This means email from your domain can be seen coming from your MX record. The email server doing the SPF check would do a MX lookup on your domain name, resolve the MX record to an IP address, and then check to see if this IP address matches the IP address that is seen sending the email.
The last portion of the SPF record notes what action the email admin would like an email server to take if the SPF lookup fails. With this last portion we are concerned with the symbol before the word “all”. The tilde (~) symbol indicates a “Soft Fail”. A soft fail tells a receiving email server that if the SPF lookup fails then accept the message but treat the message with extra scrutiny. In the case of MDaemon we would accept the email and add 2.5 points to the message’s spam score.
The opposite to a Soft Fail would be a Hard Fail. A “Hard Fail” is noted by a dash (-) before the word all (i.e. v=spf1 mx -all). If a SPF lookup fails the admin is asking the receiving server to reject the message.
***NOTE: even though you may create a strict SPF record noting a Hard Fail it is ultimately up to the email server admin on whether to reject emails that fail this lookup. The email admin may configure their email server to never reject emails that fail SPF lookups. MDaemon can be configured this way as well. If the SPF lookups fails and the admin of the sending domain notes a Hard Fail in their SPF record MDaemon would add 15.0 points to the message’s spam score.
Do you need help creating your SPF record? We can help! To see whether you qualify for our free top level support see here: C&C Software Support Polices. There are multiple web sites that will help you create your SPF record. We use MXToolBox a lot and would like to pass some love their way. They have a SPF generator tool found here.
DKIM
DomainKeys Identified Mail (DKIM) is a method to protect the headers and body of a message from being tampered with. This means that the header information, and the information in the body of an email cannot change after the email has left the server. If a change is detected, then this produces a failed DKIM lookup. DKIM protects this information using something referred to as cryptographic authentication. This simply means that a private security key is used to “sign” a message with a DKIM signature, and a public key is used to verify the DKIM signature. The private key is kept “private” on MDaemon, and the public key is found by querying a DNS server of the domain having their DKIM signature verified. In a nutshell messages are signed with a private key and verified using a public key.
The DKIM signature is added as a header on the email. Below is an example of this header.
DKIM can become a very complicated subject. You don’t need to understand everything there is to DKIM to start using it. Our blog article about how to configure MDaemon to sign emails using DKIM is very easy to follow.
A successful DKIM lookup verifies that the message’s content is the same at the time it was sent, and that the message was sent by the sender’s email server (the message isn’t spoofed).
Still feeling a bit overwhelmed? Get some help from the pros. To see whether you qualify for our free top level support see here: C&C Software Support Polices.
DMARC
Domain-based Message Authentication, Reporting, and Conformance (DMARC). DMARC consolidates what action an email server should take if the SPF, or DKIM, lookups fail.
It also provides a method for an administrator to receive reports from other email servers if their domain was used, and a message was rejected due to a failed SPF/DKIM lookup. These reports generally include information such as what lookup failed (SPF/DKIM), the domain used in the From header, and what IP address the message was sent from. Many of our customers won’t bother looking at this information, but for the security conscious admin they may find this information useful. For one it lets an administrator know that spending time creating SPF/DKIM/DMARC records and publishing them in their DNS configuration was time well spent.
Below is an example of a DMARC record.
v=DMARC1;p=reject;rua=mailto:mike@robobak.ca;ruf=mailto:mike@robobak.ca
This is a basic DMARC record that would suit many of our customers. The important part of this record is the “p=reject” portion. This asks a receiving email server to reject emails that fail SPF or the DKIM lookup. The other options available are “none”, and “quarantine”. The “none” option asks the receiving email server to take no action if the DMARC lookup fails. This could be useful for administrators that want to see if their domain name is being abused by people sending phishing emails by reviewing any DMARC reports that get sent to them.
Choosing the option to quarantine simple means that it is up to the receiving email server to take whatever action it deems fit. This could mean that the email is moved to the receiving user’s Junk E-mail folder, placed in a special folder for review of an administrator, or possibly adding a tag in the Subject of the message warning the user of a possible bad email.
There are two types of reports you can receive. Aggregate and Failure reports.
Aggregate Reports
Aggregate reports typically get sent once per day. These reports have information about emails that are authenticating against SPF/DKIM/DMARC and which ones are not. The report doesn’t include any data about the contents of the email. They are intended to help identify potential SPF/DKIM/DMARC authentication issues and/or malicious activity using your domain name.
To request an aggregate report add the rua=mailto: tag and give an email address you would like to have these reports sent to.
Forensic Reports
These reports also contain information about emails that are authenticating against SPF/DKIM/DMARC. These reports will also include some header information, the subject of the message, and if any URLs were put in to the body of the message. Unlike Aggregate reports that only get sent once per day these forensic reports are typically sent immediately after a DMARC authentication failure occurs.
To request a forensic report add the ruf=mailto tag and give an email address you would like to have these reports sent to.
For more in depth information on how to read these reports the Returnpath.com web site has some great information on this topic with examples to follow.
How To Read DMARC Reports Part 1
How To Read DMARC Reports Part 2
Hopefully this information gives administrators a good starting point to learn about, and deploy, SPF/DKIM/DMARC records. If you need any help give us a call or send us an email to support@ccsoftware.ca.
