DMARC

Aggregate Reports are sent as XML files, typically once per day. The subject mentions the "Report Domain", which indicates the DNS domain name about which the report was generated, 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 (used to be .zip).[7]

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[8] and a raw record is exemplified in dmarc.org.[9] 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.

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:

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

There are several different types of email forwarding, some of which may break SPF.[10]

Mailing lists are a frequent cause of legitimate breakage of the original author's domain DKIM signature, for example by adding a prefix to the subject header. A number of workarounds are possible,[11] and mailing list software packages are working on solutions.[12]

This workaround keeps the standard mailing list workflow, and is adopted by several large mailing list operators, but precludes the list adding footers and subject prefixes.[13] This requires careful configuration of mailing software to make sure signed headers aren't reordered or modified. A misconfigured mail server may List-id in its DKIM of messages sent to a mailing list, and then the list operator is forced to reject it or do From: rewriting.

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.[14] 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).[16] Those examples would result, respectively, in one of:

From: John Doe <user@example.com.INVALID>
From: John Doe <243576@mailinglist.example.org>
From: John Doe via MailingList <list@mailinglist.example.org>
and
Reply-To: John Doe <user@example.com>

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.[17]

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.[18]

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[4] reject using the Sender field on the non-technical basis that many user agents don't display this to the recipient.

The contributors of the DMARC specification include:[27][28]

• Receivers: AOL, Comcast, Google (Gmail), Mail.Ru, Microsoft (Outlook.com, Hotmail),[29] Netease (163.com, 126.com, 188.com, yeah.net), XS4ALL, Yahoo, Yandex
• Senders: American Greetings, Bank of America, Facebook, Fidelity Investments, JPMorganChase, LinkedIn,[30] PayPal, Twitter[31]
• Intermediaries & Vendors:[32] Agari (Founder/CEO Patrick R. Peterson),[32] Cloudmark,[32] ReturnPath,[32] Trusted Domain Project[32]