Explanation DMARC (Domain-based Message Authentication, Reporting and Conformance) in all details

2019-04-08

DMARC Overview

DMARC extends two existing mechanisms, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). It allows the administrative owner of a domain to publish a policy in their DNS records to specify which mechanism (DKIM, SPF or both) is employed when sending email from that domain; how to check the From: field presented to end users; how the receiver should deal with failures - and a reporting mechanism for actions performed under those policies.

Once the DMARC DNS entry is published, any receiving email server can authenticate the incoming email based on the instructions published by the domain owner within the DNS entry. If the email passes the authentication it will be delivered and can be trusted. If the email fails the check, depending on the instructions held within the DMARC record the email could be delivered, quarantined or rejected.

DMARC doesn't directly address whether or not an email is spam or otherwise fraudulent. Instead, DMARC requires that a message not only pass DKIM or SPF validation, but that it also pass alignment. Under DMARC a message can fail even if it passes SPF or DKIM, but fails alignment.

DMARC Flow

DMARC policy allows a sender's domain to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if one/or both of those authentication methods fail – such as to reject the message or quarantine it. The policy can also specify how an email receiver can report back to the sender's domain about messages that pass and/or fail. These policies are published in the public Domain Name System (DNS) as text TXT records.

DMARC Alignment

Domain alignment” is a concept in DMARC that expands the domain validation intrinsic to SPF and DKIM. DMARC domain alignment matches a message’s From: domain with information relevant to these other standards:

For SPF, the message’s From: domain in email header and its Return-Path: (email envelope) domain must match
For DKIM, the message’s From: domain in email header and its DKIM d= domain must match
The alignment can be relaxed (matching base domains, but allowing different subdomains) or strict (precisely matching the entire domain). This choice is specified in the published DMARC policy of the sending domain.
Strict alignment means that the Return-Path domain or the signing domain "d=" must be an exact match with the domain in the "From:" address.
Relaxed alignment means that the Return-Path domain or the signing domain "d=" can be a subdomain of the "From:" address and vice versa.

When DMARC Fail

To pass DMARC, a message must pass SPF authentication and SPF alignment or DKIM authentication and DKIM alignment. A message will fail DMARC if the message fails both (1) SPF or SPF alignment and (2) DKIM or DKIM alignment.

Example DMARC Alignment

For SPF

MAIL-FROM/RETURN-PATH: user@example.com    # SMTP envelope 
From: user@subdomain.example.com           # email header

In the above example, if DMARC was set to strict SPF mode then an email coming from subdomain.example.com would DMARC fail as the domains do not match exactly ie. they are not aligned. However, in relaxed alignment mode DMARC would pass.

For DKIM

d="example.com"                     # DKIM in email header					
From: user@subdomain.example.com    # email header

In the above example, if DMARC was set to strict DKIM mode then an email coming from subdomain.example.com would DMARC fail as the domains do not match exactly ie. they are not aligned. However, in relaxed alignment mode DMARC would pass.

DMARC PASS/FAIL with ALIGNMENT

The Overall DMARC Logic

If SPF PASSED and ALIGNED with the "From:" domain = DMARC PASS or if DKIM PASSED and ALIGNED with the "From:" domain = DMARC PASS. If both SPF and DKIM FAILED = DMARC FAIL

DMARC DNS record

DMARC records are published in DNS with a subdomain label _dmarc, for example _dmarc.example.com. The content of the TXT resource record consists of name=value tags, separated by semicolons, similar to SPF and DKIM. For example:

_dmarc.example.com	TXT	"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;"

Here, v is the version, p is the policy, sp the subdomain policy, pct is the percent of "bad" emails on which to apply the policy, and rua is the URI to send aggregate reports to. In this example, the entity controlling the example.com DNS domain intends to monitor SPF and/or DKIM failure rates and doesn't expect emails to be sent from subdomains of example.com.

The following chart illustrates some of the available tags:

Tag Name	Purpose	Sample
v	Protocol version	v=DMARC1
pct	Percentage of messages subjected to filtering	pct=20
ruf	Reporting URI for forensic reports	ruf=mailto:authfail@example.com
rua	Reporting URI of aggregate reports	rua=mailto:aggrep@example.com
p	Policy for organizational domain	p=quarantine
sp	Policy for subdomains	sp=reject
adkim	Alignment mode for DKIM	adkim=s/adkim=r
aspf	Alignment mode for SPF	aspf=r/aspf=s

Note that a subdomain can publish its own DMARC record and receivers must check it out before falling back to the organizational domain record. Only one DNS record can exist for a given domain. If DNS contained several DMARC records for the same domain, authentication would not be performed. If the DMARC record does not contain sp, the subdomains inherit the policy specifie d in p.

Reports

DMARC is capable of producing two separate types of reports. Aggregate reports are sent to the address specified following the rua. Forensic reports are emailed to the address following the ruf tag. These mail addresses must be specified in URI mailto format (e.g. mailto:worker@example.net ). Multiple reporting addresses are valid and must each be in full URI format, separated by a comma.