DMARC Record

E-Mail
1

What is DMARC?

Domain-based Message Authentication, Reporting & Conformance or DMARC is an authentication, policy, and reporting protocol. It functions by building off of already created SPF and DKIM records. The DMARC record is used to establish linkage from the domain name, it will suggest actions, to the receiving server, for authentication failures. DMARC also allows for reporting to be enabled, informing the sending domain that an authentication failure has occurred and what actions were taken. This allows the domain owner to manage and be informed of the health of their domain's email environment (i.e.: spoofing, spamming, fraudulent email, etc). DMARC is available publicly and is free for use with no licensing required.

How does DMARC work?

A DMARC policy will allow the sending domain to notify that their mail is protected by SPF and DKIM, it also will let the recipient server know what to do with authentication failures. This removes the guesswork for the recipient server on how to handle failures. 

DKIM flow
DKIM flow.png1649×998 133 KB

DMARC was designed to fulfill the following:
  •   Minimize false positives
  •   Provide detailed authentication reporting
  •   State sender policy at recipient server
  •   Reduce phishing successful deliveries
  •   Minimize the complexity of phishing a spoofing policies
  •   To work at the scale of the Internet
DMARC is meant to replace Author Domain Signing Practices by adding support for:
  •   Subdomain/wildcard policies
  •   Non-existent subdomains
  •   Slow rollouts
  •   SPF
  •   Quarantining mail
  
DMARC is built upon both DKIM and SPF specifications and ideally, would have both to validate DMARC policy.
A very useful tool for parsing aggregate and failure reports is https://dmarcian.com/dmarc-xml/. This will convert the xml file received into human readable format, including charts and calculations based on results. 

DMARC Structure

VERY IMPORTANT: When first setting up the DMARC policy, make sure to set all policies to take no action, but do have reporting enabled so that you can analyze aggregate and failure reports to validate the setup. This is an essential step to ensure no dip in receipt of mail. 
DMARC records are published in DNS as a TXT record and informs receiving server what to do with non-aligned mail.
Below I have listed an example and then broken it down:
"v=DMARC1;pct=15;rua=mailto:[email protected];ruf=mailto:[email protected];sp=reject;adkim=s;aspf=r;p=quarantine;ri=86400;fo=0:s"
Tag Name Use Example Value
v Protocol Version (this is mandatory) v=DMARC1 DMARC1
pct Percentage of messages subjected to filtering pct=15  value from 0 to 100
rua Reporting URI of aggregate reports rua=mailto:[email protected] A comma delimited list of URI(s) that aggregate mail reports should be sent to
ruf Reporting URI of forensic reports ruf=mailto:[email protected] A comma delimited list of URI(s) that failure reports should be sent to
p Policy for organizational domain p=quarantine 
none - No advice is offered to the receiving MTA
quarantine - Advises the receiving MTA to treat any mail that fails any DKIM and/or SPF checks as suspicious and perform additional checks or mark the mail as suspected SPAM
                                                                          reject - Advises the receiving MTA to reject any email that fails any DKIM and/or SPF checks
sp Policy for subdomains of Organizational Domain sp=reject
Same values as p
adkim Alignment mode for DKIM adkim=s
r (relaxed - default) - Any subdomain of d=domain (the domain in the DKIM mail headers) will be accepted
s (strict) - Strict mode the domain name must exactly match the corresponding d=name (DKIM mail header). 
aspf Alignment mode for SPF aspf=r
r (relaxed) - any valid subdomain of domain.name is acceptable
s (strict)  - the domain.name in the MAIL FROM command (SMTP) and the from: header (in mail item) must match exactly
ri Defines the time in seconds between reports requested from the receiving MTA ri=86400
Value in seconds (if omitted defaults to ri=86400 - 24 hours)
fo Defines the error reporting policy the sending MTA requests from the receiving, multiple options can be defined using colon (:) separated values fo=0:s
0 - Generate report to the sending MTA if all checks failed.
      dkim only -> dkim failed -> report sent
      SPF only -> SPF failed -> report sent
      SPF and dkim -> one fails -> report not sent
1 - Generate report to the sending MTA if ANY checks fail
d - Generate report if DKIM checks fail
s - Generate report if SPF checks fail
All information was garnered from the following sites: