What is DMARC?
DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”, is an email authentication, policy, and reporting protocol. It builds on the widely deployed SPF and DKIM protocols, adding linkage to the author (“From:”) domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor the protection of the domain from fraudulent email.
Domain-based Message Authentication, Reporting & Conformance is the latest and greatest advance in email authentication. But, like SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Mail), it’s sometimes misunderstood. That’s why we’re dedicating the last post of our three-part email authentication series to explaining how it works, and why it matters.
What it is: DMARC ensures that legitimate email is properly authenticating against established DKIM and SPF standards and that fraudulent activity appearing to come from domains under the organization’s control (active sending domains, non-sending domains, and defensively registered domains) is blocked. Two key values are domain alignment and reporting.
How it works: DMARC’s alignment feature prevents spoofing of the “header from” address by:
- Matching the “header from” domain name with the “envelope from” domain name used during an SPF check, and
- Matching the “header from” domain name with the “d= domain name” in the DKIM signature.
To pass DMARC, a message must pass SPF authentication and SPF alignment and/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.
DMARC allows senders to instruct email providers on how to handle unauthenticated mail via a DMARC policy, removing any guesswork on how they should handle messages that fail DMARC authentication. Senders can 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
- Quarantine messages that fail (e.g., move to the spam folder)
- Reject messages that fail (e.g., don’t deliver the mail at all)
Mailbox providers send regular DMARC aggregate and forensic reports back to senders, giving them visibility into what messages are authenticating, what messages are not, and why.
Why it matters: DMARC is the first and only widely deployed technology that can make the “header from” address (what users see in their email clients) trustworthy. Not only does this help protect customers and the brand, but it also discourages cybercriminals who are less likely to go after a brand with a DMARC record.
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 the URI mailto format (e.g. mailto:firstname.lastname@example.org ). Multiple reporting addresses are valid and must each be in full URI format, separated by a comma.
Target email addresses can belong to external domains. In that case, the target domain has to set up a DMARC record to say it agrees to receive them, otherwise, it would be possible to exploit reporting for spam amplification. For example, say
receiver.example receives a mail message
From: email@example.com and wishes to report it. If it finds
ruf=mailto:firstname.lastname@example.org, it looks for a confirming DNS record in the namespace administered by the target, like this:
sender.example._report._dmarc.thirdparty.example IN TXT "v=DMARC1;"
Aggregate Reports are sent as XML files, typically once per day. The subject mentions the “Report Domain”, which is the policy-publishing sender of the mail messages being reported, and the “Submitter”, which is the entity issuing the report. The payload is in an attachment with a long filename consisting of bang-separated elements such as the report-issuing receiver, the begin and end epochs of the reported period as Unix-style time stamps, an optional unique identifier and an extension which depends on the possible compression (used to be
The XML content consists of a header, containing the policy on which the report is based and report metadata, followed by a number of records. Records can be put in a database as a relation and viewed in a tabular form. The XML schema is defined in Appendix C of specifications and a raw record is exemplified in dmarc.org. Here we stick with a relational example, which better conveys the nature of the data. DMARC records can also be directly transformed in HTML by applying an XSL stylesheet.
We specialize in getting your DNS and mail setting set up correctly on your web host so you don’t have to fear email issues. If you have had issues or are looking to get ahead of the technology, give us a call today!