Below is a short history of DMARC, giving some background into why this is important and how it works.
Contents
How DMARC works
DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that provides instructions, via a DMARC policy published in DNS, to ISPs and other email receivers about how to handle unauthenticated mail. It was originally designed to detect and prevent email spoofing.
DMARC leverages two existing email authentication protocols (SPF & DKIM) to help email receivers determine the authenticity of a message and whether to deliver the message to the inbox, block the message, or place the message in quarantine or spam based on policy values that have been set by the sender.
Here is an example of a DMARC record one might find in DNS:
- v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@emarsys.com
The main purpose for DMARC is to set a "policy". This policy contains the action that should take place when unauthenticated mail from this domain is received. The options are to do nothing ("none"), put the mail in Spam folder ("quarantine") or block ("reject") the message. Only by using the “reject" policy, can a domain be fully protected.
By themselves, DKIM and SPF can be vulnerable – anyone can buy a domain and add DKIM/SPF to the headers of an email. DMARC attempts to tie the results of DKIM and SPF checks with the domain which is found in the From header – this is called alignment.
Alignment helps to avoid spoofing of the From domain by matching the domain used in From header with the “d=sender.domain” tag in the DKIM signature, and matching the sender domain to the “envelope from” domain used in SPF.
To pass DMARC, a message must pass SPF authentication and SPF alignment and/or DKIM authentication and DKIM alignment.
The second functionality of DMARC enables ISPs to send reports about the authentication success or failure for a domain. Those reports are sent to the addresses defined in "rua" (aggregated reports) and "ruf" (forensic reports). https://e-mail.eco.de/wp-content/blogs.dir/26/files/eco_dmarc_legal_report.pdf provides an interesting perspective on the legal aspect of DMARC reports.
Policy values
- reject - If the message does not pass DKIM authentication or alignment and SPF authentication or alignment, validation will fail.
- quarantine -If the message does not pass DKIM authentication or alignment and SPF authentication or alignment, validation will be handled by the mail provider accordingly (deliver to junk/spam, send a report to the sender, mark the message as suspicious, etc.).
- none - The domain owner is asking the receiver to take no action if the DMARC check fails. The receiver will still check SPF and/or DKIM validation and may reject the messages accordingly. A DMARC record with the policy value set to none may impact deliverability, but still allows the receiver to be able to identify where the messages are coming from and if they are authentic.
Tags
In addition to setting policy values, senders can add a variety of tags to their DMARC record that give further guidance to receivers about how unauthenticated mail should be handled for any particular sender.
- v - Indicates the DMARC protocol version.
- p - Indicates whether the message should be rejected, quarantined, or the policy ignored.
- pct - Indicates the percentage of mail that should be rejected if the mail does not pass authentication checks.
- rua - Provides an email address where aggregate reporting data about messages that fail DMARC can be forwarded.
- ruf - Provides an email address where forensic data about messages that fail DMARC authentication can be forwarded.
According to latest CSA guidelines and GDPR compliance, the ruf tag should be avoided.
The authentication process
This diagram from the official DMARC website gives an overview of the process.
How rua and ruf reports work
How does DMARC affect deliverability?
DMARC allows ISPs to rely more on domain reputation. Especially when sending via shared IPs, a good domain reputation can be helpful in delivering your emails to the right place. Any domain owner that does not protect with DMARC is vulnerable for phishing and spoofing abuse, and if your domain can be abused by a third party, your domain reputation will most likely suffer.
But there’s more than that. Many senders use link tracking methods to track clicks. Some of those trackable links have the same characteristics as links used in phishing emails. Using badly-designed trackable links may lead to emails landing in the spam folder or even being blocked, unless DMARC is being used. DMARC excludes the possibility that badly-designed or formatted emails can be taken as phishing attempts.
Setting up DMARC
Before you can fully protect your domain with DMARC, it may be useful to test if all the mail you send from all environments you use is properly authenticated. This can be done with a policy set to "none" or "quarantine" and reporting mode on. You should be able to read the reports you receive in order to determine if your authentication works as expected.
There are some useful tools which may help to visualize the data from aggregated reports, for example, XML to Human Converter.
As soon as SPF and DKIM are assured to be fully in line on all affected infrastructure, it is safe to change the policy to "reject". DMARC records are valid for all subdomains of the domain it is configured with. For example, a standard DMARC record on example.com also applies to subdomain.example.com. For optimal protection of your brand, it is recommended to set DMARC at the highest domain-level possible.
Troubleshooting
Troubleshooting articles related to DMARC: