RFC 9989
Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) 💌
Okay bestie, this is RFC 9989, and it's the DMARC spec 💖 It was written by T. Herr, Ed. at Valimail and J. Levine, Ed. at Standcore LLC (the "Ed." just means they're the editors, iykyk 🎀). It's from the Internet Engineering Task Force (IETF), it came out in May 2026, and it's a Standards Track document, so this is the real deal 👑 The ISSN is 2070-1721 ✨
It obsoletes RFC 7489 and RFC 9091, which means this one replaces both of them. The header doesn't list any Updates, so it isn't patching any earlier RFCs 🦋
Abstract 🌸
DMARC lets the owner of an email's Author Domain turn on validation of how that domain is used 🔍 Through it, the Domain Owner or the Public Suffix Operator can say how they'd like failed validation handled, and they can ask for reports about how the domain name is being used. Mail-receiving organizations can then use that info when they're deciding what to do with incoming mail 📬
Status of This Memo 📜
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🫶 If you want more info on Internet Standards, check out Section 2 of RFC 7841.
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9989 🔗
Copyright Notice ⚖️
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📖 Any Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty, as the Revised BSD License describes 💅
Table of Contents 🗺️
1. Introduction
2. Requirements
2.1. High-Level Goals
2.2. Anti-Phishing
2.3. Scalability
2.4. Out of Scope
3. Terminology and Definitions
3.1. Conventions Used in This Document
3.2. Definitions
3.2.1. Authenticated Identifiers
3.2.2. Author Domain
3.2.3. DKIM Signing Domain
3.2.4. SPF Domain
3.2.5. DMARC Policy Domain
3.2.6. DMARC Policy Record
3.2.7. Domain Owner
3.2.8. Domain Owner Assessment Policy
3.2.9. Enforcement
3.2.10. Identifier Alignment
3.2.11. Mail Receiver
3.2.12. Monitoring Mode
3.2.13. Non-Existent Domains
3.2.14. Organizational Domain
3.2.15. Public Suffix Domain (PSD)
3.2.16. Public Suffix Operator (PSO)
3.2.17. PSO-Controlled Domain Names
3.2.18. Report Consumer
4. Overview and Key Concepts
4.1. DMARC Basics
4.2. Use of RFC5322.From
4.3. Authentication Mechanisms
4.4. Identifier Alignment Explained
4.4.1. DKIM-Authenticated Identifiers
4.4.2. SPF-Authenticated Identifiers
4.4.3. Alignment and Extension Technologies
4.5. DMARC Policy Record Explained
4.6. DMARC Reporting URIs
4.7. DMARC Policy Record Format
4.8. Formal Definition
4.9. Flow Diagram
4.10. DNS Tree Walk
4.10.1. DMARC Policy Discovery
4.10.2. Identifier Alignment Evaluation
5. DMARC Participation
5.1. Domain Owner Actions
5.1.1. Publish an SPF Record for an Aligned Domain
5.1.2. Configure Sending System for DKIM Signing Using an
Aligned Domain
5.1.3. Set Up a Mailbox to Receive Aggregate Reports
5.1.4. Publish a DMARC Policy Record for the Author Domain and
Organizational Domain
5.1.5. Collect and Analyze Reports
5.1.6. Remediate Unaligned or Unauthenticated Mail Streams
5.1.7. Decide Whether to Update Domain Owner Assessment Policy
to Enforcement
5.1.8. A Note on Large, Complex Organizations and
Decentralized DNS Management
5.2. PSO Actions
5.3. Mail Receiver Actions
5.3.1. Extract Author Domain
5.3.2. Determine If the DMARC Mechanism Applies
5.3.3. Determine If Authenticated Identifiers Exist
5.3.4. Conduct Identifier Alignment Checks If Necessary
5.3.5. Determine DMARC "Pass" or "Fail"
5.3.6. Apply Policy If Appropriate
5.3.7. Store Results of DMARC Processing
5.3.8. Send Aggregate Reports
5.3.9. Optionally Send Failure Reports
5.4. Policy Enforcement Considerations
6. DMARC Feedback
7. Other Topics
7.1. Issues Specific to SPF
7.2. Rejecting Messages
7.3. Interoperability Issues
7.4. Interoperability Considerations
8. Conformance Requirements for Full DMARC Participation
9. IANA Considerations
9.1. Email Authentication Methods Registry Update
9.2. Email Authentication Result Names Registry Update
9.3. DMARC Tags Registry Update
9.4. DMARC Report Formats Registry Update
9.5. Underscored and Globally Scoped DNS Node Names Registry
Update
10. Privacy Considerations
10.1. Aggregate Report Considerations
10.2. Failure Report Considerations
11. Security Considerations
11.1. Authentication Methods
11.2. Attacks on Reporting URIs
11.3. DNS Security
11.4. Display Name Attacks
11.5. Denial of DMARC Processing Attacks
11.6. External Reporting Addresses
11.7. Secure Protocols
11.8. Relaxed Alignment Considerations
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Technology Considerations
A.1. S/MIME
A.2. Method Exclusion
A.3. Sender Header Field
A.4. Domain Existence Test
A.5. Organizational Domain Discovery Issues
A.6. Removal of the "pct" Tag
Appendix B. Examples
B.1. Identifier Alignment Examples
B.1.1. SPF
B.1.2. DKIM
B.2. Domain Owner Example
B.2.1. Entire Domain, Monitoring Mode
B.2.2. Entire Domain, Monitoring Mode, Per-Message Failure
Reports
B.2.3. Per-Message Failure Reports Directed to Third Party
B.2.4. Overriding Destination Addresses
B.2.5. Subdomain, Testing, and Multiple Aggregate Report URIs
B.3. Mail Receiver Example
B.3.1. SMTP Session Example
B.4. Organizational and Policy Domain Tree Walk Examples
B.4.1. Simple Organizational and Policy Example
B.4.2. Deep Tree Walk Example
B.4.3. Example with a PSD DMARC Policy Record
B.5. Utilization of Aggregate Feedback: Example
Appendix C. Changes from RFC 7489
C.1. Informational vs. Standards Track
C.2. Changes to Terminology and Definitions
C.2.1. Terms Added
C.2.2. Definitions Updated
C.3. Policy Discovery and Organizational Domain Determination
C.4. Reporting
C.5. Tags
C.5.1. Tags Added
C.5.2. Tags Removed
C.6. Expansion of Domain Owner Actions Section
C.7. Report Generator Recommendations
C.8. Removal of RFC 7489, Appendix A.5
C.9. RFC 7489 Errata Summary
C.9.1. RFC Errata, Erratum ID 5365, RFC 7489, Section 7.2.1.1
C.9.2. RFC Errata, Erratum ID 5371, RFC 7489, Section 7.2.1.1
C.9.3. RFC Errata, Erratum ID 5440, RFC 7489, Section 7.1 and
Appendices B.2.1, B.2.3, and B.2.4
C.9.4. RFC Errata, Erratum ID 6439, RFC 7489, Section 7.1
C.9.5. RFC Errata, Erratum ID 5221, RFC 7489, Appendix C
C.9.6. RFC Errata, Erratum ID 5229, RFC 7489, Appendix C
C.9.7. RFC Errata, Erratum 5495, RFC 7489, Section 6.6.3
C.9.8. RFC Errata, Erratum ID 6485, RFC 7489, Section 7.2.1.1
C.9.9. RFC Errata, Erratum ID 6729, RFC 7489, Section 3.2
C.9.10. RFC Errata, Erratum ID 7099, RFC 7489, Section 7.2.1.1
C.9.11. RFC Errata, Erratum ID 7100, RFC 7489, Section 7.2.1.1
C.9.12. RFC Errata, Erratum ID 7835, RFC 7489, Section 6.6.3
C.9.13. RFC Errata, Erratum ID 7865, RFC 7489, Appendix C
C.9.14. RFC Errata, Erratum ID 5151, RFC 7489, Section 1
C.9.15. RFC Errata, Erratum ID 5774, RFC 7489, Appendix C
C.10. General Editing and Formatting
Acknowledgements
Acknowledgements - RFC 7489
Authors' Addresses1. Introduction ✨
okay so bestie, let's start with the big problem. 🙈 Abusive email often sneaks in an unauthorized and deceptive use of a domain name in the "From" header field (defined in Section 3.6.2 of [RFC5322], and called RFC5322.From for short). That domain usually belongs to an organization the recipient is expected to know, and presumably trusts. 💔
SPF [RFC7208] and DKIM [RFC6376] give us domain-level authentication, but they aren't directly tied to the RFC5322.From domain, which is also called the Author Domain (Section 3.2.2). 🦋 This is where DMARC comes in and slays. It lets Domain Owners publish a DNS TXT record that describes their email authentication policies for the Author Domain, and asks for specific handling of messages using that domain that fail validation checks. These records are called DMARC Policy Records (Section 3.2.6). 💅
Like SPF and DKIM, DMARC validation ends in a verdict of either "pass" or "fail". 🌸 A DMARC "pass" needs more than just an SPF or DKIM pass for the message. It also (and this is the most important part, periodt) needs the domain tied to that SPF or DKIM pass to be "aligned" with the Author Domain, in one of two modes: "relaxed" or "strict". Domains are in "relaxed alignment" if they share the same Organizational Domain (Section 3.2.14). A domain's Organizational Domain is the domain at the top of that domain's namespace hierarchy that also has the same administrative authority as it. Domains are in "strict alignment" if and only if they are identical. ✨ The Domain Owner (Section 3.2.7) who publishes a DMARC Policy Record gets to pick the alignment mode. 👑
A DMARC pass only tells you that use of the Author Domain was validated for that message and authorized by the Domain Owner. 🎀 That authorization doesn't carry any explicit or implicit value claim about the message or the Domain Owner. So a DMARC pass alone does not guarantee that landing in the recipient's inbox is safe or desirable. 🙃 For a mail-receiving organization taking part in DMARC, a message that passes validation belongs to a message stream that's reliably tied to the Author Domain. So when that organization assesses the reputation of that stream, it can assume the Domain Owner authorized the use of that Author Domain. 🧚
On the flip side, a message that fails validation isn't necessarily tied to the Author Domain, so it shouldn't hurt the Author Domain's reputation. 💀 The phrase "not necessarily associated" was chosen on purpose, because some messages that make authorized use of the Author Domain can still fail DMARC validation checks. [RFC7960] and Section 7 of this document both talk about why those failures can happen. Because of that, a mail-receiving organization that does DMARC validation can choose to honor the Domain Owner's requested handling for validation failures, but it is not required to do so. 🌈 DMARC is often just one input into more complex filtering decisions, so the mail-receiving organization might pick a completely different action. 🍓
DMARC also has a reporting framework, described in the associated documents [RFC9990] and [RFC9991]. 📊 With it, a mail-receiving organization can generate regular reports about messages that use Author Domains that have a DMARC Policy Record. Those reports go to the address(es) the Domain Owner listed in that record. Domain Owners can use the reports, especially the aggregate ones, to spot sources of mail that are trying to fraudulently use their domain. Even better (maybe even more importantly) they can use them to flag and fix gaps in their own authentication practices. 🔥 Just like honoring the Domain Owner's mail handling preference, a mail-receiving organization that supports DMARC has no obligation to send the requested reports. Still, it is recommended that they do send aggregate reports. 🫶
DMARC creates some interoperability challenges, so it needs careful thought before deployment, especially with configurations that can cause mail to be rejected. Those are covered in Section 7. ⭐
2. Requirements 🎀
okay this part sets the vibe for what DMARC is supposed to do. The following sections describe the topics that guide how DMARC is specified. 💖
2.1. High-Level Goals
DMARC has the following high-level goals, bestie:
- Allow Domain Owners (Section 3.2.7) and Public Suffix Operators (PSOs) (Section 3.2.16) to validate their email authentication deployments. 🔍
- Allow Domain Owners and PSOs to assert their desired message handling for validation failures on messages purporting to have authorship within the domain. 📣
- Minimize implementation complexity for both senders and receivers. 🧩
- Reduce the amount of successfully delivered spoofed emails. 🚫
- Work at Internet scale. 🌍
2.2. Anti-Phishing
DMARC is designed to stop the unauthorized use of an email message's Author Domain (Section 3.2.2), a move known as "spoofing". 🎭 This kind of unauthorized use often shows up in messages impersonating a business entity's domain. Those messages are made to tempt the recipient into handing over sensitive info, like usernames, passwords and financial account details. These spoofed messages are commonly called "phishing". 🎣 Ew.
DMARC can only directly combat specific forms of exact-domain spoofing. It does not try to solve every problem with spoofed or otherwise fraudulent emails. 🙅 In particular, it does not address visually similar domain names, or abuse of the human-readable display name in the RFC5322.From header field, as defined in Section 3.4 of [RFC5322]. 🙄
2.3. Scalability
Scalability is a huge deal for systems that have to work in an environment as widely deployed as today's SMTP email. 📈 For that reason, DMARC tries to avoid needing third parties or pre-sending agreements between senders and receivers. That keeps the good parts of the current email infrastructure intact. 💜
DMARC doesn't bring third-party senders (meaning external agents authorized to send on behalf of an operator) into the email-handling flow, but it doesn't rule them out either. 🤝 Those third parties are free to offer services alongside DMARC. ✨
2.4. Out of Scope
Several topics and issues are specifically out of scope for this work. 🚧 These include the following:
- Different treatment of messages that are not authenticated (e.g., those that have no DKIM signature or those sent using an Author Domain (Section 3.2.2) for which no DMARC Policy Record (Section 3.2.6) exists versus those that fail validation;
- Evaluation of anything other than the RFC5322.From header field;
- Multiple reporting formats;
- Publishing policy other than via the DNS;
- Reporting or otherwise evaluating other than the last-hop IP address;
- Attacks in the display name portions of the RFC5322.From header field, also known as "display name" attacks;
- Authentication of entities other than domains, since DMARC is built upon SPF and DKIM, which authenticate domains; and
- Content analysis. 🥱
3. Terminology and Definitions 📚
this section defines the terms we'll use for the rest of the doc, so pay attention, bestie. 🤓
3.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💅
Readers are encouraged to be familiar with the contents of [RFC5598]. ✨ That document defines the various roles in the messaging infrastructure, which can show up as the same or as separate roles in different contexts. For example, a Domain Owner (Section 3.2.7) could, through the messaging security mechanisms DMARC is based on, delegate the ability to send mail as the Domain Owner to a third party with a different role. 🧠 This document doesn't address the differences among those roles, so you should get familiar with that material before continuing. 📖
3.2. Definitions
The following sections define the terms used in this document. 🎀
3.2.1. Authenticated Identifiers
Authenticated Identifiers are domain-level identifiers whose authorized use is validated using a supported authentication mechanism (Section 4.3). 🔐
3.2.2. Author Domain
The Author Domain is the domain name of the apparent author, as extracted from the RFC5322.From header field. ✍️
3.2.3. DKIM Signing Domain
The DKIM Signing Domain is the domain name that is the value of the d tag in a validated DKIM-Signature header field in an email message. 🖋️
3.2.4. SPF Domain
SPF [RFC7208] can validate the uses of both the domain found in an SMTP [RFC5321] HELO/EHLO command (the HELO identity) and the domain found in an SMTP MAIL command (the MAIL FROM identity). 💌 DMARC relies solely on SPF validation of the MAIL FROM identity. Section 2.4 of [RFC7208] describes how the MAIL FROM identity is determined for cases where the SMTP MAIL command has a null path. That's the mailbox made up of the local-part postmaster and the HELO identity. 🫣
The term "SPF Domain," when used in this document, refers to an SPF-validated MAIL FROM identity. 🦋
3.2.5. DMARC Policy Domain
The DMARC Policy Domain is the domain name at which an applicable DMARC Policy Record (Section 3.2.6) is discovered for the Author Domain (Section 3.2.2) of an email message. 🔎
3.2.6. DMARC Policy Record
A DMARC Policy Record is a DNS TXT record published by a Domain Owner (Section 3.2.7) or Public Suffix Operator (PSO) (Section 3.2.16). 📜 It enables validation of an Author Domain's (Section 3.2.2) use, indicates the Domain Owner's or PSO's message handling preference for failed validation, and optionally requests reports about the use of the Author Domain. 🌟
3.2.7. Domain Owner
A Domain Owner is an entity or organization that has control of a given DNS domain, usually by holding its registration. 👑 Domain Owners range from complex, globally distributed organizations, to service providers working on behalf of non-technical clients, to individuals maintaining personal domains. 🏡 This specification uses the term as analogous to an Administrative Management Domain (ADMD), as defined in [RFC5598]. It can also refer to delegates, such as Report Consumers, when they are outside of their immediate management domain. 🌸
3.2.8. Domain Owner Assessment Policy
The Domain Owner Assessment Policy is the message handling preference expressed in a DMARC Policy Record (Section 3.2.6) by the Domain Owner (Section 3.2.7) regarding failed validation of the Author Domain (Section 3.2.2). 💖 The possible values are described in Section 4.7. ✨
3.2.9. Enforcement 💅
okay so Enforcement is the state where the existing Domain Owner Assessment Policy (Section 3.2.8) for an Organizational Domain (Section 3.2.14) and all the subdomains under it is not p=none. 🔒 In this state, the Organizational Domain and its subdomains can only be used as Author Domains (Section 3.2.2) if they're properly validated using the DMARC mechanism. no cap, it's the strict club entrance 🚪✨
historically, p=quarantine or p=reject policies have been the higher-value signals to Mail Receivers (Section 3.2.11) 👀 so if a message has an Author Domain with one of those policies and it isn't validated with DMARC, it won't reach the inbox at Mail Receivers that take part in DMARC and respect the Domain Owner's handling preference. bestie that's a whole vibe check 💀
3.2.10. Identifier Alignment 🫶
DMARC has this concept called alignment between the Author Domain (Section 3.2.2) and an Authenticated Identifier (Section 3.2.1). it requires that kind of Identifier Alignment between the two for a message to get a DMARC pass ✅ and there are two states for it. it's giving matching energy 🧩
3.2.10.1. Relaxed Alignment 🌸
when the Author Domain (Section 3.2.2) has the same Organizational Domain (Section 3.2.14) as an Authenticated Identifier (Section 3.2.1), the two are in relaxed alignment. same family, close enough 🤝
3.2.10.2. Strict Alignment 💎
when the Author Domain (Section 3.2.2) is identical to an Authenticated Identifier (Section 3.2.1), the two are in strict alignment. no notes, exact match only 💅
3.2.11. Mail Receiver 📬
the Mail Receiver is the entity or organization that receives and processes email. Mail Receivers run one or more Internet-facing Message Transfer Agents (MTAs). they're the ones checking everyone at the door 🧚
3.2.12. Monitoring Mode 👀
Monitoring Mode is the state where the existing Domain Owner Assessment Policy (Section 3.2.8) for an Organizational Domain (Section 3.2.14) and all subdomains under it is p=none, and the Domain Owner (Section 3.2.7) is getting aggregate reports for that Organizational Domain 📊 the Organizational Domain and all its subdomains can still be validated by a Mail Receiver (Section 3.2.11) using the DMARC mechanism, but the Domain Owner doesn't express any handling preference for messages that fail DMARC validation. the Domain Owner is basically reading the tea in the aggregate reports 🍵 and using that info to make any needed tweaks to the authentication practices for their mail streams. it's the research phase, periodt 🔍
3.2.13. Non-Existent Domains 🫥
for DMARC purposes, a non-existent domain matches what [RFC8020] means by the term. so if the response code for a query on a domain name is NXDOMAIN, then that domain name and any possible subdomains don't exist. poof, gone 👻
3.2.14. Organizational Domain 🏠
the Organizational Domain for any domain is akin to the ADMD described in [RFC5598]. a domain's Organizational Domain is the domain at the top of its namespace hierarchy that still has the same administrative authority as the domain. it's the house the domain lives in 🏡 and it gets determined by applying the algorithm found in Section 4.10.
3.2.15. Public Suffix Domain (PSD) 🌐
some domains let people register subdomains that are "owned" by independent organizations. real-world examples include .com, .org, .us, and .co.uk, to name just a few 🗺️ these domains are called "Public Suffix Domains" (PSDs). for example, ietf.org is a registered domain name, and .org is its PSD. the suffix is the hallway, the registered name is the apartment 🚪
3.2.16. Public Suffix Operator (PSO) 🛠️
a PSO is an organization that manages operations within a PSD, especially the DNS records published for names at and under that domain name. the PSO is the building manager, basically 🧹
3.2.17. PSO-Controlled Domain Names 🔑
PSO-Controlled Domain Names are names in the DNS that are managed by a PSO. they can have one label (like .com) or more (like .co.uk), depending on the PSO's policy. it depends on the building rules, bestie 🏢
3.2.18. Report Consumer 📥
a Report Consumer is an operator that receives reports from another operator implementing the reporting mechanisms described in [RFC9990] and [RFC9991]. this term applies to the system components that receive and process these reports, and to the organizations that run those components 🤖
Report Consumers can receive reports about domains where the Report Consumer is also the Domain Owner (Section 3.2.7) or PSO (Section 3.2.16), or about domains that belong to another operator entirely. the DMARC mechanism lets a Domain Owner act as a Report Consumer for its own domain(s) and/or hand that job to a third party. see Section 11.6 for more on that designation 🫶
4. Overview and Key Concepts ✨
this section gives you the big-picture tour of how the DMARC environment is designed and how it runs 🗺️ let's go!
4.1. DMARC Basics 🎀
DMARC lets a Domain Owner (Section 3.2.7) or PSO (Section 3.2.16) turn on validation of an Author Domain's (Section 3.2.2) use in an email message. it also lets them say what their handling preference is when validation fails, and request reports about use of the Author Domain 📨 a domain's DMARC Policy Record (Section 3.2.6) gets published in the DNS as a TXT record at the name you get by prepending the label "_dmarc" to the domain name, and it's retrieved through normal DNS queries 🔍
DMARC's validation mechanism gives a "pass" result if a DMARC Policy Record exists for the Author Domain of an email message and the Author Domain is aligned (Section 3.2.10) with an Authenticated Identifier (Section 3.2.1) from that message ✅ when a DMARC Policy Record exists for the Author Domain and the DMARC mechanism doesn't give a "pass," the Mail Receiver's (Section 3.2.11) handling of that message can be influenced by the Domain Owner Assessment Policy (Section 3.2.8) in that record. so the policy is the tiebreaker 🥊
it's really important to note that the authentication mechanisms DMARC uses only validate the usage of a DNS domain in an email message. they don't validate the local-part of any email address identifier in that message, and those validations don't carry an explicit or implicit value assertion about that message or about the Domain Owner. no vibes-based verdicts here 🙅♀️
DMARC's reporting part collects information about received messages that use the Author Domain, and sends periodic aggregate reports to the Domain Owner or PSO 📊 the parameters and format for those reports are discussed in [RFC9990].
a Mail Receiver taking part in DMARC might also generate per-message failure reports with info about individual messages that fail DMARC validation checks 🕵️♀️ these are super useful when debugging deployments (if a message turns out to be legit even though it failed validation) or when analyzing attacks. the capability for these services is enabled by DMARC, but it's defined in other referenced material like [RFC6591] and [RFC9991] 💜
4.2. Use of RFC5322.From 🔎
okay real talk, one of the most obvious spots for security scrutiny in DMARC is the choice to focus on an identifier: the RFC5322.From address. that's part of a body of data that has been trivially forged all through email history 😭 this field is the one end users look at to figure out who sent the message, so it's always been a prime target for abuse through forgery and other tricks. still, of all the identifiers that are part of the message itself, this is the only one that's required to be present. a message without a single, properly formed RFC5322.From header field doesn't comply with [RFC5322], and handling a message like that is outside the scope of this specification 🙈
4.3. Authentication Mechanisms 🔐
the following mechanisms for determining Authenticated Identifiers (Section 3.2.1) are supported in this version of DMARC 🌈
- DKIM [RFC6376]: the DKIM Signing Domain (Section 3.2.3) from a validated
DKIM-Signatureheader field is an Authenticated Identifier. - SPF [RFC7208]: the validated SPF Domain (Section 3.2.4) from the email message is the Authenticated Identifier.
4.4. Identifier Alignment Explained 🧠
DMARC validates the authorized use of the Author Domain (Section 3.2.2) by requiring one of two things: either it has the same Organizational Domain (Section 3.2.14) as an Authenticated Identifier (Section 3.2.1) (that's the "relaxed alignment" (Section 3.2.10.1) condition), or it's identical to the Authenticated Identifier (that's the "strict alignment" (Section 3.2.10.2) condition) 🤝 the choice between relaxed and strict alignment is left to the Domain Owner (Section 3.2.7) and gets expressed in the domain's DMARC Policy Record (Section 3.2.6). in practice, nearly all Domain Owners have found relaxed alignment is enough for what they need 💅 domain name comparisons in this context are case-insensitive, per [RFC4343].
here's a table to show some possible alignment conditions 📋
+==================+==================+=========================+
| Authenticated | Author Domain | Identifier Alignment |
| Identifier | | |
+==================+==================+=========================+
| foo.example.com | news.example.com | relaxed; the two have |
| | | the same Organizational |
| | | Domain, example.com |
+------------------+------------------+-------------------------+
| news.example.com | news.example.com | strict; the two are |
| | | identical |
+------------------+------------------+-------------------------+
| foo.example.net | news.example.com | none; the two do not |
| | | share a common |
| | | Organizational Domain |
+------------------+------------------+-------------------------+
Table 1: Alignment Examplesit's important to note that Identifier Alignment can't happen with a message that isn't valid per [RFC5322], especially one with a malformed, absent, or repeated RFC5322.From header field 🚫 without a valid one there's no reliable way to find a DMARC Policy Record (Section 3.2.6) that applies to the message. so DMARC operation depends on the input being a valid message object [RFC5322]. for non-compliant cases, handling is outside the scope of this specification. more on this can be found in Section 11.5 🫧
4.4.1. DKIM-Authenticated Identifiers 🎀
Okay bestie, so DKIM lets a Domain Owner 💅 claim a little bit of responsibility for a message by putting their domain into the d tag of a DKIM-Signature header field. The claim gets backed up by a cryptographic signature sitting in that same header field, and if the signature checks out ✅, the DKIM Signing Domain becomes the DKIM-Authenticated Identifier ✨.
There's currently no generally accepted way for a Domain Owner to publish a list of third-party DKIM Signing Domains that are allowed to sign on behalf of a given Author Domain 🙈. So DMARC requires that Identifier Alignment is applied to the DKIM-Authenticated Identifier, because literally any domain can produce a valid signature, even one run by a bad actor 💀. Only a DKIM-Authenticated Identifier that has Identifier Alignment with the Author Domain is enough to validate the authorized use of the Author Domain 🔥.
A single email can carry multiple DKIM signatures, and it counts as a DMARC "pass" result if any DKIM-Authenticated Identifier aligns with the Author Domain 🌈.
4.4.2. SPF-Authenticated Identifiers 🦋
SPF can validate the use of two different domains: the one found in an SMTP HELO/EHLO command (the HELO identity) and the one found in an SMTP MAIL command (the MAIL FROM identity) 🧚. DMARC only relies on SPF validation of the MAIL FROM identity 💜. If SPF validates the domain in the MAIL FROM identity, then that domain is the SPF-Authenticated Identifier 🌸.
Same plot twist as before: there's currently no generally accepted mechanism for a Domain Owner to list third-party domains that are authorized to be used as the MAIL FROM identity for mail using a given Author Domain 😭. So DMARC requires that Identifier Alignment is applied to the SPF-Authenticated Identifier, because any Domain Owner, even a bad actor, can publish an SPF record for its own domain and send an email that gets an SPF "pass" result 💀. Only an SPF-Authenticated Identifier with Identifier Alignment to the Author Domain is enough to validate the authorized use of the Author Domain ✨.
4.4.3. Alignment and Extension Technologies 🔮
Looking ahead 👀, if DMARC gets extended to include other authentication mechanisms, those extensions MUST allow for a domain to be assigned as an Authenticated Identifier, so that alignment with the Author Domain can be validated 🫶.
4.5. DMARC Policy Record Explained 📜
A Domain Owner (Section 3.2.7) or PSO (Section 3.2.16) advertises DMARC participation for one or more of its domains by publishing DMARC Policy Records (Section 3.2.6) that apply to those domains. In doing so, they're telling the world how they want failed validation handled for messages that use their domain in the RFC5322.From header field, plus whether they'd like feedback about those messages in the form of aggregate and/or failure reports 📬.
DMARC Policy Records are stored as DNS TXT records with names starting with the label _dmarc. For example, the Domain Owner of example.com would publish a DMARC Policy Record at _dmarc.example.com, and a Mail Receiver (Section 3.2.11) looking for the DMARC Policy Record for mail with an Author Domain (Section 3.2.2) of example.com would send a TXT query to DNS for the name _dmarc.example.com. A Domain Owner or PSO can opt out of DMARC validation by Mail Receivers simply by not publishing a DMARC Policy Record for its Author Domain(s) 🙅.
DMARC Policy Records can also apply to subdomains of the name they're published at, as long as the record is published at an Organizational Domain (Section 3.2.14) for those subdomains 🌳. The Domain Owner Assessment Policy (Section 3.2.8) that applies to the subdomains can be identical to the one that applies to the Organizational Domain, but it doesn't have to be. Whether or not it's identical depends on the presence or absence of certain values in the DMARC Policy Record. See Section 4.7 for more details 🎀.
DMARC's use of the Domain Name Service comes from its use of domain names and the kind of query it makes. That query is a good match for DNS, since DNS is built for obtaining simple parametric information 🧠. DMARC uses an established method of storing information tied to the domain name targeted by a DNS query, specifically an isolated TXT record that's restricted to the DMARC context. Using DNS as the query service has the benefit of reusing an extremely well-established operations, administration, and management infrastructure, instead of creating a brand new one 🏗️.
Per [RFC1035], a TXT record can comprise multiple "character-string" objects. When that's the case, the module performing DMARC evaluation MUST concatenate these strings by joining together the objects in order and parsing the result as a single string 🧩.
A Domain Owner can choose not to have some underlying authentication mechanisms apply to DMARC evaluation of its Author Domain(s) 🙃. For example, if a Domain Owner only wants to use DKIM as the underlying authentication mechanism, then it doesn't publish an SPF record that can produce Identifier Alignment between an SPF-Authenticated Identifier and the Author Domain. Alternatively, if the Domain Owner wants to rely solely on SPF, then it can send email messages that have no DKIM-Signature header field that would produce Identifier Alignment between a DKIM-Authenticated Identifier and the Author Domain. Still, it is RECOMMENDED that Domain Owners use both DKIM and SPF as underlying authentication mechanisms for DMARC 💖.
A Mail Receiver implementing the DMARC mechanism gets the Domain Owner's or PSO's published Domain Owner Assessment Policy, and it can use that to inform its handling decisions for messages that go through DMARC validation checks and don't produce a result of "pass" 🚦. Mail handling considerations based on Domain Owner Assessment Policy enforcement are discussed below in Section 5.4 ✨.
4.6. DMARC Reporting URIs 🌈
[RFC3986] defines a syntax for identifying a resource. The DMARC mechanism uses this syntax as the format for a Domain Owner (Section 3.2.7) or PSO (Section 3.2.16) to specify the destination(s) for the two report types that are supported 📮.
The DMARC Policy Record format (Section 4.7) allows for a list of these URIs to be provided, with each URI separated by commas (ASCII 0x2c) 🍓. A report SHOULD be sent to each listed URI provided in the DMARC Policy Record 💜.
A formal definition is provided in Section 4.8 🎀.
4.7. DMARC Policy Record Format 💖
Okay so DMARC Policy Records use the same extensible "tag-value" syntax as DKIM's DNS-based key records [RFC6376] 🫶 No new drama here, just a familiar vibe 💅
Section 9 sets up a registry of known DMARC tags and registers the starter set from this document 📋 Only tags in that registry get processed, and unknown tags MUST be ignored 🙈
Here are the valid DMARC tags 🎀
adkim(plain-text; OPTIONAL; default is"r".) This tells you whether the Domain Owner (Section 3.2.7) or PSO (Section 3.2.16) wants strict or relaxed DKIM Identifier Alignment mode. Check Section 4.4.1 for the deets. Valid values:r: relaxed modes: strict mode
aspf(plain-text; OPTIONAL; default is"r".) Same idea, but for SPF Identifier Alignment: is the Domain Owner or PSO asking for strict or relaxed mode? See Section 4.4.2. Valid values:r: relaxed modes: strict mode
fo(Failure reporting options; plain-text; OPTIONAL; default is"0".) This is how you request certain options for failure reports 📨 Report generators may choose whether to follow the requested options. If there's noruftag (more on that below), this tag's content MUST be ignored 🙅♀️ You can list one or more values, except"0"and"1"can't be used together. When you have several values, separate them with colons (likefo=0:d), and they can show up in any order 🌈 Valid values:0: Generate a DMARC failure report if every underlying authentication mechanism fails to produce an aligned "pass" result.1: Generate a DMARC failure report if any underlying authentication mechanism fails to produce an aligned "pass" result.d: Generate a DKIM failure report if the message had a signature that failed evaluation, no matter its alignment. DKIM-specific reporting is covered in [RFC6651].s: Generate an SPF failure report if the message failed SPF evaluation, no matter its alignment. SPF-specific reporting is covered in [RFC6652].
np(Domain Owner Assessment Policy for non-existent subdomains of the given Organizational Domain; plain-text; OPTIONAL) ✨ "Non-existent subdomain" means the same thing as "non-existent domains" in Section 3.2.13. This tag says how the Domain Owner or PSO wants mail from non-existent subdomains of the Organizational Domain handled when it fails DMARC validation. It ONLY covers non-existent subdomains of the Organizational Domain you queried, not existing subdomains and not the domain itself 🧐 The syntax matches theptag below. Ifnpis missing, then the policy fromsp(ifspis there) or fromp(ifspisn't there) MUST be applied to non-existent subdomains 🔥p(Domain Owner Assessment Policy from Section 3.2.8; plain-text; RECOMMENDED for DMARC Policy Records) 💅 This is the message handling preference of the Domain Owner or PSO for mail from their domain that fails DMARC validation. It covers the domain you queried plus its subdomains, unlessspornpspells out a different subdomain policy. Ifpis missing from an otherwise valid DMARC Policy Record, the record gets treated like it saidp=none(see Section 4.10.1). This tag doesn't apply to third-party reporting records (see [RFC9990] and [RFC9991]). Possible values:none: The Domain Owner doesn't express a preference.quarantine: The Domain Owner thinks this mail is sus 🤨 It might be legit, but the failure is still a big concern.reject: The Domain Owner sees every one of these failures as a clear sign that the domain name isn't being used properly. Check Section 7.2 for some talk about SMTP rejection methods and what they mean.
psd(A flag saying whether the domain is a PSD; plain-text; OPTIONAL; default is"u".) Possible values:y: PSOs include this tag with the value"y"to say the domain is a PSD 👑 If a record with this tag set to"y"shows up during policy discovery, that info decides which Organizational Domain and DMARC Policy Domain apply to the message.n: The DMARC Policy Record is published for a domain that is NOT a PSD, but it IS the Organizational Domain for itself and its subdomains.u: The default. The record is published for a domain that isn't a PSD, and it may or may not be the Organizational Domain for itself and its subdomains. To figure out the Organizational Domain here, use the mechanism in Section 4.10.
rua(Addresses for aggregate feedback reports; comma-separated plain-text list of DMARC Reporting URIs; OPTIONAL) 📬 If this is there, the Domain Owner is asking Mail Receivers to send aggregate feedback reports (as defined in [RFC9990]) to the URIs listed. Any valid URI is allowed. A Mail Receiver that sends aggregate feedback reports MUST supportmailto:URIs, meaning it has to be able to send a DMARC report by email. If the tag isn't provided, Mail Receivers MUST NOT generate aggregate feedback reports for the domain. URIs with schemes that Mail Receivers don't support MUST be ignored. [RFC9990] also talks about what to think about when a URI's domain name is different from the domain publishing the record. See Section 11.6 for more on that.ruf(Addresses for message-specific failure info; comma-separated plain-text list of DMARC URIs; OPTIONAL) 🔍 If this is there, the Domain Owner is asking Mail Receivers to send detailed failure reports about messages that fail DMARC in specific ways (see thefotag above) to the URIs listed. Which format applies depends on thefovalue, and it's described in [RFC9991], [RFC6651], and [RFC6652]. Any valid URI is allowed. A Mail Receiver that sends failure reports MUST supportmailto:URIs, so it can send message-specific failure info by email. If the tag isn't provided, Mail Receivers MUST NOT generate failure reports for the domain. URIs with unsupported schemes MUST be ignored. [RFC9990] discusses what to consider when a URI's domain name differs from the domain advertising the policy. See Section 11.6 for additional considerations.sp(Domain Owner Assessment Policy for all subdomains of the given Organizational Domain; plain-text; OPTIONAL) 🌸 This is the message handling preference of the Domain Owner or PSO for mail from an existing subdomain of the Organizational Domain that fails DMARC validation. It ONLY covers existing subdomains of the message's Organizational Domain in the DNS hierarchy, not the Organizational Domain itself. The syntax matchesp. If bothspis absent ANDnpis either absent or doesn't apply, the policy frompMUST be applied to subdomains. Heads up:spgets ignored for DMARC Policy Records published on subdomains of Organizational Domains and PSDs, because of how DMARC policy discovery works (Section 4.10.1) 🙃t(DMARC policy test mode; plain-text; OPTIONAL; default is"n".) 🧪 For the Author Domain this record applies to,ttells whoever is doing DMARC validation whether the Domain Owner actually wants the policy fromp,sp, and/ornpapplied. It has no effect on DMARC report generation, and it does nothing if the policy (p,sp, ornp) isnone. See Appendix A.6 for more on using this tag. Possible values:y: This asks the validator NOT to apply the policy, but to use any special handling rules it has instead, like rewriting the RFC5322.From header field (see Appendix A.6). The Domain Owner is testing its DMARC assessment policy and expects the policy applied to failing messages to be one level lower than the specified one. So if the policy isquarantineandtisy, thennonegets applied to failing messages. If the policy isrejectandtisy, thenquarantinegets applied to failing messages, no matter what other special handling rules thet=ysetting might trigger.n: The default. This is a request to apply the Domain Owner Assessment Policy as specified to any message that gets a DMARC "fail" result.
v(Version; plain-text; REQUIRED) 🎀 This identifies the record you got back as a DMARC Policy Record.vMUST be the first tag in the list. The value is case sensitive, and the only valid value is"DMARC1". Ifvisn't first, it's missing, or its value isn't"DMARC1", then the entire record MUST be ignored 💀
4.8. Formal Definition 💅
Okay bestie, this is the part where the grammar gets serious 🤓 Every DMARC Policy Record MUST comply with the formal definition in this section. Unknown tags MUST be ignored, no debate. If the rest of the record has syntax errors, those MUST be discarded in favor of default values (if there are any) or just ignored outright 💀
Because unknown tags MUST be ignored, adding a new tag to the registered list does not, on its own, need a new version of DMARC (so the "v" tag's value stays the same) 🦋 But changing any existing tag DOES require a new version of DMARC 🫶
Here's the formal definition of the DMARC Policy Record format, written in ABNF syntax as described in [RFC5234] and [RFC7405] 🎀
dmarc-uri = URI
; "URI" is imported from [RFC3986];
; commas (ASCII 0x2C) and exclamation
; points (ASCII 0x21) MUST be
; encoded
obs-dmarc-uri = dmarc-uri obs-dmarc-report-size
; Obsolete syntax, reporters should ignore the
; obs-dmarc-report-size if it is found in a
; DMARC Policy Record.
obs-dmarc-report-size = "!" 1*DIGIT [ "k" / "m" / "g" / "t" ]
dmarc-sep = *WSP ";" *WSP
equals = *WSP "=" *WSP
dmarc-record = dmarc-version *(dmarc-sep dmarc-tag) [dmarc-sep]
dmarc-tag = 1*ALPHA equals 1*dmarc-value
; any printing characters but semicolon
dmarc-value = %x20-3A / %x3C-7E
dmarc-version = "v" equals %s"DMARC1" ; case sensitive
; specialized syntax of DMARC values
dmarc-request = "none" / "quarantine" / "reject"
dmarc-yorn = "y" / "n"
dmarc-psd = "y" / "n" / "u"
dmarc-rors = "r" / "s"
dmarc-urilist = (dmarc-uri / obs-dmarc-uri)
*(*WSP "," *WSP (dmarc-uri / obs-dmarc-uri))
dmarc-fo = ("0" / "1") *(":" dmarc-afrf)
/ dmarc-afrf [":" ("0" / "1")] [":" dmarc-afrf]
/ *(dmarc-afrf ":") ("0" / "1")
dmarc-afrf = "d" / "s"
; each may appear at most once in dmarc-foEach dmarc-tag has a dmarc-value whose syntax depends on the tag name 🧁 The table below is your cheat sheet for which ABNF rule goes with which tag:
+==========+===============+
| Tag Name | Value Rule |
+==========+===============+
| p | dmarc-request |
+----------+---------------+
| t | dmarc-yorn |
+----------+---------------+
| psd | dmarc-psd |
+----------+---------------+
| np | dmarc-request |
+----------+---------------+
| sp | dmarc-request |
+----------+---------------+
| adkim | dmarc-rors |
+----------+---------------+
| aspf | dmarc-rors |
+----------+---------------+
| rua | dmarc-urilist |
+----------+---------------+
| ruf | dmarc-urilist |
+----------+---------------+
| fo | dmarc-fo |
+----------+---------------+
Table 2: Tag Names and
Values4.9. Flow Diagram 🌸
Time for the big picture! Here's how a message travels through a DMARC-aware system 👀
+---------------+ +--------------------+
| Author Domain |< . . . . . . . . . . . . | Return-Path Domain |
+---------------+ . +--------------------+
| . ^
V V .
+-----------+ +--------+ +----------+ v
| MSA |<***>| DKIM | | DMARC | +----------+
| Service | | Signer | | Validator|<***>| SPF |
+-----------+ +--------+ +----------+ * | Validator|
| ^ * +----------+
| * *
V v *
+------+ (~~~~~~~~~~~~) +------+ * +----------+
| sMTA |------->( other MTAs )----->| rMTA | **>| DKIM |
+------+ (~~~~~~~~~~~~) +------+ | Validator|
| +----------+
| ^
V .
+-----------+ .
+---------+ | MDA | v
| User |<--| Filtering | +-----------+
| Mailbox | | Engine | | DKIM |
+---------+ +-----------+ | Signing |
| Domain(s) |
+-----------+
MSA = Mail Submission Agent
MDA = Mail Delivery Agent
sMTA = sending MTA
rMTA = receiving MTASo the vibe is: dashed lines (like -->) are the actual message flow ✈️ Dotted lines (like < . . >) are DNS queries grabbing the message policy for the supported auth schemes 🔍 And starred lines (like <**>) are the data swaps between the message-handling modules and the message authentication modules 💜
Put simply, when a message hits a DMARC-aware rMTA, a DNS query kicks off to check whether a DMARC Policy Record exists that applies to the Author Domain 👑 If one is found, the rMTA uses the results of the SPF and DKIM validation checks to work out the DMARC validation status. That status can then shape the handling decision the recipient's mail system makes 🎀
For more on what each party should actually do, check out Sections 5.1 and 5.3 🌈
4.10. DNS Tree Walk 🌳
Okay, this section is giving treasure hunt energy 🗺️ An Organizational Domain (Section 3.2.14) has two jobs, depending on the context:
- The Organizational Domain of the Author Domain (Section 3.2.2) sets up the DMARC Policy Record (Section 3.2.6) for that domain when there's no DMARC Policy Record published specifically for the Author Domain (see Section 4.10.1).
- The Organizational Domains of an Authenticated Identifier (Section 3.2.1) and the Author Domain get compared to figure out Identifier Alignment between the two (see Section 4.10.2).
Some history tea ☕ [RFC7489] defined an Organizational Domain as "The domain that was registered with a domain name registrar". It talked about using a Public Suffix List (PSL) as the authoritative list of parent domains for Organizational Domains, and it described a method for finding the Organizational Domain of an Author Domain or an Authenticated Identifier. BUT it didn't require Mail Receivers to use any specific PSL (it did suggest the one at <https://publicsuffix.org/>), and it gave no guidance on how often Mail Receivers participating in DMARC should retrieve the PSL 😬 It also admitted that Mail Receivers picking different PSLs could cause interoperability issues, and suggested that if a more reliable and secure way to find the Organizational Domain came along, that way should replace relying on a PSL.
This update gives Domain Owners more flexibility 🦋 That's especially helpful for big, complicated organizations that want decentralized management of their DNS and their DMARC Policy Records. Instead of just leaning on a PSL to find an Organizational Domain, this update defines a discovery technique nicknamed the "DNS Tree Walk". The goal of any DNS Tree Walk is to find a valid DMARC Policy Record, and using it to determine an Organizational Domain means DMARC Policy Records can be published at multiple points in the namespace ✨
Now the catch 🙈 The DNS Tree Walk makes the Mail Receiver send a series of DNS queries, so a sneaky Domain Owner could send mail with Author Domains that have tens or even hundreds of labels, just to run a denial-of-service attack on the Mail Receiver. To stop that abuse of the DNS, there's a shortcut built in: Author Domains with more than eight labels don't result in more than eight DNS queries 🛡️ When this was published, observed data showed Author Domains with up to seven labels were in use, so eight was picked as the query limit. That leaves room for future namespace expansion without needing to update this document 🌱
Here are the generic steps for a DNS Tree Walk 🧚
- Query the DNS for a TXT record that matches the format of a DMARC Policy Record at the starting point for the Tree Walk. The starting point depends on the ultimate target of the DNS Tree Walk, and Sections 4.10.1 and 4.10.2 describe the possible starting points. A possibly empty set of records is returned.
- Records that don't start with a "v" tag identifying the current version of DMARC get discarded. If multiple DMARC Policy Records come back for a single target, they're all discarded. If a single record remains and it contains a
psd=norpsd=ytag, stop. - Break the subject DNS domain name into an ordered set of labels. Assign the count of labels to "x", and number the labels from right to left. For example, for
a.mail.example.com, "x" gets the value 4, "com" is label 1, "example" is label 2, "mail" is label 3, and so on. - If
x < 8, remove the left-most (highest-numbered) label from the subject domain. Ifx >= 8, remove the left-most (highest-numbered) labels from the subject domain until 7 labels remain. The resulting DNS domain name is the new target for the next lookup. - Query the DNS for a DMARC Policy Record at the DNS domain name matching this new target. A possibly empty set of records is returned.
- Records that don't start with a "v" tag identifying the current version of DMARC get discarded. If multiple DMARC Policy Records come back for a single target, they're all discarded. If a single record remains and it contains a
psd=norpsd=ytag, stop. - Determine the target for the next query by removing the left-most label from the target of the previous query. Repeat steps 5, 6, and 7 until the process stops or there are no more labels left.
Let's see it in action 👀 For a message with the random Author Domain a.b.c.d.e.f.g.h.i.j.mail.example.com, a full DNS Tree Walk would need these eight queries to potentially find the DMARC Policy Record or Organizational Domain:
_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com_dmarc.g.h.i.j.mail.example.com_dmarc.h.i.j.mail.example.com_dmarc.i.j.mail.example.com_dmarc.j.mail.example.com_dmarc.mail.example.com_dmarc.example.com_dmarc.com
Eight queries, max, no matter how many labels the domain has 💅 Keep going, the next part is coming up 🩷
4.10.1. DMARC Policy Discovery 🔍
okay so the DMARC Policy Record that gets applied to an email message is whichever one is found at any of these spots, ranked from highest preference to lowest:
- The Author Domain
- The Organizational Domain of the Author Domain
- The PSD of the Author Domain
Policy discovery starts with a query for a valid DMARC Policy Record at the name you get by sticking the label _dmarc in front of the Author Domain of the message being evaluated. If a valid record shows up there, that's the one that gets applied 💅. But that doesn't automatically mean the Author Domain is the Organizational Domain for Identifier Alignment checks, bestie. Whether it is depends on the value of the psd tag, if it's there, or on some conditions described in Section 4.10.2.
If that first query doesn't find a valid record, do a DNS Tree Walk to find the Author Domain's Organizational Domain or its Public Suffix Domain. The starting point for that walk is figured out like this:
- If the Author Domain has eight or fewer labels, the starting point is the immediate parent domain of the Author Domain.
- Otherwise, the starting point is the name you get by shortening the Author Domain the way it's described starting in step 3 of Section 4.10.
If the DMARC Policy Record being applied is the one for the Author Domain, the Domain Owner Assessment Policy comes from the p tag of that record 🎀.
If the DMARC Policy Record being applied is the one for either the Organizational Domain or the PSD, and the Author Domain is a subdomain of that domain, then the Domain Owner Assessment Policy comes from the sp tag (if there is one) when the Author Domain exists, or from the np tag (if there is one) when the Author Domain does not exist. If there are no applicable sp or np tags, the p tag policy is used for subdomains ✨.
If a retrieved DMARC Policy Record doesn't have a valid p tag, or it has an sp or np tag that isn't valid, then:
- If a
ruatag is present and contains at least one syntactically valid reporting URI, the Mail Receiver MUST act as if a record containingp=nonewas retrieved and continue processing. - Otherwise, the Mail Receiver applies no DMARC processing to this message.
If the set produced by the DNS Tree Walk contains no DMARC Policy Record (i.e., any indication that there is no such record as opposed to a transient DNS error), Mail Receivers MUST NOT apply the DMARC mechanism to the message. 🙅♀️
Handling DNS errors while querying for the DMARC Policy Record is up to the Mail Receiver. For example, to keep mail flowing with minimal disruption, transient errors could result in delivery of the message ("fail open"). Or they could result in the message being temporarily rejected (i.e., an SMTP 4yx reply), which invites the sending MTA to try again after the condition has possibly cleared, so a definite DMARC conclusion can be reached ("fail closed") 🥺.
Note: PSD policy is not used for Organizational Domains that have published a DMARC Policy Record. Specifically, this is not a mechanism to provide feedback addresses (rua/ruf) when an Organizational Domain has declined to do so. 🚫
4.10.2. Identifier Alignment Evaluation 💜
It may be necessary to do multiple DNS Tree Walks to figure out whether an Authenticated Identifier and an Author Domain are in alignment, meaning they either have the same Organizational Domain (relaxed alignment) or they're identical (strict alignment). DNS Tree Walks done to discover an Organizational Domain for Identifier Alignment Evaluation might start at any of these spots:
- The Author Domain of the message being evaluated.
- The SPF-Authenticated Identifier, if there is an SPF "pass" result for the message being evaluated.
- Any DKIM-Authenticated Identifier, if one or more DKIM "pass" results exist for the message being evaluated.
There's no need to do Identifier Alignment Evaluations under any of these conditions 🙌:
- The Author Domain and the Authenticated Identifier(s) are all the same domain, and there's a DMARC Policy Record published for that domain. In this case, that common domain is treated as the Organizational Domain. For example, if the common domain is
mail.example.com, and there's a valid DMARC Policy Record published at_dmarc.mail.example.com, thenmail.example.comis the Organizational Domain. - No applicable DMARC Policy Record is discovered for the Author Domain. In this case, the DMARC mechanism doesn't apply to the message in question.
- The DMARC Policy Record for the Author Domain indicates strict alignment. In this case, a simple string comparison of the Author Domain and the Authenticated Identifier(s) is all that's required.
To discover the Organizational Domain for a domain, do the DNS Tree Walk described in Section 4.10 as needed for any of the domains in question.
For each Tree Walk that retrieved valid DMARC Policy Records, pick the Organizational Domain from the domains that had valid DMARC Policy Records retrieved, going from the longest to the shortest:
- If a valid DMARC Policy Record contains the
psdtag set ton(psd=n), this is the Organizational Domain, and the selection process is complete. - If a valid DMARC Policy Record, other than the one for the domain where the Tree Walk started, contains the
psdtag set toy(psd=y), the Organizational Domain is the domain one label below this one in the DNS hierarchy, and the selection process is complete. For example, if during a Tree Walk a DMARC Policy Record is queried for first at_dmarc.mail.example.comand then at_dmarc.example.com, and a valid DMARC Policy Record containingpsd=yis found at_dmarc.example.com, thenmail.example.comis the domain one label belowexample.comin the DNS hierarchy, so it's the Organizational Domain 🌸. - Otherwise, select the DMARC Policy Record found at the name with the fewest number of labels. This is the Organizational Domain, and the selection process is complete.
If this process doesn't determine the Organizational Domain, then the initial target domain is the Organizational Domain.
Let's do some examples! 🧚 Given the starting domain a.mail.example.com, a search for the Organizational Domain would need a series of DNS queries for DMARC Policy Records, starting with _dmarc.a.mail.example.com and finishing with _dmarc.com. If there are DMARC Policy Records published at _dmarc.mail.example.com and _dmarc.example.com, but not at _dmarc.a.mail.example.com or _dmarc.com, then the Organizational Domain for this domain would be example.com.
Another one: given the starting domain a.mail.example.com, if a search for the Organizational Domain turns up a DMARC Policy Record at _dmarc.mail.example.com with psd=n, then the Organizational Domain for this domain would be mail.example.com.
Last one! 🦋 Given the starting domain a.mail.example.com, if a search for the Organizational Domain only yields a DMARC Policy Record at _dmarc.com, and that record contains the tag psd=y, then the Organizational Domain for this domain would be example.com.
5. DMARC Participation 🎀
This section describes the actions for taking part in DMARC for each of three unique entities -- Domain Owners, PSOs, and Mail Receivers.
5.1. Domain Owner Actions 👑
A Domain Owner (Section 3.2.7) who wants to fully take part in DMARC will:
- Publish a DMARC Policy Record (Section 3.2.6) to cover each Author Domain (Section 3.2.2) and corresponding Organizational Domain (Section 3.2.14) that DMARC validation should apply to;
- Send email that produces at least one -- preferably two -- Authenticated Identifiers (Section 3.2.1) that align with the Author Domain;
- Receive and monitor the content of DMARC aggregate reports;
- Correct authentication shortcomings in mail making authorized use of its domains.
The following sections describe how to make this happen 🫶.
5.1.1. Publish an SPF Record for an Aligned Domain 🌈
To set up SPF for DMARC, the Domain Owner MUST send mail that has an RFC5321.MailFrom domain that will produce an SPF-Authenticated Identifier (Section 4.4.2) that has Identifier Alignment (Section 4.4) with the Author Domain.
5.1.2. Configure Sending System for DKIM Signing Using an Aligned Domain ✨
To set up DKIM for DMARC, the Domain Owner MUST send mail that has a DKIM Signing Domain (Section 3.2.3) that will produce a DKIM-Authenticated Identifier (Section 4.4.1) that has Identifier Alignment (Section 4.4) with the Author Domain.
5.1.3. Set Up a Mailbox to Receive Aggregate Reports 📬
Proper consumption and analysis of DMARC aggregate reports are essential to any successful DMARC deployment for a Domain Owner. DMARC aggregate reports, which are defined in [RFC9990], contain valuable data for the Domain Owner, showing sources of mail using the Author Domain 🔍.
5.1.4. Publish a DMARC Policy Record for the Author Domain and Organizational Domain 💖
Once SPF, DKIM, and the aggregate reports mailbox are all in place, it's time to publish a DMARC Policy Record. For best results, Domain Owners usually start with p=none (see Section 5.1.5) with the rua tag containing a URI that references the mailbox created in the previous step. This is commonly referred to as putting the Author Domain into Monitoring Mode (Section 3.2.12) 👀. If the Organizational Domain is different from the Author Domain, a record also needs to be published for the Organizational Domain.
5.1.5. Collect and Analyze Reports 📊
The reason for starting at p=none is to make sure nothing's been missed in the initial SPF and DKIM deployments. In all but the most trivial setups, a Domain Owner can overlook a server here or be unaware of a third-party sending agreement there. Starting at p=none, therefore, takes advantage of DMARC's aggregate reporting function, with the Domain Owner using the reports to audit its own mail streams' authentication configurations 🧐.
While it is possible for a human to read aggregate reports, they are formatted in such a way that it is recommended that they be machine-parsed, so setting up a mailbox involves more than just creating that mailbox. Many third-party services exist that will process DMARC aggregate reports, or the Domain Owner can create its own set of tools. No matter which method is chosen, being able to consume these reports and parse the data in them will go a long way toward a successful deployment 🔥.
5.1.6. Remediate Unaligned or Unauthenticated Mail Streams ✨
okay so, DMARC aggregate reports can show the Domain Owner mail streams using the Author Domain that aren't passing DMARC validation 😬. Some of these are sketchy, like spoofing or other attempted abuse 🚩. Others are totally legit, like a mail stream run by an agent of the Domain Owner that's failing only because its Authenticated Identifiers are unaligned or missing entirely 🥺. For those legit streams, these shortcomings MUST be addressed before the Domain Owner tries to publish a Domain Owner Assessment Policy (Section 3.2.8) of Enforcement (Section 3.2.9) for the Author Domain. No skipping this step, periodt 💅
5.1.7. Decide Whether to Update Domain Owner Assessment Policy to Enforcement 🎀
Once the Domain Owner is satisfied that it's properly authenticating all of its mail, it's finally time to decide whether it's appropriate to change its Domain Owner Assessment Policy to Enforcement (Section 3.2.9) 🥹. Depending on how often it sends mail, it may take many months of reading DMARC aggregate reports before the Domain Owner is actually sure that everything is authenticated. The decision on which "p" value to use depends on its needs, so no one-size-fits-all answer here 💖
Before deciding, it's really important to understand the interoperability issues involved and the problems that can happen for mailing lists and for delivery of legitimate mail 🧐. Those issues are discussed in detail in Section 7.4
5.1.8. A Note on Large, Complex Organizations and Decentralized DNS Management 🏢
Big, complicated organizations often go with a decentralized model for DNS management 🌐. That means the central IT organization delegates management of a subtree of the namespace to a local department. In that setup, the "psd" tag lets those local departments declare any arbitrary node in their subtree as an Organizational Domain 🦋. They do this by publishing a DMARC Policy Record at that node with the "psd" tag set to "n" (psd=n). Departments might want their own Organizational Domains for reasons like wanting different policy settings or reporting URIs than the DMARC Policy Record at the apex domain has ✨
Such configurations would work in theory, and they might involve domain names with lots of labels that reflect the structure of the organization. For example:
- Apex domain (DMARC Policy Record published here):
example.com - Zone cut domain (DMARC Policy Record with "psd=n" published here):
b.c.d.e.f.g.example.com - Author Domain:
mail.a.b.c.d.e.f.g.example.com
However, Domain Owners should be aware that, because of the anti-abuse protections built into the DNS Tree Walk (Section 4.10), the DMARC Policy Record published at the zone cut domain in this example will never be discovered 😭. A Mail Receiver performing a Tree Walk would only query these names:
_dmarc.mail.a.b.c.d.e.f.g.example.com_dmarc.c.d.e.f.g.example.com_dmarc.d.e.f.g.example.com_dmarc.e.f.g.example.com_dmarc.f.g.example.com_dmarc.g.example.com_dmarc.example.com_dmarc.com
To avoid this mess, Domain Owners who want a specific DMARC Policy Record applied to a given Author Domain (Section 3.2.2) that's longer than eight labels MUST publish a DMARC Policy Record at that domain's location in the DNS namespace 🙌. That's because those records are always queried by Mail Receivers that participate in DMARC before the Tree Walk begins. In the example above, that means publishing a DMARC Policy Record at the name "_dmarc.mail.a.b.c.d.e.f.g.example.com." 🫶
5.2. PSO Actions 🧚
On top of the DMARC Domain Owner actions, if a PSO (Section 3.2.16) publishes a DMARC Policy Record, it MUST include the "psd" tag (see Section 4.7) with a value of "y" (psd=y) 💜
5.3. Mail Receiver Actions 📬
Mail Receivers (Section 3.2.11) that want to fully participate in DMARC will apply the DMARC mechanism to inbound email messages whenever a DMARC Policy Record (Section 3.2.6) exists that applies to the Author Domain (Section 3.2.2). They'll also send aggregate feedback reports to Domain Owners that ask for them 💌. Mail Receivers might also send failure reports to Domain Owners that request those too. The following sections explain how to pull this off 🌸
The steps for applying the DMARC mechanism to an email message can happen during the SMTP transaction, and they should do so if the Mail Receiver plans to honor Domain Owner Assessment Policies (Section 3.2.8) that are at the Enforcement (Section 3.2.9) state 🔥
Lots of Mail Receivers run one or both of the underlying Authentication Mechanisms (Section 4.3) on inbound messages even when there's no DMARC Policy Record for the Author Domain of a given message, or when the Mail Receiver isn't participating in DMARC at all 🤷♀️. Nothing in this section is meant to suggest that the underlying authentication mechanisms should only be run by Mail Receivers that participate in DMARC 💅
5.3.1. Extract Author Domain 🔍
Once the email message has been transmitted to the Mail Receiver, the Mail Receiver extracts the domain in the RFC5322.From header field as the Author Domain 📨. If that domain is a U-label, it MUST be converted to an A-label, as described in Section 2.3 of [RFC5890], before any further processing 🌈
If zero domains or more than one domain is extracted from the RFC5322.From header field, then DMARC validation isn't possible and the process terminates 💀. If more than one domain is retrieved, the Mail Receiver MAY choose to go forward with DMARC validation anyway 🤔. See Section 11.5 for further discussion.
5.3.2. Determine If the DMARC Mechanism Applies 🤔
If precisely one Author Domain exists for the message, then perform the step described in "DMARC Policy Discovery" (Section 4.10.1) to figure out whether the DMARC mechanism applies 🧐. If a DMARC Policy Record (Section 3.2.6) isn't discovered during this step, then the DMARC mechanism doesn't apply and DMARC validation terminates for the message 🛑
5.3.3. Determine If Authenticated Identifiers Exist 🪪
For each authentication mechanism underlying DMARC, do the required check to determine whether an Authenticated Identifier (Section 3.2.1) exists for the message, as long as that check hasn't already been done ✅. The results from each check must be preserved for later use, as follows:
- For SPF, the preserved results MUST include "pass" or "fail". If the result is "fail", it SHOULD include information about the reasons for failure, if that's available. The results MUST further include the domain name used to complete the SPF check 🫧.
- For DKIM signature validation checks, the results MUST include "pass" or "fail" for each signature checked. If the result is "fail", it SHOULD include information about the reasons for failure. The results MUST further include the value of the "d" and "s" tags from each checked DKIM signature 🔐.
5.3.4. Conduct Identifier Alignment Checks If Necessary 🧩
For each Authenticated Identifier found in the message, the Mail Receiver checks whether that identifier is aligned (Section 4.10.2) with the Author Domain 💞
5.3.5. Determine DMARC "Pass" or "Fail" 🏁
If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check 🎉
If no Authenticated Identifiers exist for the domain, or none of them align with the Author Domain, the message is considered to fail the DMARC mechanism check 😤
5.3.6. Apply Policy If Appropriate ⚖️
Email messages that fail the DMARC mechanism check get handled according to the Mail Receiver's local policies 🙃. Those local policies may take into account the Domain Owner Assessment Policy for the Author Domain, at the Mail Receiver's discretion.
If one or more DNS queries needed to perform DMARC validation on the message don't complete because of temporary or permanent DNS errors, the message can't be considered to pass or fail the DMARC mechanism check 🥴. In that case, the Domain Owner Assessment Policy can't be applied to the message, and any other handling decisions are left to the discretion of the Mail Receiver.
See Section 7.2 for further discussion of topics regarding rejecting messages 🚫
5.3.7. Store Results of DMARC Processing 💾
If the Mail Receiver intends to send aggregate feedback reports and/or failure reports, then the results from applying the DMARC mechanism MUST be preserved so they can be presented back to the Domain Owner in the form of those reports 📊. Section 4.7 and [RFC9990] discuss aggregate feedback reports.
5.3.8. Send Aggregate Reports 📤
To make DMARC as useful as possible across the email ecosystem, Mail Receivers SHOULD generate and send aggregate reports at least once every 24 hours ⏰. These reports give Domain Owners insight into all mail streams using Author Domains under their control, and they help the Domain Owner decide whether and when to move from Monitoring Mode (Section 3.2.12) to Enforcement (Section 3.2.9) 🦋
The most common reasons a Mail Receiver opts out of sending aggregate reports are resource constraints, local policy against sharing data, and concerns about user privacy 🔒
5.3.9. Optionally Send Failure Reports 🎀
Per-message failure reports can be really useful for a Domain Owner, whether for debugging deployments or for analyzing attacks, so Mail Receivers MAY choose to send them 🕵️♀️. Experience has shown, though, that Mail Receivers who are rightly concerned about protecting user privacy have either heavily redacted the information in those reports (which can hinder their usefulness) or not sent them at all 🙈. See [RFC9991] for further information.
5.4. Policy Enforcement Considerations 💅
Okay bestie, the final handling of any message is always a matter of local policy 🧚, so the call is left to the Mail Receiver's discretion. Their decision, fr fr.
A DMARC pass only tells you that the Author Domain (Section 3.2.2) was validated for that message as authorized by the Domain Owner (Section 3.2.7). That authorization is NOT a stamp of approval on the message or the Domain Owner, not even a little bit 🙈. So Mail Receivers MAY choose to reject or quarantine a message even when it passes the DMARC validation check. Mail Receivers are also encouraged to keep anti-abuse tech running to fight DMARC-enabled abuse 🛡️.
Mail Receivers MAY choose to accept email that fails the DMARC validation check, even if the published Domain Owner Assessment Policy is "reject" 🤷♀️. Here's the tea: because of the stuff in [RFC7960] and Section 7.4 of this document, Mail Receivers SHOULD NOT reject messages just because of a published "reject" policy. Instead, they should use other knowledge and analysis, so they don't end up rejecting legit messages sent in ways DMARC can't describe, or harming how mailing lists work, and so on 💖.
If a Mail Receiver chooses not to honor the published Domain Owner Assessment Policy just to improve interoperability among mail systems, it may increase the likelihood of accepting abusive mail 😬. At a minimum, Mail Receivers SHOULD add the Authentication-Results header field (see [RFC8601]), and it is RECOMMENDED when delivering messages that fail the DMARC validation check ✨.
When Mail Receivers deviate from a published Domain Owner Assessment Policy during message processing, they SHOULD make the fact of and reason for the deviation available to the Domain Owner through feedback reporting. Specifically, that means using the "PolicyOverride" feature of the aggregate report defined in [RFC9990] 📬.
To let Domain Owners get DMARC feedback without messing with existing mail processing, discovered policies of p=none MUST NOT modify existing mail handling processes 🌸. Don't you dare change the flow, babe.
6. DMARC Feedback 🦋
DMARC feedback is described in [RFC9990].
As an operational note for PSOs: feedback for non-existent domains can be desirable and useful, just like it can be for Organizational Domains 📊. So both kinds of entities should consider including rua= tags in any DMARC Policy Records they publish for themselves. See Section 10 for the privacy considerations 🔒.
7. Other Topics 🌈
This section talks about some choices made while developing DMARC, mostly so the history gets recorded for the record 📜.
7.1. Issues Specific to SPF
Even though DMARC doesn't inherently change the semantics of an SPF policy record, lax enforcement of those policies in the past led lots of people to publish super broad records with a ton of huge network ranges 😭. Domain Owners (Section 3.2.7) are strongly encouraged to carefully review their SPF records, so they know which networks are authorized to send on their behalf before they publish a DMARC Policy Record. Domain Owners should also review their SPF records periodically to make sure the authorization still matches the domain's current needs 🧹.
SPF was meant to be implemented early in the SMTP transaction. That means a message can fail SPF validation before any message content is transmitted 💀. So some Mail Receiver architectures might run SPF before any DMARC operations happen. An SPF hard fail (-) prefix on a sender's SPF mechanism, like -all, could cause a message to be rejected early in the SMTP transaction, before any DMARC processing takes place, if the message fails SPF checks. Domain Owners who use -all to end their SPF records should be aware of this 👀. They should understand that messages which might otherwise pass DMARC thanks to an aligned DKIM-Authenticated Identifier (Section 4.4.1) could be rejected solely because of an SPF fail.
Also, messages rejected early in the SMTP transaction never show up in aggregate DMARC reports, since the transaction never gets to the DATA phase. So the RFC5322.From domain never gets revealed, and its DMARC policy never gets discovered 🫥. Domain Owners and Mail Receivers (Section 3.2.11) can check out [M3SPF] and [M3AUTH] for more discussion of this topic, plus best practices for publishing SPF records and for when to reject based solely on an SPF failure 📚.
7.2. Rejecting Messages
The DMARC mechanism calls for rejecting a message during the SMTP session in certain circumstances 🚫. That's preferable to generating a Delivery Status Notification [RFC3464], because fraudulent messages caught and rejected by DMARC would otherwise trigger the super annoying generation of failure reports that go back to the RFC5321.MailFrom address 🙄.
This synchronous rejection is typically done in one of two ways:
- A "full rejection", where the SMTP server issues a 5xy reply code to the DATA command to tell the SMTP client the transaction failed. The SMTP client is then responsible for generating a notification that delivery failed (see Section 4.2.5 of [RFC5321]) 📨.
- A "silent discard", where the SMTP server returns a 2xy reply code, implying to the client that delivery (or at least relay) was successfully completed, and then just quietly throws the message away with no further action 🤫.
Each of these has a cost 💸. A silent discard can help prevent backscatter, but it also means the SMTP server has to be programmed to give a false result, which can confuse external debugging efforts 😵💫.
The text portion of the SMTP reply can matter too. For example, when rejecting a message, revealing the reason might give an attacker enough info to dodge those efforts on a later attempt. It might also help a legit client figure out the source of some local issue that caused the rejection 🕵️♀️.
In that second case, when doing an SMTP rejection, a clear hint can really help resolve issues ✨. A Mail Receiver (Section 3.2.11) might say in plain text why it rejected by using the word "DMARC" somewhere in the reply text. For example:
550 5.7.1 Email rejected per DMARC policy for example.comLots of systems can scan SMTP reply text to figure out the nature of a rejection 🤖. So a machine-detectable reason for rejection means automated systems can properly address the problems causing rejections. Iconic, honestly 🧠.
If a Mail Receiver decides to defer delivery because it can't retrieve or apply the DMARC policy, that's best done with a 4xy SMTP reply code ⏳.
7.3. Interoperability Issues
DMARC limits which end-to-end scenarios can achieve a "pass" result 🚧.
Because DMARC relies on SPF [RFC7208] and/or DKIM [RFC6376] to achieve a "pass", their limitations apply too 🫠.
Issues specific to using policy mechanisms alongside DKIM are discussed further in [RFC6377], particularly Section 5.2 🧩.
Mail sent by authorized, independent third parties might not be sent with Identifier Alignment, which also prevents a "pass" result 📭. A Domain Owner can use DMARC aggregate reports to spot this mail and take steps to address the authentication shortcomings 🔍💜.
7.4. Interoperability Considerations 🦋
okay so the big drama here is "Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows" [RFC7960] 📚. The gist is that p=reject can be super incompatible with indirect message flows like "alumni forwarders", role-based email aliases, and mailing lists across the Internet, and it can cause interop problems there. 💀
Picture a bank that only sends targeted messages to account holders. Those account holders gave the bank addresses like jones@alumni.example.edu (an address that relays messages to another address with a real mailbox) or finance@association.example (a role-based address that does similar relaying for the current head of finance at the association). When that mail reaches the actual mailbox, it will most likely fail SPF checks unless the RFC5321.MailFrom address is rewritten by the relaying MTA, because the incoming IP address will be that of example.edu or association.example and not an IP address authorized by the originating RFC5321.MailFrom domain. DKIM signatures will generally remain valid in these relay situations. 🌸
It is therefore critical that domains that publish "p=reject" MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages. 🔥
Now for the domains with general users who send routine email. Those that publish a Domain Owner Assessment Policy (Section 3.2.8) of p=reject are likely to create significant interoperability issues. Like, if users in those domains post to mailing lists on the Internet, those messages can cause significant operational problems for the mailing lists and for the subscribers to those lists, as explained below and in [RFC7960]. 😭
It is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of "p=reject". Any such domains wishing to publish "p=reject" SHOULD first take advantage of DMARC aggregate report data for their domain to determine the possible impact to their users, first by publishing "p=none" for at least a month, followed by publishing "p=quarantine" for an equally long period of time, and comparing the message disposition results. Domains that choose to publish "p=reject" SHOULD implement policies that their users not post to Internet mailing lists and/or inform their users that their participation in mailing lists may be hindered. 🎀
As noted in Section 5.4, Mail Receivers (Section 3.2.11) need to apply more analysis than just DMARC validation in their disposition of incoming messages. An example of the consequences of honoring a Domain Owner Assessment Policy of "p=reject" without further analysis is that rejecting messages that have been relayed by a mailing list can cause the Mail Receiver's users to have their subscriptions to that mailing list canceled by the list software's automated handling of such rejections. It looks to the list manager as though the recipient's email address is no longer working, so the address is automatically unsubscribed. 💔 An example of this scenario, albeit with DKIM Author Domain Signing Practices (ADSP) rather than DMARC, can be found in Section 5.2 of [RFC6377].
It is therefore critical that Mail Receivers MUST NOT reject incoming messages solely on the basis of a "p=reject" policy by the sending domain. Mail Receivers must use the DMARC policy as part of their disposition decision, along with other knowledge and analysis. "Other knowledge and analysis" here might refer to observed sending patterns for properly authenticated mail using the sending domain, content filtering, etc. In the absence of other knowledge and analysis, Mail Receivers MUST treat such failing mail as if the policy were "p=quarantine" rather than "p=reject". 🧚
Failure to understand and abide by these considerations can cause legitimate, sometimes important, email to be rejected. It can also cause operational damage to mailing lists throughout the Internet, and it can result in trouble-desk calls and complaints from the Mail Receiver's employees, customers, and clients. Yikes 🙈
In practice, despite this advice, few Mail Receivers apply any mitigation techniques when receiving indirect mail flows, few organizations consider the effect of DMARC policies on their users' indirect mail, and it is unlikely that any advice in this document will change that. As a result, mail forwarded through mailing lists with unmodified From: header lines is frequently rejected due to a "p=reject" policy. 😩
In the ten years since large consumer mail systems started publishing p=reject policies, mailing list software has all adopted workarounds to make the From: header line DMARC aligned. Some simply use the list's address, while others do per-address modifications intended to be reversible or to allow mail to be forwarded back to the original author, e.g., bob@example.com turned into bob=example.com@user.somelist.example. While these workarounds are far from ideal, they are firmly established and list operators treat them as a fact of life. 🌈
Mail developers have been trying for a decade to invent technical methods to allow mailing lists to continue to work without modifying the From: header line, with a prominent example being the Authenticated Received Chain (ARC) protocol described in [RFC8617]. While work continues, as of this document's publication, none of the methods have become widely used. Should such a technical method achieve widespread adoption in the future, this document can be updated to reflect that. ✨
8. Conformance Requirements for Full DMARC Participation 👑
This document describes the DMARC mechanism and allows Domain Owners and Mail Receivers some leeway in deciding which parts of the mechanism to implement. This section summarizes the requirements for full participation in DMARC, either by Domain Owners or by Mail Receivers. 💅
In order to fully participate in DMARC, Domain Owners:
- MUST send mail so it produces an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain.
- MUST send mail that has a DKIM Signing Domain that will produce a DKIM-Authenticated Identifier that has Identifier Alignment with the Author Domain.
- MUST set up a mailbox to receive aggregate reports and collect and analyze those reports.
- MUST publish a DMARC Policy Record for the Author Domain and the Organizational Domain, if it differs from the Author Domain.
- MUST NOT rely solely on SPF for a DMARC pass if the DMARC policy for the Author Domain is "p=reject".
In order to fully participate in DMARC, Mail Receivers:
- MUST check for the existence of a DMARC Policy Record for the Author Domain of an inbound mail message to determine if the DMARC mechanism applies to that message.
- MUST determine if Authenticated Identifiers exist for the message and preserve the results of those checks for future use in reporting if the DMARC mechanism applies to the message.
- MUST conduct necessary Identifier Alignment checks if the DMARC mechanism applies for the message and Authenticated Identifiers exist.
- MUST use the information from the checks for Authenticated Identifiers to determine if the DMARC validation result is "pass" or "fail" for the message.
- MUST support the "mailto:" URI for sending requested reports.
- SHOULD send aggregate reports on at least a daily basis.
- MUST NOT reject messages solely on the basis of a "p=reject" policy for the Author Domain.
9. IANA Considerations 🌸
This section describes actions completed by IANA.
9.1. Email Authentication Methods Registry Update 🍓
The properties of an email message to be evaluated by an email authentication method have been registered by IANA in the "Email Authentication Methods" registry within the "Email Authentication Parameters" registry group.
Each registration includes the authentication method; the specification that defines the authentication method; the property type (ptype), which is one of the ptype values from the entries in the "Email Authentication Property Types" registry in this same registry group; the property; the value for that property; the status of the property, which is one of "active" or "deprecated"; and its version. The designated expert needs to confirm that the provided specification adequately describes the property and the method for its evaluation and clearly presents how they would be used within the DMARC context by Domain Owners and Mail Receivers. 🔍
IANA has changed the registration procedure from Expert Review to Specification Required [RFC8126] and has listed this document as an additional reference for the registry. IANA has updated the registry as follows: 💜
+======+============+======+========+===============+======+=======+
|Method| Definition |ptype |Property| Value |Status|Version|
+======+============+======+========+===============+======+=======+
|dmarc | RFC 9989 |header|from | The domain |active|1 |
| | | | | portion of | | |
| | | | | the | | |
| | | | | RFC5322.From | | |
| | | | | header field | | |
+------+------------+------+--------+---------------+------+-------+
|dmarc | RFC 9989 |policy|dmarc | The evaluated |active|1 |
| | | | | DMARC policy | | |
| | | | | applied / to | | |
| | | | | be applied | | |
| | | | | after policy | | |
| | | | | options have | | |
| | | | | been | | |
| | | | | processed. | | |
| | | | | Must be | | |
| | | | | "none", | | |
| | | | | "quarantine", | | |
| | | | | or "reject". | | |
+------+------------+------+--------+---------------+------+-------+Table 3: Email Authentication Methods Registry Update ✨
9.2. Email Authentication Result Names Registry Update ✨
okay so DMARC result codes get registered with IANA in the "Email Authentication Result Names" registry, which lives inside the "Email Authentication Parameters" registry group 💅
Each registration has the auth method, the code, the specification that defines the code, and the code's status, which is either "active" or "deprecated". The "Description" field is just there for the reader's benefit 📖 and does NOT show up in the actual IANA registry. The designated expert has to double-check that the spec adequately describes the result code and clearly shows how Domain Owners and Mail Receivers would use it in DMARC. 🫶
IANA switched the registration procedure from Expert Review to Specification Required [RFC8126], and added this document as an extra reference for the registry. IANA updated the registry like this, swapping the [RFC7489] references out for this document:
+===========+===========+===============+========+==================+
| Auth | Code | Specification | Status | Description |
| Method(s) | | | | |
+===========+===========+===============+========+==================+
| dmarc | fail | RFC 9989 | active | A DMARC Policy |
| | | | | Record exists |
| | | | | for the Author |
| | | | | Domain, but no |
| | | | | Authenticated |
| | | | | Identifier with |
| | | | | Identifier |
| | | | | Alignment |
| | | | | exists |
+-----------+-----------+---------------+--------+------------------+
| dmarc | none | RFC 9989 | active | No DMARC Policy |
| | | | | Record exists |
| | | | | for the Author |
| | | | | Domain |
+-----------+-----------+---------------+--------+------------------+
| dmarc | pass | RFC 9989 | active | A DMARC Policy |
| | | | | Record exists |
| | | | | for the Author |
| | | | | Domain, and an |
| | | | | Authenticated |
| | | | | Identifier with |
| | | | | Identifier |
| | | | | Alignment |
| | | | | exists |
+-----------+-----------+---------------+--------+------------------+
| dmarc | permerror | RFC 9989 | active | An error |
| | | | | occurred during |
| | | | | DMARC |
| | | | | evaluation that |
| | | | | is |
| | | | | unrecoverable, |
| | | | | such as the |
| | | | | retrieval of an |
| | | | | improperly |
| | | | | formatted DMARC |
| | | | | Policy Record. |
| | | | | A later attempt |
| | | | | is unlikely to |
| | | | | produce a final |
| | | | | result |
+-----------+-----------+---------------+--------+------------------+
| dmarc | temperror | RFC 9989 | active | An error |
| | | | | occurred during |
| | | | | DMARC |
| | | | | evaluation that |
| | | | | is likely |
| | | | | transient in |
| | | | | nature, such as |
| | | | | a DNS server |
| | | | | being |
| | | | | temporarily |
| | | | | unreachable. A |
| | | | | later attempt |
| | | | | might produce a |
| | | | | final result |
+-----------+-----------+---------------+--------+------------------+Table 4: Email Authentication Result Names Registry Update
9.3. DMARC Tags Registry Update ✨
Tag names used in DMARC Policy Records (as part of "tag-value" pairs) get registered with IANA in the "DMARC Tags" registry, which sits inside the "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" registry group 🎀
Entries only get assigned for values that have been documented in a way that meets the terms of Specification Required, per [RFC8126]. Each registration includes the tag name, the spec that defines the tag, the tag's status, and a short description. The designated expert has to confirm that the spec adequately describes the tag and clearly shows how Domain Owners and Mail Receivers would use it within DMARC. The "status" column is one of the following:
- "active", meaning the tag is in use in current implementations, and its specification is expected to be stable
- "experimental", meaning the tag is relatively new and may be in use in some current implementations but not in others, and its specification is not expected to be stable
- "historic", meaning the tag is considered deprecated and is not expected to be in use in any current implementation
To dodge version compatibility problems, new tags added to the DMARC specification are meant to avoid changing the semantics of existing records when they're processed by implementations that follow earlier specifications. 🦋
IANA has listed this document (rather than [RFC7489]) as the reference for the registry. IANA updated the registry as follows, including the addition of the new "t" registration:
+=======+===========+==========+====================================+
| Tag | Reference | Status | Description |
| Name | | | |
+=======+===========+==========+====================================+
| adkim | RFC 9989 | active | DKIM Identifier Alignment |
| | | | mode |
+-------+-----------+----------+------------------------------------+
| aspf | RFC 9989 | active | SPF Identifier Alignment |
| | | | mode |
+-------+-----------+----------+------------------------------------+
| fo | RFC 9989 | active | Failure reporting options |
+-------+-----------+----------+------------------------------------+
| np | RFC 9989 | active | Requested Domain Owner |
| | | | Assessment Policy for non- |
| | | | existent subdomains |
+-------+-----------+----------+------------------------------------+
| p | RFC 9989 | active | Requested Domain Owner |
| | | | Assessment Policy |
+-------+-----------+----------+------------------------------------+
| pct | [RFC7489] | historic | Sampling rate |
+-------+-----------+----------+------------------------------------+
| psd | RFC 9989 | active | Indicates whether the DMARC |
| | | | Policy Record is published |
| | | | by a Public Suffix Domain |
+-------+-----------+----------+------------------------------------+
| rf | [RFC7489] | historic | Failure reporting format(s) |
+-------+-----------+----------+------------------------------------+
| ri | [RFC7489] | historic | Aggregate Reporting |
| | | | interval |
+-------+-----------+----------+------------------------------------+
| rua | RFC 9989 | active | Reporting URI(s) for DMARC |
| | | | aggregate feedback reports |
+-------+-----------+----------+------------------------------------+
| ruf | RFC 9989 | active | Reporting URI(s) for |
| | | | message-specific DMARC |
| | | | failure reports |
+-------+-----------+----------+------------------------------------+
| sp | RFC 9989 | active | Requested Domain Owner |
| | | | Assessment Policy for |
| | | | subdomains |
+-------+-----------+----------+------------------------------------+
| t | RFC 9989 | active | DMARC policy test mode |
+-------+-----------+----------+------------------------------------+
| v | RFC 9989 | active | DMARC specification version |
+-------+-----------+----------+------------------------------------+Table 5: DMARC Tags Registry Update
9.4. DMARC Report Formats Registry Update ✨
okay bestie, so names of DMARC failure reporting formats get registered with IANA in the "DMARC Report Formats" registry 🗂️ That registry lives inside the "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" registry group, and it's giving very organized energy 💅
Entries only get assigned for values that have been documented in a way that satisfies the terms of Specification Required, per [RFC8126]. Every registration needs a reference to a permanent specification, plus the format name, the format's status, and a brief description. The designated expert has to confirm that the spec adequately describes the report format and clearly shows how Domain Owners and Mail Receivers would use it within the DMARC context 🧐 The "status" column is one of these:
- "active", meaning the format is in use in current implementations, and its specification is expected to be stable ✅
- "experimental", meaning the format is relatively new. It may be in use in some current implementations but not others, and its specification is not expected to be stable 🧪
- "historic", meaning the format is considered deprecated and is not expected to be in use in any current implementation 🕰️
IANA listed this document (rather than [RFC7489]) as the reference for the registry. IANA then updated the registry like this:
+========+===========+========+==================================+
| Format | Reference | Status | Description |
| Name | | | |
+========+===========+========+==================================+
| afrf | RFC 9989 | active | Authentication Failure Reporting |
| | | | Format (see [RFC6591]) |
+--------+-----------+--------+----------------------------------+
Table 6: DMARC Report Formats Registry Update9.5. Underscored and Globally Scoped DNS Node Names Registry Update 🌸
Names of DNS Resource Records (RRs) that begin with an underscore character and are globally scoped (as per [RFC8552]) get registered with IANA in the "Underscored and Globally Scoped DNS Node Names" registry. That registry sits within the "Domain Name System (DNS) Parameters" registry group 🧚
Each registration contains the DNS RR type and Node Name, plus a reference to a permanent specification. The designated expert needs to confirm that the spec adequately describes the Node Name and clearly shows how Domain Owners and Mail Receivers would use it within the DMARC context 🔍
IANA updated the reference for the following entry so it points to this document (instead of [RFC7489]):
+=========+============+===========+
| RR Type | _NODE NAME | Reference |
+=========+============+===========+
| TXT | _dmarc | RFC 9989 |
+---------+------------+-----------+
Table 7: Underscored and
Globally Scoped DNS Node Names
Registry Update10. Privacy Considerations 🔒
This section is all about private data that might get included when DMARC reports are requested 👀 Issues about sending aggregate reports and failure reports are covered in [RFC9990] and [RFC9991], respectively.
10.1. Aggregate Report Considerations
Aggregate reports can, especially for small organizations, give some limited insight into email sending patterns 📊 For example, in a small organization, one aggregate report from a particular domain might be enough to make the Report Consumer aware of sensitive personal or business information 😬 If you set a rua tag in a DMARC Policy Record, the reporting address needs controls that fit the organization's requirements, so the risks of receiving and handling reports get mitigated 🛡️
For rua requests from multi-organizational PSDs, there are extra information leakage considerations 🫣 Multi-organizational PSDs that don't mandate DMARC use by registrants risk exposing private data of registrant domains if they include the rua tag in their DMARC Policy Record. That's a whole mess, honestly 💀
10.2. Failure Report Considerations
Failure reports really do show email sending patterns, including specific users 👤 If you request failure reports, you need data management controls to handle that information properly. Failure reports have more details than aggregate reports, and that extra detail can mean you need even more controls 📁 For instance, a company might be legally restricted from receiving data related to a specific subsidiary. Before requesting failure reports, any data spillage risks have to be dealt with, either through data management controls or by publishing DMARC Policy Records for relevant subdomains so their emails don't get reported on 🧱
Because of the sensitive email content that failure reports can carry, most Mail Receivers refuse to send them out at all 🙅♀️ Out-of-band agreements between Report Consumers and Mail Receivers may be needed to sort out these concerns 🤝
DMARC Policy Records for multi-organizational PSDs MUST NOT include the ruf tag. 🚫
11. Security Considerations 🚨
This section covers security issues for DMARC, plus possible remediations where they exist. Buckle up, it's about to get serious 💅
11.1. Authentication Methods
Security considerations from the authentication methods that DMARC uses are incorporated here by reference 📎
Both email authentication methods underlying DMARC give some assurance that an email was sent by an MTA that's authorized to send it. SPF policies map domain names to sets of authorized MTAs (see Section 11.4 of [RFC7208]) ✉️ Validated DKIM signatures show that an email was sent by an MTA that has access to a private key matching the published DKIM key record 🔑
Whenever mail gets sent, there's a risk that an overly permissive source could send mail that gets a DMARC "pass" result that the Domain Owner never actually intended 😱 Those results can cause problems when systems read a DMARC "pass" as meaning a message is authentic. They also let unauthorized senders dodge the Domain Owner's intended message handling for DMARC validation failures 🙃
To avoid this risk, you have to make sure that no unauthorized source can add DKIM signatures to the domain's mail, or send mail that evaluates as an SPF "pass" result 🧐 That said, if a Domain Owner wants to include a permissive source in the domain's SPF record, the source can be excluded from DMARC consideration by using the ? qualifier on the SPF record mechanism associated with that source 🎯 The DMARC Working Group had a lively discussion about possibly getting rid of SPF entirely as an underlying authentication mechanism for DMARC. Consensus wasn't reached, so the ? qualifier suggestion for permissive sources is presented here instead 🤷♀️
11.2. Attacks on Reporting URIs
URIs published in DNS TXT records are well-known possible targets for attacks 🎯 Specifications such as [RFC1035] and [RFC2142] either expose email addresses or cause them to be exposed, and those addresses could be flooded by an attacker, for example 📬 Records in the DNS, like MX, NS, and others, advertise potential attack destinations. Common DNS names like "www" plainly identify where particular services can be found, which makes them targets for denial-of-service or penetration attacks 💥 So Domain Owners will need to harden these addresses against various attacks, including but not limited to:
- high-volume denial-of-service attacks;
- deliberate construction of malformed reports intended to identify or exploit parsing or processing vulnerabilities; and
- deliberate construction of reports containing false claims for the Submitter or Reported-Domain fields, including the possibility of false data from compromised but known Mail Receivers.
11.3. DNS Security
The DMARC mechanism and its underlying authentication mechanisms (SPF and DKIM) depend on the security of the DNS 🌐 Here's how hostile parties can mess with DNS traffic and hurt you:
- If they can snoop on DNS traffic, they can get an idea of who is receiving mail using the domain(s) in question 👀
- If they can block outgoing or reply DNS messages, they can stop systems from discovering senders' DMARC policies 🚫
- If they can send forged response packets, they can make aligned mail appear unaligned, or vice versa 😈
None of these threats are unique to DMARC, and they can be addressed with a bunch of techniques, including but not limited to:
- Signing DNS records with Domain Name System Security Extensions (DNSSEC) [RFC9364], which lets recipients validate the integrity of DNS data and detect and discard forged responses 🔏
- DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484] can mitigate snooping and forged responses 🔐
11.4. Display Name Attacks
An increasingly common attack in messaging abuse is putting false information in the display name part of the RFC5322.From header field 🎭 For example, the email address in that field can be an arbitrary address or domain name, while the display name contains a well-known name (a person, brand, role, etc.). The goal is to fool the end user into thinking the name is used legitimately 😤
Attacks like this, known as display name attacks, are out of scope for DMARC 🙈
11.5. Denial of DMARC Processing Attacks 💀
okay bestie, this one is a whole plot twist 😭. The bit in Section 5.3.1 (and a bunch of other places in this doc) that says messages without exactly one RFC5322.From domain are outside the scope of this document? That's an attack vector, and we have to take it seriously 🔥.
Since those messages are out of scope, an attacker can craft messages with multiple RFC5322.From domains, the spoofed one included 👀. The goal is to sneak past DMARC validation and get the fake message shown to the victim's Mail User Agent (MUA) with the spoofed domain front and centre. Lots of these messages do get rejected for other reasons. For example, most would break the [RFC5322] rule that there be precisely one From: header field. Anything that slips through still needs care: the Mail Receiver has to recognize these messages as the threats they might be and handle them properly 🫶.
The multi-valued case is the tricky one 🧐. Experience shows that most of these messages are abusive and/or unwanted by their recipients. Because of that, a Mail Receiver may make a negative disposition decision for the message before and instead of running DMARC processing on it. But if a Mail Receiver does need the message subjected to DMARC validation, the recommended approach per [RFC7489] is to apply the DMARC mechanism to each domain found in the RFC5322.From field as the Author Domain, then apply the strictest policy among the checks that fail.
That can work for a small number of Author Domains. However, applying it to messages with a large number of domains (where "large" is defined by each Mail Receiver) could expose the Mail Receiver to a denial-of-service attack 😱. Limiting the number of Author Domains processed avoids that risk. If not all Author Domains get processed, then the DMARC evaluation is incomplete.
11.6. External Reporting Addresses 📬
To avoid abuse by bad actors 🙅, reporting addresses generally have to be inside the domains the reports are requested about. For special cases, like wanting reports about domains that can't actually receive mail, Section 3 of [RFC9990] describes a DNS-based mechanism for validating approved external reporting 🌸.
The obvious thing to watch is the extra DNS load against domains that get claimed as external recipients. Negative caching helps with this, but only to a limited extent, and it mostly depends on the default TTL in the domain's SOA record 🤓.
Where possible, external reporting is best achieved by sending the report to a domain that can receive mail and letting it get automatically forwarded to the desired external destination ✨.
Heads up: the addresses in the ruf tag receive more info that might count as private data, since actual email content can show up in failure reports 😳. That makes those URIs more attractive intrusion targets than the ones in the rua tag. Attacking the DNS of the subject domain to fraudulently route failure data to an attacker's systems may also be an appealing prospect for them. If this is a concern, deploying DNSSEC [RFC9364] is advisable 🔐.
11.7. Secure Protocols 🔒
This document encourages secure transport mechanisms so private data doesn't leak to third parties who might be monitoring transmissions 👀. Unencrypted mechanisms SHOULD be avoided 🙅.
A message that was originally encrypted or otherwise secured might end up in a report that isn't sent securely. That could reveal private information 😭.
11.8. Relaxed Alignment Considerations 🧩
DMARC lets both DKIM- and SPF-Authenticated Identifiers (Section 4.4) validate authorized use of an Author Domain (Section 3.2.2) on behalf of a Domain Owner (Section 3.2.7). If malicious or unaware users can gain control of the SPF record or DKIM selector records for a subdomain of the Organizational Domain, that subdomain can be used to generate email that achieves a DMARC pass on behalf of the Organizational Domain 😬.
Here's how that could happen:
- A DMARC Policy Record exists for the domain
example.com, such thatexample.comis an Organizational Domain. - An attacker controls DNS for the domain
evil.example.comand publishes an SPF record for that domain. - The attacker sends email with the
RFC5322.Fromheader field containingfoo@example.comand an SPF-Authenticated Identifier ofevil.example.com.
Even though the Domain Owner never authorized this email, it can produce a DMARC pass. That's because the SPF-Authenticated Identifier (evil.example.com) has Identifier Alignment with the Author Domain (example.com) 🫠.
The Organizational Domain Owner should be careful not to delegate control of subdomains if this is an issue, and should consider using the strict alignment option (Section 3.2.10.2) if that's appropriate 💅.
DMARC evaluation for relaxed alignment is also super sensitive to mistakes in determining the Organizational Domain, especially if the Author Domain doesn't have a published DMARC Policy Record (Section 3.2.6) 😵. If an incorrectly selected Organizational Domain is a parent of the correct Organizational Domain, relaxed alignment could potentially let a malicious sender send mail that achieves a DMARC pass verdict. This potential exists for both the legacy [RFC7489] method and the current method for determining the Organizational Domain, and the current one is described in Section 4.10.2.
Let's look at an example of that:
- Mail is sent with an Author Domain of
a.mail.example.comand Authenticated Identifiers ofmail.example.com. - There is no DMARC Policy Record published at
_dmarc.a.mail.example.com. - There is one published at
_dmarc.mail.example.com, and this is intended to be the Organizational Domain for this message. - There is also a DMARC Policy Record published at
_dmarc.example.com, with default alignment (relaxed). - An attacker is able to send mail with the Author Domain of
evil.example.comand an Authenticated Identifier ofmail.example.com.
In this scenario, if a Mail Receiver incorrectly determines the Organizational Domain to be example.com, the attacker's mail will pass DMARC validation checks. 💀
This whole issue is completely avoided by using strict alignment and publishing explicit DMARC Policy Records for all Author Domains used in an organization's email 🎀.
If strict alignment isn't appropriate, the Domain Owner can mitigate this by periodically checking the DMARC Policy Records, if any, of PSDs (Section 3.2.15) above the Organizational Domain in the DNS tree. "Periodically" could mean weekly, or whatever frequency fits the organization's operational needs ⏰. For legacy [RFC7489], they should also check that the appropriate PSL entries are still present. If a PSD publishes a DMARC Policy Record without the appropriate psd=y tag, Organizational Domain owners can add psd=n to their Organizational Domain's DMARC Policy Record. That way, the PSD's DMARC Policy Record won't be wrongly interpreted as indicating that the PSD is the Organizational Domain 🦋.
12. References 📚
12.1. Normative References 📚✨
Okay bestie, here's the reading list for the stuff this spec depends on 🤓💖. Every entry below has to be read to get the full picture. The details are copied exactly, so you can track each one down.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case
Insensitivity Clarification", RFC 4343,
DOI 10.17487/RFC4343, January 2006,
<https://www.rfc-editor.org/info/rfc4343>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
September 2011, <https://www.rfc-editor.org/info/rfc6377>.
[RFC6591] Fontana, H., "Authentication Failure Reporting Using the
Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591,
April 2012, <https://www.rfc-editor.org/info/rfc6591>.
[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
(DKIM) for Failure Reporting", RFC 6651,
DOI 10.17487/RFC6651, June 2012,
<https://www.rfc-editor.org/info/rfc6651>.
[RFC6652] Kitterman, S., "Sender Policy Framework (SPF)
Authentication Failure Reporting Using the Abuse Reporting
Format", RFC 6652, DOI 10.17487/RFC6652, June 2012,
<https://www.rfc-editor.org/info/rfc6652>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 8601,
DOI 10.17487/RFC8601, May 2019,
<https://www.rfc-editor.org/info/rfc8601>.
[RFC9990] Brotman, A., Ed., "Domain-Based Message Authentication,
Reporting, and Conformance (DMARC) Aggregate Reporting",
RFC 9990, DOI 10.17487/RFC9990, May 2026,
<https://www.rfc-editor.org/info/rfc9990>.
[RFC9991] Jones, S., Ed. and A. Vesely, Ed., "Domain-Based Message
Authentication, Reporting, and Conformance (DMARC) Failure
Reporting", RFC 9991, DOI 10.17487/RFC9991, May 2026,
<https://www.rfc-editor.org/info/rfc9991>.12.2. Informative References 🌸💅
Next up are the extra reads that give you more context 🧠🎀. Same deal: the full details are kept exactly as written, so you can look up any of them.
[M3AUTH] Messaging Malware Mobile Anti-Abuse Working Group
(M3AAWG), "M3AAWG Email Authentication Recommended Best
Practices",
<https://www.m3aawg.org/sites/default/files/doc_files/
m3aawg-email-authentication-recommended-best-practices-
09-2020.pdf>.
[M3SPF] Messaging Malware Mobile Anti-Abuse Working Group
(M3AAWG), "M3AAWG Best Practices for Managing SPF
Records",
<https://www.m3aawg.org/sites/default/files/doc_files/
m3aawg_managing-spf_records-2017-08.pdf>.
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
<https://www.rfc-editor.org/info/rfc2142>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464,
DOI 10.17487/RFC3464, January 2003,
<https://www.rfc-editor.org/info/rfc3464>.
[RFC4870] Delany, M., "Domain-Based Email Authentication Using
Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
DOI 10.17487/RFC4870, May 2007,
<https://www.rfc-editor.org/info/rfc4870>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/info/rfc5598>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen, T., Ed., Zwicky,
E., Ed., and K. Andersen, Ed., "Interoperability Issues
between Domain-based Message Authentication, Reporting,
and Conformance (DMARC) and Indirect Email Flows",
RFC 7960, DOI 10.17487/RFC7960, September 2016,
<https://www.rfc-editor.org/info/rfc7960>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
November 2016, <https://www.rfc-editor.org/info/rfc8020>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/info/rfc8552>.
[RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M.
Kucherawy, Ed., "The Authenticated Received Chain (ARC)
Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019,
<https://www.rfc-editor.org/info/rfc8617>.
[RFC9091] Kitterman, S. and T. Wicinski, Ed., "Experimental Domain-
Based Message Authentication, Reporting, and Conformance
(DMARC) Extension for Public Suffix Domains", RFC 9091,
DOI 10.17487/RFC9091, July 2021,
<https://www.rfc-editor.org/info/rfc9091>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.Appendix A. Technology Considerations ✨🦋
Okay so this appendix is the "we thought about it but didn't do it" section 🫶. It covers some design choices for DMARC, including ideas that people floated but that didn't make the cut, with the reasoning behind each decision 💜.
A.1. S/MIME 🔐
S/MIME, which stands for Secure Multipurpose Internet Mail Extensions [RFC8551], is a standard for encrypting and signing MIME data inside a message 💌. It got suggested as a third security protocol for proving where a message came from, and it was seriously considered 👀.
Here's the tea 🍵. DMARC is all about authentication at the domain level, meaning the Domain Owner is taking responsibility for the message. S/MIME is really built for user-to-user authentication and encryption 🙈. So on its own, that mismatch makes it a bad fit for DMARC's goals 💀.
S/MIME also has the heavyweight Public Key Infrastructure (PKI) problem 😩. That means you'd have to build in a way to distribute the keys used to check signatures, and honestly, in lots of cases that alone is a total showstopper 🚫. People have kept promising that PKI usability and deployment will get better, but it hasn't happened yet ⏳. DMARC can revisit this choice once those barriers are dealt with 🌈.
S/MIME is hugely deployed in specific market segments, government for example, but it isn't widely deployed across the general Internet, and it doesn't look like that's going to change 🏛️. DKIM and SPF, on the other hand, are both widely deployed across the general Internet, and their adoption rates keep going up 📈✨.
Finally, experiments showed that adding S/MIME support to the first version of DMARC would neither cause nor enable a meaningful jump in the accuracy of the overall mechanism 🎯. So it just wasn't worth it 🙅♀️.
A.2. Method Exclusion 🚪
Someone suggested that DMARC should include a way for a Domain Owner to tell Mail Receivers not to bother validating with one of the supported methods, like "check DKIM, but not SPF" 🤷♀️. Cute idea, right?
Here's where it gets messy 😬. Picture a Domain Owner who has deployed one of the technologies, and that technology fails for some messages, but those failures don't trigger enforcement action. If they deployed DMARC, enforcement would kick in for any policy other than "none", and that would seem to kick that Domain Owner out of participating 😭.
The DMARC development team looked at policy exception mechanisms on several occasions and kept concluding there wasn't a strong enough use case to include them 🙅♀️. The target audience for DMARC doesn't seem to be worried that failure modes of one method or the other will block adoption 💅.
So in the scenario above, the Domain Owner has a few options 🌸:
- Tighten up its infrastructure to minimize the failure modes of the single deployed technology. 🔧
- Deploy the other supported authentication mechanism to offset the failure modes of the first. 🤝
- Deploy DMARC in a reporting-only mode. 👀📊
A.3. Sender Header Field 💌
Okay so a bunch of message authentication efforts have floated the idea of checking the Sender header field for an identifier of interest, because the standards say that's the proper spot to mark a re-mailing of content, like through a mailing list 📬. Most recently it was a protocol-level option for DomainKeys [RFC4870], but when things evolved into DKIM, that property got dropped 💀.
The DMARC dev team looked at this and decided not to include support, and honestly, the reasons are iconic 💅:
- The main user protection approach is to be concerned with what the user sees when a message is rendered. There is no consistent behavior among MUAs regarding what to do with the content of the
Senderfield, if present. So supporting the checking of the Sender identifier would mean applying policy to an identifier the end user might never actually see. That can create a vector for attack against end users by simply forging aSenderfield containing some identifier that DMARC will like 😭 - Although it is certainly true that this is what the Sender field is for, its use in this way is also unreliable, making it a poor candidate for inclusion in the DMARC evaluation algorithm 🙃
- Allowing multiple ways to discover policy introduces unacceptable ambiguity into the DMARC validation algorithm in terms of which policy is to be applied and when 🌀
A.4. Domain Existence Test 🔍
The presence of the np tag in this specification seemingly implies that there would be an agreed-upon standard for determining a domain's existence. Sus, right? 🤔
Since the DMARC mechanism is focused on email, you might think the definition of "resolvable" in [RFC5321] applies. Using that definition, only names that resolve to MX RRs, A RRs, or AAAA RRs are deemed to be resolvable and to exist in the DNS. This is a common practice among Mail Receivers to determine whether or not to accept a mail message before performing other, more expensive processing 📨
The DMARC mechanism makes no such requirement for the existence of specific DNS RRs in order for a domain to exist. Instead, if any RR exists for a domain, then the domain exists ✨ To use the terminology from [RFC2308], an "NXDOMAIN" response (rcode "Name Error") to a DNS query means that the domain name does not exist. A "NODATA" response (rcode "NOERROR") means that the given RR type queried for does not exist, but the domain name does 🫶
Furthermore, in keeping with [RFC8020], if a query for a name returns NXDOMAIN, then not only does the name not exist, every name below it in the DNS hierarchy also does not exist. Main character energy for the DNS hierarchy, no cap 👑
A.5. Organizational Domain Discovery Issues 🗺️
An earlier informational version of the DMARC mechanism [RFC7489] noted that the DNS does not provide a method by which the "domain of record" (the domain that was actually registered with a domain registrar) can be determined, given an arbitrary domain name 🙈 That version also mentioned suggestions that attempt to glean such information from SOA or NS RRs. But these too are not fully reliable, as the partitioning of the DNS is not always done at administrative boundaries 🤷♀️
That previous version posited that one could "climb the tree" to find the Organizational Domain. It expressed concern, though, that an attacker could exploit this for a denial-of-service attack by sending a high number of messages, each with a relatively large number of nonsense labels. That would cause a Mail Receiver to perform a large number of DNS queries in search of a DMARC Policy Record 😬 This version defines a method for performing a DNS Tree Walk (Section 4.10). It also further mitigates the risk of the denial-of-service attack by expressly limiting the number of DNS queries to execute, regardless of the number of labels in the domain name 🛡️
Readers curious about the previous method for Organizational Domain Discovery are directed to Section 3.2 of [RFC7489] 📖
A.6. Removal of the "pct" Tag 🫧
An earlier informational version of the DMARC mechanism [RFC7489] included a pct tag, and it specified all integers from 0 to 100 inclusive as valid values for the tag. The whole point of the tag was to give Domain Owners a way to gradually change their preferred Domain Owner Assessment Policy (the p tag) from "none" to "quarantine", or from "quarantine" to "reject". They did this by requesting the stricter treatment for just a percentage of messages that produced DMARC results of "fail" 🎚️
Operational experience showed that the pct tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default). The inaccuracies with other values varied widely from one implementation to another 😵💫 The default value was easy to implement, since it required no special processing on the part of the Mail Receiver. The value of 0, meanwhile, took on unintended significance as a value used by some intermediaries and mailbox providers as an indicator to deviate from standard handling of the message. Usually that meant rewriting the RFC5322.From header field in an effort to avoid DMARC failures downstream 🏃♀️
These custom actions when the pct tag was set to 0 proved valuable to the email community 💖 In particular, header field rewriting by an intermediary meant that a Domain Owner's aggregate reports could reveal how much of its traffic was routing through intermediaries that don't rewrite the RFC5322.From header field. That information wasn't explicit in the aggregate reports received. Instead, sussing it out required work on the part of the Domain Owner, who had to compare aggregate reports from before and after the p value was changed and pct=0 was included in the DMARC Policy Record. But the data was there 🧩 So knowing how much mail was subject to possible DMARC failure due to a lack of RFC5322.From header field rewriting by intermediaries could help the Domain Owner choose whether to move from Monitoring Mode (Section 3.2.12) to Enforcement (Section 3.2.9). Armed with this knowledge, the Domain Owner could make an informed decision about subjecting its mail traffic to possible DMARC failures, based on its own tolerance for such things 🎀
Because the value pct=0 provided real value to Domain Owners, it made sense to keep this functionality in the protocol. At the same time, it didn't make sense to support a tag named pct that had only two valid values 🙄 So this version of the DMARC mechanism introduces the t tag as shorthand for "testing", with the valid values of y and n. These are meant to be analogous in their application by mailbox providers and intermediaries to the pct tag values 0 and 100, respectively 🦋
Appendix B. Examples 🎀
This section illustrates both the Domain Owner side and the Mail Receiver side of a DMARC exchange 💕
B.1. Identifier Alignment Examples 🪞
The following examples illustrate the DMARC mechanism's use of Identifier Alignment. For brevity's sake, only message header fields and relevant SMTP commands are shown, since message bodies are not considered when conducting DMARC checks 🙌
B.1.1. SPF
The following SPF examples assume that SPF produces a passing result. Alignment cannot exist if SPF does not produce a passing result 🚫
Example 1: SPF in Strict Alignment:
MAIL FROM: <sender@example.com>
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sampleIn this case, the RFC5321.MailFrom domain and the Author Domain are identical. Thus, the identifiers are in strict alignment 💯
Example 2: SPF in Relaxed Alignment:
MAIL FROM: <sender@child.example.com>
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sampleIn this case, the Author Domain (example.com) is a parent of the RFC5321.MailFrom domain. Thus, the identifiers are in relaxed alignment, because they both have the same Organizational Domain (example.com) 🌸
Example 3: No SPF Identifier Alignment:
MAIL FROM: <sender@example.net>
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sampleIn this case, the RFC5321.MailFrom domain is neither the same as, a parent of, nor a child of the Author Domain. Thus, the identifiers are not in alignment 💀
B.1.2. DKIM
The examples below assume that the DKIM signatures pass validation. Alignment cannot exist with a DKIM signature that does not validate 🔐
Example 1: DKIM in Strict Alignment:
DKIM-Signature: v=1; ...; d=example.com; ...
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sampleIn this case, the DKIM d tag and the Author Domain have identical DNS domains. Thus, the identifiers are in strict alignment ✨
Example 2: DKIM in Relaxed Alignment:
DKIM-Signature: v=1; ...; d=example.com; ...
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sampleIn this case, the DKIM signature's d tag includes a DNS domain that is a parent of the Author Domain. Thus, the identifiers are in relaxed alignment, as they have the same Organizational Domain (example.com) 🦄
Example 3: No DKIM Identifier Alignment:
DKIM-Signature: v=1; ...; d=example.net; ...
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sampleIn this case, the DKIM signature's d tag includes a DNS domain that is neither the same as, a parent of, nor a child of the Author Domain. Thus, the identifiers are not in alignment 🙅♀️
B.2. Domain Owner Example 👑
A Domain Owner that wants to use DMARC should have already deployed and tested SPF and DKIM 🧁 The next step is to publish a DMARC Policy Record for the Domain Owner's Organizational Domain 🚀
B.2.1. Entire Domain, Monitoring Mode 🎀
okay so the Domain Owner for "example.com" already has SPF and DKIM running on its messaging infrastructure 💅. Now it wants to start using DMARC, but super gently. The policy will ask Mail Receivers for aggregate feedback without changing how any messages get processed ✨. The goal is to:
- Confirm that its legitimate messages are authenticating correctly 🫶
- Validate that all authorized message sources have implemented authentication measures 🔥
- Determine how many messages from other sources would be affected by publishing a Domain Owner Assessment Policy at Enforcement 👀
To make that happen, the Domain Owner builds a DMARC Policy Record that says:
- The version of DMARC being used is "DMARC1" (
v=DMARC1;) 💜 - Mail Receivers should not alter how they treat these messages because of this DMARC Policy Record (
p=none) 🌸 - Aggregate feedback reports are sent via email to the address "dmarc-feedback@example.com" (
rua=mailto:dmarc-feedback@example.com) 📬 - All messages from this Organizational Domain are subject to this policy (no "t" tag present, so the default of "n" applies) 🧚
To publish it, the DNS administrator for the Domain Owner makes an entry like this in the appropriate zone file (following the conventional zone file format) 🍓:
; DMARC Policy Record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com" )B.2.2. Entire Domain, Monitoring Mode, Per-Message Failure Reports 🦋
The Domain Owner from the last example used aggregate reporting to find some messaging systems that still hadn't implemented DKIM correctly 🙈. But they're still seeing periodic authentication failures, and those are sneaky. So they want to request per-message failure reports whenever authentication fails, to figure out what's going on ✨.
Not every Mail Receiver is going to honor that request ngl 😭. Still, the Domain Owner thinks whatever reports it does get will be helpful enough to be worth publishing this record. The default per-message failure report format [RFC9991] covers what the Domain Owner needs here 💖.
To get there, the Domain Owner adds the following to its DMARC Policy Record from Appendix B.2.1:
- Per-message failure reports are sent via email to the address "auth-reports@example.com" (
ruf=mailto:auth-reports@example.com) 💌
To publish it, the DNS administrator for the Domain Owner might create an entry like this in the appropriate zone file (following the conventional zone file format) 🌈:
; DMARC Policy Record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com; "
"ruf=mailto:auth-reports@example.com" )B.2.3. Per-Message Failure Reports Directed to Third Party 🧚♀️
Same Domain Owner, same policy, but now they want a third party to act as the Report Consumer 👑. Again, not every Mail Receiver will honor this, but the ones that do MUST implement additional checks to validate that the third party authorizes reception of failure reports on behalf of this domain 🔥.
The Domain Owner has to update its DMARC Policy Record from Appendix B.2.2 like so:
- Per-message failure reports are sent via email to the address "auth-reports@thirdparty.example.net" (
ruf=mailto:auth-reports@thirdparty.example.net) ✨
To publish it, the DNS administrator for the Domain Owner might create an entry like this in the appropriate zone file (following the conventional zone file format) 🎀:
; DMARC Policy Record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback@example.com; "
"ruf=mailto:auth-reports@thirdparty.example.net" )Because the address in the "ruf" tag sits outside the Organizational Domain where this record is published, conforming Mail Receivers MUST implement additional checks as described in Section 3 of [RFC9990] 🦋. To pass those checks, the Report Consumer's Domain Owner needs to publish an additional DMARC Policy Record too, like this:
- Given the DMARC Policy Record published by the Domain Owner at "_dmarc.example.com", the DNS administrator for the Report Consumer needs to publish a TXT RR at "example.com._report._dmarc.thirdparty.example.net" with the value "v=DMARC1;" to authorize receipt of the reports 💜
To publish that, the DNS administrator for example.net might create an entry like this in the appropriate zone file (following the conventional zone file format) 🍓:
; zone file for thirdparty.example.net
; Accept DMARC reports on behalf of example.com
example.com._report._dmarc IN TXT "v=DMARC1;"B.2.4. Overriding Destination Addresses 🌸
The third-party Report Consumer can also publish "rua" and "ruf" tags to override the specific address that example.com published, swapping in a different address within the same third-party domain 🫧. This may be necessary if the third-party Report Consumer has changed its email address, or if it wants to guard against typos in the DMARC Policy Record of the Author Domain 🙈. Intermediaries and other third parties should refer to Section 3 of [RFC9990] for the full details of this mechanism 📚.
The third-party Report Consumer does this by adding the following to its DMARC Policy Record from Appendix B.2.3:
- The override address for aggregate reports is "aggregate-reports@thirdparty.example.net" (
rua=mailto:aggregate-reports@thirdparty.example.net) 📬 - The override address for failure reports is "failure-reports@thirdparty.example.net" (
ruf=mailto:failure-reports@thirdparty.example.net) 💌
To publish it, the DNS administrator for example.net might create an entry like this in the appropriate zone file (following the conventional zone file format) ✨:
; zone file for thirdparty.example.net
; Accept DMARC reports on behalf of example.com
; Override destination mailboxes
example.com._report._dmarc IN TXT (
"v=DMARC1; "
"rua=mailto:aggregate-reports@thirdparty.example.net; "
"ruf=mailto:failure-reports@thirdparty.example.net" )In this case, only the "ruf" tag is actually overridden 🦋. That's because in the previous example, failure reporting was the only reporting type directed to the third-party Report Consumer 💅.
B.2.5. Subdomain, Testing, and Multiple Aggregate Report URIs 🧪
The Domain Owner has set up SPF and DKIM on a subdomain it uses for pre-production testing of messaging services 🛠️. Now it wants to say how it prefers messages from that subdomain to be handled when they fail DMARC validation. The signal is that use of this domain is not valid 🚫.
Step one is saying that it considers messages from this subdomain that fail DMARC validation to be suspicious 🤨. The point is to let participating Mail Receivers examine messages sent to their hosted mailboxes, which helps troubleshoot any existing authentication issues 🔍. Aggregate feedback reports go to a mailbox inside the Organizational Domain and to a mailbox at a Report Consumer that the Domain Owner selected and authorized to receive them 📬.
The Domain Owner builds a DMARC Policy Record that says:
- The version of DMARC being used is "DMARC1" (
v=DMARC1;) 💜 - It applies only to this subdomain. The DMARC Policy Record is published at "_dmarc.test.example.com" and not "_dmarc.example.com" 🎯
- Mail Receivers are advised that the Domain Owner considers messages that fail to authenticate to be suspicious (
p=quarantine) ⚠️ - Aggregate feedback reports are sent via email to the addresses "dmarc-feedback@example.com" and "example-tld-test@thirdparty.example.net" (
rua=mailto:dmarc-feedback@example.com, mailto:example-tld-test@thirdparty.example.net) 📮 - The Domain Owner only wants an actor performing a DMARC validation check to apply any special handling rules it might already have, such as rewriting the
RFC53322.Fromheader field. The Domain Owner is still testing its setup, so it does not want the Domain Owner Assessment Policy applied (t=y) 🧪
To publish it, the DNS administrator for the Domain Owner might create an entry like this in the appropriate zone file (following the conventional zone file format) 🍓:
; DMARC Policy Record for the domain test.example.com
_dmarc IN TXT ( "v=DMARC1; p=quarantine; "
"rua=mailto:dmarc-feedback@example.com,"
"mailto:tld-test@thirdparty.example.net; "
"t=y" )Once enough time has gone by to collect enough reports, the Domain Owner can feel confident that all authorized email sent from the subdomain is authenticating properly and passing DMARC validation 🥹. Then it can update the DMARC Policy Record to say that validation failures are a clear sign that use of the subdomain is not valid 🙅♀️. It does this by changing the record to tell Mail Receivers its position on such messages ("p=reject") and removing the testing flag ("t=y") 🔥.
To publish that, the DNS administrator for the Domain Owner might create an entry like this in the appropriate zone file (following the conventional zone file format) 🎀:
; DMARC Policy Record for the domain test.example.com
_dmarc IN TXT ( "v=DMARC1; p=reject; "
"rua=mailto:dmarc-feedback@example.com,"
"mailto:tld-test@thirdparty.example.net" )B.3. Mail Receiver Example ✨
A Mail Receiver that wants to join DMARC should already be checking SPF and DKIM 🫶. It also needs to be able to collect relevant information from various email-processing stages, so it can send feedback to Domain Owners, possibly through Report Consumers 📬.
B.3.1. SMTP Session Example ✨
Okay bestie, picture this: an optimal DMARC-enabled Mail Receiver does validation and Identifier Alignment checking during the SMTP [RFC5321] conversation 🧚 It's giving main character energy 💅
Before it returns a final reply to the DATA command, the Mail Receiver's MTA has already done three things:
- An SPF check to determine an SPF-Authenticated Identifier.
- DKIM checks that yield one or more DKIM-Authenticated Identifiers.
- A DMARC Policy Record lookup.
If there's an Author Domain DMARC Policy Record, that's the signal that the Mail Receiver should keep going with DMARC-specific processing before it replies to the DATA command 🎀
Given a DMARC Policy Record and the set of Authenticated Identifiers, the Mail Receiver checks whether those Authenticated Identifiers align with the Author Domain. It takes any strict versus relaxed options in the DMARC Policy Record into account too 🦋
Let's look at an example. The following sample data is considered to be from a piece of email originating from the Domain Owner of example.com:
Author Domain: example.com
SPF-authenticated Identifier: mail.example.com
DKIM-authenticated Identifier: example.com
DMARC Policy Record:
"v=DMARC1; p=reject; aspf=r;
rua=mailto:dmarc-feedback@example.com"Here, the SPF-Authenticated Identifier and the DKIM-Authenticated Identifier both align with the Author Domain 🫶 So the Mail Receiver considers the email to pass the DMARC check, dodging the reject policy that's requested for email that fails DMARC validation. Slay 😭🔥
If no Authenticated Identifiers align with the Author Domain, then the Mail Receiver applies the Domain Owner Assessment Policy. Before that happens, though, the Mail Receiver can consult external information to override the Domain Owner Assessment Policy 👀 For example, if the Mail Receiver knows this particular email came from a known and trusted forwarder (one that happens to break both SPF and DKIM), then it may choose to ignore the Domain Owner Assessment Policy 🙈
The Mail Receiver is now ready to reply to the DATA command. If the DMARC check yields that the message is to be rejected, the Mail Receiver replies with a 5xy code to tell the sender about the failure 💀 If the DMARC check can't be resolved because of transient network errors, the Mail Receiver replies with a 4xy code so the sender knows to try delivery again later 🍓 If the DMARC check yields a passing message, the Mail Receiver keeps processing the email, maybe using the DMARC result as an input to other modules like a domain reputation query ⭐
Before exiting DMARC-specific processing, the Mail Receiver checks whether the Author Domain DMARC Policy Record requests reporting based on an Authentication Failure Reporting Format (AFRF). If it does, the Mail Receiver can emit an AFRF to the reporting address supplied in the DMARC Policy Record 📬
At the exit of DMARC-specific processing, the Mail Receiver captures the result of DMARC processing, either by logging it or by inserting it directly into a data store 🗂️ That captured info is used to build feedback for the Domain Owner. This is unnecessary if the Domain Owner hasn't requested aggregate reports, i.e., no rua tag was found in the policy record 🙅♀️
B.4. Organizational and Policy Domain Tree Walk Examples 🌈
If an Author Domain has no DMARC Policy Record, a Mail Receiver uses a Tree Walk to find the DMARC Policy.
If the DMARC Policy Record allows relaxed alignment and the SPF- or DKIM-Authenticated Identifiers are different from the Author Domain, a Mail Receiver uses a Tree Walk to discover the respective Organizational Domains and figure out Identifier Alignment 🔍
B.4.1. Simple Organizational and Policy Example 🌸
A Mail Receiver receives an email with:
- Author Domain:
example.com - RFC5321.MailFrom Domain:
example.com - DKIM-Authenticated Identifier:
signing.example.com
In this example, _dmarc.example.com and _dmarc.signing.example.com both have DMARC Policy Records, while _dmarc.com does not. If SPF or DKIM yield pass results, they still have to be aligned to support a DMARC pass. Since not all domains are the same, if the alignment is relaxed, then the Tree Walk is performed to determine the Organizational Domain for each 🧩
To find the Organizational Domain for the Author Domain, query _dmarc.example.com and _dmarc.com. example.com is the last element of the DNS tree with a DMARC Policy Record, so it's the Organizational Domain for example.com 🌳
For the RFC5321.MailFrom domain, the Organizational Domain already found for example.com is example.com, so SPF is aligned ✅
To find the Organizational Domain for the DKIM-Authenticated Identifier, query _dmarc.signing.example.com, _dmarc.example.com, and _dmarc.com. Both signing.example.com and example.com have DMARC Policy Records, but example.com is the highest element in the tree with a DMARC Policy Record (it has the fewest labels), so example.com is the Organizational Domain. Since that's also the Organizational Domain for the Author Domain, DKIM is aligned for relaxed alignment 🥰
Since both SPF and DKIM are aligned, they can be used to determine whether the message has a DMARC "pass" result. If the result isn't "pass", then the policy domain's DMARC Policy Record is used to determine the appropriate policy. In this case, since the RFC5322.From domain has a DMARC Policy Record, that's the policy domain 💖
B.4.2. Deep Tree Walk Example 🧚
A Mail Receiver receives an email with:
- Author Domain:
a.b.c.d.e.f.g.h.i.j.k.example.com - RFC5321.MailFrom Domain:
example.com - DKIM-Authenticated Identifier:
signing.example.com
Both _dmarc.example.com and _dmarc.signing.example.com have DMARC Policy Records, while _dmarc.com does not. If SPF or DKIM yield pass results, they still have to be aligned to support a DMARC pass. Since not all domains are the same, if the alignment is relaxed, then the Tree Walk is performed to determine the Organizational Domain for each 🌿
To find the Organizational Domain for the Author Domain, query _dmarc.a.b.c.d.e.f.g.h.i.j.k.example.com. Then query _dmarc.g.h.i.j.k.example.com, skipping the intermediate names. Then query _dmarc.h.i.j.k.example.com, _dmarc.i.j.k.example.com, _dmarc.j.k.example.com, _dmarc.k.example.com, _dmarc.example.com, and _dmarc.com. None of a.b.c.d.e.f.g.h.i.j.k.example.com, g.h.i.j.k.example.com, h.i.j.k.example.com, i.j.k.example.com, j.k.example.com, or k.example.com have a DMARC Policy Record 🕵️♀️
Since example.com is the last element of the DNS tree with a DMARC Policy Record, it's the Organizational Domain for a.b.c.d.e.f.g.h.i.j.k.example.com 🎯
For the RFC5321.MailFrom domain, the Organizational Domain already found for example.com is example.com. SPF is aligned ✨
For the DKIM-Authenticated Identifier, query _dmarc.signing.example.com, _dmarc.example.com, and _dmarc.com. Both signing.example.com and example.com have DMARC Policy Records, but example.com is the highest element in the tree with a DMARC Policy Record, so example.com is the Organizational Domain. Since that's also the Organizational Domain for the Author Domain, DKIM is aligned for relaxed alignment 💜
Since both SPF and DKIM are aligned, they can be used to determine whether the message has a DMARC "pass" result. If the results for both aren't "pass", then the policy domain's DMARC Policy Record is used to determine the appropriate policy. In this case, the Author Domain doesn't have a DMARC Policy Record, so the policy domain is the highest element in the DNS tree with a DMARC Policy Record, which is example.com 🌟
B.4.3. Example with a PSD DMARC Policy Record 🦋
In rare cases, a PSD publishes a DMARC Policy Record with a psd tag, which the Tree Walk has to take into account 🧐
A Mail Receiver receives an email with:
- Author Domain:
giant.bank.example - RFC5321.MailFrom Domain:
mail.giant.bank.example - DKIM-Authenticated Identifier:
mail.mega.bank.example
In this case, _dmarc.bank.example has a DMARC Policy Record that includes the psd=y tag, and _dmarc.example doesn't have a DMARC Policy Record. While _dmarc.giant.bank.example has a DMARC Policy Record without a psd tag, _dmarc.mega.bank.example and _dmarc.mail.mega.bank.example have no DMARC Policy Records 🏦
Since the three domains are all different, Tree Walks find their Organizational Domains to see which ones are aligned 🔎
For the Author Domain giant.bank.example, the Tree Walk finds the DMARC Policy Record at _dmarc.giant.bank.example, then the DMARC Policy Record at _dmarc.bank.example, and stops because of the psd=y flag. The Organizational Domain is giant.bank.example because it's the domain directly below the one with psd=y. Since the Organizational Domain has a DMARC Policy Record, it's also the policy domain 💅
For the RFC5321.MailFrom domain mail.giant.bank.example, the Tree Walk finds no DMARC Policy Record at _dmarc.mail.giant.bank.example, but it does find the DMARC Policy Record at _dmarc.giant.bank.example, then the one at _dmarc.bank.example, and stops because of the psd=y flag. Again, the Organizational Domain is giant.bank.example because it's the domain directly below the one with psd=y. Since that's the same Organizational Domain as the Author Domain, SPF is aligned 🙌
For the DKIM-Authenticated Identifier mail.mega.bank.example, the Tree Walk finds no DMARC Policy Records at _dmarc.mail.mega.bank.example or _dmarc.mega.bank.example. Then it finds the DMARC Policy Record at _dmarc.bank.example and stops because of the psd=y flag. The Organizational Domain is mega.bank.example, so DKIM is not aligned 🙅♀️
Since SPF is aligned, it can be used to determine whether the message has a DMARC "pass" result. If the result isn't "pass", then the policy domain's DMARC Policy Record is used to determine the appropriate policy 🎀
B.5. Utilization of Aggregate Feedback: Example
Okay, so aggregate feedback is what Domain Owners use to see how their domain is being processed by the Mail Receiver 👀💅. Aggregate reporting data on emails that pass all of the underlying authentication checks is how Domain Owners make sure their authentication practices are still accurate ✨. For example, if a third party is sending on behalf of a Domain Owner, the Domain Owner can use aggregate report data to validate that third party's ongoing authentication practices 🫶.
Data on email that only partially passes the underlying authentication checks shows problems the Domain Owner needs to deal with 🔥. For example, if either SPF or DKIM fails to produce an Authenticated Identifier, the Domain Owner gets enough info to either directly fix the problem or figure out where authentication-breaking changes are being introduced in the email transmission path 🧚. If authentication-breaking changes caused by the transmission path can't be directly corrected, the Domain Owner at least keeps an understanding of how DMARC-based policies are affecting their email 💜.
Data on email that fails all of the underlying authentication checks gives baseline visibility into how the Domain Owner's domain is being received at the Mail Receiver 🌸. Based on that visibility, the Domain Owner can start deploying authentication technologies across uncovered email sources, as long as the failing mail was generated by or on behalf of the Domain Owner 🎀. Data about failing checks can also help the Domain Owner understand how its domain is being misused 😭.
Appendix C. Changes from RFC 7489 ✨
This document is intended to render [RFC7489] obsolete 💀. As one might guess, that means there are significant differences between [RFC7489] and this document. This section will summarize those changes 🦋.
C.1. Informational vs. Standards Track
[RFC7489] wasn't the product of any IETF work stream. It was published into the RFC Series by the Independent Submissions Editor and classified as an Informational RFC 🌈.
This document, by contrast, is an Internet Standards Track document 👑.
C.2. Changes to Terminology and Definitions
The following changes were made to the "Terminology and Definitions" section 📝.
C.2.1. Terms Added
These terms were added:
- Domain Owner Assessment Policy
- Enforcement
- Monitoring Mode
- Non-existent Domains
- Public Suffix Domain (PSD)
- Public Suffix Operator (PSO)
- PSO-Controlled Domain Names
C.2.2. Definitions Updated
These definitions were updated:
- Organizational Domain
- Report Receiver (renamed to Report Consumer)
C.3. Policy Discovery and Organizational Domain Determination
The algorithms for DMARC policy discovery and for determining the Organizational Domain have been changed 🔄. Specifically, reliance on a PSL has been replaced by a technique called a "DNS Tree Walk," and the methodology for the DNS Tree Walk is explained in detail in this document ✨.
The DNS Tree Walk also incorporates PSD policy discovery, which was introduced in [RFC9091]. That RFC was an Experimental RFC, and the results of that experiment were that the RFC was not implemented as written 🧪. Instead, this document redefines the algorithm for PSD policy discovery and thus obsoletes [RFC9091]. Specifically, the DNS Tree Walk defined in this document obviates the need for a PSD DMARC registry, and that PSD DMARC registry is what made [RFC9091] an Experimental RFC 💅.
These algorithm changes introduce the possibility of interoperability issues. A Domain Owner might expect a DMARC Policy Record or an Organizational Domain to be identified by the Tree Walk process, but a Mail Receiver using an implementation of DMARC based on [RFC7489] and relying on a PSL might arrive at a different answer 😬.
This issue is entirely avoided by using strict alignment and publishing explicit DMARC Policy Records for all Author Domains used in an organization's email 🫶.
C.4. Reporting
Discussion of both aggregate and failure reporting has been moved to separate documents dedicated to those topics 📚.
In addition, the ability to specify a maximum report size in the DMARC URI has been removed 🙈.
C.5. Tags
Several tags have been added to the "DMARC Policy Record Format" section of this document since [RFC7489] was published. At the same time, several others were removed 🍓.
C.5.1. Tags Added
np:Policy for non-existent domains (imported from [RFC9091]).psd:Flag indicating whether a domain is a PSD.t:Replacement for some "pct" tag functionality. See Appendix A.6 for further discussion.
C.5.2. Tags Removed
pct:Tag requesting application of the DMARC policy to only a percentage of messages. See Appendix A.6 for discussion.rf:Tag specifying requested format of failure reports.riTag specifying requested interval between aggregate reports.
C.6. Expansion of Domain Owner Actions Section
[RFC7489] only had two paragraphs in its "Domain Owner Actions" section. The content of those paragraphs was correct, but it was minimalist in its approach to guiding Domain Owners on how to actually implement DMARC 🥺.
This document provides much more detail and explanatory text for a Domain Owner. It focuses not just on what to do to implement DMARC, but also on the reasons for each step and the repercussions of each decision 🧠✨.
In particular, this document makes explicit that domains for general-purpose email SHOULD NOT deploy a DMARC policy of "p=reject". See Section 7.4 for further discussion of this topic ⚠️.
C.7. Report Generator Recommendations
In the cases where a DMARC Policy Record specifies multiple destinations for either aggregate reports or failure reports, [RFC7489] stated:
Receivers MAY impose a limit on the number of URIs to which they will send reports but MUST support the ability to send to at least two.
Section 4.6 of this document includes this text:
A report SHOULD be sent to each listed URI provided in the DMARC Policy Record.
C.8. Removal of RFC 7489, Appendix A.5
One of the appendices in [RFC7489], specifically Appendix A.5, has been removed from the text with this update 🗑️. The appendix was titled "Issues with ADSP in Operation," and it contained a list of issues associated with ADSP that influenced the direction of DMARC. The ADSP protocol was moved to "Historic" status in 2013, and working group consensus was that such a discussion of ADSP's influence on DMARC was no longer relevant 🕰️.
C.9. RFC 7489 Errata Summary
This document and its companion documents ([RFC9990] and [RFC9991]) address the following errata filed against [RFC7489] since that document's publication in March, 2015. More details on each of these can be found at <https://www.rfc-editor.org/errata_search.php?rfc=7489> 🔍.
C.9.1. RFC Errata, Erratum ID 5365, RFC 7489, Section 7.2.1.1
See <https://www.rfc-editor.org/errata/eid5365>. This erratum is addressed in [RFC9990].
C.9.2. RFC Errata, Erratum ID 5371, RFC 7489, Section 7.2.1.1
See <https://www.rfc-editor.org/errata/eid5371>. This erratum is addressed in [RFC9990].
C.9.3. RFC Errata, Erratum ID 5440, RFC 7489, Section 7.1 and Appendices B.2.1, B.2.3, and B.2.4
See <https://www.rfc-editor.org/errata/eid5440>. This erratum references several mentions in [RFC7489] of the "v=" tag from the Domain Owner Assessment Policy and/or its value. Specifically, it points out mentions that were not, but should have been, v=DMARC1;. Some of those mentions are preserved in this document, and those mentions have been addressed as per the erratum. The rest have moved to [RFC9990] and are addressed there 📌.
C.9.4. RFC Errata, Erratum ID 6439, RFC 7489, Section 7.1
See <https://www.rfc-editor.org/errata/eid6439>. This erratum is addressed in [RFC9990].
C.9.5. RFC Errata, Erratum ID 5221, RFC 7489, Appendix C
See <https://www.rfc-editor.org/errata/eid5221>. The regular expression pattern for IP addresses has been removed from this document and from [RFC9990] 🗑️.
C.9.6. RFC Errata, Erratum ID 5229, RFC 7489, Appendix C
See <https://www.rfc-editor.org/errata/eid5229>. This erratum is addressed in [RFC9990].
C.9.7. RFC Errata, Erratum 5495, RFC 7489, Section 6.6.3
See <https://www.rfc-editor.org/errata/eid5495>. This erratum is in reference to the description of the process documented in [RFC7489] for the applicable DMARC policy for an email message. The process for doing this has drastically changed in this document, so the text identified in this erratum no longer exists 🪄.
C.9.8. RFC Errata, Erratum ID 6485, RFC 7489, Section 7.2.1.1
See <https://www.rfc-editor.org/errata/eid6485>. This erratum is addressed in [RFC9990].
C.9.9. RFC Errata, Erratum ID 6729, RFC 7489, Section 3.2
See <https://www.rfc-editor.org/errata/eid6729>. This erratum is in reference to a search of the PSL as part of finding a DMARC Policy Record (a.k.a., Domain Owner Assessment Policy). The PSL is no longer relied upon for this practice, and the text at issue has been removed from this document 👋.
C.9.10. RFC Errata, Erratum ID 7099, RFC 7489, Section 7.2.1.1
See <https://www.rfc-editor.org/errata/eid7099>. This erratum is addressed in [RFC9990].
C.9.11. RFC Errata, Erratum ID 7100, RFC 7489, Section 7.2.1.1
See <https://www.rfc-editor.org/errata/eid7100>. This erratum is addressed in [RFC9990].
C.9.12. RFC Errata, Erratum ID 7835, RFC 7489, Section 6.6.3
See <https://www.rfc-editor.org/errata/eid7835>. This erratum is in reference to the description of the process documented in [RFC7489] for the applicable DMARC policy for an email message. The process for doing this has drastically changed in this document, so the text identified in this erratum no longer exists 🪄.
C.9.13. RFC Errata, Erratum ID 7865, RFC 7489, Appendix C
See <https://www.rfc-editor.org/errata/eid7865>. The regular expression pattern for IP addresses has been removed from this document and from [RFC9990] 🗑️.
C.9.14. RFC Errata, Erratum ID 5151, RFC 7489, Section 1
See <https://www.rfc-editor.org/errata/eid5151>. This erratum is in reference to the Introduction section of [RFC7489]. That section has been substantially rewritten in this document, so the text at issue for this erratum no longer exists 💫.
C.9.15. RFC Errata, Erratum ID 5774, RFC 7489, Appendix C
See <https://www.rfc-editor.org/errata/eid5774>. This erratum is addressed in [RFC9990].
C.10. General Editing and Formatting
A great deal of the content from [RFC7489] was preserved in this document. Much of it was subject to minor editing, the reordering of sections, or both 🪞.
Acknowledgements ✨
The reworking of the DMARC mechanism specified in [RFC7489] is the result of contributions from many participants in the DMARC Working Group. Although the contributors are too numerous to mention, significant contributions were made by Kurt Andersen, Laura Atkins, Seth Blank, Alex Brotman, Dave Crocker, Douglas E. Foster, Ned Freed, Mike Hammer, Steven M. Jones, Scott Kitterman, Murray S. Kucherawy, Barry Leiba, Alessandro Vesely, and Tim Wicinski 🫶🌸.
The authors and contributors also recognize that this document would not have been possible without the work done by those who had a hand in producing [RFC7489]. The Acknowledgements section from that document is preserved in full below 🎀.
Acknowledgements ✨
Okay bestie, the thank-you section 🫶 DMARC and the draft of this doc that went to the Independent Submission Editor were the result of a LOT of work from an informal industry consortium called DMARC.org (you can find them at https://dmarc.org) 💜 Companies that helped out were Agari, American Greetings, AOL, Bank of America, Cloudmark, Comcast, Facebook, Fidelity Investments, Google, JPMorgan Chase & Company, LinkedIn, Microsoft, Netease, PayPal, ReturnPath, The Trusted Domain Project, and Yahoo! 🌈 There were way too many contributors and supporters to name them all, but a few people made especially big contributions: J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen 👑 The contributors also want to give a shoutout to J.D. Falk, whose early input and guidance were absolutely invaluable ✨
Extra contributions within the IETF context came from Kurt Andersen, Michael Jack Assels, Les Barstow, Anne Bennett, Jim Fenton, J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine, S. Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull 🦋 Everyone on this list is literally iconic 💅
Authors' Addresses 🎀
Todd M. Herr (editor) Valimail Email: todd@someguyinva.com
John Levine (editor) Standcore LLC Email: standards@standcore.com
📦 where this page comes from
- ietf: rfc9989 2026-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms