DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise attacks, phishing emails, email scams and other cyber threat activities.
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 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.
A 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 neither of those authentication methods passes – 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.
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.
Setting up DMARC may have a positive impact on deliverability for legitimate senders.
DMARC operates by checking that the domain in the message's
From: field (also called "5322.From") is "aligned" with other authenticated domain names. If either SPF or DKIM alignment checks pass, then the DMARC alignment test passes.
Alignment may be specified as strict or relaxed. For strict alignment, the domain names must be identical. For relaxed alignment, the top-level "Organizational Domain" must match. The Organizational Domain is found by checking a list of public DNS suffixes, and adding the next DNS label. So, for example, "a.b.c.d.example.com.au" and "example.com.au" have the same Organizational Domain, because there is a registrar that offers names in ".com.au" to customers. Albeit at the time of DMARC spec there was an IETF working group on domain boundaries, nowadays the organizational domain can only be derived from the Public Suffix List.
Like SPF and DKIM, DMARC uses the concept of a domain owner, the entity or entities that are authorized to make changes to a given DNS domain.
SPF checks that the IP address of the sending server is authorized by the owner of the domain that appears in the SMTP
MAIL FROM command. (The email address in MAIL FROM is also called envelope-from or 5321.MailFrom.) In addition to requiring that the SPF check pass, DMARC additionally checks that 5321.MailFrom aligns with 5322.From.
DKIM allows parts of an email message to be cryptographically signed, and the signature must cover the From field. Within the DKIM-Signature mail header, the
d= (domain) and
s= (selector) tags specify where in DNS to retrieve the public key for the signature. A valid signature proves that the signer is a domain owner, and that the From field hasn't been modified since the signature was applied. There may be several DKIM signatures on an email message; DMARC requires one valid signature where the domain in the
d= tag aligns with the sender's domain stated in the
From: header field.
DMARC records are published in DNS with a subdomain label
_dmarc, for example
_dmarc.example.com. Compare this to SPF at
example.com, and DKIM at
The content of the TXT resource record consists of
name=value tags, separated by semicolons, similar to SPF and DKIM. For example:
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. Note that a subdomain can publish its own DMARC record; receivers must check it out before falling back to the organizational domain 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 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.
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.
|Source IP||Count||Disposition||SPF||DKIM||Header from||SPF domain (result)||DKIM domain (result)|
|192.0.2.1||12||none||✓ Pass||✓ Pass||example.org||example.org (✓ Pass)||example.org (✓ Pass)|
|192.0.2.1||1||none||✓ Pass||✗ Fail||example.org||example.org (✓ Pass)||example.org (✗ Fail)|
|192.0.2.28||42||none||✗ Fail||✓ Pass||example.org||example.org (✗ Fail)||example.org (✓ Pass)||forwarder.example (✓ Pass)|
|192.0.2.82||21||none||✗ Fail||✗ Fail||example.org||discusslist.example (✓ Pass)||example.org (✗ Fail)||discusslist.example (✓ Pass)|
Rows are grouped by source IP and authentication results, passing just the count of each group. The leftmost result columns, labelled SPF and DKIM show DMARC-wise results, either pass or fail, taking alignment into account. The rightmost ones, with similar labels, show the name of the domain which claims to participate in the sending of the message and (in parentheses) the authentication status of that claim according to the original protocol, SPF or DKIM, regardless of Identifier Alignment. On the right side, SPF can appear at most twice, once for the
Return-Path: test and once for the
HELO test; DKIM can appear once for each signature present in the message. In the example, the first row represents the main mail flow from example.org, and the second row is a DKIM glitch, such as signature breakage due to a minor alteration in transit. The third and fourth rows show typical failures modes of a forwarder and a mailing list, respectively. DMARC authentication failed for the last row only; it could have affected the message disposition if example.org had specified a strict policy.
The disposition reflects the policy published actually applied to the messages, none, quarantine, or reject. Along with it, not shown in the table, DMARC provides for a policy override. Some reasons why a receiver can apply a policy different from the one requested are already provided for by the specification:
- while keeping the same bounce address, usually doesn't break DKIM,
- sampled out
- because a sender can choose to only apply the policy to a percentage of messages only,
- trusted forwarder
- the message arrived from a locally known source
- mailing list
- the receiver heuristically determined that the message arrived from a mailing list,
- local policy
- receivers are obviously free to apply the policy they like, it is just cool to let senders know,
- if none of the above applies, a comment field allows to say more.
Forensic Reports, also known as Failure Reports, are generated in real time and consist of redacted copies of individual emails that failed SPF, DKIM or both based upon what value is specified in the
fo tag. Their format, an extension of Abuse Reporting Format, resembles that of regular bounces in that they contain either a "message/rfc822" or a "text/rfc822-headers".
Mailing lists are a frequent cause of legitimate breakage of the original author's domain DKIM signature. They routinely change the SPF-authenticated domain, and therefore break DMARC alignment. A number of workarounds are possible, and mailing list software packages are working on solutions.
One of the most popular and least intrusive workarounds consists of rewriting the
From: header field. The original author's address can then be added to the
Reply-To: field. Rewriting can range from just appending
.INVALID[note 1] to the domain name, to allocating a temporary user ID to forward replies through the list;[note 2] where an opaque ID is used, this keeps the user's "real" email address private from the list. In addition, the display name can be changed so as to show both the author and the list (or list operator). Those examples would result, respectively, in one of:
From: John Doe <email@example.com.INVALID> From: John Doe <firstname.lastname@example.org> From: John Doe via MailingList <email@example.com> and Reply-To: John Doe <firstname.lastname@example.org>
The last line,
Reply-To:, has to be designed in order to accommodate reply-to-author functionality, in case reply-to-list function is covered by the preceding change in the
From: header field. That way, the original meaning of those fields is reversed.
Altering the author is not fair in general, and can break the expected relationship between meaning and appearance of that datum. It also breaks automated use of it. There are communities which use mailing lists to coordinate their work, and deploy tools which use the
From: field to attribute authorship to attachments.
Wrapping the message works nicely, for those who use an email client which understands wrapped messages. Not doing any change is perhaps the most obvious solution, except that they seem to be legally due in some countries, and that routinely losing SPF authentication may render overall authentication more fragile.
Making changes to the
From: header field to pass DKIM alignment may bring the message out of compliance with RFC 5322 section 3.6.2: "The 'From:' field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message." Mailbox refers to the author's email address. The
Sender: header is available to indicate that an email was sent on behalf of another party, but DMARC only checks policy for the From domain and ignores the Sender domain.[note 3]
Both ADSP and DMARC reject using the Sender field on the non-technical basis that many user agents don't display this to the recipient.
A draft DMARC specification has been maintained since January 30, 2012,
In October 2013, GNU Mailman 2.1.16 was released with options to handle posters from a domain with the DMARC policy of
p=reject. The change tried to anticipate the interoperability issues expected in case restrictive policies were applied to domains with human users (as opposed to purely transactional mail domains).
In April 2014, Yahoo changed its DMARC policy to
p=reject, thereby causing misbehavior in several mailing lists. A few days later, AOL also changed its DMARC policy to
p=reject. Those moves resulted in a significant amount of disruption, and those mailbox providers have been accused of forcing the costs of their own security failures onto third parties.
An IETF working group was formed in August 2014 in order to address DMARC issues, starting from interoperability concerns and possibly continuing with a revised standard specification and documentation. Meanwhile, the existing DMARC specification had reached an editorial state agreed upon and implemented by many. It was published in March 2015 on the Independent Submission stream in the "Informational" (non-standard) category as RFC 7489.
In March 2017, the Federal Trade Commission published a study on DMARC usage by businesses. The study found that about 10% of 569 businesses with a significant online presence publish strict DMARC policies.
- Receivers: AOL, Comcast, Google (Gmail), Netease (163.com, 126.com, 188.com, yeah.net), Microsoft (Outlook.com, Hotmail), Yahoo, Mail.Ru, XS4ALL, Yandex
- Senders: American Greetings, Bank of America, Facebook, Fidelity Investments, LinkedIn, PayPal, JPMorganChase, Twitter
- Intermediaries and vendors: Agari, Cloudmark, Netcraft, MailReport, ReturnPath, Redsift OnDMARC, Trusted Domain Project, Symantec
- Authenticated Received Chain (ARC)
- Author Domain Signing Practices
- E-mail authentication
- Certified email
- Mail servers with DMARC
- INVALID is a top level domain reserved by RFC 2606 for such kind of usage
- Eric Thomas described the updated behaviour of Listserv software: "incoming Yahoo and AOL addresses are automatically rewritten to local addresses that can receive private replies and forward them to the original poster"
- Use of the Sender field by remailers is mentioned (in the context of DKIM, not DMARC) in sections B.1.4 and B.2.3 of RFC 4871.
- "RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)". datatracker.ietf.org.
- Terry Zink (27 September 2016). "How we moved microsoft.com to a p=quarantine DMARC record". MSDN blog.
If that sounds like a lot of work, that’s because it was
- Kucherawy, Murray. The Current DMARC Internet Draft. IETF.org. Jul 15, 2013
- "Bulk Senders Guidelines – Gmail Help". support.google.com. Retrieved 2015-04-24.
- John Levine (2 November 2017). "Use of the public suffix list". Mailman developers (Mailing list).
- "I need to implement aggregate reports, what do they look like?". DMARC.org. Retrieved 26 May 2016.
- Franck Martin; Eliot Lear; Tim Draegen; Elizabeth Zwicky; Kurt Andersen, eds. (September 2016). "Alias". Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows. IETF. sec. 3.2.1. doi:10.17487/RFC7960. RFC 7960. Retrieved 14 March 2017.
- John Levine (31 May 2014). "Mitigating DMARC damage to third party mail". wiki. ASRG. Retrieved 1 June 2014.
- Mark Sapiro (16 October 2013). "Mailman and DMARC". list.org. Retrieved 13 August 2015.
- Al Iverson (9 April 2014). "Spam Resource: Run an email discussion list? Here's how to deal with DMARC". spamresource.com. Retrieved 18 April 2014.
- "LISTSERV® Inventor Develops Seamless Solution to DMARC Hassles". L-Soft Press Releases. Retrieved 22 May 2016.
- "How Threadable solved the DMARC problem". Threadable Blog. Retrieved 21 May 2016.
- Theodore Ts'o (18 December 2016). "Realistic responses to DMARC". IETF-Discussion (Mailing list). Retrieved 14 March 2017.
The fact that the from field is not rewritten is IMPORTANT because rewriting the from field would break the "git am" command, since it uses the From: field to fill in the git commit's from field
- Kucherawy, M.; Zwicky, E. (July 15, 2013). "Domain-based Message Authentication, Reporting and Conformance (DMARC) [draft 01]". IETF. Appendix A.3, Sender Header Field. Retrieved 24 May 2016.
- "History", dmarc.org
- Lucian Constantin (8 April 2014). "Yahoo email anti-spoofing policy breaks mailing lists". PC World. Retrieved 15 April 2014.
- Vishwanath Subramanian (22 April 2014). "AOL Mail updates DMARC policy to 'reject'". AOL. Retrieved 13 August 2015.
- John Levine (13 August 2016). "DMARC and ietf.org". IETF (Mailing list). Retrieved 10 October 2016.
- "WG Action: Formed Domain-based Message Authentication, Reporting & Conformance (dmarc)". IETF-Announce (Mailing list). 11 August 2014. Retrieved 10 October 2016.
- "dmarc.org – Domain Message Authentication Reporting & Conformance". dmarc.org.
- "Businesses Can Help Stop Phishing and Protect their Brands Using Email Authentication" (PDF). Federal Trade Commission. 3 March 2017.
- Murray, Kucherawy; Elizabeth, Zwicky. "Domain-based Message Authentication, Reporting, and Conformance (DMARC)". tools.ietf.org.
- DMARC Contributors (PDF)
- Vitaldevara, Krish (10 December 2012). "Outlook.com increases security with support for DMARC and EV certificates". Outlook Blog. Microsoft. Retrieved 12 December 2012.
- Martin, Franck (20 September 2012). "DMARC: a new tool to detect genuine emails". LinkedIn Engineering Blog. Linkedin. Retrieved 17 August 2013.
- Josh Aberant (21 February 2013). "Introducing DMARC for Twitter.com emails". twitter.com. Retrieved 10 April 2014.
- Ian McShane (27 March 2014). "Introducing DMARC Validation in Email Security.cloud". symantec.com. Retrieved 10 April 2014.