RFC 7489
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Part 1 of 15 🎀
Domain-based Message Authentication, Reporting, and Conformance (DMARC) ✨
okay bestie, this is RFC 7489 💖 an RFC is just an official IETF document, and this one is all about DMARC. Here's the title block tea ☕
- Stream: Independent Submission, so it's not from the main IETF stream 🦋
- Category: Informational, which means it's published for info and is not a Standards Track spec 💅
- Authors: M. Kucherawy (Ed.) and E. Zwicky (Ed.), both at Yahoo! 🫶
- Date: March 2015 📅
- ISSN: 2070-1721 🌈
- Obsoletes / Updates: the title block doesn't list any, so this doc doesn't replace or update another RFC 🙈
Abstract 🌸
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism that lets a mail-originating organization express domain-level policies and preferences for message validation, disposition, and reporting. A mail-receiving organization can then use those preferences to improve how it handles mail 💜
okay so why does anyone need this? Originators of Internet Mail need to be able to attach reliable, authenticated domain identifiers to messages, communicate policies about messages that use those identifiers, and get reports about mail using those identifiers. These abilities have a few perks: receivers can give Domain Owners feedback about how their domains are being used, and that feedback can be super valuable for spotting internal operations issues and external domain name abuse 🔥
And the big thing: DMARC does not produce or encourage elevated delivery privilege of authenticated email 🙅♀️ It's a mechanism for policy distribution that lets receivers get increasingly strict with messages that fail authentication checks. That ranges from no action, to altered delivery, all the way up to message rejection ✨
Status of This Memo 💅
This document is not an Internet Standards Track specification. It's published for informational purposes 🎀
This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment 🦋 Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard. See Section 2 of RFC 5741 for the details 💖
Want the current status, errata, or a way to send feedback? Check http://www.rfc-editor.org/info/rfc7489 🌸
Copyright Notice 🌈
Copyright (c) 2015 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 (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions with respect to this document 📜
Table of Contents 🧚
1. Introduction ....................................................3
2. Requirements ....................................................5
2.1. High-Level Goals ...........................................5
2.2. Out of Scope ...............................................6
2.3. Scalability ................................................6
2.4. Anti-Phishing ..............................................7
3. Terminology and Definitions .....................................7
3.1. Identifier Alignment .......................................8
3.2. Organizational Domain .....................................11
4. Overview .......................................................12
4.1. Authentication Mechanisms .................................12
4.2. Key Concepts ..............................................12
4.3. Flow Diagram ..............................................13
5. Use of RFC5322.From ............................................15
6. Policy .........................................................15
6.1. DMARC Policy Record .......................................16
6.2. DMARC URIs ................................................16
6.3. General Record Format .....................................17
6.4. Formal Definition .........................................21
6.5. Domain Owner Actions ......................................22
6.6. Mail Receiver Actions .....................................23
6.7. Policy Enforcement Considerations .........................27
7. DMARC Feedback .................................................28
7.1. Verifying External Destinations ...........................28
7.2. Aggregate Reports .........................................30
7.3. Failure Reports ...........................................36
8. Minimum Implementations ........................................37
9. Privacy Considerations .........................................38
9.1. Data Exposure Considerations ..............................38
9.2. Report Recipients .........................................39
10. Other Topics ..................................................39
10.1. Issues Specific to SPF ...................................39
10.2. DNS Load and Caching .....................................40
10.3. Rejecting Messages .......................................40
10.4. Identifier Alignment Considerations ......................41
10.5. Interoperability Issues ..................................41
11. IANA Considerations ...........................................42
11.1. Authentication-Results Method Registry Update ............42
11.2. Authentication-Results Result Registry Update ............42
11.3. Feedback Report Header Fields Registry Update ............44
11.4. DMARC Tag Registry .......................................44
11.5. DMARC Report Format Registry .............................45
12. Security Considerations .......................................46
12.1. Authentication Methods ...................................46
12.2. Attacks on Reporting URIs ................................46
12.3. DNS Security .............................................47
12.4. Display Name Attacks .....................................47
12.5. External Reporting Addresses .............................48
12.6. Secure Protocols .........................................48
13. References ....................................................49
13.1. Normative References .....................................49
13.2. Informative References ...................................50
Appendix A. Technology Considerations .............................52
A.1. S/MIME .....................................................52
A.2. Method Exclusion ...........................................53
A.3. Sender Header Field ........................................53
A.4. Domain Existence Test ......................................54
A.5. Issues with ADSP in Operation ..............................54
A.6. Organizational Domain Discovery Issues .....................55
Appendix B. Examples ..............................................56
B.1. Identifier Alignment Examples ..............................56
B.2. Domain Owner Example .......................................58
B.3. Mail Receiver Example .....................................63
B.4. Utilization of Aggregate Feedback: Example .................64
B.5. mailto Transport Example ...................................65
Appendix C. DMARC XML Schema ......................................66
Acknowledgements ..................................................73
Authors' Addresses ................................................731. Introduction ✨
okay so the Sender Policy Framework ([SPF]) and DomainKeys Identified Mail ([DKIM]) give us domain-level authentication 🔐 They help cooperating email receivers detect mail that's authorized to use a domain name, and that can allow differential handling. (If you want the deep dive on the threats these systems try to address, see [DKIM-THREATS] 🧠)
BUT, and this is the tea, there has never been a single widely accepted or publicly available mechanism to communicate domain-specific message-handling policies to receivers, or to request reporting on how received mail was authenticated and disposed of 😭 Without feedback reports, originators who've set up email authentication have a hard time figuring out how well it's actually working. So using authentication failures to filter mail typically doesn't succeed 💀
Over time, one-on-one relationships formed between certain senders and receivers. They privately agreed on ways to state policy and to receive message traffic and authentication disposition reports 🤝 These ad hoc practices have mostly worked, but they need a ton of manual coordination between parties, and that model just doesn't scale for general use on the Internet 🙃
This document defines Domain-based Message Authentication, Reporting, and Conformance (DMARC) 💖 It's a mechanism that lets email operators build on existing authentication and policy advertisement technologies. The result is both message-stream feedback and enforcement of policies against unauthenticated email 🎀
DMARC lets Domain Owners and receivers team up by:
- Giving receivers assertions about Domain Owners' policies
- Giving senders feedback so they can monitor authentication and judge threats
The basic outline of DMARC goes like this 🦋
- Domain Owners publish policy assertions about their domains via the DNS.
- Receivers compare the
RFC5322.Fromaddress in the mail to the SPF and DKIM results (if present) and to the DMARC policy in DNS. - Receivers use those results to decide how the mail should be handled.
- The receiver sends reports to the Domain Owner, or its designee, about mail claiming to be from their domain.
Security terms used in this document are defined in [SEC-TERMS] 🔒
DMARC is different from earlier approaches to policy advertisement (like [SPF] and [ADSP]) in a few ways 👑
- Authentication technologies are:
- decoupled from any technology-specific policy mechanisms, and
- used only to establish reliable per-message domain-level identifiers.
- Multiple authentication technologies are used to:
- reduce the impact of transient authentication errors,
- reduce the impact of site-specific configuration errors and deployment gaps, and
- enable more use cases than any single technology supports alone.
- Receiver-generated feedback is supported, so senders can build confidence in their authentication practices 🌸
- The domain name pulled from a message's
RFC5322.Fromfield is the primary identifier in the DMARC mechanism. It's used together with the results of the underlying authentication technologies to evaluate results under DMARC ✨
Real talk: experience with DMARC has revealed some interoperability issues with email in general that deserve careful thought before deployment 🙈 These are especially important for configurations that can cause mail to be rejected. They're discussed in Section 10 💅
2. Requirements 🧚
Specification of DMARC is guided by the following high-level goals, security dependencies, detailed requirements, and items that are documented as out of scope 💜
2.1. High-Level Goals ✨
okay bestie, so DMARC has five main goals and they are giving main character energy 💅🎀
- Allow Domain Owners to assert the preferred handling of authentication failures, for messages purporting to have authorship within the domain. 🦋
- Allow Domain Owners to verify their authentication deployment. 🔍
- Minimize implementation complexity for both senders and receivers, as well as the impact on handling and delivery of legitimate messages. 🧚
- Reduce the amount of successfully delivered spoofed email. 🚫📨
- Work at Internet scale. 🌍💖
2.2. Out of Scope 🙅♀️
ngl there's a whole list of stuff that is NOT happening in this first version, so don't go looking for it here 🙈 it's out of scope for now:
- different treatment of messages that are not authenticated versus those that fail authentication; 💀
- evaluation of anything other than RFC5322.From; 💅
- multiple reporting formats; 📄
- publishing policy other than via the DNS; 🌐
- reporting or otherwise evaluating other than the last-hop IP address; 📍
- attacks in the RFC5322.From 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. 🧐
2.3. Scalability 📈
scalability is a HUGE deal for anything that has to work in a system as widely deployed as current SMTP email 😤 so DMARC tries really hard to avoid needing third parties or pre-sending agreements between senders and receivers. this keeps the good stuff about the current email infrastructure intact ✨
tbh DMARC doesn't bring third-party senders (external agents authorized to send on behalf of an operator) into the email-handling flow, but it also doesn't block them. those third parties are totally free to offer services alongside DMARC 💜
2.4. Anti-Phishing 🎣
DMARC is designed to stop bad actors from sending mail that pretends to come from legitimate senders, especially senders of transactional email (official mail about business transactions) 🛑 one of the big uses of this kind of spoofed mail is phishing, which is when people get tricked into handing over info by pretending to be the real service asking for it 😱 so DMARC is heavily informed by ongoing efforts to enact large-scale, Internet-wide anti-phishing measures 🔥
DMARC can only directly fight specific forms of exact-domain spoofing, but the mechanism has been found to be really useful for building reliable and defensible message streams 🎀
DMARC does not try to solve every problem with spoofed or otherwise fraudulent email, okay?? 🙃 in particular, it doesn't deal with visually similar domain names ("cousin domains") or abuse of the RFC5322.From human-readable <display-name> 💀
- Terminology and Definitions 📚
this section is where we define the terms the rest of the doc uses, so let's get into it 🧚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
readers are encouraged to get familiar with [EMAIL-ARCH] 🫶 it defines the various roles in the messaging infrastructure, which can show up as the same or as separate things depending on context. for example, a Domain Owner could, through the messaging security mechanisms DMARC is built on, delegate the ability to send mail as the Domain Owner to a third party with another role. this document doesn't get into the differences between those roles, so go read that material before continuing 📖💅
the following terms are also used:
Authenticated Identifiers: Domain-level identifiers that are validated using authentication technologies are referred to as "Authenticated Identifiers". See Section 4.1 for details about the supported mechanisms. 🔐
Author Domain: The domain name of the apparent author, as extracted from the RFC5322.From field. ✍️
Domain Owner: An entity or organization that owns a DNS domain. The term "owns" here indicates that the entity or organization being referenced holds the registration of that DNS domain. Domain Owners range from complex, globally distributed organizations, to service providers working on behalf of non-technical clients, to individuals responsible for maintaining personal domains. This specification uses this term as analogous to an Administrative Management Domain as defined in [EMAIL-ARCH]. It can also refer to delegates, such as Report Receivers, when those are outside of their immediate management domain. 👑
Identifier Alignment: When the domain in the RFC5322.From address matches a domain validated by SPF or DKIM (or both), it has Identifier Alignment. 💖
Mail Receiver: The entity or organization that receives and processes email. Mail Receivers operate one or more Internet-facing Mail Transport Agents (MTAs). 📬
Organizational Domain: The domain that was registered with a domain name registrar. In the absence of more accurate methods, heuristics are used to determine this, since it is not always the case that the registered domain name is simply a top-level DNS domain plus one component (e.g., "example.com", where "com" is a top-level domain). The Organizational Domain is determined by applying the algorithm found in Section 3.2. 🌸
Report Receiver: An operator that receives reports from another operator implementing the reporting mechanism described in this document. Such an operator might be receiving reports about its own messages, or reports about messages related to another operator. This term applies collectively to the system components that receive and process these reports and the organizations that operate them. 🧾
3.1. Identifier Alignment 🦋
okay so email auth technologies check different parts of a message, and they're all kinda different 👀 for example, [DKIM] checks the domain that put a signature on the message, while [SPF] can check either the domain in the RFC5321.MailFrom (MAIL FROM) part of [SMTP] or the RFC5321.EHLO/HELO domain, or both. these can be different domains, and they're usually not visible to the end user 🫣
DMARC checks the RFC5322.From domain by requiring it to match (be aligned with) an Authenticated Identifier. the RFC5322.From domain got picked as the central identity of DMARC because it's a required header field, so it's guaranteed to be there in compliant messages 🙌 and most Mail User Agents (MUAs) show the RFC5322.From field as the originator and render some or all of it for end users 💌
which is exactly why it's a prime target for abuse 😤 lots of high-profile email sources, like email service providers, require the sending agent to authenticate before email can be generated. so for those mailboxes, this mechanism gives recipient end users strong evidence that the message really came from the agent they associate with that mailbox, as long as the end user knows those protections are in place 🥹✨
domain names get compared in a case-insensitive manner, per [DNS-CASE] 🔤
it's super important to know that Identifier Alignment can't happen with a message that isn't valid per [MAIL], especially one with a malformed, absent, or repeated RFC5322.From field 🚨 with no reliable way to figure out which DMARC policy applies, there's nothing to align. so DMARC assumes the input is a valid RFC5322 message object, and handling non-compliant cases is outside the scope of this spec. more on this in Section 6.6.1 💅
each underlying authentication technology DMARC takes as input gives back authenticated domains when it succeeds 🎉 from DMARC's point of view, each can run in a "strict" mode or a "relaxed" mode. a Domain Owner would normally pick strict mode if they only want Mail Receivers to apply DMARC processing to messages whose RFC5322.From domain exactly matches the domains those mechanisms verify. relaxed mode can be used when the operator also wants to affect message flows bearing subdomains of the verified domains 🌈
3.1.1. DKIM-Authenticated Identifiers 🔏
DMARC lets Identifier Alignment based on a DKIM authentication be strict or relaxed 💖 (side note, these aren't related to DKIM's "simple" and "relaxed" canonicalization modes, so don't mix them up 🙃) in relaxed mode, the Organizational Domains of both the [DKIM]-authenticated signing domain (taken from the value of the "d=" tag in the signature) and the RFC5322.From domain must be equal for the identifiers to count as aligned. in strict mode, only an exact match between both Fully Qualified Domain Names (FQDNs) produces Identifier Alignment 🎯
for example, in relaxed mode, if a validated DKIM signature verifies with a "d=" domain of "example.com", and the RFC5322.From address is "alerts@news.example.com", the DKIM "d=" domain and the RFC5322.From domain are considered to be "in alignment" ✨ in strict mode, this test would fail, since the "d=" domain doesn't exactly match the FQDN of the address 💅
but a DKIM signature with "d=com" would NEVER give an "in alignment" result 💀 "com" should appear on all public suffix lists (see Appendix A.6.1), so it can't be an Organizational Domain 🙅♀️
Identifier Alignment is required because a message can carry a valid signature from any domain, including domains used by a mailing list or even a bad actor 😬 so just having a valid signature isn't enough to infer that the Author Domain is authentic 🫠
also, a single email can have multiple DKIM signatures, and it counts as a DMARC "pass" if any DKIM signature is aligned and verifies 🎀
3.1.2. SPF-Authenticated Identifiers 📮
DMARC lets Identifier Alignment based on an SPF authentication be strict or relaxed 💜
in relaxed mode, the [SPF]-authenticated domain and the RFC5322.From domain must have the same Organizational Domain. in strict mode, only an exact DNS domain match produces Identifier Alignment 🎯
the RFC5321.HELO identity isn't typically used in DMARC (except when it's needed to "fake" an otherwise null reverse-path) 🙈 even though a "pure SPF" implementation according to [SPF] would check that identifier 🤷♀️
for example, if a message passes an SPF check with an RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address portion of the RFC5322.From field contains "payments@example.com", the Authenticated RFC5321.MailFrom domain identifier and the RFC5322.From domain are considered "in alignment" in relaxed mode, but NOT in strict mode 🦋🧚
3.1.3. Alignment and Extension Technologies 🌸
if DMARC ever gets extended to use other authentication mechanisms, those extensions will need to allow for domain identifier extraction so that alignment with the RFC5322.From domain can be verified 🔮💖
3.2. Organizational Domain 🏠✨
okay so the Organizational Domain gets figured out with this algorithm, bestie 💅
- Grab a "public suffix" list 📜. It's a list of DNS domain names that are reserved for registrations. Some country TLDs have their own rules (the United Kingdom puts company registrations under ".co.uk", which is so specific 😭), and other TLDs like ".com" show up in the IANA registry of top-level DNS domains. A public suffix list is the union of all of these. Appendix A.6.1 has some discussion about getting one 🦋
- Chop the subject DNS domain name into a set of "n" ordered labels 🔪. Number them right to left, so for "example.com", "com" is label 1 and "example" is label 2 🔢
- Search the public suffix list for the name that matches the most labels in the subject DNS domain 🔍. Call that number "x".
- Build a brand new DNS domain name from the name that matched on the public suffix list, with the "x+1"th label from the subject domain stuck on the front 🧩. That new name is the Organizational Domain 👑
Thus, since "com" is an IANA-registered TLD, a subject domain of a.b.c.d.example.com gets an Organizational Domain of example.com. Iconic 💖
ngl, figuring out the suffix is still kind of a heuristic 🙈. No list is guaranteed to be accurate or current, so keep that in mind, bestie 💀
4. Overview 🌸
okay so this section gives you the big-picture vibe of how the DMARC environment works and runs 🦋
4.1. Authentication Mechanisms 🔐
these are the mechanisms for figuring out Authenticated Identifiers that are supported in this version of DMARC 💅
- [DKIM] gives you a domain-level identifier in the content of the
d=tag of a validatedDKIM-Signatureheader field 🔏 - [SPF] can authenticate both the domain in an [SMTP]
HELO/EHLOcommand (the HELO identity) and the domain in an SMTPMAILcommand (the MAIL FROM identity) ✨. DMARC uses the result of SPF authentication of the MAIL FROM identity. Section 2.4 of [SPF] describes MAIL FROM processing for cases where the MAIL command has a null path 🙈
4.2. Key Concepts 🗝️
DMARC policies are published by the Domain Owner, and the Mail Receiver grabs them during the SMTP session, via the DNS 📮
DMARC's filtering function is based on whether the RFC5322.From field domain is aligned with (matches) an authenticated domain name from SPF or DKIM 🎯. When a DMARC policy is published for the domain name found in the RFC5322.From field, and that domain name isn't validated through SPF or DKIM, the disposition of that message can be affected by that DMARC policy when it's delivered to a participating receiver 💅
It is important to note that the authentication mechanisms DMARC uses only authenticate a DNS domain. They do NOT authenticate the local-part of any email address identifier found in a message, and they don't validate the legitimacy of message content 🚨
DMARC's feedback component collects information about received messages that claim to be from the Organizational Domain, for periodic aggregate reports to the Domain Owner 📊. The parameters and format for those reports are discussed in later sections of this document 🧚
A DMARC-enabled Mail Receiver might also generate per-message reports with info about individual messages that fail SPF and/or DKIM 🔎. Per-message failure reports are super useful when debugging deployments (if messages can be determined to be legitimate even though they fail authentication) or when analyzing attacks 🕵️♀️. The capability for these services is enabled by DMARC but defined in other referenced material, such as [AFRF] 💜
A message satisfies the DMARC checks if at least one of the supported authentication mechanisms:
- produces a "pass" result, and
- produces that result based on an identifier that is in alignment, as defined in Section 3.
4.3. Flow Diagram 🗺️
+---------------+
| Author Domain |< . . . . . . . . . . . . . . . . . . . . . . .
+---------------+ . . .
| . . .
V V V .
+-----------+ +--------+ +----------+ +----------+ .
| MSA |<***>| DKIM | | DKIM | | SPF | .
| Service | | Signer | | Verifier | | Verifier | .
+-----------+ +--------+ +----------+ +----------+ .
| ^ ^ .
| ************** .
V * .
+------+ (~~~~~~~~~~~~) +------+ * .
| sMTA |------->( other MTAs )----->| rMTA | * .
+------+ (~~~~~~~~~~~~) +------+ * .
| * ........
| * .
V * .
+-----------+ V V
+---------+ | MDA | +----------+
| User |<--| Filtering |<***>| DMARC |
| Mailbox | | Engine | | Verifier |
+---------+ +-----------+ +----------+
MSA = Mail Submission Agent
MDA = Mail Delivery Agentthe diagram shows a simple flow of messages through a DMARC-aware system 🦋. Solid lines are the actual message flow, dotted lines are DNS queries used to retrieve message policy for the supported message authentication schemes, and asterisk lines are data exchanges between message-handling modules and message authentication modules ✨. "sMTA" is the sending MTA, and "rMTA" is the receiving MTA 💅
so in essence, here are the steps 👇
- Domain Owner constructs an SPF policy and publishes it in its DNS database as per [SPF]. Domain Owner also configures its system for DKIM signing as described in [DKIM]. Finally, Domain Owner publishes a DMARC message-handling policy via the DNS 📜
- Author generates a message and hands it to Domain Owner's designated mail submission service ✍️
- Submission service passes relevant details to the DKIM signing module so it can generate a DKIM signature to be applied to the message 🔏
- Submission service relays the now-signed message to its designated transport service for routing to its intended recipient(s) 🚀
- Message may pass through other relays, but eventually it arrives at a recipient's transport service 🌈
- Recipient delivery service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which requires queries to the Author Domain's DNS data (when identifiers are aligned; see below) 🔍
- The results get passed to the DMARC module along with the Author's domain. The DMARC module attempts to retrieve a policy from the DNS for that domain. If none is found, the DMARC module determines the Organizational Domain and repeats the attempt to retrieve a policy from the DNS. (This is described in further detail in Section 6.6.3.) 🔁
- If a policy is found, it's combined with the Author's domain and the SPF and DKIM results to produce a DMARC policy result (a "pass" or "fail"). It can optionally cause one of two kinds of reports to be generated (not shown) 📊
- Recipient transport service either delivers the message to the recipient inbox or takes other local policy action based on the DMARC result (not shown) 📬
- When requested, Recipient transport service collects data from the message delivery session to be used in providing feedback (see Section 7) 💖
5. Use of RFC5322.From 📧
okay so one of the most obvious points of security scrutiny for DMARC is the choice to focus on an identifier, namely the RFC5322.From address 👀. That field is part of a body of data that has been trivially forged throughout the history of email 💀
Several points suggest this is the most correct and safest thing to do in this context ✨:
- Of all the identifiers that are part of the message itself, this is the only one guaranteed to be present 🫶
- It seems like the best identifier to focus on, since most MUAs display some or all of the contents of that field in a way that strongly suggests the data reflects the true originator of the message 👑
The absence of a single, properly formed RFC5322.From field renders the message invalid 🚫. Handling of such a message is outside the scope of this specification.
Since the sorts of mail typically protected by DMARC participants tend to have only single Authors, DMARC participants generally operate under a slightly restricted profile of RFC5322 when it comes to the expected syntax of this field 🎀. See Section 6.6 for details 🧚
6. Policy 📜
DMARC policies are published by Domain Owners and applied by Mail Receivers 🦋
A Domain Owner advertises DMARC participation for one or more of its domains by adding a DNS TXT record (described in Section 6.1) to those domains 📣. By doing so, Domain Owners make specific requests of Mail Receivers about the disposition of messages purporting to be from one of the Domain Owner's domains, plus the provision of feedback about those messages 💌
A Domain Owner may choose not to participate in DMARC evaluation by Mail Receivers 🙅♀️. In that case, the Domain Owner simply declines to advertise participation in those schemes. For example, if the results of path authorization checks ought not be considered as part of the overall DMARC result for a given Author Domain, then the Domain Owner doesn't publish an SPF policy record that can produce an SPF pass result 💅
A Mail Receiver implementing the DMARC mechanism SHOULD make a best-effort attempt to adhere to the Domain Owner's published DMARC policy when a message fails the DMARC test 🔥. Since email streams can be complicated (due to forwarding, existing RFC5322.From domain-spoofing services, etc.), Mail Receivers MAY deviate from a Domain Owner's published policy during message processing, and they SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the "PolicyOverride" feature of the aggregate report (see Section 7.2) 🌈
6.1. DMARC Policy Record 💖
okay so, Domain Owner DMARC preferences get stored as DNS TXT records in subdomains named _dmarc. For example, the Domain Owner of "example.com" would post their DMARC preferences in a TXT record at _dmarc.example.com. 🎀 And a Mail Receiver who wants to check DMARC preferences for mail with an RFC5322.From domain of "example.com" would send a TXT query to DNS for the subdomain _dmarc.example.com. The DNS-located DMARC preference data will hereafter be called the "DMARC record" ✨
DMARC uses DNS the way it does because of how it uses domain names and the kind of query it makes. The query needs are a perfect match for DNS, since it's just grabbing simple parametric info. The info is stored in a well-established way, tied to the target domain name, in an isolated TXT record that's restricted to the DMARC context. 🧚 Using DNS as the query service is honestly iconic, because it reuses an extremely well-established operations, administration, and management infrastructure instead of building a brand new one. 💅
Per [DNS], a TXT record can hold several "character-string" objects. When that happens, the module doing DMARC evaluation MUST concatenate these strings by joining the objects together in order and parsing the result as a single string. 🧩
6.2. DMARC URIs 🔗
[URI] defines a generic syntax for identifying a resource. DMARC borrows this format so a Domain Owner can say where to send the two supported report types. 🦋
The place these URIs get specified (see Section 6.3) lets a list of them be provided. Reports are normally sent to each listed URI in the order the Domain Owner gave. Receivers MAY impose a limit on how many URIs they'll send reports to, but they MUST support being able to send to at least two. The list of URIs is separated by commas (ASCII 0x2C). 💜
Each URI can also come with a maximum report size. To do that, you add an exclamation point (ASCII 0x21), followed by a maximum-size indication, right before a separating comma or the terminating semicolon. 🌸
So a DMARC URI is a URI where any commas or exclamation points are percent-encoded per [URI], followed by an OPTIONAL exclamation point and a maximum-size specification, and, if there are more reporting URIs in the list, a comma and the next URI. Lowkey a lot of punctuation, but it makes sense once you see it 🙈
For example, mailto:reports@example.com!50m would request that a report be emailed to reports@example.com as long as the report payload doesn't go over 50 megabytes 📬
A formal definition is provided in Section 6.4. 🧾
6.3. General Record Format 📜
DMARC records follow the extensible "tag-value" syntax for DNS-based key records that's defined in DKIM [DKIM]. Lowkey iconic that it's reusing an existing format 🫶
Section 11 creates a registry for known DMARC tags and registers the initial set defined in this document. Only tags defined in this document or in later extensions, and therefore added to that registry, are to be processed. Unknown tags MUST be ignored. 🚫
The following tags are introduced as the initial valid DMARC tags:
adkim: (plain-text; OPTIONAL; default is "r".) This says whether strict or relaxed DKIM Identifier Alignment mode is required by the Domain Owner. See Section 3.1.1 for details. Valid values are:
r: relaxed modes: strict mode
aspf: (plain-text; OPTIONAL; default is "r".) This says whether strict or relaxed SPF Identifier Alignment mode is required by the Domain Owner. See Section 3.1.2 for details. Valid values are:
r: relaxed modes: strict mode
fo: Failure reporting options (plain-text; OPTIONAL; default is "0"). This gives requested options for generating failure reports. Report generators MAY choose to adhere to the requested options. This tag's content MUST be ignored if a "ruf" tag (below) is not also specified. The value is a colon-separated list of characters that indicate failure reporting options, as follows:
0: Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned "pass" result.1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned "pass" result.d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment. DKIM-specific reporting is described in [AFRF-DKIM].s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment. SPF-specific reporting is described in [AFRF-SPF].
p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records). This is the policy the Receiver should enact at the Domain Owner's request. The policy applies to the domain queried and to subdomains, unless a subdomain policy is explicitly described using the sp tag. This tag is mandatory for policy records only, not for third-party reporting records (see Section 7.1). Possible values are:
none: The Domain Owner requests no specific action be taken regarding delivery of messages.quarantine: The Domain Owner wants email that fails the DMARC mechanism check to be treated by Mail Receivers as suspicious. Depending on the Mail Receiver's capabilities, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious". 🕵️reject: The Domain Owner wants Mail Receivers to reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction. See Section 10.3 for some discussion of SMTP rejection methods and their implications. 🚪
pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL; default is 100). This is the percentage of messages from the Domain Owner's mail stream that the DMARC policy gets applied to. However, this MUST NOT be applied to the DMARC-generated reports, all of which must be sent and received unhindered. The whole point of pct is to let Domain Owners do a slow rollout of DMARC enforcement. "All or nothing" is recognized as stopping lots of organizations from experimenting with strong authentication-based mechanisms, so this helps with that 🌈 See Section 6.6.4 for details. Random selection based on this percentage, like the pseudocode below, is adequate:
if (random mod 100) < pct then
selected = true
else
selected = falserf: Format to be used for message-specific failure reports (colon-separated plain-text list of values; OPTIONAL; default is "afrf"). The value is a list of one or more report formats the Domain Owner wants used when a message fails both [SPF] and [DKIM] tests, to report details of the individual failure. The values MUST be present in the registry of reporting formats defined in Section 11. A Mail Receiver that sees a different value SHOULD ignore it, or MAY ignore the entire DMARC record. For this version, only "afrf" (the auth-failure report type defined in [AFRF]) is currently supported. See Section 7.3 for details. For interoperability, the Authentication Failure Reporting Format (AFRF) MUST be supported. 📑
ri: Interval requested between aggregate reports (plain-text 32-bit unsigned integer; OPTIONAL; default is 86400). This is a request to Receivers to generate aggregate reports separated by no more than the requested number of seconds. DMARC implementations MUST be able to provide daily reports and SHOULD be able to provide hourly reports when requested. Anything other than a daily report is understood to be handled on a best-effort basis, though 🕰️
rua: Addresses to which aggregate feedback is to be sent (comma-separated plain-text list of DMARC URIs; OPTIONAL). A comma or exclamation point that's part of a DMARC URI MUST be encoded per Section 2.1 of [URI], so it isn't mistaken for the list delimiter or an OPTIONAL size limit. Section 7.1 covers the considerations that apply when a URI's domain name differs from the domain advertising the policy. See Section 12.5 for additional considerations. Any valid URI can be specified. A Mail Receiver MUST implement support for a "mailto:" URI, i.e., the ability to send a DMARC report via electronic mail. If it's not provided, Mail Receivers MUST NOT generate aggregate feedback reports. URIs not supported by Mail Receivers MUST be ignored. The aggregate feedback report format is described in Section 7.2. 📊
ruf: Addresses to which message-specific failure information is to be reported (comma-separated plain-text list of DMARC URIs; OPTIONAL). If present, the Domain Owner is asking Mail Receivers to send detailed failure reports about messages that fail the DMARC evaluation in specific ways (see the fo tag above). The format of the message to be generated MUST follow the format specified for the rf tag. Section 7.1 covers the considerations that apply when a URI's domain name differs from the domain advertising the policy. A Mail Receiver MUST implement support for a "mailto:" URI, i.e., the ability to send a DMARC report via electronic mail. If it's not provided, Mail Receivers MUST NOT generate failure reports. See Section 12.5 for additional considerations. 🔍
sp: Requested Mail Receiver policy for all subdomains (plain-text; OPTIONAL). This is the policy the Receiver should enact at the Domain Owner's request. It applies only to subdomains of the domain queried, not to the domain itself. Its syntax is identical to that of the p tag defined above. If absent, the policy specified by the p tag MUST be applied for subdomains. Note that sp will be ignored for DMARC records published on subdomains of Organizational Domains, because of the effect of the DMARC policy discovery mechanism described in Section 6.6.3. 🙃
v: Version (plain-text; REQUIRED). This identifies the record retrieved as a DMARC record. It MUST have the value DMARC1. The value of this tag MUST match precisely. If it doesn't, or if it's absent, the entire retrieved record MUST be ignored. It MUST be the first tag in the list. 👑
A DMARC policy record MUST comply with the formal specification found in Section 6.4, in that the v and p tags MUST be present and MUST appear in that order. Unknown tags MUST be ignored. Syntax errors in the rest of the record SHOULD be discarded in favor of default values (if any) or ignored outright. 🧹
Note that, given the rules of the previous paragraph, adding a new tag to the registered list of tags does not by itself require a new version of DMARC to be generated (with a corresponding change to the v tag's value). But changing any existing tags does require a new version of DMARC 💖 periodt.
6.4. Formal Definition ✨
okay so the whole DMARC format is written out in [ABNF] 🎀 bestie, this is the grammar for the record, so every piece has to match exactly:
dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ]
; "URI" is imported from [URI]; commas (ASCII
; 0x2C) and exclamation points (ASCII 0x21)
; MUST be encoded; the numeric portion MUST fit
; within an unsigned 64-bit integer
dmarc-record = dmarc-version dmarc-sep
[dmarc-request]
[dmarc-sep dmarc-srequest]
[dmarc-sep dmarc-auri]
[dmarc-sep dmarc-furi]
[dmarc-sep dmarc-adkim]
[dmarc-sep dmarc-aspf]
[dmarc-sep dmarc-ainterval]
[dmarc-sep dmarc-fo]
[dmarc-sep dmarc-rfmt]
[dmarc-sep dmarc-percent]
[dmarc-sep]
; components other than dmarc-version and
; dmarc-request may appear in any order
dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31
dmarc-sep = *WSP %x3b *WSP
dmarc-request = "p" *WSP "=" *WSP
( "none" / "quarantine" / "reject" )
dmarc-srequest = "sp" *WSP "=" *WSP
( "none" / "quarantine" / "reject" )
dmarc-auri = "rua" *WSP "=" *WSP
dmarc-uri *(*WSP "," *WSP dmarc-uri)
dmarc-furi = "ruf" *WSP "=" *WSP
dmarc-uri *(*WSP "," *WSP dmarc-uri)
dmarc-adkim = "adkim" *WSP "=" *WSP
( "r" / "s" )
dmarc-aspf = "aspf" *WSP "=" *WSP
( "r" / "s" )
dmarc-ainterval = "ri" *WSP "=" *WSP 1*DIGIT
dmarc-fo = "fo" *WSP "=" *WSP
( "0" / "1" / "d" / "s" )
*(*WSP ":" *WSP ( "0" / "1" / "d" / "s" ))
dmarc-rfmt = "rf" *WSP "=" *WSP Keyword *(*WSP ":" Keyword)
; registered reporting formats only
dmarc-percent = "pct" *WSP "=" *WSP
1*3DIGIT"Keyword" gets borrowed from Section 4.1.2 of [SMTP], so you don't have to define it again 🧚
Now the size thing 📦. If you put a size limit in a dmarc-uri, it's read as a count of units, and then there's an OPTIONAL unit size: "k" for kilobytes, "m" for megabytes, "g" for gigabytes, or "t" for terabytes. No unit at all? Then the number is just a plain byte count. And these units are powers of two, so a kilobyte is 2^10, a megabyte is 2^20, and so on. Literally math with a bow on it 🎀
6.5. Domain Owner Actions 💅
okay so, to actually run DMARC, the only thing a Domain Owner has to do is make the DMARC policy record in DNS 🌸 that's it, that's the required part. BUT if they want it to be useful, they need to at least do one of two things: set up an address to get reports, or deploy authentication tech and make sure Identifier Alignment works. Most Domain Owners are going to want to do both, honestly the main character move 👑
The reports are going to be pretty big, and the addresses that get them are publicly visible, so we really encourage Domain Owners to make dedicated email addresses just for reports 📥 and to add abuse countermeasures on those addresses where it makes sense 🛡️
The authentication stuff lives in [DKIM] (also check out [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT]) and in [SPF] 🔐
6.6. Mail Receiver Actions 📬
this part is all about what the receivers do on their end 🫶
6.6.1. Extract Author Domain 🔍
the domain in the RFC5322.From field is what gets pulled out to be checked by DMARC. If that domain is UTF-8 encoded, it has to get turned into an A-label first, the way Section 2.3 of [IDNA] describes, before any further processing 🌈
Real talk: a message usually needs exactly one RFC5322.From domain (one From: field with one domain in it) for DMARC to work on it 💀 Not every message is like that, and what happens to the messages that aren't is outside the scope of this document. Here are the typical exceptions and how DMARC folks have historically handled them:
- Messages with multiple RFC5322.From fields are typically rejected, since that form is forbidden under RFC 5322 [MAIL];
- Messages with a single RFC5322.From field that holds multiple addresses (so multiple domain names to check) are typically rejected, because the kind of mail DMARC usually protects doesn't use that format;
- Messages with no RFC5322.From field at all are typically rejected, since that form is forbidden under RFC 5322 [MAIL];
- Messages with an RFC5322.From field that doesn't contain any meaningful domains, like RFC 5322 [MAIL]'s "group" syntax, are typically ignored.
The multi-valued RFC5322.From field is the tricky one 😭 If it's syntactically valid but has multiple domains, the process is to run the DMARC check with each of those domains as the Author Domain, and then apply the strictest policy out of the checks that fail 💜
6.6.2. Determine Handling Policy 🧠
okay so to figure out a policy for one message, Mail Receivers MUST do these steps (or their semantic equivalents) ✨ Steps 2-4 MAY be done in parallel, but steps 5 and 6 need input from the earlier steps 🎀
- Extract the RFC5322.From domain from the message (as above).
- Query the DNS for a DMARC policy record. Continue if one is found, or terminate DMARC evaluation otherwise. See Section 6.6.3 for details.
- Perform DKIM signature verification checks. A single email could contain multiple DKIM signatures. The results of this step are passed to the remainder of the algorithm and MUST include the value of the "d=" tag from each checked DKIM signature.
- Perform SPF validation checks. The results of this step are passed to the remainder of the algorithm and MUST include the domain name used to complete the SPF check.
- Conduct Identifier Alignment checks. Once the authentication checks and policy discovery are done, the Mail Receiver checks whether the Authenticated Identifiers line up as described in Section 3. If one or more of them align with the RFC5322.From domain, the message passes the DMARC mechanism check. Everything else (authentication failures, identifier mismatches) counts as a DMARC mechanism check failure.
- Apply policy. Emails that fail the DMARC mechanism check get disposed of according to the Domain Owner's discovered DMARC policy. See Section 6.3 for details.
Heuristics used when a Domain Owner isn't using SPF or DKIM at all (like [Best-Guess-SPF]) SHOULD NOT be used 🙅♀️ The reason is that the Domain Owner might not want a Message Receiver to look at the results of that underlying authentication protocol at all.
DMARC can only give a "pass" result after one of the underlying authentication mechanisms passes for an aligned identifier 💖 If neither passes, and one or both fail because of a temporary error, the Receiver can't conclude that the DMARC mechanism had a permanent failure. So they can't apply the advertised DMARC policy. When it's otherwise appropriate, Receivers MAY send feedback reports about temporary errors 📨
What happens when SPF and/or DKIM hit a permanent DNS error is up to the Mail Receiver 🤷♀️
6.6.3. Policy Discovery 🔎
so as we said above, DMARC uses DNS TXT records to advertise policy 🍓 Policy discovery works in a way that's similar to how SPF records are found. That method, plus the big differences between DMARC and SPF, is explained below.
To balance wildcarding, letting subdomains override policy, and not spamming DNS with queries, this lookup scheme is used:
- Mail Receivers MUST query the DNS for a DMARC TXT record at the DNS domain matching the RFC5322.From domain in the message. A possibly empty set of records is returned.
- Records that do not start with a "v=" tag identifying the current version of DMARC are discarded.
- If the set is now empty, the Mail Receiver MUST query the DNS for a DMARC TXT record at the DNS domain matching the Organizational Domain instead of the RFC5322.From domain in the message (if they're different). This record can hold policy for subdomains of the Organizational Domain. A possibly empty set of records is returned.
- Records that do not start with a "v=" tag identifying the current version of DMARC are discarded.
- If the remaining set has multiple records or no records, policy discovery stops and DMARC processing is not applied to this message.
- If a retrieved policy record doesn't have a valid "p" tag, or it has an "sp" tag that isn't valid, then:
- if a "rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver SHOULD act as if a record containing a valid "v" tag and "p=none" was retrieved, and keep processing;
- otherwise, the Mail Receiver applies no DMARC processing to this message.
If the set from the mechanism above has no DMARC policy record (meaning there's any sign there's no such record, as opposed to a passing DNS hiccup), Mail Receivers SHOULD NOT apply the DMARC mechanism to the message 🙈
How DNS errors get handled when looking up the DMARC policy record is up to the Mail Receiver 💅 For example, to keep mail flowing with minimal disruption, transient errors could let the message through ("fail open"). Or they could cause the message to be temporarily rejected (an SMTP 4yx reply), which invites the sending MTA to try again once the problem has maybe cleared, so a definite DMARC answer can be reached ("fail closed") 🌈
6.6.4. Message Sampling 🎲
if the "pct" tag is in the policy record, the Mail Receiver MUST NOT enact the requested policy ("p" tag or "sp" tag") on more than the stated percent of the affected messages 🥺 BUT no matter whether "pct" is there or not, the Mail Receiver MUST include all relevant message data in any reports it makes.
If email is under the DMARC policy of "quarantine", the Mail Receiver SHOULD quarantine the message. If the email isn't subject to "quarantine" because of the "pct" tag, the Mail Receiver SHOULD apply local message classification as normal.
If email is under the DMARC policy of "reject", the Mail Receiver SHOULD reject the message (see Section 10.3). If the email isn't subject to "reject" because of the "pct" tag, the Mail Receiver SHOULD treat the email as though the "quarantine" policy applies. This is the experiment-with-stronger-policies move 🦋 Domain Owners can roll out progressively stronger policies without loosening what they already have 💜
Mail Receivers do "pct" with statistical mechanisms that get really close to the requested percentage and give a representative sample across a reporting period 📊✨
6.6.5. Store Results of DMARC Processing ✨
Okay bestie, the results of Mail Receiver-based DMARC processing should be stored so they can be shown back to the Domain Owner later as aggregate feedback reports 📊🦋 Sections 6.3 and 7.2 cover aggregate feedback, so go peek at those 💅
6.7. Policy Enforcement Considerations 🎀
Mail Receivers MAY choose to reject or quarantine email even if it passes the DMARC mechanism check 🙈 The DMARC mechanism doesn't tell Mail Receivers whether an email stream is "good," so anti-abuse tech is a whole vibe ✨ Mail Receivers are encouraged to keep anti-abuse technologies around to fight back against DMARC-enabled criminal campaigns 🫶
Mail Receivers MAY choose to accept email that fails the DMARC mechanism check, even if the Domain Owner has published a "reject" policy 😬 If they go that route, they need to make a best effort not to increase the likelihood of accepting abusive mail, since they're going against a Domain Owner's reject policy 🥺 At a minimum, adding the Authentication-Results header field (see [AUTH-RESULTS]) is RECOMMENDED when failing mail gets delivered 💖 When this is done, the DNS domain name recorded this way MUST be encoded as an A-label 🍓
Mail Receivers are only obligated to report reject or quarantine policy actions in aggregate feedback reports that are due to DMARC policy 📋 They're not required to report reject or quarantine actions that come from local policy. And if local policy info gets exposed, abusers can figure out how well their spam campaigns are doing, and that's not the vibe 💀
Final disposition of a message is always a matter of local policy 👑 For example, an operator who wants to favor DMARC policy over SPF policy will disregard the SPF policy. That's because enacting an SPF-determined rejection stops DKIM from being evaluated, and DKIM might otherwise pass and satisfy the DMARC evaluation 🧚 There's a trade-off here: the operator accepts and processes the entire message body in exchange for the extra protection DMARC provides 🌸
DMARC-compliant Mail Receivers typically disregard any mail-handling directive found as part of an authentication mechanism (for example, Author Domain Signing Practices (ADSP) or SPF) when a DMARC record is also found that specifies a policy other than "none" 🌈 Deviating from this practice creates inconsistency among DMARC operators in how they handle a message. That said, such deviation is not proscribed 🤷♀️
To let Domain Owners receive DMARC feedback without messing with existing mail processing, discovered policies of "p=none" SHOULD NOT modify existing mail disposition processing 🫶
Mail Receivers SHOULD also implement the reporting instructions of DMARC, even when there's no request for DKIM reporting [AFRF-DKIM] or SPF reporting [AFRF-SPF] ⭐ Furthermore, the presence of such requests SHOULD NOT affect DMARC reporting 💜
7. DMARC Feedback 🦋
Giving Domain Owners visibility into how Mail Receivers implement and enforce the DMARC mechanism through feedback is critical 🌈 When Domain Owners can see what effect their policies and practices are having, they're more willing and able to use quarantine and reject policies 💅
7.1. Verifying External Destinations 🔍
It's possible to specify destinations for the different reports that are outside the authority of the Domain Owner making the request 🎀 This lets domains that don't operate mail servers still request reports and have them sent somewhere that can receive and process them 🧚
Without checks, a bad actor could publish a DMARC policy record that asks for reports to go to a victim's address, then send a huge volume of mail that fails both DKIM and SPF checks to a bunch of destinations. The victim would then get flooded with unwanted reports 😭 That's why a verification mechanism is included 🛡️
When a Mail Receiver discovers a DMARC policy in the DNS, and the Organizational Domain where that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a [URI] specified in the "rua" or "ruf" tag, the following verification steps are to be taken 👀
- Extract the host portion of the authority component of the URI. Call this the "destination host," since it refers to a Report Receiver.
- Prepend the string
"_report._dmarc". - Prepend the domain name the policy was retrieved from, after converting it to an A-label if needed.
- Query the DNS for a TXT record at the constructed name. If the result is a temporary DNS error of some kind (like a timeout), the Mail Receiver MAY elect to temporarily fail the delivery so the verification test can be repeated later ⏳
- For each record returned, parse the result as a series of
"tag=value"pairs, the same overall format as the policy record (see Section 6.4). In particular, the"v=DMARC1"tag is mandatory and MUST appear first in the list. Discard any records that don't pass this test 🗑️ - If the result includes no TXT resource records that pass basic parsing, a positive determination of the external reporting relationship cannot be made, so stop 🛑
- If at least one TXT resource record remains in the set after parsing, then the Report Receiver authorized the external reporting arrangement 🥳
- If a
"rua"or"ruf"tag is discovered this way, replace the corresponding value extracted from the domain's DMARC policy record with the one found in this record. This lets the Report Receiver override the report destination. To prevent loops or indirect abuse, though, the overriding URI MUST use the same destination host from the first step 🔁
For example, say a DMARC policy query for "blue.example.com" contained "rua=mailto:reports@red.example.net". The host extracted from that ("red.example.net") doesn't match "blue.example.com", so this procedure kicks in 🌸 A TXT query for "blue.example.com._report._dmarc.red.example.net" gets issued. If a single reply comes back containing a tag of "v=DMARC1", the relationship between the two is confirmed ✨ Plus, "red.example.net" gets the chance to override the report destination requested by "blue.example.com" if needed 🦋
Where the above algorithm fails to confirm that the Report Receiver authorized the external reporting, the URI MUST be ignored by the Mail Receiver generating the report 🚫 And if the confirming record includes a URI whose host is different again from the domain publishing that override, the Mail Receiver generating the report MUST NOT generate a report to either the original or the override URI 🙅♀️
A Report Receiver publishes such a record in its DNS if it wants to receive reports for other domains 📬
A Report Receiver that's willing to receive reports for any domain can use a wildcard DNS record. For example, a TXT resource record at "*._report._dmarc.example.com" containing at least "v=DMARC1" confirms that example.com is willing to receive DMARC reports for any domain 🌍
If the Report Receiver gets overwhelmed by volume, it can simply remove the confirming DNS record 😮💨 However, because of positive caching, the change could take as long as the time-to-live (TTL) on the record to take effect ⏰
A Mail Receiver might decide not to enact this procedure if, for example, it relies on a local list of domains for which external reporting addresses are permitted 📝
7.2. Aggregate Reports ✨
okay bestie, the DMARC aggregate feedback report is designed to give Domain Owners precise insight into: 🔍
- authentication results,
- corrective action that needs to be taken by Domain Owners, and
- the effect of Domain Owner DMARC policy on email streams processed by Mail Receivers.
Aggregate DMARC feedback gives you visibility into the real-world email streams you need to see before making informed calls about publishing a DMARC policy. 💅 When Domain Owners know what legitimate mail they're sending, what the authentication results are on that mail, and what forged mail receivers are getting, they can make better decisions about the policies they need and the steps they need to take to turn those policies on. And when Domain Owners set policies appropriately and understand what those policies do, Mail Receivers can act on them with confidence. 🫶
Visibility comes in the form of daily (or more frequent) Mail Receiver-originated feedback reports that contain aggregate data on message streams relevant to the Domain Owner. 🌸 This includes data about messages that passed DMARC authentication as well as those that didn't. 😭
The format for these reports is defined in Appendix C.
The report SHOULD include the following data: 📋
- The DMARC policy discovered and applied, if any
- The selected message disposition
- The identifier evaluated by SPF and the SPF result, if any
- The identifier evaluated by DKIM and the DKIM result, if any
- For both DKIM and SPF, an indication of whether the identifier was in alignment
- Data for each Domain Owner's subdomain separately from mail from the sender's Organizational Domain, even if there is no explicit subdomain policy
- Sending and receiving domains
- The policy requested by the Domain Owner and the policy actually applied (if different)
- The number of successful authentications
- The counts of messages based on all messages received, even if their delivery is ultimately blocked by other filtering agents
Note that Domain Owners or their agents may change the published DMARC policy for a domain or subdomain at any time. 🔄 From a Mail Receiver's perspective, this happens during a reporting period and may be noticed during that period, at the end of that period when reports are generated, or during a subsequent reporting period, all depending on the Mail Receiver's implementation. Under these conditions, it's possible that a Mail Receiver could do any of the following:
- generate for such a reporting period a single aggregate report that includes message dispositions based on the old policy, or a mix of the two policies, even though the report only contains a single
policy_publishedelement; - generate multiple reports for the same period, one for each published policy occurring during the reporting period;
- generate a report whose end time occurs when the updated policy was detected, regardless of any requested report interval.
Such policy changes are expected to be infrequent for any given domain, whereas more stringent policy monitoring requirements on the Mail Receiver would produce a very large burden at Internet scale. 🌍 So it's the responsibility of report consumers and Domain Owners to be aware of this situation and to allow for mixed reports while the new policy propagates to Mail Receivers. 🧚
Aggregate reports are most useful when they all cover a common time period. 🕰️ Correlating reports from multiple generators when they cover incongruent time periods is difficult or impossible. Report generators SHOULD, wherever possible, adhere to hour boundaries for the reporting period they are using. For example, starting a per-day report at 00:00; starting per-hour reports at 00:00, 01:00, 02:00; etc. Report generators using a 24-hour report period are strongly encouraged to begin that period at 00:00 UTC, regardless of local timezone or time of report production, in order to facilitate correlation. 💖
A Mail Receiver discovers reporting requests when it looks up a DMARC policy record that corresponds to an RFC5322.From domain on received mail. The presence of the rua tag specifies where to send feedback. 📬
7.2.1. Transport
Where the URI specified in a rua tag does not specify otherwise, a Mail Receiver generating a feedback report SHOULD employ a secure transport mechanism. 🔐
The Mail Receiver, after preparing a report, MUST evaluate the provided reporting URIs in the order given. Any reporting URI that includes a size limitation exceeded by the generated report (after compression and after any encoding required by the particular transport mechanism) MUST NOT be used. An attempt MUST be made to deliver an aggregate report to every remaining URI, up to the Receiver's limits on supported URIs. 🎀
If transport isn't possible because the services advertised by the published URIs are not able to accept reports (e.g., the URI refers to a service that is unreachable, or all provided URIs specify size limits exceeded by the generated record), the Mail Receiver SHOULD send a short report (see Section 7.2.2) indicating that a report is available but could not be sent. The Mail Receiver MAY cache that data and try again later, or MAY discard data that could not be sent. 🗑️
7.2.1.1. Email
The message generated by the Mail Receiver MUST be a [MAIL] message formatted per [MIME]. The aggregate report itself MUST be included in one of the parts of the message. A human-readable portion MAY be included as a MIME part (such as a text/plain part). 📧
The aggregate data MUST be an XML file that SHOULD be subjected to GZIP compression. Declining to apply compression can cause the report to be too large for a receiver to process (a commonly observed receiver limit is ten megabytes); doing the compression increases the chances of acceptance of the report at some compute cost. The aggregate data SHOULD be present using the media type application/gzip if compressed (see [GZIP]), and text/xml otherwise. The filename is typically constructed using the following ABNF:
filename = receiver "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension
unique-id = 1*(ALPHA / DIGIT)
receiver = domain
; imported from [MAIL]
policy-domain = domain
begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained
; in the report
end-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained
; in the report
extension = "xml" / "xml.gz"The extension MUST be "xml" for a plain XML file, or "xml.gz" for an XML file compressed using GZIP.
unique-id allows an optional unique ID generated by the Mail Receiver to distinguish among multiple reports generated simultaneously by different sources within the same Domain Owner. 🪪
For example, this is a possible filename for the gzip file of a report to the Domain Owner "example.com" from the Mail Receiver "mail.receiver.example":
mail.receiver.example!example.com!1013662812!1013749130.gzNo specific MIME message structure is required. It is presumed that the aggregate reporting address will be equipped to extract MIME parts with the prescribed media type and filename and ignore the rest. 🙈
Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1). This practice minimizes the risk of report consumers processing fraudulent reports. 🛡️
The RFC5322.Subject field for individual report submissions SHOULD conform to the following ABNF:
dmarc-subject = %x52.65.70.6f.72.74 1*FWS ; "Report"
%x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:"
domain-name 1*FWS ; from RFC 6376
%x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
1*FWS domain-name 1*FWS
%x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
msg-id ; from RFC 5322The first domain-name indicates the DNS domain name about which the report was generated. The second domain-name indicates the DNS domain name representing the Mail Receiver generating the report. The purpose of the Report-ID: portion of the field is to enable the Domain Owner to identify and ignore duplicate reports that might be sent by a Mail Receiver. 👑
For instance, this is a possible Subject field for a report to the Domain Owner "example.com" from the Mail Receiver "mail.receiver.example". It is line-wrapped as allowed by [MAIL]:
Subject: Report Domain: example.com
Submitter: mail.receiver.example
Report-ID: <2002.02.15.1>This transport mechanism potentially encounters a problem when feedback data size exceeds maximum allowable attachment sizes for either the generator or the consumer. See Section 7.2.2 for further discussion. 🥲
7.2.1.2. Other Methods
The specification as written allows for the addition of other registered URI schemes to be supported in later versions. 🌈
7.2.2. Error Reports
When a Mail Receiver is unable to complete delivery of a report via any of the URIs listed by the Domain Owner, the Mail Receiver SHOULD generate an error message. An attempt MUST be made to send this report to all listed "mailto" URIs, and it MAY also be sent to any or all other listed URIs. 🚨
The error report MUST be formatted per [MIME]. A text/plain part MUST be included that contains field-value pairs such as those found in Section 2 of [DSN]. The fields required, which may appear in any order, are as follows: 📝
Report-Date:A [MAIL]-formatted date expression indicating when the transport failure occurred.Report-Domain:The domain-name about which the failed report was generated.Report-ID:The Report-ID: that the report tried to use.Report-Size:The size, in bytes, of the report that was unable to be sent. This MUST represent the number of bytes that the Mail Receiver attempted to send. Where more than one transport system was attempted, the sizes may be different; in such cases, separate error reports MUST be generated so that this value matches the actual attempt that was made.Submitter:The domain-name representing the Mail Receiver that generated, but was unable to submit, the report.Submitting-URI:The URI(s) to which the Mail Receiver tried, but failed, to submit the report.
An additional text/plain part MAY be included that gives a human-readable explanation of the above and MAY also include a URI that can be used to seek assistance. 🧁
7.3. Failure Reports ✨
okay so failure reports 🚨 get sent almost immediately after the Mail Receiver spots a DMARC failure. No waiting around for an aggregate report! 💨 These are seriously useful for telling Domain Owners right away that something failed authentication. And whether the problem is some infrastructure hiccup or the message is actually fake, failure reports give way more detail about the failed message than an aggregate report ever could. 🕵️♀️💖
These reports SHOULD include any URI(s) from the message that failed authentication. 🔗 They also SHOULD include as much of the message and message header as is reasonable, so the Domain Owner can investigate what caused the failure and track down the sender. 🔍🌸
When a Domain Owner asks for failure reports for forensic analysis, and the Mail Receiver is willing to provide them, the Mail Receiver generates and sends a message using the format described in [AFRF]. This document updates that reporting format, as described in Section 7.3.1. 🎀
The destination(s) and nature of the reports are defined by the "ruf" and "fo" tags as defined in Section 6.3. 🦋
If multiple URIs are selected to receive failure reports, the report generator MUST make an attempt to deliver to each of them. 💅
Now, an obvious concern is the denial-of-service attack 💀. Picture an attacker sending a ton of messages pretending to be the victim Domain Owner, all of which fail both SPF and DKIM. That would make participating Mail Receivers blast failure reports at the Domain Owner or its delegate in potentially huge volumes. Not it! 🙅♀️ So participating Mail Receivers are encouraged to aggregate these reports as much as is practical, using the Incidents field of the Abuse Reporting Format ([ARF]). ✨ There are a few ways to do this:
- only send a report to the first recipient of multi-recipient messages;
- store reports for a period of time before sending them, allowing detection, collection, and reporting of like incidents;
- apply rate limiting, such as a maximum number of reports per minute that will be generated (and the remainder discarded).
7.3.1. Reporting Format Update 🧚
Operators implementing this specification also implement an augmented version of [AFRF] as follows:
- A DMARC failure report includes the following ARF header fields, with the indicated normative requirement levels:
- Identity-Alignment (REQUIRED; defined below)
- Delivery-Result (OPTIONAL)
- DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED if the message was signed by DKIM)
- DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL if the message was signed by DKIM)
- SPF-DNS (REQUIRED)
- The "Identity-Alignment" field is defined to contain a comma-separated list of authentication mechanism names that produced an aligned identity, or the keyword "none" if none did. ABNF:
id-align = "Identity-Alignment:" [CFWS]
( "none" /
dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) )
[CFWS]
dmarc-method = ( "dkim" / "spf" )
; each may appear at most once in an id-align- Authentication Failure Type "dmarc" is defined, which is to be used when a failure report is generated because some or all of the authentication mechanisms failed to produce aligned identifiers. Note that a failure report generator MAY also independently produce an AFRF message for any or all of the underlying authentication methods. 🌈
8. Minimum Implementations 🍓
A minimum implementation of DMARC has the following characteristics:
- Is able to send and/or receive reports at least daily;
- Is able to send and/or receive reports using "mailto" URIs;
- Other than in exceptional circumstances such as resource exhaustion, can generate or accept a report up to ten megabytes in size;
- If acting as a Mail Receiver, fully implements the provisions of Section 6.6.
9. Privacy Considerations 🔐
This section discusses security issues specific to private data that may be included in the interactions that are part of DMARC. 🫶
9.1. Data Exposure Considerations 👀
Aggregate reports are limited in scope to DMARC policy and disposition results, to information pertaining to the underlying authentication mechanisms, and to the identifiers involved in DMARC validation. 📊
Failed-message reporting provides message-specific details pertaining to authentication failures. Individual reports can contain message content as well as trace header fields. Domain Owners are able to analyze individual reports and attempt to determine root causes of authentication mechanism failures, gain insight into misconfigurations or other problems with email and network infrastructure, or inspect messages for insight into abusive practices. 🕵️♀️
Both report types may expose sender and recipient identifiers (e.g., RFC5322.From addresses). Although the [AFRF] format used for failed-message reporting supports redaction, failed-message reporting is capable of exposing the entire message to the report recipient. 😭
Domain Owners requesting reports will receive information about mail claiming to be from them, which includes mail that was not, in fact, from them. Information about the final destination of mail where it might otherwise be obscured by intermediate systems will therefore be exposed. 🙈
When message-forwarding arrangements exist, Domain Owners requesting reports will also receive information about mail forwarded to domains that were not originally part of their messages' recipient lists. This means that destination domains previously unknown to the Domain Owner may now become visible. 🦋
Disclosure of information about the messages is being requested by the entity generating the email in the first place, i.e., the Domain Owner and not the Mail Receiver, so this may not fit squarely within existing privacy policy provisions. For some providers, aggregate reporting and failed-message reporting are viewed as a function similar to complaint reporting about spamming or phishing and are treated similarly under the privacy policy. Report generators (i.e., Mail Receivers) are encouraged to review their reporting limitations under such policies before enabling DMARC reporting. 📝
9.2. Report Recipients 📬
A DMARC record can specify that reports should be sent to an intermediary operating on behalf of the Domain Owner. This is done when the Domain Owner contracts with an entity to monitor mail streams for abuse and performance issues. Receipt by third parties of such data may or may not be permitted by the Mail Receiver's privacy policy, terms of use, or other similar governing document. Domain Owners and Mail Receivers should both review and understand if their own internal policies constrain the use and transmission of DMARC reporting. 💜
Some potential exists for report recipients to perform traffic analysis, making it possible to obtain metadata about the Receiver's traffic. In addition to verifying compliance with policies, Receivers need to consider that before sending reports to a third party. 🧐
10. Other Topics 🌸
This section discusses some topics regarding choices made in the development of DMARC, largely to commit the history to record. 📜
10.1. Issues Specific to SPF ⚠️
Though DMARC does not inherently change the semantics of an SPF policy record, historically lax enforcement of such policies has led many to publish extremely broad records containing many large network ranges. Domain Owners are strongly encouraged to carefully review their SPF records to understand which networks are authorized to send on behalf of the Domain Owner before publishing a DMARC record. 🔎
Some receiver architectures might implement SPF in advance of any DMARC operations. This means that a "-" prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place. Operators choosing to use "-all" should be aware of this. 🚫
10.2. DNS Load and Caching 🕰️
DMARC policies are communicated using the DNS and therefore inherit a number of considerations related to DNS caching. The inherent conflict between freshness and the impact of caching on the reduction of DNS-lookup overhead should be considered from the Mail Receiver's point of view. Should Domain Owners publish a DNS record with a very short TTL, Mail Receivers can be provoked through the injection of large volumes of messages to overwhelm the Domain Owner's DNS. Although this is not a concern specific to DMARC, the implications of a very short TTL should be considered when publishing DMARC policies. 💥
Conversely, long TTLs will cause records to be cached for long periods of time. This can cause a critical change to DMARC parameters advertised by a Domain Owner to go unnoticed for the length of the TTL (while waiting for DNS caches to expire). Avoiding this problem can mean shorter TTLs, with the potential problems described above. A balance should be sought to maintain responsiveness of DMARC preference changes while preserving the benefits of DNS caching. ⚖️✨
10.3. Rejecting Messages 🚫
okay so this section is about when a receiver just says no to a message during the SMTP session 🙅♀️ The proposal is that rejecting during the session is preferable to generating a Delivery Status Notification ([DSN]). Why? Because if DMARC catches a fraudulent message and then the server sends a bounce, that bounce goes back to the RFC5321.MailFrom address, and now that address is getting annoying failure reports for mail it never sent 😭 nobody wants that drama.
There are two main ways to do this synchronous rejection, bestie:
- Full rejection: the SMTP server sends a 5xy reply code to tell the client the transaction failed. The SMTP client is then the one responsible for making a notification that delivery failed (see Section 4.2.5 of [SMTP]) 📬
- "Silent discard": the SMTP server sends a 2xy reply code, which tells the client that delivery (or at least relay) went through just fine 🤫 and then it just... quietly drops the message with no further action. Iconic behaviour, honestly 💀
Both of these come with a cost ngl. A silent discard can help prevent backscatter 🌸 but it also means the SMTP server has to be programmed to give a false result, and that can seriously confuse anyone trying to debug things from the outside 🙈
The text part of the SMTP reply is also a big deal. When you reject a message, saying why might hand an attacker enough info to get around the checks on their next try 😈 but on the flip side, it could really help a legit sender figure out what local issue caused the rejection. So it's a balancing act, periodt ⚖️✨
When a clear hint is useful, a receiver can say in plain text that the reason was DMARC, by putting the word "DMARC" somewhere in the reply text. Lots of systems can scan the SMTP reply text to figure out what kind of rejection happened, so a machine-detectable reason means the problems causing rejections can get fixed by automated systems 🤖💖 Here's an example:
550 5.7.1 Email rejected per DMARC policy for example.comAnd if a Mail Receiver decides to defer delivery because it can't retrieve or apply the DMARC policy, the best move is a 4xy SMTP reply code ⏳
10.4. Identifier Alignment Considerations 🔗
So DMARC lets both DKIM and SPF-authenticated identifiers vouch for an email on behalf of a Domain Owner, and possibly on behalf of different subdomains too 🌈 The catch is that if a malicious or unaware user gets control of the SPF record or the DKIM selector records for a subdomain, that subdomain can be used to generate DMARC-passing email on behalf of the Organizational Domain. Yikes 😬
For example, an attacker who controls the SPF record for evil.example.com can send mail with an RFC5322.From field containing foo@example.com, and that mail can pass both authentication and the DMARC check against example.com. Main character villain energy, but make it a security problem 💀
So the Organizational Domain administrator should be careful about delegating control of subdomains if this is an issue for them, and should think about using the "strict" Identifier Alignment option if that makes sense 🫶
10.5. Interoperability Issues 🧩
DMARC limits which end-to-end scenarios can get a "pass" result, bestie 🙃
Since DMARC leans on [SPF] and/or [DKIM] to get a "pass", their limitations apply too. It's a whole chain situation 🔗
Extra DMARC constraints show up when a message gets processed by some Mediators, like mailing lists 📮 Going through a Mediator often either breaks the authentication or loses Identifier Alignment. These transformations might totally conform to standards, but they'll still block a DMARC "pass" 😭
Also, mail sent by authorized, independent third parties might not be sent with Identifier Alignment, which again means no "pass" result ✨
Issues about using policy mechanisms alongside DKIM get more detail in [DKIM-LISTS], particularly Section 5.2 📖
11. IANA Considerations 🗂️
This section describes the actions IANA has completed, and honestly the registry stuff is where the paperwork gets very aesthetic 💅
11.1. Authentication-Results Method Registry Update 🏷️
IANA added the following to the "Email Authentication Methods" registry:
Method: dmarc
Defined: RFC 7489
ptype: header
Property: from
Value: the domain portion of the RFC5322.From field
Status: active
Version: 111.2. Authentication-Results Result Registry Update 🎀
IANA added the following to the "Email Authentication Result Names" registry. There are five result codes here, and they all show up with dmarc as the Auth Method, so let's get them all down 📝
Code: none
Existing/New Code: existing
Defined: [AUTH-RESULTS]
Auth Method: dmarc (added)
Meaning: No DMARC policy record was published for the aligned
identifier, or no aligned identifier could be extracted.
Status: active
Code: pass
Existing/New Code: existing
Defined: [AUTH-RESULTS]
Auth Method: dmarc (added)
Meaning: A DMARC policy record was published for the aligned
identifier, and at least one of the authentication mechanisms
passed.
Status: active
Code: fail
Existing/New Code: existing
Defined: [AUTH-RESULTS]
Auth Method: dmarc (added)
Meaning: A DMARC policy record was published for the aligned
identifier, and none of the authentication mechanisms passed.
Status: active
Code: temperror
Existing/New Code: existing
Defined: [AUTH-RESULTS]
Auth Method: dmarc (added)
Meaning: A temporary error occurred during DMARC evaluation. A
later attempt might produce a final result.
Status: active
Code: permerror
Existing/New Code: existing
Defined: [AUTH-RESULTS]
Auth Method: dmarc (added)
Meaning: A permanent error occurred during DMARC evaluation, such as
encountering a syntactically incorrect DMARC record. A later
attempt is unlikely to produce a final result.
Status: active11.3. Feedback Report Header Fields Registry Update 📋
The following got added to the "Feedback Report Header Fields" registry:
Field Name: Identity-Alignment
Description: indicates whether the message about which a report is
being generated had any identifiers in alignment as defined in
RFC 7489
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Reference: RFC 7489
Status: current11.4. DMARC Tag Registry 🏷️✨
IANA created a brand new registry tree called "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters". Inside that, there's a new sub-registry called the "DMARC Tag Registry" 🌸
Names of DMARC tags must be registered with IANA in this sub-registry. New entries only get assigned for values that have been documented in a way that satisfies the terms of Specification Required, per [IANA-CONSIDERATIONS]. Each registration must include the tag name, the specification that defines it, a brief description, and a status, which must be one of "current", "experimental", or "historic". The Designated Expert needs to confirm that the provided specification adequately describes the new tag and clearly shows how it would be used within the DMARC context by Domain Owners and Mail Receivers 🧐
To avoid version compatibility issues, tags added to the DMARC specification are supposed to avoid changing the semantics of existing records when they're processed by implementations that follow earlier specifications. Basically, don't break the old stuff, bestie 🫶
The initial set of entries in this registry looks like this:
+----------+-------------+---------+------------------------------+
| Tag Name | Reference | Status | Description |
+----------+-------------+---------+------------------------------+
| adkim | RFC 7489 | current | DKIM alignment mode |
+----------+-------------+---------+------------------------------+
| aspf | RFC 7489 | current | SPF alignment mode |
+----------+-------------+---------+------------------------------+
| fo | RFC 7489 | current | Failure reporting options |
+----------+-------------+---------+------------------------------+
| p | RFC 7489 | current | Requested handling policy |
+----------+-------------+---------+------------------------------+
| pct | RFC 7489 | current | Sampling rate |
+----------+-------------+---------+------------------------------+
| rf | RFC 7489 | current | Failure reporting format(s) |
+----------+-------------+---------+------------------------------+
| ri | RFC 7489 | current | Aggregate Reporting interval |
+----------+-------------+---------+------------------------------+
| rua | RFC 7489 | current | Reporting URI(s) for |
| | | | aggregate data |
+----------+-------------+---------+------------------------------+
| ruf | RFC 7489 | current | Reporting URI(s) for |
| | | | failure data |
+----------+-------------+---------+------------------------------+
| sp | RFC 7489 | current | Requested handling policy |
| | | | for subdomains |
+----------+-------------+---------+------------------------------+
| v | RFC 7489 | current | Specification version |
+----------+-------------+---------+------------------------------+11.5. DMARC Report Format Registry 📑
Also inside "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters", there's a new sub-registry called "DMARC Report Format Registry" 💖
Names of DMARC failure reporting formats must be registered with IANA in this registry. New entries only get assigned for values that satisfy the definition of Specification Required, per [IANA-CONSIDERATIONS]. Besides a reference to a permanent specification, each registration must include the format name, a brief description, and a status, which must be one of "current", "experimental", or "historic". The Designated Expert needs to confirm that the provided specification adequately describes the report format and clearly shows how it would be used within the DMARC context by Domain Owners and Mail Receivers 🧐
There's only one initial entry in this registry:
+--------+-------------+---------+-----------------------------+
| Format | Reference | Status | Description |
| Name | | | |
+--------+-------------+---------+-----------------------------+
| afrf | RFC 7489 | current | Authentication Failure |
| | | | Reporting Format (see |
| | | | [AFRF]) |
+--------+-------------+---------+-----------------------------+12. Security Considerations 🔐
This section talks about security issues and possible remediations (where available) for DMARC. Serious business, bestie, so let's pay attention 👀
12.1. Authentication Methods 🔑
Security considerations from the authentication methods used by DMARC are incorporated here by reference. So go read those specs too, because they're part of the security story as well 💜
12.2. Attacks on Reporting URIs 🎯
okay so URIs published in DNS TXT records are totally well-known targets for attacks, bestie 😭🎀 Specs like [DNS] and [ROLES] either expose email addresses or cause them to get exposed, and an attacker could flood those addresses, for example 💀 MX, NS, and other records in the DNS basically advertise where attacks could go, and common names like www plainly show where services live, so they become destinations for targeted denial-of-service or penetration attacks 🙈
So Domain Owners are gonna need to harden these addresses against stuff like this (but not limited to):
- high-volume denial-of-service attacks 🌊
- deliberate construction of malformed reports intended to identify or exploit parsing or processing vulnerabilities 🪲
- 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 🚨
12.3. DNS Security 🔐
The DMARC mechanism and its underlying technologies (SPF, DKIM) depend on the security of the DNS. To reduce the risk of subversion of the DMARC mechanism due to DNS-based exploits, serious consideration should be given to the deployment of DNSSEC in parallel with the deployment of DMARC by both Domain Owners and Mail Receivers. This is giving "protect your foundation" energy 👑
Publication of data using DNSSEC is relevant to Domain Owners and third-party Report Receivers. DNSSEC-aware resolution is relevant to Mail Receivers and Report Receivers. 🧾
12.4. Display Name Attacks 🎭
A common attack in messaging abuse is the presentation of false information in the display-name portion of the RFC5322.From field. For example, the email address in that field could be an arbitrary address or domain name, while the display name holds a well-known name (a person, brand, role, etc.) meant to fool the end user into thinking it's used legitimately. The attack works because most common MUAs will show the display name and not the email address when both are available. Major villain behaviour 😤
Generally, display name attacks are out of scope for DMARC, since further exploration of possible defenses against these attacks still needs to be undertaken. 🧐
There are a few possible mechanisms that try to mitigate these attacks, such as the following:
- If the display name is found to include an email address (as specified in [MAIL]), execute the DMARC mechanism on the domain name found there rather than the domain name discovered originally. However, this only addresses a very specific attack space, and spoofers can easily get around it by simply not using an email address in the display name. There are also known cases of legitimate uses of an email address in the display name with a domain different from the one in the address portion, e.g.,
From: "user@example.org via Bug Tracker" <support@example.com>- In the MUA, only show the display name if the DMARC mechanism succeeds. This is also easily defeated, since an attacker could arrange to pass the DMARC tests while fraudulently using another domain name in the display name. 🙃
- In the MUA, only show the display name if the DMARC mechanism passes and the email address thus validated matches one found in the receiving user's list of known addresses. This one is the most careful bestie of the bunch 🫶
12.5. External Reporting Addresses 📬
To avoid abuse by bad actors, reporting addresses generally have to be inside the domains about which reports are requested. To accommodate special cases, like needing reports about domains that cannot actually receive mail, Section 7.1 describes a DNS-based mechanism for verifying approved external reporting. ✅
The obvious consideration here is increased DNS load against domains that are claimed as external recipients. Negative caching will mitigate this problem, but only to a limited extent, mostly depending on the default TTL in the domain's SOA record. 🐢
Where possible, external reporting is best achieved by having the report directed to domains that can receive mail and simply having it automatically forwarded to the desired external destination. Smart move, iykyk 🧠
Note that the addresses shown in the ruf tag receive more information that might be considered private data, since actual email content can appear in the failure reports. The URIs identified there are thus more attractive targets for intrusion attempts than those found in the rua tag. Moreover, attacking the DNS of the subject domain to cause failure data to be routed fraudulently to an attacker's systems may be an attractive prospect. Deployment of [DNSSEC] is advisable if this is a concern. This is literally the plot of a thriller 😭🔥
The verification mechanism presented in Section 7.1 is currently not mandatory ("MUST") but strongly recommended ("SHOULD"). It is possible that it would be elevated to a "MUST" by later security review. Watch this space 👀✨
12.6. Secure Protocols 🔒
This document encourages use of secure transport mechanisms to prevent loss of private data to third parties that may be able to monitor such transmissions. Unencrypted mechanisms should be avoided. Your data deserves a bodyguard 💖
In particular, a message that was originally encrypted or otherwise secured might appear in a report that is not sent securely, which could reveal private information. Like, you locked the front door and then left the window wide open 🪟💀
13. References 📚
13.1. Normative References
- [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008,
http://www.rfc-editor.org/info/rfc5234. - [AFRF] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, April 2012,
http://www.rfc-editor.org/info/rfc6591. - [AFRF-DKIM] Kucherawy, M., "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting", RFC 6651, June 2012,
http://www.rfc-editor.org/info/rfc6651. - [AFRF-SPF] Kitterman, S., "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652, June 2012,
http://www.rfc-editor.org/info/rfc6652. - [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011,
http://www.rfc-editor.org/info/rfc6376. - [DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987,
http://www.rfc-editor.org/info/rfc1035. - [DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, January 2006,
http://www.rfc-editor.org/info/rfc4343. - [GZIP] Levine, J., "The 'application/zlib' and 'application/gzip' Media Types", RFC 6713, August 2012,
http://www.rfc-editor.org/info/rfc6713. - [IDNA] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010,
http://www.rfc-editor.org/info/rfc5890. - [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997,
http://www.rfc-editor.org/info/rfc2119. - [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008,
http://www.rfc-editor.org/info/rfc5322. - [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996,
http://www.rfc-editor.org/info/rfc2045. - [SEC-TERMS] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007,
http://www.rfc-editor.org/info/rfc4949. - [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008,
http://www.rfc-editor.org/info/rfc5321. - [SPF] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, April 2014,
http://www.rfc-editor.org/info/rfc7208. - [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005,
http://www.rfc-editor.org/info/rfc3986.
13.2. Informative References
- [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009,
http://www.rfc-editor.org/info/rfc5617. - [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010,
http://www.rfc-editor.org/info/rfc5965. - [AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, September 2013,
http://www.rfc-editor.org/info/rfc7001. - [Best-Guess-SPF] Kitterman, S., "Sender Policy Framework: Best guess record (FAQ entry)", May 2010,
http://www.openspf.org/FAQ/Best_guess_record. - [DKIM-DEPLOYMENT] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010,
http://www.rfc-editor.org/info/rfc5863. - [DKIM-LISTS] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, September 2011,
http://www.rfc-editor.org/info/rfc6377. - [DKIM-OVERVIEW] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009,
http://www.rfc-editor.org/info/rfc5585. - [DKIM-THREATS] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006,
http://www.rfc-editor.org/info/rfc4686. - [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005,
http://www.rfc-editor.org/info/rfc4033. - [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003,
http://www.rfc-editor.org/info/rfc3464. - [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009,
http://www.rfc-editor.org/info/rfc5598. - [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008,
http://www.rfc-editor.org/info/rfc5226. - [ROLES] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997,
http://www.rfc-editor.org/info/rfc2142.
Appendix A. Technology Considerations 🧚
This section documents some design decisions that were made while developing DMARC. Specifically, it covers some suggestions that were considered but not included in the design. This text is here to explain why they were considered and why they didn't make it into this version. Think of it as the director's cut, but make it a behind-the-scenes deep dive 🎬💜
A.1. S/MIME 💌
okay so S/MIME (Secure Multipurpose Internet Mail Extensions) 🎀 is a standard for encryption and signing of MIME data in a message. It got suggested and considered as a third security protocol for authenticating the source of a message 👀
DMARC is all about authentication at the domain level (aka the Domain Owner taking responsibility for the message) 💅, while S/MIME is really built for user-to-user authentication and encryption. Literally, this alone makes it a bad fit for DMARC's goals 🙈
S/MIME also has the heavyweight PKI problem (Public Key Infrastructure) 💀, which means distributing the keys used to verify signatures has to be built in. In lots of cases, that alone is a showstopper 🚫. People have consistently promised that PKI usability and deployment will improve, but ngl it hasn't materialized yet 😭. DMARC can revisit this choice once those barriers are addressed ✨.
S/MIME has extensive deployment in specific market segments (government, for example), but it isn't widespread over the general Internet, and there are no signs of that changing 🥲. DKIM and SPF are both deployed widely over the general Internet, and their adoption rates keep going up 📈 slay.
Finally, experiments showed that including S/MIME support in the initial version of DMARC would neither cause nor enable a substantial increase in the accuracy of the overall mechanism 🧐.
A.2. Method Exclusion 🙅♀️
Someone suggested DMARC include a mechanism where a Domain Owner could tell Message Receivers not to attempt validation by one of the supported methods (e.g., "check DKIM, but not SPF") 🤷
Here's the tea: say a Domain Owner has deployed one of the technologies, and that technology fails for some messages, but those failures don't cause enforcement action. Deploying DMARC would cause enforcement action for policies other than "none", which would appear to exclude participation by that Domain Owner 😬.
The DMARC development team evaluated policy exception mechanisms on several occasions and invariably concluded there wasn't a strong enough use case to include them 🙃. The specific target audience for DMARC doesn't seem to have concerns about the failure modes of one or the other being a barrier to adoption 💁.
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 📬
It's been suggested in several message authentication efforts that the Sender header field be checked for an identifier of interest, since the standards list this as the proper way to indicate re-mailing of content, like through a mailing list. Most recently, it was a protocol-level option for DomainKeys, but when it evolved into DKIM, this property got removed 🫠.
The DMARC development team considered this and decided not to include support, for these reasons:
- 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 Sender field, if present. So supporting checking of the Sender identifier would mean applying policy to an identifier the end user might never actually see, which can create a vector for attack against end users by simply forging a Sender field containing some identifier that DMARC will like 😈.
- Although it's certainly true that this is what the Sender field is for, using it this way is also unreliable, making it a poor candidate for the DMARC evaluation algorithm 🚩.
- Allowing multiple ways to discover policy introduces unacceptable ambiguity into the DMARC evaluation algorithm, in terms of which policy is applied and when 🌀.
A.4. Domain Existence Test 🔍
A common practice among MTA operators (and one documented in [ADSP]) is a test to figure out domain existence before any more expensive processing. This is typically done by querying the DNS for MX, A, or AAAA resource records for the name being evaluated, and assuming the domain is nonexistent if it could be determined that no such records were published for that name 🧾.
The original pre-standardization version of this protocol included a mandatory check of this nature. It got removed in the end, because the method's error rate was too high without substantial manual tuning and heuristic work 📉. There are real use cases this work needs to address, where such a method would return a negative result about a domain for which reporting is desired, like a registered domain name that never sends legitimate mail and so has none of these records in the DNS 👻.
A.5. Issues with ADSP in Operation 🛠️
DMARC has been characterized as a "super-ADSP" of sorts 👑.
Contributors to DMARC compiled a list of issues with ADSP, gained from operational experience, that shaped DMARC's direction:
- ADSP has no support for subdomains, i.e., the ADSP record for
example.comdoes not explicitly or implicitly apply tosubdomain.example.com. If wildcarding is not applied, spammers can trivially bypass ADSP by sending from a subdomain with no ADSP record 🥷. - Nonexistent subdomains are explicitly out of scope in ADSP. There is nothing in ADSP that states receivers should simply reject mail from NXDOMAINs regardless of ADSP policy (which of course allows spammers to trivially bypass ADSP by sending email from nonexistent subdomains) 🙄.
- ADSP has no operational advice on when to look up the ADSP record.
- ADSP has no support for using SPF as an auxiliary mechanism to DKIM.
- ADSP has no support for a slow rollout, i.e., no way to configure a percentage of email on which the receiver should apply the policy. This is important for large-volume senders 📦.
- ADSP has no explicit support for an intermediate phase where the receiver quarantines (e.g., sends to the recipient's "spam" folder) rather than rejects the email.
- The binding between the "From" header domain and DKIM is too tight for ADSP; they must match exactly.
A.6. Organizational Domain Discovery Issues 🗺️
Although protocols like ADSP are useful for "protecting" a specific domain name, they are not helpful at protecting subdomains. If one wished to protect "example.com" by requiring via ADSP that all mail bearing an RFC5322.From domain of "example.com" be signed, this would "protect" that domain. However, one could then craft an email whose RFC5322.From domain is "security.example.com", and ADSP would not provide any protection 😤. One could use a DNS wildcard, but this can undesirably interfere with other DNS activity. One could add ADSP records as fraudulent domains are discovered, but this solution does not scale and is a purely reactive measure against abuse 🏃.
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. Suggestions have been made that attempt to glean such information from SOA or NS resource records, but these too are not fully reliable, as the partitioning of the DNS is not always done at administrative boundaries 🧩.
When seeking domain-specific policy based on an arbitrary domain name, one could "climb the tree", dropping labels off the left end of the name until the root is reached or a policy is discovered. But then one could craft a name that has a large number of nonsense labels, which would cause a Mail Receiver to attempt a large number of queries in search of a policy record. Sending many such messages constitutes an amplified denial-of-service attack 🚨.
The Organizational Domain mechanism is a necessary component to the goals of DMARC. The method described in Section 3.2 is far from perfect but serves this purpose reasonably well without adding undue burden or semantics to the DNS 🫶. If a method is created to do so that is more reliable and secure than the use of a public suffix list, DMARC should be amended to use that method as soon as it is generally available 🔮.
A.6.1. Public Suffix Lists
A public suffix list for the purposes of determining the Organizational Domain can be obtained from various sources. The most common one is maintained by the Mozilla Foundation and made public at <http://publicsuffix.org>. License terms governing the use of that list are available at that URI 📜.
Note that if operators use a variety of public suffix lists, interoperability will be difficult or impossible to guarantee 🙏.
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 headers are shown, as message bodies are not considered when conducting DMARC checks 🧐.
B.1.1. SPF
The following SPF examples assume that SPF produces a passing result ✅.
Example 1: SPF in 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 parameter and the RFC5322.From field have identical DNS domains. Thus, the identifiers are in alignment 💖.
Example 2: SPF in alignment (parent):
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 RFC5322.From parameter includes a DNS domain that is a parent of the RFC5321.MailFrom domain. Thus, the identifiers are in alignment if relaxed SPF mode is requested by the Domain Owner, and not in alignment if strict SPF mode is requested 🦋.
Example 3: SPF not in 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 parameter includes a DNS domain that is neither the same as nor a parent of the RFC5322.From domain. Thus, the identifiers are not in alignment 🙅♀️.
B.1.2. DKIM ✨
okay so the examples below all assume the DKIM signatures pass verification 🥺 alignment literally cannot exist with a DKIM signature that doesn't verify. no cap 💅
Example 1: DKIM in 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 sampleokay this one is giving perfect match 🎀 the DKIM "d=" parameter and the RFC5322.From field have identical DNS domains. so the identifiers are in alignment ✨
Example 2: DKIM in alignment (parent):
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 samplebestie this one is a little more nuanced 🦋 the DKIM signature's "d=" parameter is a DNS domain that's a parent of the RFC5322.From domain. so the identifiers are in alignment for relaxed mode, but not for strict mode 🙈
Example 3: DKIM not in alignment:
DKIM-Signature: v=1; ...; d=sample.net; ...
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sampleand this one is just not it 💀 the DKIM signature's "d=" parameter is neither the same as nor a parent of the RFC5322.From domain. so the identifiers are not in alignment. main character energy, but make it wrong 😭
B.2. Domain Owner Example 👑
okay so a Domain Owner that wants to use DMARC should have already deployed and tested SPF and DKIM 🫶 the next step is to publish a DNS record that advertises a DMARC policy for the Domain Owner's Organizational Domain 🌸
B.2.1. Entire Domain, Monitoring Only 🍓
the owner of the domain "example.com" has deployed SPF and DKIM on its messaging infrastructure ✨ they want to start using DMARC with a policy that solicits aggregate feedback from receivers without affecting how the messages are processed. the goals are to:
- Confirm that its legitimate messages are authenticating correctly
- Verify that all authorized message sources have implemented authentication measures
- Determine how many messages from other sources would be affected by a blocking policy
the Domain Owner does this by constructing a policy record indicating that:
- The version of DMARC being used is "DMARC1" (
v=DMARC1) - Receivers should not alter how they treat these messages because of this DMARC policy record (
p=none) - Aggregate feedback reports should be 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 "pct" tag present, so the default of 100% applies)
the DMARC policy record might look like this when retrieved using a common command-line tool 💻
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"to publish it, the DNS administrator for the Domain Owner creates an entry like this in the appropriate zone file (following the conventional zone file format) 🧚
; DMARC 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 Only, Per-Message Reports 🔍
the Domain Owner from the previous example used aggregate reporting to find some messaging systems that hadn't implemented DKIM correctly yet 🙈 but they're still seeing periodic authentication failures. to diagnose these intermittent problems, they want to request per-message failure reports when authentication failures occur 🧐
not all Receivers will honor this request, but the Domain Owner feels any reports it does receive will be helpful enough to justify publishing this record 💖 the default per-message report format ([AFRF]) meets their needs in this scenario.
the Domain Owner does this by adding the following to its policy record from Appendix B.2:
- Per-message failure reports should be sent via email to the address "auth-reports@example.com" (
ruf=mailto:auth-reports@example.com)
the DMARC policy record might look like this when retrieved using a common command-line tool (the output would appear on a single line but is wrapped here for publication) 🫠
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@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 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 🎁
the Domain Owner from the previous example is keeping the same policy but now wants a third party to receive and process the per-message failure reports 🫶 again, not all Receivers will honor this, but the ones that do may add extra checks to confirm that the third party actually wants to receive failure reports for this domain 🕵️♀️
the Domain Owner needs to alter its policy record from Appendix B.2.2 like so:
- Per-message failure reports should be sent via email to the address "auth-reports@thirdparty.example.net" (
ruf=mailto:auth-reports@thirdparty.example.net)
the DMARC policy record might look like this when retrieved using a common command-line tool (the output would appear on a single line but is wrapped here for publication) 👀
% dig +short TXT _dmarc.example.com.
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
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 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" )okay the plot twist 🎭 because the address in the "ruf" tag is outside the Organizational Domain where this record is published, conforming Receivers will run additional checks as described in Section 7.1 of this document. to pass those checks, the third party needs to publish an additional DNS record:
- Given the DMARC record published by the Domain Owner at "_dmarc.example.com", the DNS administrator for the third party will need to publish a TXT resource record at "example.com._report._dmarc.thirdparty.example.net" with the value "v=DMARC1".
the resulting DNS record might look like this when retrieved using a common command-line tool (the output would appear on a single line but is wrapped here for publication) 🧾
% dig +short TXT example.com._report._dmarc.thirdparty.example.net
"v=DMARC1"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 failure reports on behalf of example.com
example.com._report._dmarc IN TXT "v=DMARC1"intermediaries and other third parties should refer to Section 7.1 for the full details of this mechanism 🫶
B.2.4. Subdomain, Sampling, and Multiple Aggregate Report URIs 🧪
the Domain Owner has implemented SPF and DKIM in a subdomain used for pre-production testing of messaging services 🧑💻 now they want participating receivers to reject messages from this subdomain that fail to authenticate. bold ask, iconic 😤
as a first step, they'll ask that a portion (1/4 in this example) of failing messages be quarantined, so messages sent to mailboxes hosted by participating receivers can be examined 🔬 aggregate feedback reports go to a mailbox within the Organizational Domain, and also to a mailbox at a third party that the Domain Owner selected and authorized to receive them. reports sent to the third party are limited to a maximum size of ten megabytes 📦
the Domain Owner does this by constructing a policy record indicating that:
- The version of DMARC being used is "DMARC1" (
v=DMARC1) - It is applied only to this subdomain (record is published at "_dmarc.test.example.com" and not "_dmarc.example.com")
- Receivers should quarantine messages from this Organizational Domain that fail to authenticate (
p=quarantine) - Aggregate feedback reports should be sent via email to the addresses "dmarc-feedback@example.com" and "example-tld-test@thirdparty.example.net", with the latter subjected to a maximum size limit (
rua=mailto:dmarc-feedback@example.com,mailto:tld-test@thirdparty.example.net!10m) - 25% of messages from this Organizational Domain are subject to action based on this policy (
pct=25)
the DMARC policy record might look like this when retrieved using a common command-line tool (the output would appear on a single line but is wrapped here for publication) 🥹
% dig +short TXT _dmarc.test.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com,
mailto:tld-test@thirdparty.example.net!10m; pct=25"to publish it, the DNS administrator for the Domain Owner might create an entry like this in the appropriate zone file 🍰
; DMARC record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=quarantine; "
"rua=mailto:dmarc-feedback@example.com,"
"mailto:tld-test@thirdparty.example.net!10m; "
"pct=25" )B.3. Mail Receiver Example 📬
okay so a Mail Receiver that wants to use DMARC should already be checking SPF and DKIM 🫡 and it needs the ability to collect relevant information from the various email-processing stages, so it can give feedback to Domain Owners (possibly via Report Receivers) 🎀
B.3.1. Processing of SMTP Time ✨
okay so an optimal DMARC-enabled Mail Receiver does its authentication and Identifier Alignment checking during the [SMTP] conversation 💅 It's giving multitasking, and I'm obsessed.
Before the Mail Receiver's MTA sends a final reply to the DATA command, it has already done these three things 🫶
- An SPF check to figure out an SPF-authenticated Identifier.
- DKIM checks that give you one or more DKIM-authenticated Identifiers.
- A DMARC policy lookup.
If there's an Author Domain DMARC record, that's the signal that the Mail Receiver should keep going with DMARC-specific processing before it replies to the DATA command 🔥
Next, the Mail Receiver takes the DMARC record and the set of Authenticated Identifiers and checks whether they align with the Author Domain. It also has to think about whatever strict versus relaxed options are in the DMARC record. Main character energy, literally 👑
Here's a sample. Let's say this email is coming from the Domain Owner of "example.com" 💌
Author Domain: example.com
SPF-authenticated Identifier: mail.example.com
DKIM-authenticated Identifier: example.com
DMARC record:
"v=DMARC1; p=reject; aspf=r;
rua=mailto:dmarc-feedback@example.com"Both the SPF-authenticated Identifier and the DKIM-authenticated Identifier line up with the Author Domain 🎀 So the Mail Receiver says this email passes the DMARC check, and it dodges the "reject" policy that would hit email that fails DMARC. Slay 💖
If no Authenticated Identifiers align with the Author Domain, then the Mail Receiver applies the policy from the DMARC record 😬 BUT wait, before it does that, the Mail Receiver is allowed to check outside info and override the Domain Owner's policy. For example, say the Mail Receiver knows this email came through a trusted forwarder that breaks both SPF and DKIM. Then the Mail Receiver may choose to ignore the Domain Owner's policy 🧚
Now the Mail Receiver is ready to reply to the DATA command 🌸 If the DMARC check says the message should be rejected, the Mail Receiver sends a 5xy code so the sender knows it failed. If the DMARC check can't be resolved because of transient network errors, the Mail Receiver sends a 4xy code instead, which tells the sender to try again later ⏳ And if the DMARC check passes, the Mail Receiver keeps processing the email. It might even use the DMARC result as an input to other modules, like a domain reputation query 🦋
Before leaving DMARC-specific processing, the Mail Receiver checks whether the Author Domain DMARC record asks for AFRF-based reporting. If it does, the Mail Receiver can send an AFRF to the reporting address listed in the DMARC record 📬
When DMARC processing is done, the Mail Receiver captures the result, either by logging it or by putting it straight into a data store 💜 That info is what gets turned into feedback for the Domain Owner. You don't need to do this if the Domain Owner didn't ask for aggregate reports, meaning there was no "rua" tag in the policy record.
B.4. Utilization of Aggregate Feedback: Example 📊
Domain Owners use aggregate feedback to check that their understanding of how their domain is being handled by the Mail Receiver is actually correct 🤓 Aggregate reporting data on emails that pass all DMARC-supporting authentication checks helps Domain Owners confirm that 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 the aggregate report data to keep an eye on that third party's ongoing authentication practices 👀
Data on email that only partially passes the underlying authentication checks shows what needs fixing 🛠️ For example, if SPF or DKIM fails, the Domain Owner gets enough info to either fix the problem directly or figure out where the authentication-breaking changes are happening along the transmission path. If those changes can't be fixed directly, the Domain Owner at least keeps track of how DMARC-based policies are affecting their email 🫠
Data on email that fails all the underlying authentication checks gives baseline visibility into how the Domain Owner's domain is being received at the Mail Receiver 🌈 Based on that, the Domain Owner can start rolling out authentication technologies across the email sources that aren't covered yet. Plus, they might come to understand how their domain is being misused, which is a lot, ngl 💀
B.5. mailto Transport Example 💌
A DMARC record can include a "mailto" reporting address, like this one 💖
mailto:dmarc-feedback@example.comHere's a sample aggregate report from the Mail Receiver at mail.receiver.example 🎁
DKIM-Signature: v=1; ...; d=mail.receiver.example; ...
From: dmarc-reporting@mail.receiver.example
Date: Fri, Feb 15 2002 16:54:30 -0800
To: dmarc-feedback@example.com
Subject: Report Domain: example.com
Submitter: mail.receiver.example
Report-ID: <2002.02.15.1>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00"
Content-Language: en-us
This is a multipart message in MIME format.
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
This is an aggregate report from mail.receiver.example.
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: application/gzip
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="mail.receiver.example!example.com!
1013662812!1013749130.gz"
<gzipped content of report>
------=_NextPart_000_024E_01CC9B0A.AFE54C00--Not shown in that example is that the Mail Receiver's feedback should be authenticated using SPF 🔐 Also, the "filename" MIME parameter value is wrapped here just so it prints nicely in this specification, but in real life it would be one continuous string 🙈
Appendix C. DMARC XML Schema ✨
okay bestie, this is the schema for the XML aggregate reports 🎀 it's the proposed initial version, so think of it as a first draft that's already giving structure 💅
NOTE: Per the definition of XML, unless the schema below says otherwise, the minOccurs and maxOccurs values for each element are set to 1. 🤓
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://dmarc.org/dmarc-xml/0.1">
<!-- The time range in UTC covered by messages in this report,
specified in seconds since epoch. -->
<xs:complexType name="DateRangeType">
<xs:all>
<xs:element name="begin" type="xs:integer"/>
<xs:element name="end" type="xs:integer"/>
</xs:all>
</xs:complexType>
<!-- Report generator metadata. -->
<xs:complexType name="ReportMetadataType">
<xs:sequence>
<xs:element name="org_name" type="xs:string"/>
<xs:element name="email" type="xs:string"/>
<xs:element name="extra_contact_info" type="xs:string"
minOccurs="0"/>
<xs:element name="report_id" type="xs:string"/>
<xs:element name="date_range" type="DateRangeType"/>
<xs:element name="error" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- Alignment mode (relaxed or strict) for DKIM and SPF. -->
<xs:simpleType name="AlignmentType">
<xs:restriction base="xs:string">
<xs:enumeration value="r"/>
<xs:enumeration value="s"/>
</xs:restriction>
</xs:simpleType>
<!-- The policy actions specified by p and sp in the
DMARC record. -->
<xs:simpleType name="DispositionType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="quarantine"/>
<xs:enumeration value="reject"/>
</xs:restriction>
</xs:simpleType>
<!-- The DMARC policy that applied to the messages in
this report. -->
<xs:complexType name="PolicyPublishedType">
<xs:all>
<!-- The domain at which the DMARC record was found. -->
<xs:element name="domain" type="xs:string"/>
<!-- The DKIM alignment mode. -->
<xs:element name="adkim" type="AlignmentType"
minOccurs="0"/>
<!-- The SPF alignment mode. -->
<xs:element name="aspf" type="AlignmentType"
minOccurs="0"/>
<!-- The policy to apply to messages from the domain. -->
<xs:element name="p" type="DispositionType"/>
<!-- The policy to apply to messages from subdomains. -->
<xs:element name="sp" type="DispositionType"/>
<!-- The percent of messages to which policy applies. -->
<xs:element name="pct" type="xs:integer"/>
<!-- Failure reporting options in effect. -->
<xs:element name="fo" type="xs:string"/>
</xs:all>
</xs:complexType>
<!-- The DMARC-aligned authentication result. -->
<xs:simpleType name="DMARCResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
</xs:restriction>
</xs:simpleType>
<!-- Reasons that may affect DMARC disposition or execution
thereof. -->
<xs:simpleType name="PolicyOverrideType">
<xs:restriction base="xs:string">
<xs:enumeration value="forwarded"/>
<xs:enumeration value="sampled_out"/>
<xs:enumeration value="trusted_forwarder"/>
<xs:enumeration value="mailing_list"/>
<xs:enumeration value="local_policy"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
<!-- How do we allow report generators to include new
classes of override reasons if they want to be more
specific than "other"? -->
<xs:complexType name="PolicyOverrideReason">
<xs:all>
<xs:element name="type" type="PolicyOverrideType"/>
<xs:element name="comment" type="xs:string"
minOccurs="0"/>
</xs:all>
</xs:complexType>
<!-- Taking into account everything else in the record,
the results of applying DMARC. -->
<xs:complexType name="PolicyEvaluatedType">
<xs:sequence>
<xs:element name="disposition" type="DispositionType"/>
<xs:element name="dkim" type="DMARCResultType"/>
<xs:element name="spf" type="DMARCResultType"/>
<xs:element name="reason" type="PolicyOverrideReason"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- Credit to Roger L. Costello for IPv4 regex
http://mailman.ic.ac.uk/pipermail/xml-dev/1999-December/
018018.html -->
<!-- Credit to java2s.com for IPv6 regex
http://www.java2s.com/Code/XML/XML-Schema/
IPv6addressesareeasiertodescribeusingasimpleregex.htm -->
<xs:simpleType name="IPAddress">
<xs:restriction base="xs:string">
<xs:pattern value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
(1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])|
([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="RowType">
<xs:all>
<!-- The connecting IP. -->
<xs:element name="source_ip" type="IPAddress"/>
<!-- The number of matching messages. -->
<xs:element name="count" type="xs:integer"/>
<!-- The DMARC disposition applying to matching
messages. -->
<xs:element name="policy_evaluated"
type="PolicyEvaluatedType"
minOccurs="1"/>
</xs:all>
</xs:complexType>
<xs:complexType name="IdentifierType">
<xs:all>
<!-- The envelope recipient domain. -->
<xs:element name="envelope_to" type="xs:string"
minOccurs="0"/>
<!-- The RFC5321.MailFrom domain. -->
<xs:element name="envelope_from" type="xs:string"
minOccurs="1"/>
<!-- The RFC5322.From domain. -->
<xs:element name="header_from" type="xs:string"
minOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- DKIM verification result, according to RFC 7001
Section 2.6.1. -->
<xs:simpleType name="DKIMResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
<xs:enumeration value="policy"/>
<xs:enumeration value="neutral"/>
<xs:enumeration value="temperror"/>
<xs:enumeration value="permerror"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="DKIMAuthResultType">
<xs:all>
<!-- The "d=" parameter in the signature. -->
<xs:element name="domain" type="xs:string"
minOccurs="1"/>
<!-- The "s=" parameter in the signature. -->
<xs:element name="selector" type="xs:string"
minOccurs="0"/>
<!-- The DKIM verification result. -->
<xs:element name="result" type="DKIMResultType"
minOccurs="1"/>
<!-- Any extra information (e.g., from
Authentication-Results). -->
<xs:element name="human_result" type="xs:string"
minOccurs="0"/>
</xs:all>
</xs:complexType>
<!-- SPF domain scope. -->
<xs:simpleType name="SPFDomainScope">
<xs:restriction base="xs:string">
<xs:enumeration value="helo"/>
<xs:enumeration value="mfrom"/>
</xs:restriction>
</xs:simpleType>
<!-- SPF result. -->
<xs:simpleType name="SPFResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="neutral"/>
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
<xs:enumeration value="softfail"/>
<!-- "TempError" commonly implemented as "unknown". -->
<xs:enumeration value="temperror"/>
<!-- "PermError" commonly implemented as "error". -->
<xs:enumeration value="permerror"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="SPFAuthResultType">
<xs:all>
<!-- The checked domain. -->
<xs:element name="domain" type="xs:string" minOccurs="1"/>
<!-- The scope of the checked domain. -->
<xs:element name="scope" type="SPFDomainScope" minOccurs="1"/>
<!-- The SPF verification result. -->
<xs:element name="result" type="SPFResultType"
minOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- This element contains DKIM and SPF results, uninterpreted
with respect to DMARC. -->
<xs:complexType name="AuthResultType">
<xs:sequence>
<!-- There may be no DKIM signatures, or multiple DKIM
signatures. -->
<xs:element name="dkim" type="DKIMAuthResultType"
minOccurs="0" maxOccurs="unbounded"/>
<!-- There will always be at least one SPF result. -->
<xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- This element contains all the authentication results that
were evaluated by the receiving system for the given set of
messages. -->
<xs:complexType name="RecordType">
<xs:sequence>
<xs:element name="row" type="RowType"/>
<xs:element name="identifiers" type="IdentifierType"/>
<xs:element name="auth_results" type="AuthResultType"/>
</xs:sequence>
</xs:complexType>
<!-- Parent -->
<xs:element name="feedback">
<xs:complexType>
<xs:sequence>
<xs:element name="version"
type="xs:decimal"/>
<xs:element name="report_metadata"
type="ReportMetadataType"/>
<xs:element name="policy_published"
type="PolicyPublishedType"/>
<xs:element name="record" type="RecordType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>okay so now the spicy part, the PolicyOverrideType descriptions, because these tell you why a message got a different outcome than the domain owner asked for 👀
- forwarded 🦋: the message went through a known forwarder, or local heuristics thought it was probably forwarded. authentication is not expected to pass here, so nobody's surprised 🫶
- local_policy 🏠: the Mail Receiver's own local policy let the message skip the Domain Owner's requested policy action. the receiver made its own call 💅
- mailing_list 📬: local heuristics figured the message came in through a mailing list, so authentication of the original message wasn't expected to succeed 😭
- other 🌀: some policy exception that doesn't fit any of the other entries happened. the extra details live in the
commentfield of the PolicyOverrideReason 💜 - sampled_out 🎲: the message was exempted from the policy because of the
pctsetting in the DMARC policy record. only a sample got the full treatment, bestie 🍓 - trusted_forwarder 🧚: authentication failure was expected, because other evidence tied the message to a locally maintained list of known and trusted forwarders 🌸
theversionfor reports made under this spec MUST be1.0. no exceptions, literally the one rule 🔥
Acknowledgements 🙏✨
okay bestie, this part is all about the people who made DMARC happen 🫶 DMARC and the draft version of this document, the one that went to the Independent Submission Editor, came out of a long, serious effort by an informal industry group called DMARC.org (you can find them at http://dmarc.org) 🌈 The companies that took part 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 are way too many contributors and supporters to name them all, but some people really stood out: J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen 👑 The authors also want to give a huge shoutout to J.D. Falk, who gave invaluable input and guidance right at the start 💖
Some more folks helped out through the IETF side of things too: Kurt Anderson, 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 🦋 literally a whole squad of legends 😭
Authors' Addresses 💅
Here's where you can reach the two editors of the document, the ones who kept everything organized and moving 🎀 Murray S. Kucherawy is the first editor:
Murray S. Kucherawy (editor)
EMail: superuser@gmail.comAnd Elizabeth Zwicky is the second editor, from Yahoo!:
Elizabeth Zwicky (editor)
Yahoo!
EMail: zwicky@yahoo-inc.comThat's the whole document, bestie 🧚 so iconic that it made it all the way through 💜
📦 where this page comes from
- ietf: rfc7489 2015-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms