DMARC* is fundamentally an email authentication protocol, like SPF and DKIM, but with the primary focus of preventing email impersonation (domain-spoofing phishing attacks). This also makes it a very useful additional indicator for email legitimacy, bringing deliverability benefits to its deployment, as well as the primary security benefits it was designed for.
*Domain-based Message Authentication, Reporting & Conformance - rarely referred-to in its long form, thankfully!
Unlike SPF and DKIM however, which are both self-contained (i.e. they work independently of any other authentication protocols), DMARC has to piggyback off either SPF or DKIM for it to function.
When an email is received by a DMARC-enabled receiving system, the system will look at the domain of the From: address in the email's headers (sometimes called the 'visible' from, since that is the address the user sees in email clients). It will then perform a DNS lookup for that domain, looking for any associated DMARC record.
If a valid DMARC record is found then the system will proceed with DMARC authentication. If no record is found then no DMARC authentication will take place (and the receiving system may view the email with extra suspicion..).
This is where it can get slightly complicated; if you don't need/want to know the details, the SendForensics Email Deliverability Suite will help you achieve DMARC compliance painlessly. If you are interested though, read on!
The DMARC authentication process looks at the results of the email's SPF and DKIM checks. The requirement for DMARC authentication to check-out/pass, is:
So, of SPF and DKIM checks, only one needs to pass, but it must be an 'aligned pass' for DMARC authentication itself to pass.
What does this mean? In short, SPF and DKIM are not necessarily authenticated using the same domain as the visible From: address's domain. But to be considered 'aligned', the domain they authenticate with has to match the visible From: address's domain. Some visual examples may help here:
Once the DMARC authentication assessment has been performed by the DMARC-enabled receiving system, it proceeds to the next step - policy enforcement.
If the DMARC authentication is a pass, then enforcement is not necessary and the system should give the email another tick in the overall authenticity box. But if it fails, then the system looks at the policy statement within the DMARC record (in the From: domain's DNS) for directions on how to treat the email.
There are three possible policy options indicated in the record, which advises the DMARC-enabled receiving system on how to treat the failed email:
p=none advises the receiving-system to take no action, effectively providing no protection if there is a DMARC fail. This is usually the status set while DMARC compliance is being implemented across an organisation.
p=quarantine advises the receiving-system to quarantine the email for further analysis i.e. treat the email with greater suspicion.
p=reject advises the receiving-system to reject the failing email entirely. This is the most severe policy and can be dangerous to enact if an organisation is not completely sure it has achieved domain-wide compliance i.e. if a legitimate email fails for whatever reason, it may be lost.
It is worth noting here that there are currently no hard and fast rules on how a DMARC-enabled receiving system should treat the email, despite the policy statement. For example, it may decide that a hard reject for a p=reject policy is too severe and may quarantine instead in a spam folder. However, the policy should generally be respected as it is there to help a receiving system with their filtering of legitimate and illegitimate email.
This brings us onto the most useful secondary function of the DMARC protocol; its reporting abilities. It can instruct DMARC-enabled receiving servers to send information of transactions involving emails they receive from the domain (whether those emails are legitimate or not).
The information sent can help an organisation audit their overall email output to see when/where (and from which systems) emails are being sent that are failing SPF, DKIM, and of course DMARC itself. This information is sent to an email address (or addresses) specificied in the DMARC record.
There are two types of reports available:
RUA reports are sent periodically from individual providers (receiving-systems) as emails containing aggregated XML data for transactions involving received emails from the domain during a specific timeframe. Specifically, the data contained at time of writing is as follows (subject to future protocol updates):
Crucially RUA reports do not contain email content, nor any other personally-identifying information (PII).
RUF reports are sent immediately on reception of a DMARC-failing email, and may contain the entire email's contents. However, given the privacy implications, RUF reports are now rarely sent in these days of GDPR et al and so have limited use. We'll therefore leave them out of this introduction for simplicity's sake.
Processing the data contained in RUA reports can uncover a host of useful information about an organisation's outbound email sending. Ultimately, it can guide the path towards organisation-wide DMARC compliance and maintain it indefinitely, unlocking the associated benefits in deliverability and security.