Prerequisites: Those who already authenticate their mail with SPF and DKIM and are interested in leveraging those technologies for more powerful mail authentication. At a minimum, an intermediate understanding of SPF and DKIM is required for this article, and as each will not be covered in length.

Acronyms:

(DMARC) Domain-based Message Authentication, Reporting and Conformance
(SPF) Sender Policy Framework
(DKIM) DomainKeys Identified Mail

What is DMARC?

A simple and powerful policy layer that encapsulates SPF and DKIM and substantially amplifies their authentication power and usefulness.

This enhanced authentication power has a significant impact on reducing domain spoofing, and the enhanced usefulness takes the shape of a highly insightful reporting mechanism baked into DMARC that allows for more flexible policy decisions, and more control over those decisions, for both email senders and receivers.

The core mechanism that DMARC uses to accomplish its goals is an ‘Alignment check’. When you think of DMARC you should think of the Alignment Check.

The Alignment Check

The DMARC alignment check tests and enforces Identifier Alignment to determine if the purported message “aligns” with what the receiver knows about the sender.

Three domains are relevant in this Alignment Check:

DMARC: Mail User Agent (MUA) visible “RFC5322.From” header field
SPF: The Organizational Domain of the SPF Authenticated RFC5321:Mail From
DKIM: The Organizational domain from 'd=' value of DKIM authenticated signature

The alignment check is a comparison between DMARC RFC5322.From” header field, to each of the SPF domain and DKIM domains to see if they match. For DMARC to pass, and to consider the mail properly aligned,only one Authenticated Identifier(SPF or DKIM domains) has to Align.

There is a binary option of either Relaxed (default) or Strict alignment which can be set separately for either/or SPF and DKIM. With relaxed alignment set only the Organizational Domain (second-level domain) must match, where as in strict alignment the domains must match exactly.

So what happens now that we have aligned or unaligned mail?

DMARC policy records

DMARC policy records specify how a receiver should treat your mail once the DMARC has checked for alignment. These records are very simple TXT records published in your DNS on the subdomain “_dmarc.yourdomain.com”. The records are concise and will look similar to this, give or take a field:

"v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com"

In this example, the sender requests that the receiver outright reject all non-aligned messages and send a report, in a specified aggregate format, about the rejections to a specified address.

Only the ’p’ field, and ‘v’ field are required to create a well formed DMARC record. There are several other flags which are available, and there are many easily accessible resources where they can be found.

Note the p= flag. There are three policy options for DMARC:

“none” – simply monitor and supply feedback
“quarantine” – process email with high degree of suspicion (instruct receiver to send to spam folder) “reject” – do not accept email that fails DMARC check

When first implementing DMARC this value should be set to none, and as you gain more experience, and learn more about how your mail stream is behaving, this tag is encouraged to be escalated to quarantine, and then even to reject.

Starting off your very first DMARC record should look something like this:

v=DMARC1; p=none; rua=mailto:aggregate@example.com;

Note: DMARC will first check for a DMARC record at the exact RFC5322.From. If a record is not found, next it checks the Organizational domain of the RFC5322.From.

DMARC Implementation Checklist

Deploy DKIM and SPF
Ensure that your mailers are correctly aligning the appropriate identifiers.
Publish a DMARC record with the “none” flag set for the policies, which requests data reports.
Analyze the data and modify your mail streams as appropriate.
Modify your DMARC policy flags from “none” to “quarantine” to “reject” as you gain experience.