DMARC extends two existing email authentication mechanisms, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).
DMARC is defined in the Internet Engineering Task Force's published document RFC 7489,[1] dated March 2015, as "Informational".
The policy can also specify how an email receiver can report back to the sender's domain about messages that pass and/or fail.
[3] These policies are published in the public Domain Name System (DNS) as text TXT records.
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.
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.
The content of the TXT resource record consists of name=value tags, separated by semicolons, similar to SPF and DKIM.
[8][9][10] The concept of stepwise adoption assumes that the goal of DMARC is the strongest setting, which is not the case for all 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.
If it finds ruf=mailto:some-id@thirdparty.example, it looks for a confirming DNS record in the namespace administered by the target, like this: Aggregate Reports are sent as XML files, typically once per day.
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).
DMARC authentication failed for the last row only; it could have affected the message disposition if example.org had specified a strict policy.
Some reasons why a receiver can apply a policy different from the one requested are already provided for by the specification: Forensic Reports, also known as Failure Reports, are generated in real time and consist of redacted copies of individual messages that failed SPF, DKIM or both based upon what value is specified in the fo tag.
[19] 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.
[23] This requires careful configuration of mailing software to make sure signed headers are not reordered or modified.
Altering the author is not fair in general, and can break the expected relationship between meaning and appearance of that datum.
There are communities which use mailing lists to coordinate their work, and deploy tools which use the From: field to attribute authorship to attachments.
[note 2] Both ADSP and DMARC[4] reject using the Sender field on the non-technical basis that many user agents do not display this to the recipient.
[28] 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.
[31] 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 onto third parties.
[32] As of 2020, the FAQ in the official DMARC wiki contains several suggestions for mailing lists to handle messages from a domain with a strict DMARC policy,[33] of which the most widely implemented is the mailing list changing the “From” header to an address in its own domain.
An 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.