Domain-based Message Authentication, Reporting and Conformance or DMARC is a method of email authentication, that is a way to mitigate email abuse. It expands on two existing mechanisms, the well-known Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM), coordinating their results on the alignment of the domain in the
From: header field, which is often visible to end users. It allows specification of policies (the procedures for handling incoming mail based on the combined results,) and provides for reporting of actions performed under those policies.
Ideas and early testing date around 2010 at Agari, and early adoption started in 2011. Then, DMARC was launched in 2012 by a group of organizations to help reduce the potential for email-based abuse, such as email spoofing and phishing, by solving some long-standing operational, deployment and reporting issues related to email authentication protocols. The contributing organizations included many of the largest mail systems in the world, so that this new email security scheme is emerging pretty fast.
After one year, in 2013, DMARC was estimated to protect 60% of the world's mailboxes.
DMARC aims at standardizing how email receivers perform email authentication, so that senders will experience consistent authentication results for their messages at any email receiver implementing DMARC. In March 2013 the specification was moved to the IETF, intended for the independent stream. The specification creators hope this will encourage senders to more broadly authenticate their outbound email which can make email a more reliable way to communicate.
In April 2014, Yahoo changed its DMARC policy to
p=reject, thereby causing misbehavior in several mailing lists. DMARC is not yet a standard protocol, and currently is missing a provision for such sudden changes. This change has caused significant debate in the IETF mailing list about whether DMARC is ready for deployment, about whether it is good for the Internet at all, and about whether its making process was correct, starting with message http://www.ietf.org/mail-archive/web/ietf/current/msg87171.html
A DMARC policy allows a sender 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 junk or reject the message. DMARC removes guesswork from the receiver's handling of these failed messages, limiting or eliminating the user's exposure to potentially fraudulent & harmful messages. DMARC also provides a way for the email receiver to report back to the sender about messages that pass and/or fail DMARC evaluation.
DMARC is designed to fit into an organization's existing inbound email authentication process. The way it works is to help email receivers determine if the purported message aligns with what the receiver knows about the sender. If not, DMARC includes guidance on how to handle the "non-aligned" messages. 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. For SPF, the message must PASS the SPF check, and the domain in the From: header must match the domain used to validate SPF (must exactly match for strict alignment, or must be a sub-domain for relaxed alignment). For DKIM, the message must be validly signed and the d= domain of the valid signature must align with the domain in the From: header (must exactly match for strict alignment, or must be a sub-domain for relaxed alignment). Under DMARC a message can fail even if it passes SPF or DKIM, but fails alignment.
To ensure the sender trusts this process and knows the impact of publishing a policy different than p=none (monitor mode), the receiver sends daily aggregate reports indicating to the sender how many emails have been received and if these emails passed SPF and/or DKIM and were aligned.
DMARC policies are published by Domain Owners and applied by Mail Receivers to the messages that don't pass the alignment test. The domain being queried is the author domain, that is the domain to the right of
@ in the
From: header field. The policy can be one of
none the so-called monitor mode,
quarantine to treat the message with suspicion according to the receiver capabilities, or
reject to reject the message outright. Reject policy is fine for domains that don't have individual human users, or for companies with firm staff policies that all mail goes through the company mail server, and employees don't join mailing lists and the like using company addresses, or the company provides a separate less strictly managed domain for its staff mail. Strict policies will never be appropriate for public webmail systems where the users will use their mail addresses any way one can use a mail address.
In fact, human use of a mail address may involve email forwarding from a dismissed address, and mailing lists, which are frequent causes of legitimate breakage of DMARC alignment. Various workarounds have been proposed to cope with domains that publish strict policies unwittingly. For example, a mailing list manager should reject posts from authors who use problematic email domains. The latter behavior is the most respectful the communication protocols as well as the domain owner's will. However, it might cause inconveniences in the face of sudden policy changes. According to John Levine, a well known mail expert, the least intrusive way to temporarily mitigate the damage would be to rewrite the
From: address in a predictable, comprehensible manner, such as the following:
change From: John Doe <firstname.lastname@example.org> to From: John Doe <email@example.com.INVALID>
.INVALID top level domain is reserved by RFC 2606 for such kind of usage. In order to apply that change, before re-mailing a message, a mail agent must look up the TXT RR at
_dmarc.example.com, if any, and check if it specifies a strict policy. If the change is applied, any recipient who wish to reply to the author can easily find out how to correct the address; in the same way, search engines that crawl mail archives can learn to discard the invalidating suffix.
For a more intrusive workaround, the
From: field can be rewritten boldly, thereby taking ownership of the message. The original author's address can then be added to the
- Receivers: AOL, Comcast, Gmail, Netease (163.com, 126.com, 188.com, yeah.net), Outlook.com and Hotmail, Yahoo! Mail, Mail.ru, XS4ALL, Yandex.ru
- Senders: American Greetings, Bank of America, Facebook, Fidelity Investments, LinkedIn, PayPal, JPMorganChase, Twitter
- Intermediaries & Vendors: Agari, Cloudmark, Return Path, Trusted Domain Project, Symantec
- Author Domain Signing Practices
- Demarcation point
- E-mail authentication
- Certified email
- Mail servers with DMARC
- "Agari, company". Retrieved 10 April 2014.
- Thomas Claburn (30 November 2011). "Major Email Providers Set Phish Trap". DarkReading.com. InformationWeek. Retrieved 10 April 2014.
- Butcher, Mike. DMARC Promises A World Of Less Phishing. Tech Crunch. Jan 30, 2012
- DMARC adoption
- "In First Year, DMARC Protects 60 Percent of Global Consumer Mailboxes". dmarc.org. 6 February 2013. Retrieved 10 April 2014.
- Lucian Constantin (8 April 2014). "Yahoo email anti-spoofing policy breaks mailing lists". PC World. Retrieved 15 April 2014.
- Kucherawy, Murray. The Current DMARC Internet Draft. IETF.org. Jul 15, 2013
- John Levine (8 April 2014). "DMARC: perspectives from a listadmin of large open-source lists". IETF Discussion List. IETF. Retrieved 11 April 2014.
- John Levine (31 May 2014). "Mitigating DMARC damage to third party mail". wiki. ASRG. Retrieved 1 June 2014.
- 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.
- DMARC specification Acknowledgements
- 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.