View source for DMARC

{{Short description|System to prevent email fraud}}
'''Domain-based Message Authentication, Reporting and Conformance''' ('''DMARC''') is an [[Email authentication|email authentication]] protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as [[Email spoofing|email spoofing]]. The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise attacks, [[Phishing|phishing]] email, email scams and other cyber threat activities.

Once the DMARC DNS entry is published, any receiving email server can authenticate the incoming email based on the instructions published by the domain owner within the DNS entry. If the email passes the authentication, it will be delivered and can be trusted. If the email fails the check, depending on the instructions held within the DMARC record the email could be delivered, quarantined or rejected.

DMARC extends two existing email authentication mechanisms, [[Sender Policy Framework]] (SPF) and [[DomainKeys Identified Mail]] (DKIM). It allows the administrative owner of a domain to publish a policy in their DNS records to specify how to check the <code>From:</code> field presented to end users; how the receiver should deal with failures – and provides a reporting mechanism for actions performed under those policies.

DMARC is defined in the [[Organization:Internet Engineering Task Force|Internet Engineering Task Force]]'s published document {{IETF RFC|7489}}, dated March 2015, as "Informational".<ref name="rfc7489">{{cite IETF |title=Domain-based Message Authentication, Reporting, and Conformance (DMARC) |rfc=7489 |author1= 	Murray Kucherawy |author2= Elizabeth Zwicky |date=18 March 2015 |publisher=[[Organization:Internet Engineering Task Force|IETF]]}}</ref>

==Overview==
A DMARC policy allows a sender's domain to indicate that their email messages are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes – such as to reject the message or quarantine it. The policy can also specify how an email receiver can report back to the sender's domain about messages that pass and/or fail.<ref>{{Cite web |url=https://blogs.msdn.microsoft.com/tzink/2016/09/27/how-we-moved-microsoft-com-to-a-pquarantine-dmarc-record/ |title=How we moved microsoft.com to a p=quarantine DMARC record |author=Terry Zink |date=27 September 2016 |website=MSDN blog |quote=If that sounds like a lot of work, that’s because it was}}</ref>

These policies are published in the public [[Domain Name System]] (DNS) as text [[TXT record]]s.

DMARC does not directly address whether or not an email is spam or otherwise fraudulent. Instead, DMARC can require that a message not only pass DKIM or SPF validation, but that it also pass {{slink||Alignment}}. Under DMARC a message can fail even if it passes SPF or DKIM but fails alignment.<ref name="Kucherawy2013" />

Setting up DMARC may improve the deliverability of messages from legitimate senders.<ref>{{Cite web|title = Bulk Senders Guidelines – Gmail Help|url = https://support.google.com/mail/answer/81126?hl=en#authentication|website = support.google.com|access-date = 2015-04-24}}</ref>

== Alignment ==
DMARC operates by checking that the domain in the message's <code>From:</code> field (also called "RFC5322.From"<ref name="rfc7489" />) 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. Although at the time of DMARC spec there was an IETF working group on domain boundaries, nowadays the organizational domain can only be derived from the [[Public Suffix List]].<ref>{{cite mailing list |url=https://www.mail-archive.com/mailman-developers@python.org/msg16926.html |author=John Levine |title=Use of the public suffix list |date=2 November 2017 |mailing-list=Mailman developers}}</ref>

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 <code>MAIL FROM</code> command. (The email address in MAIL FROM is also called the [[Bounce address|bounce address]], envelope-from or RFC5321.MailFrom.) In addition to requiring that the SPF check passes, DMARC checks that RFC5321.MailFrom aligns with 5322.From.<ref name="rfc7489"/>

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 <code>d=</code> (domain) and <code>s=</code> (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,<!--{{refn| group=note|That is, the entity that applied the signature and specified the <code>d=</code> domain could cause a corresponding DNS record to be published, possibly by providing the public key and appropriate authorization to the entity that actually controls the DNS entry.}}--> 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 <code>d=</code> tag aligns with the sender's domain stated in the <code>From:</code> header field.

== DNS record ==
DMARC records are published in DNS with a subdomain label <code>_dmarc</code>, for example <code>_dmarc.example.com</code>. Compare this to SPF at <code>example.com</code>, and DKIM at <code>selector._domainkey.example.com</code>.

The content of the TXT resource record consists of <code>name=value</code> tags, separated by semicolons, similar to SPF and DKIM. For example:
 <nowiki>"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;"</nowiki>

Here, <code>v</code> is the version, <code>p</code> is the policy (see below), <code>sp</code> the subdomain policy, <code>pct</code> is the percent of "bad" email on which to apply the policy, and <code>rua</code> 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 email 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.

===Step by step adoption===
The protocol provides for various ratchets, or transitional states, to allow mail admins to gradually transition from not implementing DMARC at all the way through to an unyielding setup.<ref>{{cite web| url=https://support.google.com/a/answer/10032473?hl=en| title=Tutorial: Recommended DMARC rollout| website=google.com}}</ref><ref>{{cite web| url=https://www.cyber.gc.ca/en/guidance/implementation-guidance-email-domain-protection#anna4| title=Implementation Guidance: Email Domain Protection| date=12 August 2021| website=cyber.gc.ca}}</ref><ref>{{cite web| url=https://www.cisco.com/c/dam/en/us/td/docs/security/phishing_protection-and-domain_protection/dp_user_guide.pdf| title=User Guide for Cisco Domain Protection| date=25 May 2021| website=cisco.com}}</ref>  The concept of stepwise adoption assumes that the goal of DMARC is the strongest setting, which is not the case for all domains. Regardless of intent, these mechanisms allow for greater flexibility.

====Policy====
First and foremost, there are three policies:

* '''none''' is the entry level policy.  No special treatment is required by receivers, but enables a domain to receive feedback reports.
* '''quarantine''' asks receivers to treat messages that fail DMARC check with suspicion.  Different receivers have different means to implement that, for example flag messages or deliver them in the spam folder.
* '''reject''' asks receivers to outright reject messages that fail DMARC check.

The policy published can be mitigated by applying it to only a percentage of the messages that fail DMARC check.  Receivers are asked to select the given percentage of messages by a simple [[Bernoulli sampling]] algorithm.  The rest of the messages should undergo the lower policy; that is, none if <code>p=quarantine</code>, quarantine if <code>p=reject</code>.  If not specified, pct defaults to 100% of messages.  The case <code>p=quarantine; pct=0;</code> is being used to force mailing list managers to rewrite the From: field, as some don't do so when <code>p=none</code>.<ref>{{cite mailing list| url=http://lists.dmarc.org/pipermail/dmarc-discuss/2018-October/004166.html| title="p=none" vs. "p=quarantine; pct=0"| date=9 October 2018| author=Jonathan Kamens| website=dmarc.org}}</ref>

Finally, the subdomain policy, <code>sp=</code> and the newly added no-domain policy<ref>{{cite IETF |title=Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains |rfc=9091| author=Scott Kitterman| editor=Tim Wicinski| date=26 July 2021 |publisher=[[Organization:Internet Engineering Task Force|IETF]]}}</ref> allow tweaking the policy for specific subdomains.

== Reports ==
DMARC is capable of producing two separate types of reports. Aggregate reports are sent to the address specified following the <code>rua</code>. Forensic reports are emailed to the address following the <code>ruf</code> tag. These mail addresses must be specified in URI [[Mailto|mailto]] format (e.g. <nowiki>mailto:worker@example.net</nowiki> ). Multiple reporting addresses are valid and must each be in full URI format, separated by a comma.<ref>{{cite web |url=https://blog.progist.net/explain-dmarc-report-rua-and-ruf/|website=Progist.net|title=RUA vs RUF - Different DMARC Report Types Explained|access-date=14 December 2023}}</ref>

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 [[Denial-of-service attack#Amplification|spam amplification]]. For example, say <code>receiver.example</code> receives a mail message <code>From: someone@sender.example</code> and wishes to report it. If it finds <code><nowiki>ruf=mailto:some-id@thirdparty.example</nowiki></code>, it looks for a confirming DNS record in the namespace administered by the target, like this:

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

=== Aggregate reports ===
Aggregate Reports are sent as [[XML]] files, typically once per day. The [[Email#Message header|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 [[Lossless compression|compression]] (used to be <code>.zip</code>).<ref>{{cite web |url=https://dmarc.org/wiki/FAQ#What_is_the_rationale_for_choosing_ZIP_for_the_aggregate_reports.3F |website=DMARC.org |title=What is the rationale for choosing ZIP for the aggregate reports? |year=2012 |access-date=3 April 2019 |quote=Once GZIP is registered as a MIME application type with IANA, the DMARC group will consider it as inclusion in the draft}}</ref>

For example:
<code>example.com!example.org!1475712000!1475798400.xml.gz</code>.

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<ref>{{cite IETF | title = Domain-based Message Authentication, Reporting, and Conformance (DMARC) | rfc = 7489 | sectionname = DMARC XML Schema | appendix=C | editor1 = Murray S. Kucherawy | editor1-link=Murray Kucherawy |editor2=Elizabeth Zwicky | date = March 2015 | publisher = [[Organization:Internet Engineering Task Force|IETF]] | access-date = 3 March 2019 }}</ref> and a raw record is exemplified in dmarc.org.<ref name="dmarc.org">{{cite web|title=I need to implement aggregate reports, what do they look like?|url=https://dmarc.org/wiki/FAQ#I_need_to_implement_aggregate_reports.2C_what_do_they_look_like.3F|website=DMARC.org|access-date=26 May 2016}}</ref> 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|XSL stylesheet]].

{| class="wikitable"
|+ DMARC rows of an aggregate record shown in tabular form
! Source IP !! Count
! Disposition !! SPF !! DKIM
! Header from
! SPF domain (result)
! DKIM domain (result)
! &nbsp;
|-
| 192.0.2.1 || 12
| none || {{yes|{{pass}}}} || {{yes|{{pass}}}}
| example.org
| {{yes|example.org ({{pass}})}}
| {{yes|example.org ({{pass}})}}
| &nbsp;
|-
| 192.0.2.1 || 1
| none || {{yes|{{pass}}}} || {{failure|{{fail}}}}
| example.org
| {{yes|example.org ({{pass}})}}
| {{failure|example.org ({{fail}})}}
| &nbsp;
|-
| 192.0.2.28 || 42
| none || {{failure|{{fail}}}} || {{yes|{{pass}}}}
| example.org
| {{failure|example.org ({{fail}})}}
| {{yes|example.org ({{pass}})}}
| {{yes|forwarder.example ({{pass}})}}
|-
| 192.0.2.82 || 21
| none || {{failure|{{fail}}}} || {{failure|{{fail}}}}
| example.org
| {{yes|discusslist.example ({{pass}})}}
| {{failure|example.org ({{fail}})}}
| {{yes|discusslist.example ({{pass}})}}
|-
! colspan="9" style="text-align: left;" | ...
|}

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 <code>Return-Path:</code> test and once for the <code>HELO</code> 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 ===

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 <code>fo</code> 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".

Forensic Reports also contain the following:

* Source of Sending IP Address
* From email address
* Recipient email address
* Email subject line
* SPF and DKIM authentication results
* Received time
* Email message headers which include the sending host, email message ID, DKIM signature, and any other custom header information.<ref>{{Cite web|url=https://glockapps.com/tutorials/dmarc-monitoring-reporting/|title = The Ultimate Guide to DMARC Reporting in 2022|date = 23 August 2019}}</ref>

==Compatibility==
===Forwarders===
There are several different types of [[Email forwarding|email forwarding]], some of which may break SPF.<ref>{{cite IETF |title=Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows |rfc=7960 |sectionname=Alias |section=3.2.1 |editor1=Franck Martin |editor2=Eliot Lear |editor3=Tim Draegen |editor4=Elizabeth Zwicky |editor5=Kurt Andersen |date=September 2016 |publisher=[[Organization:Internet Engineering Task Force|IETF]] |access-date=14 March 2017 }}</ref> One of the reasons why email forwarding can affect DMARC authentication results. <ref>{{Cite web|url=https://blog.progist.net/how-does-email-forwarding-affect-dmarc-authentication-results/|title=How does email forwarding affect DMARC authentication results?|date=6 January 2023|work=progist.net}}</ref>

===Mailing lists===

[[Electronic mailing list|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,<ref>{{cite web| url=https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail| title=Mitigating DMARC damage to third party mail| author=[[Anti-Spam Research Group]]}}</ref><ref>[https://dmarc.org/wiki/FAQ#senders dmarc.org wiki]</ref> and mailing list software packages are working on solutions.<ref name="Mark Sapiro"/>

====Turn off all message modifications====

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.<ref>{{Cite web|url=https://lists.debian.org/debian-devel-announce/2015/08/msg00003.html|title=Upcoming changes for lists.debian.org|website=lists.debian.org}}</ref> This requires careful configuration of mailing software to make sure signed headers are not reordered or modified. A misconfigured email server may put 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.

====<code>From:</code> rewriting====
One of the most popular and least intrusive workarounds consists of rewriting the <code>From:</code> header field. The original author's address can then be added to the <code>Reply-To:</code> field.<ref>{{cite web |url=http://www.spamresource.com/2014/04/run-email-discussion-list-heres-how-to.html |title=Spam Resource: Run an email discussion list? Here's how to deal with DMARC |author=Al Iverson |date=9 April 2014 |website=spamresource.com |access-date=18 April 2014}}</ref> Rewriting can range from just appending <code>.INVALID</code>{{refn| group=note| INVALID is a top level domain reserved by RFC 2606 for this kind of usage.}} to the domain name, to allocating a temporary user ID where an opaque ID is used, which 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).<ref name="Threadable" /> Those examples would result, respectively, in one of the following:
<source lang="email">
From: John Doe <user@example.com.INVALID>
From: John Doe <243576@mailinglist.example.org>
From: John Doe via MailingList <list@mailinglist.example.org>
Reply-To: John Doe <user@example.com>
</source>
The last line, <code>Reply-To:</code>, has to be designed in order to accommodate reply-to-author functionality, in which case reply-to-list functionality is covered by the preceding change in the <code>From:</code> 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 <code>From:</code> field to attribute authorship to attachments.<ref>{{cite mailing list |url=https://mailarchive.ietf.org/arch/msg/ietf/qLMLIcG6mwUfZPkamLVYqM9jPSU |title=Realistic responses to DMARC |date=18 December 2016 |access-date=14 March 2017 |mailing-list=IETF-Discussion |author=Theodore Ts'o |quote= The fact that the from field is not rewritten is IMPORTANT because rewriting the from field would break the 'git am' command, since it uses the From: field to fill in the [[Software:Git|git]] commit's from field}}</ref>

====Other workarounds====
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 required in some countries, and that routinely losing SPF authentication may render overall authentication more fragile.<ref name="Mitigating">{{cite web |url=http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail |title=Mitigating DMARC damage to third party mail |author=John Levine |date=31 May 2014 |work=wiki |publisher=[[Anti-Spam Research Group|ASRG]] |access-date=1 June 2014}}</ref>

===Sender field===

Making changes to the <code>From:</code> 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 <code>Sender:</code> 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.{{refn|group=note|Use of the Sender field by remailers is mentioned (in the context of DKIM, not DMARC) in sections B.1.4 and B.2.3 of RFC 4871.}}

Both [[Author Domain Signing Practices|ADSP]]<!-- citation pending--> and DMARC<ref name="Kucherawy2013">{{cite web|last1=Kucherawy|first1=M.|  last2=Zwicky|first2=E.| title=Domain-based Message Authentication, Reporting and Conformance (DMARC) [draft 01]| at=Appendix A.3, Sender Header Field| url=https://tools.ietf.org/html/draft-kucherawy-dmarc-base-01#appendix-A.3| publisher=IETF| access-date=24 May 2016|date=15 July 2013}}</ref> reject using the Sender field on the non-technical basis that many user agents do not display this to the recipient.

==History==
A draft DMARC specification has been maintained since 30 January 2012.<ref>[https://dmarc.org/about/history/ "History"], dmarc.org</ref>

In October 2013, [[Software:GNU Mailman|GNU Mailman]] 2.1.16 was released with options to handle posters from a domain with the DMARC policy of <code>p=reject</code>.<ref name="Mark Sapiro">{{cite web |url=http://wiki.list.org/DEV/DMARC |title=Mailman and DMARC |author=Mark Sapiro |date=16 October 2013 |website=list.org |access-date=13 August 2015}}</ref> 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 <code>p=reject</code>, thereby causing misbehavior in several mailing lists.<ref>{{cite web |url=http://www.pcworld.com/article/2141120/yahoo-email-antispoofing-policy-breaks-mailing-lists.html |title=Yahoo email anti-spoofing policy breaks mailing lists |author=Lucian Constantin |date= 8 April 2014 |publisher=PC World |access-date=15 April 2014}}</ref><ref>{{cite web| url=https://wordtothewise.com/2014/04/yahoo-statement-dmarc-policy/| title=Yahoo Statement on DMARC policy| author=Laura Atkins| date=April 12, 2014| publisher=wordtothewise.com}}</ref> A few days later, AOL also changed its DMARC policy to <code>p=reject</code>.<ref>{{cite web |url=http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ |title=AOL Mail updates DMARC policy to 'reject' |author=Vishwanath Subramanian |date=22 April 2014 |publisher=AOL |access-date=13 August 2015 |archive-url=https://web.archive.org/web/20150813145754/http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ |archive-date=13 August 2015 |url-status=dead }}</ref> Those moves resulted in a significant amount of disruption, and those [[Mailbox provider|mailbox provider]]s have been accused of forcing the costs of their own security failures onto third parties.<ref>{{cite mailing list |url=https://mailarchive.ietf.org/arch/msg/ietf/kL24edUthAOuHuwK3ZnpFkCXduI |title=DMARC and ietf.org |date=13 August 2016 |access-date=10 October 2016 |mailing-list=IETF |author=John Levine |author-link=John Levine }}</ref> 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,<ref>{{cite web|title=FAQ in DMARC wiki|url=https://dmarc.org/wiki/FAQ|access-date=2020-07-15}}</ref> of which the most widely implemented is the mailing list changing the “From” header to an address in its own domain.

An [[Organization:Internet Engineering Task Force|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.<ref>{{cite mailing list |url=https://mailarchive.ietf.org/arch/msg/ietf-announce/wcJEsW2nQaShjli9XfqayvIVW14 |title=WG Action: Formed Domain-based Message Authentication, Reporting & Conformance (dmarc) |date=11 August 2014 |access-date=10 October 2016 |mailing-list= IETF-Announce<!-- |no author, auto-generated by the IESG --> }}</ref> 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.<ref>{{cite web|url=https://dmarc.org/|title=DMARC FAQ|website=dmarc.org}}</ref>

In March 2017, the Federal Trade Commission published a study on DMARC usage by businesses.<ref>{{cite web |url=https://www.ftc.gov/system/files/documents/reports/businesses-can-help-stop-phishing-protect-their-brands-using-email-authentication-ftc-staff/email_authentication_staff_perspective.pdf |title=Businesses Can Help Stop Phishing and Protect their Brands Using Email Authentication |date=3 March 2017 |publisher=Federal Trade Commission}}</ref> Out of 569 businesses, the study found about a third implemented any DMARC configuration, fewer than 10% used DMARC to instruct servers to reject unauthenticated messages, and a majority had implemented SPF.

=== Contributors ===
The contributors of the DMARC specification include:<ref>{{cite IETF|draft=draft-kucherawy-dmarc-base-01|appendix=E|sectionname=Acknowledgements|title=Domain-based Message Authentication, Reporting, and Conformance (DMARC)|last1=Kucherawy|first1=Murray|last2=Zwicky|first2=Elizabeth}}</ref><ref>[http://www.dmarc.org/ DMARC Contributors] (PDF)</ref>
* Receivers: AOL, Comcast, [[Company:Google|Google]] ([[Software:Gmail|Gmail]]), [[Software:Mail.Ru|Mail.Ru]], [[Company:Microsoft|Microsoft]] ([[Software:Outlook.com|Outlook.com]], Hotmail),<ref>{{cite web|last=Vitaldevara|first=Krish|title=Outlook.com increases security with support for DMARC and EV certificates|url=http://blogs.office.com/b/microsoft-outlook/archive/2012/12/10/outlook-com-increases-security-with-support-for-dmarc-and-ev-certificates.aspx|work=Outlook Blog|publisher=Microsoft|access-date=12 December 2012|date=10 December 2012}}</ref> Netease (163.com, 126.com, 188.com, yeah.net), XS4ALL, Yahoo, [[Company:Yandex|Yandex]]
* Senders: American Greetings, [[Company:Bank of America|Bank of America]], [[Company:Facebook|Facebook]], Fidelity Investments, JPMorganChase, [[Company:LinkedIn|LinkedIn]],<ref>{{cite web|last=Martin|first=Franck|title=DMARC: a new tool to detect genuine emails|url=http://engineering.linkedin.com/email/dmarc-new-tool-detect-genuine-emails|work=LinkedIn Engineering Blog|publisher=Linkedin|access-date=17 August 2013|date=20 September 2012}}</ref> [[Company:PayPal|PayPal]], [[Company:Twitter|Twitter]]<ref>{{cite web |url=https://blog.twitter.com/2013/introducing-dmarc-for-twittercom-emails |title=Introducing DMARC for Twitter.com emails |author=Josh Aberant |date=21 February 2013 |website=twitter.com |access-date=10 April 2014}}</ref>
* Intermediaries & Vendors:<ref name="History – dmarc.org">{{Cite web|title=History – dmarc.org|url=https://dmarc.org/about/history/|access-date=2020-09-23|website=dmarc.org}}</ref> Agari (Founder/CEO Patrick R. Peterson),<ref name="History – dmarc.org"/> Cloudmark,<ref name="History – dmarc.org"/> [https://dmarcadvisor.com/ DMARC Advisor],<ref name="History – dmarc.org" /> Red Sift,<ref name="History – dmarc.org"/> ReturnPath,<ref name="History – dmarc.org"/> Trusted Domain Project,<ref name="History – dmarc.org"/> [https://progist.net/products/prodmarc.html ProDMARC], <ref name="History – dmarc.org" />

==See also==
* [[Authenticated Received Chain|Authenticated Received Chain (ARC)]]
* [[Author Domain Signing Practices]]
* [[Brand Indicators for Message Identification|Brand Indicators for Message Identification (BIMI)]]
* [[DomainKeys Identified Mail]] (DKIM)
* E-mail authentication
* [[Certified email]]
* [[Comparison of mail servers#Antispam features|Mail servers with DMARC]]
* [[Sender Policy Framework]] (SPF)

==Notes==
{{Reflist|group=note}}

==References==
{{Reflist| refs=
<ref name="Threadable">{{cite web|title=How Threadable solved the DMARC problem|url=http://blog.threadable.com/how-threadable-solved-the-dmarc-problem|website=Threadable Blog|access-date=21 May 2016}}</ref>
<!-- not used <ref name="Listserv">{{cite web|title=LISTSERV® Inventor Develops Seamless Solution to DMARC Hassles|url=http://www.lsoft.com/news/2014/listserv160-2014a-us.asp|website=L-Soft Press Releases|access-date=22 May 2016}}</ref>-->
}}

== External links ==
* The Anti Spam Research Group wiki: [https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail Mitigating DMARC damage to third party mail]

[[Category:Email authentication]]
[[Category:Spam filtering]]

{{Sourceattribution|DMARC}}