DMARC (Domain-based Message Authentication, Reporting & Conformance) is the recent advancement in email authentication technology. Like SPF (Sender Policy Framework) & DKIM (Domain Keys Identified Mail), it can be confusing and misunderstood. That’s why we’re dedicating the post for email authentication, explaining how DMARC works, and why it matters to you as a web developer.
Introduction
DMARC ensures the legitimacy of an email with DKIM and SPF standards. It also helps prevent fraudulent email activity which spoof email addresses they are sent from. If they do not pass the DMARC policies, the recipient server can quarantine or reject the email. Domain Alignment verification and Reporting are two key aspects of DMARC.
Operation:
Alignment validation:
DMARC’s alignment feature compares the “header from” domain name against the “envelope from” domain name specified in the SPF. It also checks the “header from” domain against the “d=domain_name” attribute in the DKIM signature.
To pass DMARC, an email must pass SPF authentication and alignment and/or DKIM authentication and alignment. It will fail DMARC test if the email fails both SPF or SPF alignment and DKIM or DKIM alignment.
Reporting:
Reporting is a key aspect of DMARC that provides domain owners a wealth of information on their email activity. This helps them identify all parties sending email on their behalf. DMARC policies instruct recipient email servers on how to handle emails that do not pass a DMARC policy test. This allows recipient email servers to automatically handle messages that fail DMARC authentication. The recepient email servers then send aggregate reports to the emails listed in DMARC syntax.
Senders can create DMARC policy to either:
Monitor all mail, to understand their brand’s email authentication ecosystem, and ensure legitimate mail is authenticating properly without interfering with the delivery of messages that fail DMARC
Quarantine messages that fail DMARC (e.g., move to the spam folder)
Reject messages that fail DMARC (e.g., don’t deliver the mail at all)
Recipient email servers (e.g., Google, Outlook, Zoho) send reports based on email listed on DMARC policy. The DMARC policy syntax can include two emails: for DMARC aggregate (rua) and forensic (ruf) reports. This allows senders to receive reports about their email activity, giving them actionable data about what emails are originating from the organization and which are not.
Structure (Setting up DMARC):
A typical DMARC record:
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=s; aspf=s; fo=0; ri:86400;
Most of the attributes are optional based on your requirements. As an example, If you want to receive reports, you need to assign an email as well as the interval in which the reports are sent. Some policies like ‘report interval’ and ‘alignment checks’ user default policy if they aren’t included.
1. DMARC Syntax (v=DMARC1) is a required attribute for a DMARC syntax
Policy (p=quarantine) (required) allows senders to dictate email receivers on how to handle emails failing the DMARC check.
Options: p=none, p=quarantine or p=reject
2. Sub domain policy (sp=quarantine) (optional) is same as policy but which apply to sub-domains.
Options: p=none, p=quarantine or p=reject
3. Aggregate reports email (rua=mailto:[email protected]) (optional) is the email sent for aggregate reports from the recipient mailbox providers (Google, Outlook)
4. Forensic reports email (ruf=mailto:[email protected]) (optional) is the email sent for forensic reports for mails that fail DMARC validation
5. Percentage (pct=100) is the percentage of emails checked for DMARC validation. It instructs mailbox providers to only apply the DMARC policy to a percentage of failing emails. ’pct=50’ will instruct receivers to only apply the policy for 50% of the emails that fail the DMARC validation.
NOTE: this will not work for the “p=none" policy, but only for the “p=quarantine" or “p=reject" policies.
6. DKIM Alignment (adkim=s) (optional) tells the recipient to strictly check for DKIM alignment to validate DMARC. Defaults to ‘relaxed’ when not included
Options: adkim=s or adkim=r
7. SPF Alignment (aspf=s) (optional) tells the recipient to be strict for SPF alignment to validate DMARC. Defaults to ‘relaxed’ when not included
Options aspf=s or aspf=r
8. Forensic option (fo=0) (optional) tells the server when to send forensic reports
Options:
0 if DKIM AND SPF don’t pass or align,
1 if DKIM or SPF don’t pass or align,
d if DKIM doesn’t pass or align,
s if SPF doesn’t pass or align,
Report Interval (ri:86400) (optional) is the interval to receive the reports from recipient mail servers, which mostly defaults to one a day.
9. Reporting format (rf=afrf) (optional) is the reporting format
Options: “rf=afrf” or “rf=iodef”.
10. Report Interval (ri:86400) (optional) is the interval between reports
Conclusion:
DMARC combines established standards like SPF and DKIM to make it easy to identify authentic emails. Widely deployed, it can make emails more trustworthy and reduce the guesswork. The end users can confirm that the email’s “header from” address is a valid source of the email. With DMARC policy combined with SPF and DKIM alignment verification, cyber-criminals are less likely to impersonate a brand email for phishing and spam.