Demystifying DMARC

[katebo]

Below is a short history of DMARC, giving some background into why this is important and how it works.

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 (p=none), put the mail in a Spam folder (p=quarantine) or block the message (p=reject). 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 – so-called alignment.

Alignment helps to avoid spoofing of the From: domain by matching the domain used in From: header with the d=sender.domain.com 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).

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 instructing 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 – The DMARC protocol version. Mandatory, always DMARC1


• p – Defines whether the message should be rejected, quarantined, or the policy ignored. Mandatory.


• pct – Indicates the percentage of mail that should be rejected/quarantined if the mail does not pass authentication checks. Optional, default: 100.


• rua – Provides an email address where aggregate reporting data about messages that fail DMARC can be forwarded. Optional.


• ruf – Provides an email address where forensic data about messages that fail DMARC authentication can be forwarded. Optional.


• aspf – Defines the alignment mode between From: and SPF domains, aspf=r for relaxed alignment and aspf=s for strict. Optional, default: r


• adkim – Defines the alignment mode between From: and DKIM domains, adkim=r for relaxed alignment and adkim=s for strict. Optional, default: r


• sp – Defines policy for all the subdomains of the domain. Works in the same way as p= tag and overwrites its value, if defined. If not defined, p= tag is applied to all subdomains.

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.

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.

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 (example.com) and not only on the sending domains, since it will protect even domains that do not currently exist, but can be spoofed.

What’s next?

Please leave feedback below and/or hit the “like” button to show this type of content is useful.

You can ask questions and provide suggestions for helpful email deliverability topics in the Q&A area Q&A – SAP Emarsys Email Deliverability.

And if you’d like to find out more SAP Emarsys, you can visit the community page: SAP Emarsys CX.