DMARC

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators and that the email (including attachments) has not been modified during transport.

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.

DMARC is specified in RFC 7489.

History

A group of leading organizations came together in the spring of 2011 to collaborate on a method for combating fraudulent email at Internet-scale, based on practical experience with DKIM and SPF. They aimed to enable senders to publish easily discoverable policies on unauthenticated email - and to enable receivers to provide authentication reporting to senders to improve and monitor their authentication infrastructures.

The resulting DMARC specification was published on January 30, 2012, and within one year DMARC was estimated to protect 60% of the world's mailboxes.

In October 2013, Mailman 2.1.16 is released with options to handle posters from domain with the DMARC policy of p=reject.

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.

In March 2015, DMARC was published as RFC 7489, “Domain-based Message Authentication, Reporting, and Conformance (DMARC)” on the Independent Submission stream

Overview

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 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's domain 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.

DMARC policies are published in the public Domain Name System (DNS) as text (TXT) resource records (RR) and announce what an email receiver should do with non-aligned mail it receives.

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 may have a positive impact on deliverability for legitimate senders, at least Google recommends the use of DMARC for Bulk senders

Human policy

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 the original author's domain DKIM signature and therefore 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 <user@example.com>
  
 to
 From: John Doe <user@example.com.INVALID>

The .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. However, mail receiving systems may adversely treat an email containing an invalid domain in its key header fields.

For a more intrusive workaround, for forwarders that make changes to either the body or subject of the message, therefore invalidating the DKIM signature of the original author's domain, the From: field can be rewritten, thereby taking ownership of the message. The original author's address can then be added to the Reply-To: field.

Several mailing lists software now propose various options to deal with members posting from a domain with p=reject. For instance Mailman 2.1.16 (16 October 2013) and onward have such options.

Making either change 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.

Registrar support

Setting up DMARC on a domain requires creation of sub-domains starting with an underscore. Some registrars, however, such as 1&1, do not allow the creation of sub-domains starting with an underscore. Additionally, some registrars, such as Network Solutions, do not support underscores in cname records, which prevents the workaround by employing CNAME redirection.

Contributors

The contributors of the DMARC specification include:

• 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, Return Path, Trusted Domain Project, Symantec

See also

• Author Domain Signing Practices
• Demarcation point
• E-mail authentication
• Certified email
• Mail servers with DMARC

External links

• Official website
• DMARC Record Lookup
• Phishing Scorecard
• Google Apps DMARC documentation
• DMARC monitoring (free)
• DMARC monitoring & tools
• DMARC Compass Explorer - DMARC Lookup Tool (Free)