Domain-based Message Authentication, Reporting and Conformance or DMARC is a technical specification created by a group of organizations to help reduce the potential for email-based abuse, such as email spoofing and phishing e-mails, by solving some long-standing operational, deployment, and reporting issues related to email authentication protocols.
DMARC standardizes how email receivers perform email authentication using the well-known Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) mechanisms. This means that senders will experience consistent authentication results for their messages at AOL, Comcast, Gmail, Hotmail, Mail.ru, Netease, XS4ALL, Yahoo! and any other email receiver implementing DMARC. 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.
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.
- Receivers: AOL, Comcast, Gmail, Netease, Outlook.com, Yahoo! Mail
- Senders: American Greetings, Bank of America, Facebook, Fidelity Investments, LinkedIn, PayPal, JPMorganChase
- Intermediaries & Vendors: Agari, Cloudmark, Return Path, Trusted Domain Project
- Author Domain Signing Practices
- Demarcation point
- E-mail authentication
- Certified email
- Mail servers with DMARC
- Butcher, Mike. DMARC Promises A World Of Less Phishing. Tech Crunch. Jan 30, 2012
- DMARC adoption
- Kucherawy, Murray. The Current DMARC Internet Draft. IETF.org. Jul 15, 2013
- 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.