DMARC

This article is about an email validation system. For the telephony junction point, see demarcation point.

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email-validation system designed to detect and prevent email spoofing. It is intended to combat certain techniques often used in phishing and email spam, such as emails with forged sender addresses that appear to originate from legitimate organizations. DMARC is specified in RFC 7489.

DMARC is built on top of two existing mechanisms, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). It allows the administrative owner of a domain to publish a policy on which mechanism (DKIM, SPF or both) is employed when sending email from that domain and how the receiver should deal with failures. Additionally, it provides a reporting mechanism of actions performed under those policies. It thus coordinates the results of DKIM and SPF and specifies under which circumstances the From: header field, which is often visible to end users, should be considered legitimate.

DMARC's validation of the From field has similarities to Author Domain Signing Practices (ADSP, originally called DKIM Sender Signing Practices, DKIM-SSP). The reporting aspect builds on Abuse Reporting Format (ARF).

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.

A draft DMARC specification has been maintained since January 30, 2012, and within one year DMARC was estimated to protect 60% of the world's mailboxes.

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 on third parties.

A 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.

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 two ways for the email receiver to report back to the sender's domain about messages that pass and/or fail DMARC evaluation. Aggregate reports contain statistical data, while forensic reports can include the message at fault.

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), receivers send 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. The sender looks at failing IP addresses in aggregate reports in order to find the (sub)domains responsible of bad authentication.

DMARC may have a positive impact on deliverability for legitimate senders. Google, at least, recommends the use of DMARC for bulk email senders.

Alignment

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.

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 passes, 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.

DNS record

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 selector._domainkey.example.com.

The content of the TXT resource record consists of name=value tags, separated by semicolons, similar to SPF and DKIM. For example:

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com"

Here, 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.

Reports

DMARC is capable of producing two separate types of reports. Aggregate reports, are sent to the address specified under the rua and Forensic reports are emailed to the address following the ruf tag. These mail addresses must be specified in URI mailto format (e.g. mailto:worker@example.net ). 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: someone@sender.example and wishes to report it. If it finds ruf=mailto:some-id@thirdparty.example, it looks for a confirming DNS record in the namespace administered by the target, like so:

  sender.example._report._dmarc.thirdparty.example IN TXT "v=DMARC1"

Aggregate reports

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 , 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. For example example.com!example.org!1475712000!1475798400.xml.gz.

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 record can also be directly transformed in HTML by applying an XSL stylesheet.

DMARC rows of an aggregate record shown in tabular form

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		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 are DMARC-wise, they must be either pass or fail, and take alignment into account. The rightmost ones are the original results as specified by SPF and DKIM, regardless of Identifier Alignment. 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.

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:

• forwarded 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,
• other, if none of the above applies, a comment field allows to say more.

Forensic reports

Forensic 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 resembles that of regular bounces.

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.

Compatibility

Mailing lists

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 of 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 wishes 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.

A number of mailing lists have adopted variations of rewriting the From: header. One approach is to show both the original sender and list (or list operator) in the display name:

From: John Doe via MailingList <list@mailinglist.example.org> 

For reply-to-author rather than reply-to-list, a Reply-To header can be added with only the original author's, but not the list's address:

Reply-To: John Doe <user@example.com>

Another approach is to assign a user ID and forward replies through the list; where an opaque ID is used, this keeps the user's "real" email address private from the list:

From: John Doe <243576@mailinglist.example.org>

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.

Sender field

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.

Both ADSP and DMARC reject using the Sender field on the basis that many user agents don't display this to the recipient.

DNS support

Setting up DMARC on a domain requires creation of sub-domains starting with an underscore. Some DNS providers, however, such as 1&1, do not allow the creation of sub-domains starting with an underscore. Additionally, some providers, such as Network Solutions, do not support underscores in cname records, which interferes with the consolidation of multiple records by 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, ReturnPath, Trusted Domain Project, Symantec

See also

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

External links

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