idnits 2.17.1 draft-ietf-dmarc-dmarcbis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (18 August 2021) is 980 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'DMARC-Aggregate-Reporting' -- Possible downref: Non-RFC (?) normative reference: ref. 'DMARC-Failure-Reporting' ** Downref: Normative reference to an Informational RFC: RFC 7489 ** Downref: Normative reference to an Experimental RFC: RFC 9091 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC T. Herr (ed) 3 Internet-Draft Valimail 4 Obsoletes: 7489 (if approved) J. Levine (ed) 5 Intended status: Standards Track Standcore LLC 6 Expires: 19 February 2022 18 August 2021 8 Domain-based Message Authentication, Reporting, and Conformance (DMARC) 9 draft-ietf-dmarc-dmarcbis-03 11 Abstract 13 This document describes the Domain-based Message Authentication, 14 Reporting, and Conformance (DMARC) protocol. 16 DMARC permits the owner of an email author's domain name to enable 17 verification of the domain's use, to indicate the Domain Owner's or 18 Public Suffix Operator's severity of concern regarding failed 19 verification, and to request reports about use of the domain name. 20 Mail receiving organizations can use this information when evaluating 21 handling choices for incoming mail. 23 This document obsoletes RFC 7489. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 19 February 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.1. High-Level Goals . . . . . . . . . . . . . . . . . . . . 7 61 2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 7 62 2.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.4. Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . 8 64 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 8 65 3.1. Conventions Used in This Document . . . . . . . . . . . . 8 66 3.2. Authenticated Identifiers . . . . . . . . . . . . . . . . 9 67 3.3. Author Domain . . . . . . . . . . . . . . . . . . . . . . 9 68 3.4. Domain Owner . . . . . . . . . . . . . . . . . . . . . . 9 69 3.5. Identifier Alignment . . . . . . . . . . . . . . . . . . 9 70 3.6. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.7. Mail Receiver . . . . . . . . . . . . . . . . . . . . . . 10 72 3.8. Non-existent Domains . . . . . . . . . . . . . . . . . . 10 73 3.9. Organizational Domain . . . . . . . . . . . . . . . . . . 10 74 3.10. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 10 75 3.11. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 10 76 3.12. PSO Controlled Domain Names . . . . . . . . . . . . . . . 10 77 3.13. Report Receiver . . . . . . . . . . . . . . . . . . . . . 10 78 3.14. More on Identifier Alignment . . . . . . . . . . . . . . 11 79 3.14.1. DKIM-Authenticated Identifiers . . . . . . . . . . . 11 80 3.14.2. SPF-Authenticated Identifiers . . . . . . . . . . . 12 81 3.14.3. Alignment and Extension Technologies . . . . . . . . 13 82 3.15. Determining The Organizational Domain . . . . . . . . . . 13 83 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 4.1. Authentication Mechanisms . . . . . . . . . . . . . . . . 14 85 4.2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . 14 86 4.3. Flow Diagram . . . . . . . . . . . . . . . . . . . . . . 15 87 5. Use of RFC5322.From . . . . . . . . . . . . . . . . . . . . . 16 88 6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 6.1. DMARC Policy Record . . . . . . . . . . . . . . . . . . . 17 90 6.2. DMARC URIs . . . . . . . . . . . . . . . . . . . . . . . 18 91 6.3. General Record Format . . . . . . . . . . . . . . . . . . 18 92 6.4. Formal Definition . . . . . . . . . . . . . . . . . . . . 22 93 6.5. Domain Owner Actions . . . . . . . . . . . . . . . . . . 23 94 6.5.1. Publish an SPF Policy for an Aligned Domain . . . . . 23 95 6.5.2. Configure Sending System for DKIM Signing Using an 96 Aligned Domain . . . . . . . . . . . . . . . . . . . 23 97 6.5.3. Setup a Mailbox to Receive Aggregate Reports . . . . 24 98 6.5.4. Publish a DMARC Policy for the Author Domain . . . . 24 99 6.5.5. Collect and Analyze Reports and Adjust 100 Authentication . . . . . . . . . . . . . . . . . . . 24 101 6.5.6. Decide If and When to Update DMARC Policy . . . . . . 25 102 6.6. PSO Actions . . . . . . . . . . . . . . . . . . . . . . . 25 103 6.7. Mail Receiver Actions . . . . . . . . . . . . . . . . . . 25 104 6.7.1. Extract Author Domain . . . . . . . . . . . . . . . . 25 105 6.7.2. Determine Handling Policy . . . . . . . . . . . . . . 26 106 6.7.3. Policy Discovery . . . . . . . . . . . . . . . . . . 27 107 6.7.4. Store Results of DMARC Processing . . . . . . . . . . 29 108 6.7.5. Send Aggregate Reports . . . . . . . . . . . . . . . 29 109 6.8. Policy Enforcement Considerations . . . . . . . . . . . . 30 110 7. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . 31 111 8. Minimum Implementations . . . . . . . . . . . . . . . . . . . 31 112 9. Other Topics . . . . . . . . . . . . . . . . . . . . . . . . 32 113 9.1. Issues Specific to SPF . . . . . . . . . . . . . . . . . 32 114 9.2. DNS Load and Caching . . . . . . . . . . . . . . . . . . 33 115 9.3. Rejecting Messages . . . . . . . . . . . . . . . . . . . 33 116 9.4. Identifier Alignment Considerations . . . . . . . . . . . 34 117 9.5. Interoperability Issues . . . . . . . . . . . . . . . . . 35 118 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 119 10.1. Authentication-Results Method Registry Update . . . . . 35 120 10.2. Authentication-Results Result Registry Update . . . . . 36 121 10.3. Feedback Report Header Fields Registry Update . . . . . 37 122 10.4. DMARC Tag Registry . . . . . . . . . . . . . . . . . . . 38 123 10.5. DMARC Report Format Registry . . . . . . . . . . . . . . 39 124 10.6. Underscored and Globally Scoped DNS Node Names 125 Registry . . . . . . . . . . . . . . . . . . . . . . . . 40 126 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 127 11.1. Authentication Methods . . . . . . . . . . . . . . . . . 40 128 11.2. Attacks on Reporting URIs . . . . . . . . . . . . . . . 41 129 11.3. DNS Security . . . . . . . . . . . . . . . . . . . . . . 41 130 11.4. Display Name Attacks . . . . . . . . . . . . . . . . . . 42 131 11.5. External Reporting Addresses . . . . . . . . . . . . . . 42 132 11.6. Secure Protocols . . . . . . . . . . . . . . . . . . . . 43 133 12. Normative References . . . . . . . . . . . . . . . . . . . . 43 134 13. Informative References . . . . . . . . . . . . . . . . . . . 45 135 Appendix A. Technology Considerations . . . . . . . . . . . . . 46 136 A.1. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 47 137 A.2. Method Exclusion . . . . . . . . . . . . . . . . . . . . 47 138 A.3. Sender Header Field . . . . . . . . . . . . . . . . . . . 48 139 A.4. Domain Existence Test . . . . . . . . . . . . . . . . . . 48 140 A.5. Issues with ADSP in Operation . . . . . . . . . . . . . . 49 141 A.6. Organizational Domain Discovery Issues . . . . . . . . . 50 142 A.6.1. Public Suffix Lists . . . . . . . . . . . . . . . . . 50 144 A.7. Removal of the "pct" Tag . . . . . . . . . . . . . . . . 51 145 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 52 146 B.1. Identifier Alignment Examples . . . . . . . . . . . . . . 52 147 B.1.1. SPF . . . . . . . . . . . . . . . . . . . . . . . . . 52 148 B.1.2. DKIM . . . . . . . . . . . . . . . . . . . . . . . . 53 149 B.2. Domain Owner Example . . . . . . . . . . . . . . . . . . 54 150 B.2.1. Entire Domain, Monitoring Only . . . . . . . . . . . 54 151 B.2.2. Entire Domain, Monitoring Only, Per-Message 152 Reports . . . . . . . . . . . . . . . . . . . . . . . 55 153 B.2.3. Per-Message Failure Reports Directed to Third 154 Party . . . . . . . . . . . . . . . . . . . . . . . . 56 155 B.2.4. Subdomain, Testing, and Multiple Aggregate Report 156 URIs . . . . . . . . . . . . . . . . . . . . . . . . 57 157 B.3. Mail Receiver Example . . . . . . . . . . . . . . . . . . 59 158 B.4. Processing of SMTP Time . . . . . . . . . . . . . . . . . 59 159 B.5. Utilization of Aggregate Feedback: Example . . . . . . . 61 160 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 61 161 C.1. January 5, 2021 . . . . . . . . . . . . . . . . . . . . . 61 162 C.1.1. Ticket 80 - DMARCbis SHould Have Clear and Concise 163 Defintion of DMARC . . . . . . . . . . . . . . . . . 61 164 C.2. February 4, 2021 . . . . . . . . . . . . . . . . . . . . 62 165 C.2.1. Ticket 1 - SPF RFC 4408 vs 7208 . . . . . . . . . . . 62 166 C.3. February 10, 2021 . . . . . . . . . . . . . . . . . . . . 62 167 C.3.1. Ticket 84 - Remove Erroneous References to RFC3986 . 62 168 C.4. March 1, 2021 . . . . . . . . . . . . . . . . . . . . . . 62 169 C.4.1. Design Team Work Begins . . . . . . . . . . . . . . . 62 170 C.5. March 8, 2021 . . . . . . . . . . . . . . . . . . . . . . 62 171 C.5.1. Removed E. Gustafsson as editor . . . . . . . . . . 62 172 C.5.2. Ticket 3 - Two tiny nits . . . . . . . . . . . . . . 62 173 C.5.3. Ticket 4 - Definition of "fo" parameter . . . . . . . 63 174 C.6. March 16, 2021 . . . . . . . . . . . . . . . . . . . . . 63 175 C.6.1. Ticket 7 - ABNF for dmarc-record is slightly wrong . 63 176 C.6.2. Ticket 26 - ABNF for pct allows "999" . . . . . . . . 63 177 C.7. March 23, 2021 . . . . . . . . . . . . . . . . . . . . . 63 178 C.7.1. Ticket 75 - Using wording alternatives to 179 'disposition', 'dispose', and the like . . . . . . . 63 180 C.7.2. Ticket 72 - Remove absolute requirement for p= tag in 181 DMARC record . . . . . . . . . . . . . . . . . . . . 63 182 C.8. March 29, 2021 . . . . . . . . . . . . . . . . . . . . . 64 183 C.8.1. Ticket 54 - Remove or expand limits on number of 184 recipients per report . . . . . . . . . . . . . . . . 64 185 C.9. April 12, 2021 . . . . . . . . . . . . . . . . . . . . . 64 186 C.9.1. Ticket 50 - Remove ri= tag . . . . . . . . . . . . . 64 187 C.9.2. Ticket 66 - Define what it means to have implemented 188 DMARC . . . . . . . . . . . . . . . . . . . . . . . . 64 189 C.9.3. Ticket 96 - Tweaks to Abstract and Introduction . . . 64 190 C.10. April 13, 2021 . . . . . . . . . . . . . . . . . . . . . 64 191 C.10.1. Ticket 53 - Remove reporting message size 192 chunking . . . . . . . . . . . . . . . . . . . . . . 64 193 C.10.2. Ticket 52 - Remove strict alignment (and adkim and 194 aspf tags) . . . . . . . . . . . . . . . . . . . . . 64 195 C.10.3. Ticket 47 - Remove pct= tag . . . . . . . . . . . . 65 196 C.10.4. Ticket 2 - Flow of operations text in dmarc-base . . 65 197 C.11. April 14, 2021 . . . . . . . . . . . . . . . . . . . . . 65 198 C.11.1. Ticket 107 - DMARCbis should take a stand on 199 multi-valued From fields . . . . . . . . . . . . . . 65 200 C.11.2. Ticket 82 - Deprecate rf= and maybe fo= tag . . . . 65 201 C.11.3. Ticket 85 - Proposed change to wording describing 'p' 202 tag and values . . . . . . . . . . . . . . . . . . . 65 203 C.12. April 15, 2021 . . . . . . . . . . . . . . . . . . . . . 65 204 C.12.1. Ticket 86 - A-R results for DMARC . . . . . . . . . 65 205 C.12.2. Ticket 62 - Make aggregate reporting a normative 206 MUST . . . . . . . . . . . . . . . . . . . . . . . . 66 207 C.13. April 19, 2021 . . . . . . . . . . . . . . . . . . . . . 66 208 C.13.1. Ticket 109 - Sanity Check DMARCbis Document . . . . 66 209 C.14. April 20, 2021 . . . . . . . . . . . . . . . . . . . . . 66 210 C.14.1. Ticket 108 - Changes to DMARCbis for PSD . . . . . . 66 211 C.15. April 22, 2021 . . . . . . . . . . . . . . . . . . . . . 66 212 C.15.1. Ticket 104 - Update the Security Considerations 213 section 11.3 on DNS . . . . . . . . . . . . . . . . . 66 214 C.16. June 16, 2021 . . . . . . . . . . . . . . . . . . . . . . 66 215 C.16.1. Publication of draft-ietf-dmarc-dmarcbis-02 . . . . 66 216 C.17. August 12, 2021 . . . . . . . . . . . . . . . . . . . . . 66 217 C.17.1. Publication of draft-ietf-dmarc-dmarcbis-03 . . . . 66 218 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 67 219 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 221 1. Introduction 223 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: 224 The source for this draft is maintained in GitHub at: 225 https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis 226 (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis) 228 Abusive email often includes unauthorized and deceptive use of a 229 domain name in the RFC5322.From header field. The domain typically 230 belongs to an organization expected to be known to - and presumably 231 trusted by - the recipient. The Sender Policy Framework (SPF) 232 ([RFC7208]) and DomainKeys Identified Mail (DKIM) ([RFC6376]) 233 protocols provide domain-level authentication but are not directly 234 associated with the RFC5322.From domain. DMARC leverages them, so 235 that Domain Owners publish a DNS record indicating their RFC5322.From 236 field: 238 * Email authentication policies 239 * Level of concern for mail that fails authentication checks 241 * Desire for reports about email use of the domain name 243 DMARC can cover non-existent sub-domains, below the "Organizational 244 Domain", as well as domains at the top of the name hierarchy, 245 controlled by Public Suffix Operators (PSOs). 247 As with SPF and DKIM, DMARC classes results as "pass" or "fail". A 248 pass from either SPF or DKIM is required. Depending on the stated 249 DMARC policy, the passed domain must be "aligned" with the 250 RFC5322.From domain in one of two modes - "relaxed" or "strict". 251 Domains are said to be "in relaxed alignment" if they have the same 252 Organizational Domain, which is at the top of the domain hierarchy, 253 while having the same administrative authority as the RFC5322.From 254 domain, while domains are "in strict alignment" if and only if they 255 are identical. 257 A DMARC pass indicates only that the RFC5322.From domain has been 258 authenticated for that message; authentication does not carry an 259 explicit or implicit value assertion about that message or about the 260 Domain Owner. Indeed, a mail-receiving organization that performs 261 DMARC verification can choose to follow the Domain Owner's requested 262 disposition for authentication failures, and to inform the Domain 263 Owner of the mail handling decision for that message. It also might 264 choose different actions. 266 For a mail-receiving organization supporting DMARC, a message that 267 passes verification is part of a message stream that is reliably 268 associated with the RFC5322.From field Domain Owner. Therefore, 269 reputation assessment of that stream by the mail-receiving 270 organization is not encumbered by accounting for unauthorized use of 271 that domain in the RFC5322.From field. A message that fails this 272 verification is not necessarily associated with the Domain Owner's 273 domain and its reputation. 275 DMARC, in the associated [DMARC-Aggregate-Reporting] and 276 [DMARC-Failure-Reporting] documents, also specifies a reporting 277 framework. Using it, a mail-receiving domain can generate regular 278 reports about messages that claim to be from a domain publishing 279 DMARC policies, sending those reports to the address(es) specified by 280 the Domain Owner. 282 Use of DMARC creates some interoperability challenges that require 283 due consideration before deployment, particularly with configurations 284 that can cause mail to be rejected. These are discussed in 285 Section 9. 287 2. Requirements 289 Specification of DMARC is guided by the following high-level goals, 290 security dependencies, detailed requirements, and items that are 291 documented as out of scope. 293 2.1. High-Level Goals 295 DMARC has the following high-level goals: 297 * Allow Domain Owners and PSOs to assert their severity of concern 298 for authentication failures for messages purporting to have 299 authorship within the domain. 301 * Allow Domain Owners and PSOs to verify their authentication 302 deployment. 304 * Minimize implementation complexity for both senders and receivers, 305 as well as the impact on handling and delivery of legitimate 306 messages. 308 * Reduce the amount of successfully delivered spoofed email. 310 * Work at Internet scale. 312 2.2. Out of Scope 314 Several topics and issues are specifically out of scope for this 315 work. These include the following: 317 * different treatment of messages that are not authenticated versus 318 those that fail authentication; 320 * evaluation of anything other than RFC5322.From header field; 322 * multiple reporting formats; 324 * publishing policy other than via the DNS; 326 * reporting or otherwise evaluating other than the last-hop IP 327 address; 329 * attacks in the From: header field, also known as "display name" 330 attacks; 332 * authentication of entities other than domains, since DMARC is 333 built upon SPF and DKIM, which authenticate domains; and 335 * content analysis. 337 2.3. Scalability 339 Scalability is a major issue for systems that need to operate in a 340 system as widely deployed as current SMTP email. For this reason, 341 DMARC seeks to avoid the need for third parties or pre-sending 342 agreements between senders and receivers. This preserves the 343 positive aspects of the current email infrastructure. 345 Although DMARC does not introduce third-party senders (namely 346 external agents authorized to send on behalf of an operator) to the 347 email-handling flow, it also does not preclude them. Such third 348 parties are free to provide services in conjunction with DMARC. 350 2.4. Anti-Phishing 352 DMARC is designed to prevent bad actors from sending mail that claims 353 to come from legitimate senders, particularly senders of 354 transactional email (official mail that is about business 355 transactions). One of the primary uses of this kind of spoofed mail 356 is phishing (enticing users to provide information by pretending to 357 be the legitimate service requesting the information). Thus, DMARC 358 is significantly informed by ongoing efforts to enact large-scale, 359 Internet-wide anti-phishing measures. 361 Although DMARC can only be used to combat specific forms of exact- 362 domain spoofing directly, the DMARC mechanism has been found to be 363 useful in the creation of reliable and defensible message streams. 365 DMARC does not attempt to solve all problems with spoofed or 366 otherwise fraudulent email. In particular, it does not address the 367 use of visually similar domain names ("cousin domains") or abuse of 368 the RFC5322.From human-readable . 370 3. Terminology and Definitions 372 This section defines terms used in the rest of the document. 374 3.1. Conventions Used in This Document 376 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 377 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 378 "OPTIONAL" in this document are to be interpreted as described in BCP 379 14 [RFC2119] [RFC8174] when, and only when, they appear in all 380 capitals, as shown here. 382 Readers are encouraged to be familiar with the contents of [RFC5598]. 383 In particular, that document defines various roles in the messaging 384 infrastructure that can appear the same or separate in various 385 contexts. For example, a Domain Owner could, via the messaging 386 security mechanisms on which DMARC is based, delegate the ability to 387 send mail as the Domain Owner to a third party with another role. 388 This document does not address the distinctions among such roles; the 389 reader is encouraged to become familiar with that material before 390 continuing. 392 3.2. Authenticated Identifiers 394 Domain-level identifiers that are verified using authentication 395 technologies are referred to as "Authenticated Identifiers". See 396 Section 4.1 for details about the supported mechanisms. 398 3.3. Author Domain 400 The domain name of the apparent author, as extracted from the From: 401 header field. 403 3.4. Domain Owner 405 An entity or organization that owns a DNS domain. The term "owns" 406 here indicates that the entity or organization being referenced holds 407 the registration of that DNS domain. Domain Owners range from 408 complex, globally distributed organizations, to service providers 409 working on behalf of non-technical clients, to individuals 410 responsible for maintaining personal domains. This specification 411 uses this term as analogous to an Administrative Management Domain as 412 defined in [RFC5598]. It can also refer to delegates, such as Report 413 Receivers, when those are outside of their immediate management 414 domain. 416 3.5. Identifier Alignment 418 When the domain in the address in the From: header field has the same 419 Organizational Domain as a domain verified by SPF or DKIM (or both), 420 it has Identifier Alignment. (see below) 422 3.6. Longest PSD 424 The term Longest PSD is defined in [RFC9091]. 426 3.7. Mail Receiver 428 The entity or organization that receives and processes email. 429 Mail Receivers operate one or more Internet-facing Mail Transport 430 Agents (MTAs). 432 3.8. Non-existent Domains 434 For DMARC purposes, a non-existent domain is a domain for which there 435 is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This 436 is a broader definition than that in [RFC8020]. 438 3.9. Organizational Domain 440 The domain that was registered with a domain name registrar. In the 441 absence of more accurate methods, heuristics are used to determine 442 this, since it is not always the case that the registered domain name 443 is simply a top-level DNS domain plus one component (e.g., 444 "example.com", where "com" is a top-level domain). The 445 Organizational Domain is determined by applying the algorithm found 446 in Section 3.15. 448 3.10. Public Suffix Domain (PSD) 450 The term Public Suffix Domain is defined in [RFC9091]. 452 3.11. Public Suffix Operator (PSO) 454 The term Public Suffix Operator is defined in [RFC9091]. 456 3.12. PSO Controlled Domain Names 458 The term PSO Controlled Domain Names is defined in [RFC9091]. 460 3.13. Report Receiver 462 An operator that receives reports from another operator implementing 463 the reporting mechanisms described in this document and/or the 464 documents [DMARC-Aggregate-Reporting] and [DMARC-Failure-Reporting]. 465 Such an operator might be receiving reports about messages related to 466 a domain for which it is the Domain Owner or PSO, or reports about 467 messages related to another operator's domain. This term applies 468 collectively to the system components that receive and process these 469 reports and the organizations that operate them. 471 3.14. More on Identifier Alignment 473 Email authentication technologies authenticate various (and 474 disparate) aspects of an individual message. For example, DKIM 475 [RFC6376] authenticates the domain that affixed a signature to the 476 message, while SPF [RFC7208] can authenticate either the domain that 477 appears in the RFC5321.MailFrom (MAIL FROM) portion of an SMTP 478 [RFC5321] conversation or the RFC5321.EHLO/HELO domain, or both. 479 These may be different domains, and they are typically not visible to 480 the end user. 482 DMARC authenticates use of the RFC5322.From domain by requiring that 483 it have the same Organizational Domain as (i.e., be aligned with) an 484 Authenticated Identifier. Domain names in this context are to be 485 compared in a case-insensitive manner, per [RFC4343]. The 486 RFC5322.From domain was selected as the central identity of the DMARC 487 mechanism because it is a required message header field and therefore 488 guaranteed to be present in compliant messages, and most Mail User 489 Agents (MUAs) represent the RFC5322.From header field as the 490 originator of the message and render some or all of this header 491 field's content to end users. 493 It is important to note that Identifier Alignment cannot occur with a 494 message that is not valid per [RFC5322], particularly one with a 495 malformed, absent, or repeated RFC5322.From header field, since in 496 that case there is no reliable way to determine a DMARC policy that 497 applies to the message. Accordingly, DMARC operation is predicated 498 on the input being a valid RFC5322 message object, and handling of 499 such non-compliant cases is outside of the scope of this 500 specification. Further discussion of this can be found in 501 Section 6.7.1. 503 Each of the underlying authentication technologies that DMARC takes 504 as input yields authenticated domains as their outputs when they 505 succeed. 507 3.14.1. DKIM-Authenticated Identifiers 509 DMARC requires Identifier Alignment based on the result of a DKIM 510 authentication because a message can bear a valid signature from any 511 domain, including domains used by a mailing list or even a bad actor. 512 Therefore, merely bearing a valid signature is not enough to infer 513 authenticity of the Author Domain. 515 DMARC permits Identifier Alignment based on the result of a DKIM 516 authentication to be strict or relaxed. (Note that these terms are 517 not related to DKIM's "simple" and "relaxed" canonicalization modes.) 518 In relaxed mode, the Organizational Domains of both the DKIM- 519 authenticated signing domain (taken from the value of the d= tag in 520 the signature) and that of the RFC5322.From domain must be equal if 521 the identifiers are to be considered to be aligned. In strict mode, 522 only an exact match between both Fully Qualified Domain Names (FQDNs) 523 is considered to produce Identifier Alignment. 525 To illustrate, in relaxed mode, if a verified DKIM signature 526 successfully verifies with a "d=" domain of "example.com", and the 527 RFC5322.From address is "alerts@news.example.com", the DKIM "d=" 528 domain and the RFC5322.From domain are considered to be "in 529 alignment", because both domains have the same Organizational Domain 530 of "example.com". In strict mode, this test would fail because the 531 d= domain does not exactly match the RFC5322.From domain. 533 However, a DKIM signature bearing a value of "d=com" would never 534 allow an "in alignment" result, as "com" should appear on all public 535 suffix lists (see Appendix A.6.1) and therefore cannot be an 536 Organizational Domain. 538 Note that a single email can contain multiple DKIM signatures, and it 539 is considered to produce a DMARC "pass" result if any DKIM signature 540 is aligned and verifies. 542 3.14.2. SPF-Authenticated Identifiers 544 DMARC permits Identifier Alignment based on the result of an SPF 545 authentication. As with DKIM, Identifier Alignement can be either 546 strict or relaxed. 548 In relaxed mode, the Organizational Domains of the SPF-authenticated 549 domain and RFC5322.From domain must be equal if the identifiers are 550 to be considered to be aligned. In strict mode, the two FQDNs must 551 match exactly in order from them to be considered to be aligned. 553 For example, in relaxed mode, if a message passes an SPF check with 554 an RFC5321.MailFrom domain of "cbg.bounces.example.com", and the 555 address portion of the RFC5322.From header field contains 556 "payments@example.com", the Authenticated RFC5321.MailFrom domain 557 identifier and the RFC5322.From domain are considered to be "in 558 alignment" because they have the same Organizational Domain 559 ("example.com"). In strict mode, this test would fail because the 560 two domains are not identical. 562 The reader should note that SPF alignment checks in DMARC rely solely 563 on the RFC5321.MailFrom domain. This differs from section 2.3 of 564 [RFC7208], which recommends that SPF checks be done on not only the 565 "MAIL FROM" but also on a separate check of the "HELO" identity. 567 3.14.3. Alignment and Extension Technologies 569 If in the future DMARC is extended to include the use of other 570 authentication mechanisms, the extensions will need to allow for 571 domain identifier extraction so that alignment with the RFC5322.From 572 domain can be verified. 574 3.15. Determining The Organizational Domain 576 The Organizational Domain is determined using the following 577 algorithm: 579 1. Acquire a "public suffix" list, i.e., a list of DNS domain names 580 reserved for registrations. Some country Top-Level Domains 581 (TLDs) make specific registration requirements, e.g., the United 582 Kingdom places company registrations under ".co.uk"; other TLDs 583 such as ".com" appear in the IANA registry of top-level DNS 584 domains. A public suffix list is the union of all of these. 585 Appendix A.6.1 contains some discussion about obtaining a public 586 suffix list. 588 2. Break the subject DNS domain name into a set of "n" ordered 589 labels. Number these labels from right to left; e.g., for 590 "example.com", "com" would be label 1 and "example" would be 591 label 2. 593 3. Search the public suffix list for the name that matches the 594 largest number of labels found in the subject DNS domain. Let 595 that number be "x". 597 4. Construct a new DNS domain name using the name that matched from 598 the public suffix list and prefixing to it the "x+1"th label from 599 the subject domain. This new name is the Organizational Domain. 601 Thus, since "com" is an IANA-registered TLD, a subject domain of 602 "a.b.c.d.example.com" would have an Organizational Domain of 603 "example.com". 605 The process of determining a suffix is currently a heuristic one. No 606 list is guaranteed to be accurate or current. 608 4. Overview 610 This section provides a general overview of the design and operation 611 of the DMARC environment. 613 4.1. Authentication Mechanisms 615 The following mechanisms for determining Authenticated Identifiers 616 are supported in this version of DMARC: 618 * DKIM, [RFC6376], which provides a domain-level identifier in the 619 content of the "d=" tag of a verified DKIM-Signature header field. 621 * SPF, [RFC7208], which can authenticate both the domain found in an 622 [RFC5321] HELO/EHLO command (the HELO identity) and the domain 623 found in an SMTP MAIL command (the MAIL FROM identity). As noted 624 earlier, however, DMARC relies solely on SPF authentication of the 625 domain found in SMTP MAIL FROM command. Section 2.4 of [RFC7208] 626 describes MAIL FROM processing for cases in which the MAIL command 627 has a null path. 629 4.2. Key Concepts 631 DMARC policies are published by the Domain Owner or PSO, and 632 retrieved by the Mail Receiver during the SMTP session, via the DNS. 634 DMARC's verification function is based on whether the RFC5322.From 635 domain is aligned with an authenticated domain name from SPF or DKIM. 636 When a DMARC policy is published for the domain name found in the 637 RFC5322.From header field, and that domain name is not verified 638 through SPF or DKIM, the handling of that message can be affected by 639 that DMARC policy when delivered to a participating receiver. 641 It is important to note that the authentication mechanisms employed 642 by DMARC authenticate only a DNS domain and do not authenticate the 643 local-part of any email address identifier found in a message, nor do 644 they validate the legitimacy of message content. 646 DMARC's feedback component involves the collection of information 647 about received messages claiming to be from the Author Domain for 648 periodic aggregate reports to the Domain Owner or PSO. The 649 parameters and format for such reports are discussed in 650 [DMARC-Aggregate-Reporting] 652 A DMARC-enabled Mail Receiver might also generate per-message reports 653 that contain information related to individual messages that fail SPF 654 and/or DKIM. Per-message failure reports are a useful source of 655 information when debugging deployments (if messages can be determined 656 to be legitimate even though failing authentication) or in analyzing 657 attacks. The capability for such services is enabled by DMARC but 658 defined in other referenced material such as [RFC6591] and 659 [DMARC-Failure-Reporting] 660 A message satisfies the DMARC checks if at least one of the supported 661 authentication mechanisms: 663 1. produces a "pass" result, and 665 2. produces that result based on an identifier that is in alignment, 666 as defined in Section 3. 668 4.3. Flow Diagram 670 +---------------+ +--------------------+ 671 | Author Domain |< . . . . . . . . . . . . | Return-Path Domain | 672 +---------------+ . +--------------------+ 673 | . ^ 674 V V . 675 +-----------+ +--------+ +----------+ v 676 | MSA |<***>| DKIM | | DMARC | +----------+ 677 | Service | | Signer | | Verifier |<***>| SPF | 678 +-----------+ +--------+ +----------+ * | Verifier | 679 | ^ * +----------+ 680 | * * 681 V v * 682 +------+ (~~~~~~~~~~~~) +------+ * +----------+ 683 | sMTA |------->( other MTAs )----->| rMTA | **>| DKIM | 684 +------+ (~~~~~~~~~~~~) +------+ | Verifier | 685 | +----------+ 686 | ^ 687 V . 688 +-----------+ . 689 +---------+ | MDA | v 690 | User |<--| Filtering | +-----------+ 691 | Mailbox | | Engine | | DKIM | 692 +---------+ +-----------+ | Signing | 693 | Domain(s) | 694 +-----------+ 696 MSA = Mail Submission Agent 697 MDA = Mail Delivery Agent 699 The above diagram shows a simple flow of messages through a DMARC- 700 aware system. Solid lines denote the actual message flow, dotted 701 lines involve DNS queries used to retrieve message policy related to 702 the supported message authentication schemes, and asterisk lines 703 indicate data exchange between message-handling modules and message 704 authentication modules. "sMTA" is the sending MTA, and "rMTA" is the 705 receiving MTA. 707 Put simply, when a message reaches a DMARC-aware rMTA, a DNS query 708 will be initiated to determine if the author domain has published a 709 DMARC policy. If a policy is found, the rMTA will use the results of 710 SPF and DKIM verification checks to determine the ultimate DMARC 711 authentication status. The DMARC status can then factor into the 712 message handling decision made by the recipient's mail sytsem. 714 More details on specific actions for the parties involved can be 715 found in Section 6.5 and Section 6.7. 717 5. Use of RFC5322.From 719 One of the most obvious points of security scrutiny for DMARC is the 720 choice to focus on an identifier, namely the RFC5322.From address, 721 which is part of a body of data that has been trivially forged 722 throughout the history of email. This field is the one used by end 723 users to identify the source of the message, and so it has always 724 been a prime target for abuse through such forgery and other means. 726 Several points suggest that it is the most correct and safest thing 727 to do in this context: 729 * Of all the identifiers that are part of the message itself, this 730 is the only one guaranteed to be present. 732 * It seems the best choice of an identifier on which to focus, as 733 most MUAs display some or all of the contents of that field in a 734 manner strongly suggesting those data as reflective of the true 735 originator of the message. 737 * Many high-profile email sources, such as email service providers, 738 require that the sending agent have authenticated before email can 739 be generated. Thus, for these mailboxes, the mechanism described 740 in this document provides recipient end users with strong evidence 741 that the message was indeed originated by the agent they associate 742 with that mailbox, if the end user knows that these various 743 protections have been provided. 745 The absence of a single, properly formed RFC5322.From header field 746 renders the message invalid. Handling of such a message is outside 747 of the scope of this specification. 749 Since the sorts of mail typically protected by DMARC participants 750 tend to only have single Authors, DMARC participants generally 751 operate under a slightly restricted profile of RFC5322 with respect 752 to the expected syntax of this field. See Section 6.7 for details. 754 6. Policy 756 DMARC policies are published by Domain Owners and PSOs and can be 757 used by Mail Receivers to inform their message handling decisions. 759 A Domain Owner or PSO advertises DMARC participation of one or more 760 of its domains by adding a DNS TXT record (described in Section 6.1) 761 to those domains. In doing so, Domain Owners and PSOs indicate their 762 severity of concern regarding failed authentication for email 763 messages making use of their domain in the RFC5322.From header field 764 as well as the provision of feedback about those messages. Mail 765 Receivers in turn can take into account the Domain Owner's severity 766 of concern when making handling decisions about email messages that 767 fail DMARC authentication checks. 769 A Domain Owner or PSO may choose not to participate in DMARC 770 evaluation by Mail Receivers. In this case, the Domain Owner simply 771 declines to advertise participation in those schemes. For example, 772 if the results of path authorization checks ought not be considered 773 as part of the overall DMARC result for a given Author Domain, then 774 the Domain Owner does not publish an SPF policy record that can 775 produce an SPF pass result. 777 A Mail Receiver implementing the DMARC mechanism SHOULD make a best- 778 effort attempt to adhere to the Domain Owner's or PSO's published 779 DMARC Domain Owner Assessment Policy when a message fails the DMARC 780 test. 781 Since email streams can be complicated (due to forwarding, existing 782 RFC5322.From domain-spoofing services, etc.), Mail Receivers MAY 783 deviate from a published Domain Owner Assessment Policy during 784 message processing and SHOULD make available the fact of and reason 785 for the deviation to the Domain Owner via feedback reporting, 786 specifically using the "PolicyOverride" feature of the aggregate 787 report defined in [DMARC-Aggregate-Reporting] 789 6.1. DMARC Policy Record 791 Domain Owner and PSO DMARC preferences are stored as DNS TXT records 792 in subdomains named "_dmarc". For example, the Domain Owner of 793 "example.com" would post DMARC preferences in a TXT record at 794 "_dmarc.example.com". Similarly, a Mail Receiver wishing to query 795 for DMARC preferences regarding mail with an RFC5322.From domain of 796 "example.com" would issue a TXT query to the DNS for the subdomain of 797 "_dmarc.example.com". The DNS-located DMARC preference data will 798 hereafter be called the "DMARC record". 800 DMARC's use of the Domain Name Service is driven by DMARC's use of 801 domain names and the nature of the query it performs. The query 802 requirement matches with the DNS, for obtaining simple parametric 803 information. It uses an established method of storing the 804 information, associated with the target domain name, namely an 805 isolated TXT record that is restricted to the DMARC context. Use of 806 the DNS as the query service has the benefit of reusing an extremely 807 well-established operations, administration, and management 808 infrastructure, rather than creating a new one. 810 Per [RFC1035], a TXT record can comprise several "character-string" 811 objects. Where this is the case, the module performing DMARC 812 evaluation MUST concatenate these strings by joining together the 813 objects in order and parsing the result as a single string. 815 6.2. DMARC URIs 817 [RFC3986] defines a generic syntax for identifying a resource. The 818 DMARC mechanism uses this as the format by which a Domain Owner or 819 PSO specifies the destination for the two report types that are 820 supported. 822 The place such URIs are specified (see Section 6.3) allows a list of 823 these to be provided. The list of URIs is separated by commas (ASCII 824 0x2c). A report SHOULD be sent to each listed URI provided in the 825 DMARC record. 827 A formal definition is provided in Section 6.4. 829 6.3. General Record Format 831 DMARC records follow the extensible "tag-value" syntax for DNS-based 832 key records defined in DKIM [RFC6376]. 834 Section 10 creates a registry for known DMARC tags and registers the 835 initial set defined in this document. Only tags defined in this 836 document or in later extensions, and thus added to that registry, are 837 to be processed; unknown tags MUST be ignored. 839 The following tags are valid DMARC tags: 841 adkim: (plain-text; OPTIONAL; default is "r".) Indicates whether 842 strict or relaxed DKIM Identifier Alignment mode is required by 843 the Domain Owner. See Section 3.14.1 for details. Valid values 844 are as follows: 846 r: relaxed mode 847 s: strict mode 849 aspf: (plain-text; OPTIONAL; default is "r".) Indicates whether 850 strict or relaxed SPF Identifier Alignment mode is required by the 851 Domain Owner. See Section 3.14.2 for details. Valid values are 852 as follows: 854 r: relaxed mode 856 s: strict mode 858 fo: Failure reporting options (plain-text; OPTIONAL; default is "0") 859 Provides requested options for generation of failure reports. 860 Report generators MAY choose to adhere to the requested options. 861 This tag's content MUST be ignored if a "ruf" tag (below) is not 862 also specified. Failure reporting options are shown below. The 863 value of this tag is either "0", "1", or a colon-separated list of 864 the options represented by alphabetic characters. 866 The valid values and their meanings are: 868 0: 869 : Generate a DMARC failure report if all underlying 870 authentication mechanisms fail to produce an aligned "pass" 871 result. 873 1: 874 : Generate a DMARC failure report if any underlying 875 authentication mechanism produced something other than an 876 aligned "pass" result. 878 d: 879 : Generate a DKIM failure report if the message had a signature 880 that failed evaluation, regardless of its alignment. DKIM- 881 specific reporting is described in [@!RFC6651]. 883 s: 884 : Generate an SPF failure report if the message failed SPF 885 evaluation, regardless of its alignment. SPF-specific 886 reporting is described in [@!RFC6652]. 888 np: Domain Owner Assessment Policy for non-existent subdomains 889 (plain-text; OPTIONAL). Indicates the severity of concern the 890 Domain Owner or PSO has for mail using non-existent subdomains of 891 the domain queried. It applies only to non-existent subdomains of 892 the domain queried and not to either existing subdomains or the 893 domain itself. Its syntax is identical to that of the "p" tag 894 defined below. If the "np" tag is absent, the policy specified by 895 the "sp" tag (if the "sp" tag is present) or the policy specified 896 by the "p" tag, if the "sp" tag is not present, MUST be applied 897 for non-existent subdomains. Note that "np" will be ignored for 898 DMARC records published on subdomains of Organizational Domains 899 and PSDs due to the effect of the DMARC policy discovery mechanism 900 described in Section 6.7.3. 902 p: Domain Owner Assessment Policy (plain-text; RECOMMENDED for 903 policy records). Indicates the severity of concern the Domain 904 Owner or PSO has for mail using its domain but not passing DMARC 905 verification. Policy applies to the domain queried and to 906 subdomains, unless subdomain policy is explicitly described using 907 the "sp" or "np" tags. This tag is mandatory for policy records 908 only, but not for third-party reporting records (see 909 [DMARC-Aggregate-Reporting] and [DMARC-Failure-Reporting]) 910 Possible values are as follows: 912 none: The Domain Owner offers no expression of concern. 914 quarantine: The Domain Owner considers such mail to be 915 suspicious. It is possible the mail is valid, although the 916 failure creates a significant concern. 918 reject: The Domain Owner considers all such failures to be a 919 clear indication that the use of the domain name is not valid. 920 See Section 9.3 for some discussion of SMTP rejection methods 921 and their implications. 923 rua: Addresses to which aggregate feedback is to be sent (comma- 924 separated plain-text list of DMARC URIs; OPTIONAL). Section 3 of 925 [DMARC-Aggregate-Reporting] discusses considerations that apply 926 when the domain name of a URI differs from that of the domain 927 advertising the policy. See Section 11.5 for additional 928 considerations. Any valid URI can be specified. 929 A Mail Receiver MUST implement support for a "mailto:" URI, i.e., 930 the ability to send a DMARC report via electronic mail. If not 931 provided, Mail Receivers MUST NOT generate aggregate feedback 932 reports. URIs not supported by Mail Receivers MUST be ignored. 933 The aggregate feedback report format is described in 934 [DMARC-Aggregate-Reporting] 936 ruf: Addresses to which message-specific failure information is to 937 be reported (comma-separated plain-text list of DMARC URIs; 938 OPTIONAL). If present, the Domain Owner or PSO is requesting Mail 939 Receivers to send detailed failure reports about messages that 940 fail the DMARC evaluation in specific ways (see the "fo" tag 941 above). The format of the message to be generated MUST follow the 942 format specified for the "rf" tag. Section 3 of 944 [DMARC-Aggregate-Reporting] discusses considerations that apply 945 when the domain name of a URI differs from that of the domain 946 advertising the policy. A Mail Receiver MUST implement support 947 for a "mailto:" URI, i.e., the ability to send a DMARC report via 948 electronic mail. If not provided, Mail Receivers MUST NOT 949 generate failure reports. See Section 11.5 for additional 950 considerations. 952 sp: Domain Owner Assessment Policy for all subdomains (plain-text; 953 OPTIONAL). Indicates the severity of concern the Domain Owner or 954 PSO has for mail using an existing subdomain of the domain queried 955 but not passing DMARC verification. It applies only to subdomains 956 of the domain queried and not to the domain itself. Its syntax is 957 identical to that of the "p" tag defined above. If both the "sp" 958 tag is absent and the "np" tag is either absent or not applicable, 959 the policy specified by the "p" tag MUST be applied for 960 subdomains. Note that "sp" will be ignored for DMARC records 961 published on subdomains of Organizational Domains due to the 962 effect of the DMARC policy discovery mechanism described in 963 Section 6.7.3. 965 t: DMARC policy test mode (plain-text; OPTIONAL; default is 'n'). 966 For the RFC5322.From domain to which the DMARC record applies, the 967 "t" tag serves as a signal to the actor performing DMARC 968 verification checks as to whether or not the domain owner wishes 969 the assessment policy declared in the "p=", "sp=", and/or "np=" 970 tags to actually be applied. This parameter does not affect the 971 generation of DMARC reports. Possible values are as follows: 973 y: A request that the actor performing the DMARC verification 974 check not apply the policy, but instead apply any special 975 handling rules it might have in place, such as rewriting the 976 RFC5322.From header. The domain owner is currently testing its 977 specified DMARC assessment policy. 979 n: The default, a request to apply the policy as specified to any 980 message that produces a DMARC "fail" result. 982 v: Version (plain-text; REQUIRED). Identifies the record retrieved 983 as a DMARC record. It MUST have the value of "DMARC1". The value 984 of this tag MUST match precisely; if it does not or it is absent, 985 the entire retrieved record MUST be ignored. It MUST be the first 986 tag in the list. 988 A DMARC policy record MUST comply with the formal specification found 989 in Section 6.4 in that the "v" tag MUST be present and MUST appear 990 first. Unknown tags MUST be ignored. Syntax errors in the remainder 991 of the record SHOULD be discarded in favor of default values (if any) 992 or ignored outright. 994 Note that given the rules of the previous paragraph, addition of a 995 new tag into the registered list of tags does not itself require a 996 new version of DMARC to be generated (with a corresponding change to 997 the "v" tag's value), but a change to any existing tags does require 998 a new version of DMARC. 1000 6.4. Formal Definition 1002 The formal definition of the DMARC format, using [RFC5234], is as 1003 follows: 1005 dmarc-uri = URI 1006 ; "URI" is imported from [RFC3986]; commas (ASCII 1007 ; 0x2C) and exclamation points (ASCII 0x21) 1008 ; MUST be encoded 1010 dmarc-record = dmarc-version dmarc-sep *(dmarc-tag dmarc-sep) 1012 dmarc-tag = dmarc-request / 1013 dmarc-test / 1014 dmarc-srequest / 1015 dmarc-nprequest / 1016 dmarc-adkim / 1017 dmarc-aspf / 1018 dmarc-auri / 1019 dmarc-furi / 1020 dmarc-fo / 1021 dmarc-rfmt 1022 ; components other than dmarc-version and 1023 ; dmarc-request may appear in any order 1025 dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31 1027 dmarc-sep = *WSP %x3b *WSP 1029 dmarc-request = "p" *WSP "=" *WSP 1030 ( "none" / "quarantine" / "reject" ) 1032 dmarc-test = "t" *WSP "=" ( "y" / "n" ) 1034 dmarc-srequest = "sp" *WSP "=" *WSP 1035 ( "none" / "quarantine" / "reject" ) 1037 dmarc-nprequest = "np" *WSP "=" *WSP 1038 ( "none" / "quarantine" / "reject" ) 1040 dmarc-adkim = "adkim" *WSP "=" *WSP ( "r" / "s" ) 1042 dmarc-aspf = "aspf" *WSP "=" *WSP ( "r" / "s" ) 1044 dmarc-auri = "rua" *WSP "=" *WSP 1045 dmarc-uri *(*WSP "," *WSP dmarc-uri) 1047 dmarc-furi = "ruf" *WSP "=" *WSP 1048 dmarc-uri *(*WSP "," *WSP dmarc-uri) 1050 dmarc-fo = "fo" *WSP "=" *WSP 1051 ( "0" / "1" / ( "d" / "s" / "d:s" / "s:d" ) ) 1053 dmarc-rfmt = "rf" *WSP "=" *WSP Keyword *(*WSP ":" Keyword) 1054 ; registered reporting formats only 1056 "Keyword" is imported from Section 4.1.2 of [RFC5321]. 1058 6.5. Domain Owner Actions 1060 This section describes Domain Owner actions to fully implement the 1061 DMARC mechanism. 1063 6.5.1. Publish an SPF Policy for an Aligned Domain 1065 Because DMARC relies on SPF [RFC7208] and DKIM [RFC6376], in order to 1066 take full advantage of DMARC, a Domain Owner SHOULD first ensure that 1067 SPF and DKIM authentication are properly configured. The easiest 1068 first step here is to choose a domain to use as the RFC5321.From 1069 domain (i.e., the Return-Path domain) for its mail, one that aligns 1070 with the Author Domain, and then publish an SPF policy in DNS for 1071 that domain. 1073 6.5.2. Configure Sending System for DKIM Signing Using an Aligned 1074 Domain 1076 While it is possible to secure a DMARC pass verdict based on only SPF 1077 or DKIM, it is commonly accepted best practice to ensure that both 1078 authentication mechanisms are in place in order to guard against 1079 failure of just one of them. The Domain Owner SHOULD choose a DKIM- 1080 Signing domain (i.e., the d= domain in the DKIM-Signature header) 1081 that aligns with the Author Domain and configure its system to sign 1082 using that domain. 1084 6.5.3. Setup a Mailbox to Receive Aggregate Reports 1086 Proper consumption and analysis of DMARC aggregate reports is the key 1087 to any successful DMARC deployment for a Domain Owner. DMARC 1088 aggregate reports, which are XML documents and are defined in 1089 [DMARC-Aggregate-Reporting], contain valuable data for the Domain 1090 Owner, showing sources of mail using the Author Domain. Depending on 1091 how mature the Domain Owner's DMARC rollout is, some of these sources 1092 could be legitimate ones that were overlooked during the intial 1093 deployment of SPF and/or DKIM. 1095 Because the aggregate reports are XML documents, it is strongly 1096 advised that they be machine-parsed, so setting up a mailbox involves 1097 more than just the physical creation of the mailbox. Many third- 1098 party services exist that will process DMARC aggregate reports, or 1099 the Domain Owner can create its own set of tools. No matter which 1100 method is chosen, the ability to parse these reports and consume the 1101 data contained in them will go a long way to ensuring a successful 1102 deployment. 1104 6.5.4. Publish a DMARC Policy for the Author Domain 1106 Once SPF, DKIM, and the aggregate reports mailbox are all in place, 1107 it's time to publish a DMARC record. For best results, Domain Owners 1108 SHOULD start with "p=none", with the rua tag containg the mailbox 1109 created in the previous step. 1111 6.5.5. Collect and Analyze Reports and Adjust Authentication 1113 The reason for starting at "p=none" is to ensure that nothing's been 1114 missed in the initial SPF and DKIM deployments. In all but the most 1115 trivial setups, it is possible for a Domain Owner to overlook a 1116 server here or be unaware of a third party sending agreeement there. 1117 Starting at "p=none", therefore, takes advantage of DMARC's aggregate 1118 reporting function, with the Domain Owner using the reports to audit 1119 its own mail streams. Should any overlooked systems be found in the 1120 reports, the Domain Owner can adjust the SPF record and/or configure 1121 DKIM signing for those systems. 1123 6.5.6. Decide If and When to Update DMARC Policy 1125 Once the Domain Owner is satisfied that it is properly authenticating 1126 all of its mail, then it is time to decide if it is appropriate to 1127 change the p= value in its DMARC record to p=quarantine or p=reject. 1128 Depending on its cadence for sending mail, it may take many months of 1129 consuming DMARC aggregate reports before a Domain Owner reaches the 1130 point where it is sure that it is properly authenticating all of its 1131 mail, and the decision on which p= value to use will depend on its 1132 needs. 1134 6.6. PSO Actions 1136 In addition to the DMARC Domain Owner actions, PSOs that require use 1137 of DMARC and participate in PSD DMARC ought to make that information 1138 availablle to Mail Receivers. [RFC9091] is an experimental method 1139 for doing so, and the experiment is described in Appendix B of that 1140 document. 1142 6.7. Mail Receiver Actions 1144 This section describes receiver actions in the DMARC environment. 1146 6.7.1. Extract Author Domain 1148 The domain in the RFC5322.From header field is extracted as the 1149 domain to be evaluated by DMARC. If the domain is encoded with UTF- 1150 8, the domain name must be converted to an A-label, as described in 1151 Section 2.3 of [RFC5890], for further processing. 1153 In order to be processed by DMARC, a message typically needs to 1154 contain exactly one RFC5322.From domain (a single From: field with a 1155 single domain in it). Not all messages meet this requirement, and 1156 the handling of those that are forbidden under [RFC5322] or that 1157 contain no meaningful domains is outside the scope of this document. 1159 The case of a syntactically valid multi-valued RFC5322.From header 1160 field presents a particular challenge. When a single RFC5322.From 1161 header field contains multiple addresses, it is possible that there 1162 may be multiple domains used in those addresses. The process in this 1163 case is to only proceed with DMARC checking if the domain is 1164 identical for all of the addresses in a multi-valued RFC5322.From 1165 header field. Multi-valued RFC5322.From header fields with multiple 1166 domains MUST be exempt from DMARC checking. 1168 Note that domain names that appear on a public suffix list are not 1169 exempt from DMARC policy application and reporting. 1171 6.7.2. Determine Handling Policy 1173 To arrive at a policy for an individual message, Mail Receivers MUST 1174 perform the following actions or their semantic equivalents. Steps 1175 2-4 MAY be done in parallel, whereas steps 5 and 6 require input from 1176 previous steps. 1178 The steps are as follows: 1180 1. Extract the RFC5322.From domain from the message (as above). 1182 2. Query the DNS for a DMARC policy record. Continue if one is 1183 found, or terminate DMARC evaluation otherwise. See 1184 Section 6.7.3 for details. 1186 3. Perform DKIM signature verification checks. A single email could 1187 contain multiple DKIM signatures. The results of this step are 1188 passed to the remainder of the algorithm, MUST include "pass" or 1189 "fail", and if "fail", SHOULD include information about the 1190 reasons for failure. The results MUST further include the value 1191 of the "d=" and "s=" tags from each checked DKIM signature. 1193 4. Perform SPF verification checks. The results of this step are 1194 passed to the remainder of the algorithm, MUST include "pass" or 1195 "fail", and if "fail", SHOULD include information about the 1196 reasons for failure. The results MUST further include the domain 1197 name used to complete the SPF check. 1199 5. Conduct Identifier Alignment checks. With authentication checks 1200 and policy discovery performed, the Mail Receiver checks to see 1201 if Authenticated Identifiers fall into alignment as described in 1202 Section 3. If one or more of the Authenticated Identifiers align 1203 with the RFC5322.From domain, the message is considered to pass 1204 the DMARC mechanism check. All other conditions (authentication 1205 failures, identifier mismatches) are considered to be DMARC 1206 mechanism check failures. 1208 6. Apply policy. Emails that fail the DMARC mechanism check are 1209 handled in accordance with the discovered DMARC policy of the 1210 Domain Owner and any local policy rules enforced by the Mail 1211 Receiver. See Section 6.3 for details. 1213 Heuristics applied in the absence of use by a Domain Owner of either 1214 SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be 1215 the case that the Domain Owner wishes a Message Receiver not to 1216 consider the results of that underlying authentication protocol at 1217 all. 1219 DMARC evaluation can only yield a "pass" result after one of the 1220 underlying authentication mechanisms passes for an aligned 1221 identifier. If neither passes and one or both of them fail due to a 1222 temporary error, the Receiver evaluating the message is unable to 1223 conclude that the DMARC mechanism had a permanent failure; they 1224 therefore cannot apply the advertised DMARC policy. When otherwise 1225 appropriate, Receivers MAY send feedback reports regarding temporary 1226 errors. 1228 Handling of messages for which SPF and/or DKIM evaluation encounter a 1229 permanent DNS error is left to the discretion of the Mail Receiver. 1231 6.7.3. Policy Discovery 1233 As stated above, the DMARC mechanism uses DNS TXT records to 1234 advertise policy. Policy discovery is accomplished via a method 1235 similar to the method used for SPF records. This method, and the 1236 important differences between DMARC and SPF mechanisms, are discussed 1237 below. 1239 To balance the conflicting requirements of supporting wildcarding, 1240 allowing subdomain policy overrides, and limiting DNS query load, the 1241 following DNS lookup scheme is employed: 1243 1. Mail Receivers MUST query the DNS for a DMARC TXT record at the 1244 DNS domain matching the one found in the RFC5322.From domain in 1245 the message. A possibly empty set of records is returned. 1247 2. Records that do not start with a "v=" tag that identifies the 1248 current version of DMARC are discarded. 1250 3. If the set is now empty, the Mail Receiver MUST query the DNS for 1251 a DMARC TXT record at the DNS domain matching the Organizational 1252 Domain in place of the RFC5322.From domain in the message (if 1253 different). This record can contain policy to be asserted for 1254 subdomains of the Organizational Domain. A possibly empty set of 1255 records is returned. 1257 4. Records that do not start with a "v=" tag that identifies the 1258 current version of DMARC are discarded. 1260 5. If the set is now empty and the longest PSD Section 3.6 of the 1261 Organizational Domain is one that the receiver has determined is 1262 acceptable for PSD DMARC (based on the data in one of the DMARC 1263 PSD Registry Examples decribed in Appendix B of [RFC9091]) the 1264 Mail Receiver MUST query the DNS for a DMARC TXT record at the 1265 DNS domain matching the longest PSD in place of the RFC5322.From 1266 domain in the message (if different). A possibly empty set of 1267 records is returned. 1269 6. Records that do not start with a "v=" tag that identifies the 1270 current version of DMARC are discarded. 1272 7. If the remaining set contains multiple records or no records, 1273 policy discovery terminates and DMARC processing is not applied 1274 to this message. 1276 8. If a retrieved policy record does not contain a valid "p" tag, or 1277 contains an "sp" tag that is not valid, then: 1279 1. if a "rua" tag is present and contains at least one 1280 syntactically valid reporting URI, the Mail Receiver SHOULD 1281 act as if a record containing a valid "v" tag and "p=none" 1282 was retrieved, and continue processing; 1284 2. otherwise, the Mail Receiver applies no DMARC processing to 1285 this message. 1287 If the set produced by the mechanism above contains no DMARC policy 1288 record (i.e., any indication that there is no such record as opposed 1289 to a transient DNS error), Mail Receivers SHOULD NOT apply the DMARC 1290 mechanism to the message. 1292 Handling of DNS errors when querying for the DMARC policy record is 1293 left to the discretion of the Mail Receiver. For example, to ensure 1294 minimal disruption of mail flow, transient errors could result in 1295 delivery of the message ("fail open"), or they could result in the 1296 message being temporarily rejected (i.e., an SMTP 4yx reply), which 1297 invites the sending MTA to try again after the condition has possibly 1298 cleared, allowing a definite DMARC conclusion to be reached ("fail 1299 closed"). 1301 6.7.3.1. Longest PSD Example 1303 As an example of step 5 above, for a message with the Organizational 1304 Domain of "example.compute.cloudcompany.com.example", the query for 1305 PSD DMARC would use "compute.cloudcompany.com.example" as the longest 1306 PSD. The receiver would check to see if that PSD is listed in the 1307 DMARC PSD Registry, and if so, perform the policy lookup at 1308 "_dmarc.compute.cloudcompany.com.example". 1310 Note: Because the PSD policy query comes after the Organizational 1311 Domain policy query, PSD policy is not used for Organizational 1312 domains that have published a DMARC policy. Specifically, this is 1313 not a mechanism to provide feedback addresses (RUA/RUF) when an 1314 Organizational Domain has declined to do so. 1316 6.7.4. Store Results of DMARC Processing 1318 The results of Mail Receiver-based DMARC processing should be stored 1319 for eventual presentation back to the Domain Owner in the form of 1320 aggregate feedback reports. Section 6.3 and 1321 [DMARC-Aggregate-Reporting] discuss aggregate feedback. 1323 6.7.5. Send Aggregate Reports 1325 For a Domain Owner, DMARC aggregate reports provide data about all 1326 mailstreams making use of its domain in email, to include not only 1327 illegitimate uses but also, and perhaps more importantly, all 1328 legitimate uses. Domain Owners can use aggregate reports to ensure 1329 that all legitimate uses of their domain for sending email are 1330 properly authenticated, and once they are, increase the severity of 1331 concern expressed in the p= tag in their DMARC policy records from 1332 none to quarantine to reject, if appropriate. In turn, DMARC policy 1333 records with p= tag values of 'quarantine' or 'reject' are higher 1334 value signals to Mail Receivers, ones that can assist Mail Receivers 1335 with handling decisions for a message in ways that p= tag values of 1336 'none' cannot. 1338 In order to ensure maximum usefulness for DMARC across the email 1339 ecosystem, then, Mail Receivers MUST generate and send aggregate 1340 reports with a frequency of at least once every 24 hours. 1342 6.8. Policy Enforcement Considerations 1344 Mail Receivers MAY choose to reject or quarantine email even if email 1345 passes the DMARC mechanism check. The DMARC mechanism does not 1346 inform Mail Receivers whether an email stream is "good"; a DMARC 1347 result of "pass" only means that the domain in the RFC5322.From 1348 header has been verified by the DMARC mechanism. Mail Receivers are 1349 encouraged to maintain anti-abuse technologies to combat the 1350 possibility of DMARC-enabled criminal campaigns. 1352 Mail Receivers MAY choose to accept email that fails the DMARC 1353 mechanism check even if the published Domain Owner Assessment Policy 1354 is "reject". Mail Receivers need to make a best effort not to 1355 increase the likelihood of accepting abusive mail if they choose not 1356 to honor the published Domain Owner Assessment Policy. At a minimum, 1357 addition of the Authentication-Results header field (see [RFC8601]) 1358 is RECOMMENDED when delivery of failing mail is done. When this is 1359 done, the DNS domain name thus recorded MUST be encoded as an 1360 A-label. 1362 Mail Receivers are only obligated to report reject or quarantine 1363 policy actions in aggregate feedback reports that are due to 1364 published DMARC Domain Owner Assessment Policy. They are not 1365 required to report reject or quarantine actions that are the result 1366 of local policy. If local policy information is exposed, abusers can 1367 gain insight into the effectiveness and delivery rates of spam 1368 campaigns. 1370 Final handling of a message is always a matter of local policy. An 1371 operator that wishes to favor DMARC policy over SPF policy, for 1372 example, will disregard the SPF policy, since enacting an SPF- 1373 determined rejection prevents evaluation of DKIM; DKIM might 1374 otherwise pass, satisfying the DMARC evaluation. There is a trade- 1375 off to doing so, namely acceptance and processing of the entire 1376 message body in exchange for the enhanced protection DMARC provides. 1378 DMARC-compliant Mail Receivers typically disregard any mail-handling 1379 directive discovered as part of an authentication mechanism (e.g., 1380 Author Domain Signing Practices (ADSP), SPF) where a DMARC record is 1381 also discovered that specifies a policy other than "none". Deviating 1382 from this practice introduces inconsistency among DMARC operators in 1383 terms of handling of the message. However, such deviation is not 1384 proscribed. 1386 To enable Domain Owners to receive DMARC feedback without impacting 1387 existing mail processing, discovered policies of "p=none" SHOULD NOT 1388 modify existing mail handling processes. 1390 Mail Receivers MUST also implement reporting instructions of DMARC, 1391 even in the absence of a request for DKIM reporting [RFC6651] or SPF 1392 reporting [RFC6652]. Furthermore, the presence of such requests 1393 SHOULD NOT affect DMARC reporting. 1395 7. DMARC Feedback 1397 Providing Domain Owners with visibility into how Mail Receivers 1398 implement and enforce the DMARC mechanism in the form of feedback is 1399 critical to establishing and maintaining accurate authentication 1400 deployments. When Domain Owners can see what effect their policies 1401 and practices are having, they are better willing and able to use 1402 quarantine and reject policies. 1404 The details of this feedback are described in 1405 [DMARC-Aggregate-Reporting] 1407 Operational note for PSD DMARC: For PSOs, feedback for non-existent 1408 domains is desirable and useful, just as it is for org-level DMARC 1409 operators. See Section 4 of [RFC9091] for discussion of Privacy 1410 Considerations for PSD DMARC 1412 8. Minimum Implementations 1414 Domain owners, mediators, and mail receivers can all claim to 1415 implement DMARC, but what that means will depend on their role in the 1416 transmission of mail. To remove any ambiguity from the claims, this 1417 document specifies the following minimum criteria that must be met 1418 for each agent to rightly claim to be "implementing DMARC". 1420 Domain Owner: To implement DMARC, a Domain Owner MUST configure its 1421 domain to convey its concern that unauthenticated mail be rejected or 1422 at least treated with suspicion. Furthermore, the Domain Owner MUST 1423 actively solicit aggregate feedback reports regarding mail using its 1424 domain. This means that it MUST publish a policy record that: 1426 * Has a p tag with a value of 'quarantine' or 'reject' 1428 * Has a rua tag with at least one valid URI 1430 * If applicable, has an sp tag with a value of 'quarantine' or 1431 'reject' 1433 * If desired, has an np tag with a value of 'quarantine' or 'reject' 1435 While 'none' is a syntactically valid value for both p, sp, and np 1436 tags, the practical value of any of those tags being 'none' means 1437 that the Domain Owner is still gathering information about mail flows 1438 for the domain or sub-domains. It is not yet ready to commit to 1439 conveying a severity of concern for unauthenticated email using its 1440 domain. 1442 Mediator: To implement DMARC, a mediator MUST do the following before 1443 passing the message to the next hop or rejecting it as appropriate: 1445 * Perform DMARC verification checks on inbound mail 1447 * Perform verification on any authentication checks recorded by 1448 previous mediators. 1450 * Record the results of its authentication checks in message headers 1451 for consumption by later hosts. 1453 Mail Receiver: To implement DMARC, a mail receiver MUST do the 1454 following: 1456 * Perform DMARC verification checks on inbound mail 1458 * Perform verification checks on any authentication check results 1459 recorded by mediators that handled the message prior to its 1460 reaching the Mail Receiver. 1462 * Send aggregate reports to Domain Owners at least every 24 hours 1463 when a minimum of 100 messages with that domain in the 1464 RFC5322.From header field have been seen during the reporting 1465 period 1467 9. Other Topics 1469 This section discusses some topics regarding choices made in the 1470 development of DMARC, largely to commit the history to record. 1472 9.1. Issues Specific to SPF 1474 Though DMARC does not inherently change the semantics of an SPF 1475 policy record, historically lax enforcement of such policies has led 1476 many to publish extremely broad records containing many large network 1477 ranges. Domain Owners are strongly encouraged to carefully review 1478 their SPF records to understand which networks are authorized to send 1479 on behalf of the Domain Owner before publishing a DMARC record. 1481 Some receiver architectures might implement SPF in advance of any 1482 DMARC operations. This means that a "-" prefix on a sender's SPF 1483 mechanism, such as "-all", could cause that rejection to go into 1484 effect early in handling, causing message rejection before any DMARC 1485 processing takes place. Operators choosing to use "-all" should be 1486 aware of this. 1488 9.2. DNS Load and Caching 1490 DMARC policies are communicated using the DNS and therefore inherit a 1491 number of considerations related to DNS caching. The inherent 1492 conflict between freshness and the impact of caching on the reduction 1493 of DNS-lookup overhead should be considered from the Mail Receiver's 1494 point of view. Should Domain Owners or PSOs publish a DNS record 1495 with a very short TTL, Mail Receivers can be provoked through the 1496 injection of large volumes of messages to overwhelm the publisher's 1497 DNS. Although this is not a concern specific to DMARC, the 1498 implications of a very short TTL should be considered when publishing 1499 DMARC policies. 1501 Conversely, long TTLs will cause records to be cached for long 1502 periods of time. This can cause a critical change to DMARC 1503 parameters advertised by a Domain Owner or PSO to go unnoticed for 1504 the length of the TTL (while waiting for DNS caches to expire). 1505 Avoiding this problem can mean shorter TTLs, with the potential 1506 problems described above. A balance should be sought to maintain 1507 responsiveness of DMARC preference changes while preserving the 1508 benefits of DNS caching. 1510 9.3. Rejecting Messages 1512 This protocol calls for rejection of a message during the SMTP 1513 session under certain circumstances. This is preferable to 1514 generation of a Delivery Status Notification ([RFC3464]), since 1515 fraudulent messages caught and rejected using DMARC would then result 1516 in annoying generation of such failure reports that go back to the 1517 RFC5321.MailFrom address. 1519 This synchronous rejection is typically done in one of two ways: 1521 * Full rejection, wherein the SMTP server issues a 5xy reply code as 1522 an indication to the SMTP client that the transaction failed; the 1523 SMTP client is then responsible for generating notification that 1524 delivery failed (see Section 4.2.5 of [RFC5321]). 1526 * A "silent discard", wherein the SMTP server returns a 2xy reply 1527 code implying to the client that delivery (or, at least, relay) 1528 was successfully completed, but then simply discarding the message 1529 with no further action. 1531 Each of these has a cost. For instance, a silent discard can help to 1532 prevent backscatter, but it also effectively means that the SMTP 1533 server has to be programmed to give a false result, which can 1534 confound external debugging efforts. 1536 Similarly, the text portion of the SMTP reply may be important to 1537 consider. For example, when rejecting a message, revealing the 1538 reason for the rejection might give an attacker enough information to 1539 bypass those efforts on a later attempt, though it might also assist 1540 a legitimate client to determine the source of some local issue that 1541 caused the rejection. 1543 In the latter case, when doing an SMTP rejection, providing a clear 1544 hint can be useful in resolving issues. A receiver might indicate in 1545 plain text the reason for the rejection by using the word "DMARC" 1546 somewhere in the reply text. Many systems are able to scan the SMTP 1547 reply text to determine the nature of the rejection. Thus, providing 1548 a machine-detectable reason for rejection allows the problems causing 1549 rejections to be properly addressed by automated systems. For 1550 example: 1552 550 5.7.1 Email rejected per DMARC policy for example.com 1554 If a Mail Receiver elects to defer delivery due to inability to 1555 retrieve or apply DMARC policy, this is best done with a 4xy SMTP 1556 reply code. 1558 9.4. Identifier Alignment Considerations 1560 The DMARC mechanism allows both DKIM and SPF-authenticated 1561 identifiers to authenticate email on behalf of a Domain Owner and, 1562 possibly, on behalf of different subdomains. If malicious or unaware 1563 users can gain control of the SPF record or DKIM selector records for 1564 a subdomain, the subdomain can be used to generate DMARC-passing 1565 email on behalf of the Organizational Domain. 1567 For example, an attacker who controls the SPF record for 1568 "evil.example.com" can send mail with an RFC5322.From header field 1569 containing "foo@example.com" that can pass both authentication and 1570 the DMARC check against "example.com". 1572 The Organizational Domain administrator should be careful not to 1573 delegate control of subdomains if this is an issue, and to consider 1574 using the "strict" Identifier Alignment option if appropriate. 1576 9.5. Interoperability Issues 1578 DMARC limits which end-to-end scenarios can achieve a "pass" result. 1580 Because DMARC relies on SPF [RFC7208] and/or DKIM [RFC6376] to 1581 achieve a "pass", their limitations also apply. 1583 Additional DMARC constraints occur when a message is processed by 1584 some Mediators, such as mailing lists. Transiting a Mediator often 1585 causes either the authentication to fail or Identifier Alignment to 1586 be lost. These transformations may conform to standards but will 1587 still prevent a DMARC "pass". 1589 In addition to Mediators, mail that is sent by authorized, 1590 independent third parties might not be sent with Identifier 1591 Alignment, also preventing a "pass" result. 1593 Issues specific to the use of policy mechanisms alongside DKIM are 1594 further discussed in [RFC6377], particularly Section 5.2. 1596 10. IANA Considerations 1598 This section describes actions completed by IANA. 1600 10.1. Authentication-Results Method Registry Update 1602 IANA has added the following to the "Email Authentication Methods" 1603 registry: 1605 +======+===========+======+==========+==============+======+========+ 1606 |Method| Defined |ptype | Property |Value |Status|Version | 1607 +======+===========+======+==========+==============+======+========+ 1608 |dmarc | [RFC7489] |header| from |the domain |active|1 | 1609 | | | | |portion of the| | | 1610 | | | | |RFC5322.From | | | 1611 | | | | |header field | | | 1612 +------+-----------+------+----------+--------------+------+--------+ 1613 |dmarc | [RFC7489] |polrec| p |the p= value |active|1 | 1614 | | | | |read from the | | | 1615 | | | | |discovered | | | 1616 | | | | |policy record | | | 1617 +------+-----------+------+----------+--------------+------+--------+ 1618 |dmarc | [RFC7489] |polrec| domain |the domain at |active|1 | 1619 | | | | |which the | | | 1620 | | | | |policy record | | | 1621 | | | | |was | | | 1622 | | | | |discovered, if| | | 1623 | | | | |different from| | | 1624 | | | | |the | | | 1625 | | | | |RFC5322.From | | | 1626 | | | | |domain | | | 1627 +------+-----------+------+----------+--------------+------+--------+ 1629 Table 1: "Authentication-Results Method Registry Update" 1631 10.2. Authentication-Results Result Registry Update 1633 IANA has added the following in the "Email Authentication Result 1634 Names" registry: 1636 +===========+===========+===========+=======+================+======+ 1637 | Code | Existing/ | Defined |Auth |Meaning |Status| 1638 | | New Code | |Method | | | 1639 +===========+===========+===========+=======+================+======+ 1640 | none | existing | [RFC8601] |dmarc |No DMARC policy |active| 1641 | | | |(added)|record was | | 1642 | | | | |published for | | 1643 | | | | |the aligned | | 1644 | | | | |identifier, or | | 1645 | | | | |no aligned | | 1646 | | | | |identifier could| | 1647 | | | | |be extracted. | | 1648 +-----------+-----------+-----------+-------+----------------+------+ 1649 | pass | existing | [RFC8601] |dmarc |A DMARC policy |active| 1650 | | | |(added)|record was | | 1651 | | | | |published for | | 1652 | | | | |the aligned | | 1653 | | | | |identifier, and | | 1654 | | | | |at least one of | | 1655 | | | | |the | | 1656 | | | | |authentication | | 1657 | | | | |mechanisms | | 1658 | | | | |passed. | | 1659 +-----------+-----------+-----------+-------+----------------+------+ 1660 | fail | existing | [RFC8601] |dmarc |A DMARC policy |active| 1661 | | | |(added)|record was | | 1662 | | | | |published for | | 1663 | | | | |the aligned | | 1664 | | | | |identifier, and | | 1665 | | | | |none of the | | 1666 | | | | |authentication | | 1667 | | | | |mechanisms | | 1668 | | | | |passed. | | 1669 +-----------+-----------+-----------+-------+----------------+------+ 1670 | temperror | existing | [RFC8601] |dmarc |A temporary |active| 1671 | | | |(added)|error occurred | | 1672 | | | | |during DMARC | | 1673 | | | | |evaluation. A | | 1674 | | | | |later attempt | | 1675 | | | | |might produce a | | 1676 | | | | |final result. | | 1677 +-----------+-----------+-----------+-------+----------------+------+ 1678 | permerror | existing | [RFC8601] |dmarc |A permanent |active| 1679 | | | |(added)|error occurred | | 1680 | | | | |during DMARC | | 1681 | | | | |evaluation, such| | 1682 | | | | |as encountering | | 1683 | | | | |a syntactically | | 1684 | | | | |incorrect DMARC | | 1685 | | | | |record. A later| | 1686 | | | | |attempt is | | 1687 | | | | |unlikely to | | 1688 | | | | |produce a final | | 1689 | | | | |result. | | 1690 +-----------+-----------+-----------+-------+----------------+------+ 1692 Table 2: "Authentication-Results Result Registry Update" 1694 10.3. Feedback Report Header Fields Registry Update 1696 The following has been added to the "Feedback Report Header Fields" 1697 registry: 1699 Field Name: Identity-Alignment 1700 Description: indicates whether the message about which a report is 1701 being generated had any identifiers in alignment as defined in RFC 1702 7489 1704 Multiple Appearances: No 1706 Related "Feedback-Type": auth-failure 1708 Reference: RFC 7489 1710 Status: current 1712 10.4. DMARC Tag Registry 1714 A new registry tree called "Domain-based Message Authentication, 1715 Reporting, and Conformance (DMARC) Parameters" has been created. 1716 Within it, a new sub-registry called the "DMARC Tag Registry" has 1717 been created. 1719 Names of DMARC tags must be registered with IANA in this new sub- 1720 registry. New entries are assigned only for values that have been 1721 documented in a manner that satisfies the terms of Specification 1722 Required, per [RFC8126]. Each registration must include the tag 1723 name; the specification that defines it; a brief description; and its 1724 status, which must be one of "current", "experimental", or 1725 "historic". The Designated Expert needs to confirm that the provided 1726 specification adequately describes the new tag and clearly presents 1727 how it would be used within the DMARC context by Domain Owners and 1728 Mail Receivers. 1730 To avoid version compatibility issues, tags added to the DMARC 1731 specification are to avoid changing the semantics of existing records 1732 when processed by implementations conforming to prior specifications. 1734 The initial set of entries in this registry is as follows: 1736 +==========+===========+==========+==============================+ 1737 | Tag Name | Reference | Status | Description | 1738 +==========+===========+==========+==============================+ 1739 | adkim | RFC 7489 | current | DKIM alignment mode | 1740 +----------+-----------+----------+------------------------------+ 1741 | aspf | RFC 7489 | current | SPF alignment mode | 1742 +----------+-----------+----------+------------------------------+ 1743 | fo | RFC 7489 | current | Failure reporting options | 1744 +----------+-----------+----------+------------------------------+ 1745 | p | RFC 7489 | current | Requested handling policy | 1746 +----------+-----------+----------+------------------------------+ 1747 | pct | RFC 7489 | historic | Sampling rate | 1748 +----------+-----------+----------+------------------------------+ 1749 | rf | RFC 7489 | historic | Failure reporting format(s) | 1750 +----------+-----------+----------+------------------------------+ 1751 | ri | RFC 7489 | historic | Aggregate Reporting interval | 1752 +----------+-----------+----------+------------------------------+ 1753 | rua | RFC 7489 | current | Reporting URI(s) for | 1754 | | | | aggregate data | 1755 +----------+-----------+----------+------------------------------+ 1756 | ruf | RFC 7489 | current | Reporting URI(s) for failure | 1757 | | | | data | 1758 +----------+-----------+----------+------------------------------+ 1759 | sp | RFC 7489 | current | Requested handling policy | 1760 | | | | for subdomains | 1761 +----------+-----------+----------+------------------------------+ 1762 | t | RFC 7489 | current | Test mode for the specified | 1763 | | | | policy | 1764 +----------+-----------+----------+------------------------------+ 1765 | v | RFC 7489 | current | Specification version | 1766 +----------+-----------+----------+------------------------------+ 1768 Table 3: "DMARC Tag Registry" 1770 10.5. DMARC Report Format Registry 1772 Also within "Domain-based Message Authentication, Reporting, and 1773 Conformance (DMARC) Parameters", a new sub-registry called "DMARC 1774 Report Format Registry" has been created. 1776 Names of DMARC failure reporting formats must be registered with IANA 1777 in this registry. New entries are assigned only for values that 1778 satisfy the definition of Specification Required, per [RFC8126]. In 1779 addition to a reference to a permanent specification, each 1780 registration must include the format name; a brief description; and 1781 its status, which must be one of "current", "experimental", or 1782 "historic". The Designated Expert needs to confirm that the provided 1783 specification adequately describes the report format and clearly 1784 presents how it would be used within the DMARC context by Domain 1785 Owners and Mail Receivers. 1787 The initial entry in this registry is as follows: 1789 +========+===========+=========+==================================+ 1790 | Format | Reference | Status | Description | 1791 | Name | | | | 1792 +========+===========+=========+==================================+ 1793 | afrf | RFC 7489 | current | Authentication Failure Reporting | 1794 | | | | Format (see [RFC6591]) | 1795 +--------+-----------+---------+----------------------------------+ 1797 Table 4: "DMARC Report Format Registry" 1799 10.6. Underscored and Globally Scoped DNS Node Names Registry 1801 Per [RFC8552], please add the following entry to the "Underscored and 1802 Globally Scoped DNS Node Names" registry: 1804 +=========+============+===========+ 1805 | RR Type | _NODE NAME | Reference | 1806 +=========+============+===========+ 1807 | TXT | _dmarc | RFC 7489 | 1808 +---------+------------+-----------+ 1810 Table 5: "Underscored and 1811 Globally Scoped DNS Node Names" 1812 registry 1814 11. Security Considerations 1816 This section discusses security issues and possible remediations 1817 (where available) for DMARC. 1819 11.1. Authentication Methods 1821 Security considerations from the authentication methods used by DMARC 1822 are incorporated here by reference. 1824 11.2. Attacks on Reporting URIs 1826 URIs published in DNS TXT records are well-understood possible 1827 targets for attack. Specifications such as [RFC1035] and [RFC2142] 1828 either expose or cause the exposure of email addresses that could be 1829 flooded by an attacker, for example; MX, NS, and other records found 1830 in the DNS advertise potential attack destinations; common DNS names 1831 such as "www" plainly identify the locations at which particular 1832 services can be found, providing destinations for targeted denial-of- 1833 service or penetration attacks. 1835 Thus, Domain Owners will need to harden these addresses against 1836 various attacks, including but not limited to: 1838 * high-volume denial-of-service attacks; 1840 * deliberate construction of malformed reports intended to identify 1841 or exploit parsing or processing vulnerabilities; 1843 * deliberate construction of reports containing false claims for the 1844 Submitter or Reported-Domain fields, including the possibility of 1845 false data from compromised but known Mail Receivers. 1847 11.3. DNS Security 1849 The DMARC mechanism and its underlying technologies (SPF, DKIM) 1850 depend on the security of the DNS. Examples of how hostile parties 1851 can have an adverse impact on DNS traffic include: * If they can 1852 snoop on DNS traffic, they can get an idea of who is sending mail. 1854 * If they can block outgoing or reply DNS messages, they can prevent 1855 systems from discovering senders' DMARC policies, causing 1856 recipients to assume p=none by default. 1858 * If they can send forged response packets, they can make aligned 1859 mail appear unaligned or vice-versa. 1861 None of these threats are unique to DMARC, and they can be addressed 1862 using a variety of techniques, including, but not limited to: 1864 * Signing DNS records with DNSSEC [RFC4033], which enables 1865 recipients to detect and discard forged responses. 1867 * DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484] can mitigate 1868 snooping and forged responses. 1870 11.4. Display Name Attacks 1872 A common attack in messaging abuse is the presentation of false 1873 information in the display-name portion of the RFC5322.From header 1874 field. For example, it is possible for the email address in that 1875 field to be an arbitrary address or domain name, while containing a 1876 well-known name (a person, brand, role, etc.) in the display name, 1877 intending to fool the end user into believing that the name is used 1878 legitimately. The attack is predicated on the notion that most 1879 common MUAs will show the display name and not the email address when 1880 both are available. 1882 Generally, display name attacks are out of scope for DMARC, as 1883 further exploration of possible defenses against these attacks needs 1884 to be undertaken. 1886 There are a few possible mechanisms that attempt mitigation of these 1887 attacks, such as the following: 1889 * If the display name is found to include an email address (as 1890 specified in [RFC5322]), execute the DMARC mechanism on the domain 1891 name found there rather than the domain name discovered 1892 originally. However, this addresses only a very specific attack 1893 space, and spoofers can easily circumvent it by simply not using 1894 an email address in the display name. There are also known cases 1895 of legitimate uses of an email address in the display name with a 1896 domain different from the one in the address portion, e.g., 1898 From: "user@example.org via Bug Tracker" support@example.com 1899 (mailto:support@example.com) 1901 * In the MUA, only show the display name if the DMARC mechanism 1902 succeeds. This too is easily defeated, as an attacker could 1903 arrange to pass the DMARC tests while fraudulently using another 1904 domain name in the display name. 1906 * In the MUA, only show the display name if the DMARC mechanism 1907 passes and the email address thus verified matches one found in 1908 the receiving user's list of known addresses. 1910 11.5. External Reporting Addresses 1912 To avoid abuse by bad actors, reporting addresses generally have to 1913 be inside the domains about which reports are requested. In order to 1914 accommodate special cases such as a need to get reports about domains 1915 that cannot actually receive mail, Section 3 of 1916 [DMARC-Aggregate-Reporting] describes a DNS-based mechanism for 1917 verifying approved external reporting. 1919 The obvious consideration here is an increased DNS load against 1920 domains that are claimed as external recipients. Negative caching 1921 will mitigate this problem, but only to a limited extent, mostly 1922 dependent on the default TTL in the domain's SOA record. 1924 Where possible, external reporting is best achieved by having the 1925 report be directed to domains that can receive mail and simply having 1926 it automatically forwarded to the desired external destination. 1928 Note that the addresses shown in the "ruf" tag receive more 1929 information that might be considered private data, since it is 1930 possible for actual email content to appear in the failure reports. 1931 The URIs identified there are thus more attractive targets for 1932 intrusion attempts than those found in the "rua" tag. Moreover, 1933 attacking the DNS of the subject domain to cause failure data to be 1934 routed fraudulently to an attacker's systems may be an attractive 1935 prospect. Deployment of [RFC4033] is advisable if this is a concern. 1937 11.6. Secure Protocols 1939 This document encourages use of secure transport mechanisms to 1940 prevent loss of private data to third parties that may be able to 1941 monitor such transmissions. Unencrypted mechanisms should be 1942 avoided. 1944 In particular, a message that was originally encrypted or otherwise 1945 secured might appear in a report that is not sent securely, which 1946 could reveal private information. 1948 12. Normative References 1950 [DMARC-Aggregate-Reporting] 1951 Brotman, A., Ed., "DMARC Aggregate Reporting", February 1952 2021, . 1955 [DMARC-Failure-Reporting] 1956 Jones, S.M., Ed. and A. Vesely, Ed., "DMARC Failure 1957 Reporting", February 2021, 1958 . 1961 [RFC1035] Mockapetris, P., "Domain names - implementation and 1962 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1963 November 1987, . 1965 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1966 Requirement Levels", BCP 14, RFC 2119, 1967 DOI 10.17487/RFC2119, March 1997, 1968 . 1970 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1971 Resource Identifier (URI): Generic Syntax", STD 66, 1972 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1973 . 1975 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case 1976 Insensitivity Clarification", RFC 4343, 1977 DOI 10.17487/RFC4343, January 2006, 1978 . 1980 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1981 Specifications: ABNF", STD 68, RFC 5234, 1982 DOI 10.17487/RFC5234, January 2008, 1983 . 1985 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1986 DOI 10.17487/RFC5321, October 2008, 1987 . 1989 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1990 DOI 10.17487/RFC5322, October 2008, 1991 . 1993 [RFC5890] Klensin, J., "Internationalized Domain Names for 1994 Applications (IDNA): Definitions and Document Framework", 1995 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1996 . 1998 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1999 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 2000 RFC 6376, DOI 10.17487/RFC6376, September 2011, 2001 . 2003 [RFC6591] Fontana, H., "Authentication Failure Reporting Using the 2004 Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591, 2005 April 2012, . 2007 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail 2008 (DKIM) for Failure Reporting", RFC 6651, 2009 DOI 10.17487/RFC6651, June 2012, 2010 . 2012 [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) 2013 Authentication Failure Reporting Using the Abuse Reporting 2014 Format", RFC 6652, DOI 10.17487/RFC6652, June 2012, 2015 . 2017 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 2018 Authorizing Use of Domains in Email, Version 1", RFC 7208, 2019 DOI 10.17487/RFC7208, April 2014, 2020 . 2022 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 2023 Message Authentication, Reporting, and Conformance 2024 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 2025 . 2027 [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource 2028 Records through "Underscored" Naming of Attribute Leaves", 2029 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 2030 . 2032 [RFC9091] Kitterman, S. and T. Wicinski, Ed., "Experimental Domain- 2033 Based Message Authentication, Reporting, and Conformance 2034 (DMARC) Extension for Public Suffix Domains", RFC 9091, 2035 DOI 10.17487/RFC9091, July 2021, 2036 . 2038 13. Informative References 2040 [Best-Guess-SPF] 2041 Kitterman, S., "Sender Policy Framework: Best guess record 2042 (FAQ entry)", May 2010, 2043 . 2045 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 2046 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 2047 . 2049 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 2050 for Delivery Status Notifications", RFC 3464, 2051 DOI 10.17487/RFC3464, January 2003, 2052 . 2054 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2055 Rose, "DNS Security Introduction and Requirements", 2056 RFC 4033, DOI 10.17487/RFC4033, March 2005, 2057 . 2059 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 2060 DOI 10.17487/RFC5598, July 2009, 2061 . 2063 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, 2064 "DomainKeys Identified Mail (DKIM) Author Domain Signing 2065 Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617, August 2066 2009, . 2068 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 2069 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 2070 September 2011, . 2072 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 2073 and P. Hoffman, "Specification for DNS over Transport 2074 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2075 2016, . 2077 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 2078 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 2079 November 2016, . 2081 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2082 Writing an IANA Considerations Section in RFCs", BCP 26, 2083 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2084 . 2086 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2087 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2088 May 2017, . 2090 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 2091 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 2092 . 2094 [RFC8601] Kucherawy, M., "Message Header Field for Indicating 2095 Message Authentication Status", RFC 8601, 2096 DOI 10.17487/RFC8601, May 2019, 2097 . 2099 Appendix A. Technology Considerations 2101 This section documents some design decisions that were made in the 2102 development of DMARC. Specifically, addressed here are some 2103 suggestions that were considered but not included in the design. 2104 This text is included to explain why they were considered and not 2105 included in this version. 2107 A.1. S/MIME 2109 S/MIME, or Secure Multipurpose Internet Mail Extensions, is a 2110 standard for encryption and signing of MIME data in a message. This 2111 was suggested and considered as a third security protocol for 2112 authenticating the source of a message. 2114 DMARC is focused on authentication at the domain level (i.e., the 2115 Domain Owner taking responsibility for the message), while S/MIME is 2116 really intended for user-to-user authentication and encryption. This 2117 alone appears to make it a bad fit for DMARC's goals. 2119 S/MIME also suffers from the heavyweight problem of Public Key 2120 Infrastructure, which means that distribution of keys used to verify 2121 signatures needs to be incorporated. In many instances, this alone 2122 is a showstopper. There have been consistent promises that PKI 2123 usability and deployment will improve, but these have yet to 2124 materialize. DMARC can revisit this choice after those barriers are 2125 addressed. 2127 S/MIME has extensive deployment in specific market segments 2128 (government, for example) but does not enjoy similar widespread 2129 deployment over the general Internet, and this shows no signs of 2130 changing. DKIM and SPF both are deployed widely over the general 2131 Internet, and their adoption rates continue to be positive. 2133 Finally, experiments have shown that including S/MIME support in the 2134 initial version of DMARC would neither cause nor enable a substantial 2135 increase in the accuracy of the overall mechanism. 2137 A.2. Method Exclusion 2139 It was suggested that DMARC include a mechanism by which a Domain 2140 Owner could tell Message Receivers not to attempt verification by one 2141 of the supported methods (e.g., "check DKIM, but not SPF"). 2143 Specifically, consider a Domain Owner that has deployed one of the 2144 technologies, and that technology fails for some messages, but such 2145 failures don't cause enforcement action. Deploying DMARC would cause 2146 enforcement action for policies other than "none", which would appear 2147 to exclude participation by that Domain Owner. 2149 The DMARC development team evaluated the idea of policy exception 2150 mechanisms on several occasions and invariably concluded that there 2151 was not a strong enough use case to include them. The specific 2152 target audience for DMARC does not appear to have concerns about the 2153 failure modes of one or the other being a barrier to DMARC's 2154 adoption. 2156 In the scenario described above, the Domain Owner has a few options: 2158 1. Tighten up its infrastructure to minimize the failure modes of 2159 the single deployed technology. 2161 2. Deploy the other supported authentication mechanism, to offset 2162 the failure modes of the first. 2164 3. Deploy DMARC in a reporting-only mode. 2166 A.3. Sender Header Field 2168 It has been suggested in several message authentication efforts that 2169 the Sender header field be checked for an identifier of interest, as 2170 the standards indicate this as the proper way to indicate a re- 2171 mailing of content such as through a mailing list. Most recently, it 2172 was a protocol-level option for DomainKeys, but on evolution to DKIM, 2173 this property was removed. 2175 The DMARC development team considered this and decided not to include 2176 support for doing so, for the following reasons: 2178 1. The main user protection approach is to be concerned with what 2179 the user sees when a message is rendered. There is no consistent 2180 behavior among MUAs regarding what to do with the content of the 2181 Sender field, if present. Accordingly, supporting checking of 2182 the Sender identifier would mean applying policy to an identifier 2183 the end user might never actually see, which can create a vector 2184 for attack against end users by simply forging a Sender field 2185 containing some identifier that DMARC will like. 2187 2. Although it is certainly true that this is what the Sender field 2188 is for, its use in this way is also unreliable, making it a poor 2189 candidate for inclusion in the DMARC evaluation algorithm. 2191 3. Allowing multiple ways to discover policy introduces unacceptable 2192 ambiguity into the DMARC evaluation algorithm in terms of which 2193 policy is to be applied and when. 2195 A.4. Domain Existence Test 2197 A common practice among MTA operators, and indeed one documented in 2198 [RFC5617], is a test to determine domain existence prior to any more 2199 expensive processing. This is typically done by querying the DNS for 2200 MX, A, or AAAA resource records for the name being evaluated and 2201 assuming that the domain is nonexistent if it could be determined 2202 that no such records were published for that domain name. 2204 The original pre-standardization version of this protocol included a 2205 mandatory check of this nature. It was ultimately removed, as the 2206 method's error rate was too high without substantial manual tuning 2207 and heuristic work. There are indeed use cases this work needs to 2208 address where such a method would return a negative result about a 2209 domain for which reporting is desired, such as a registered domain 2210 name that never sends legitimate mail and thus has none of these 2211 records present in the DNS. The addition of the "np=" tag in this 2212 version of the protocol is one way to address these use cases. 2214 A.5. Issues with ADSP in Operation 2216 DMARC has been characterized as a "super-ADSP" of sorts. 2218 Contributors to DMARC have compiled a list of issues associated with 2219 ADSP, gained from operational experience, that have influenced the 2220 direction of DMARC: 2222 1. ADSP has no support for subdomains, i.e., the ADSP record for 2223 example.com does not explicitly or implicitly apply to 2224 subdomain.example.com. If wildcarding is not applied, then 2225 spammers can trivially bypass ADSP by sending from a subdomain 2226 with no ADSP record. 2228 2. Nonexistent subdomains are explicitly out of scope in ADSP. 2229 There is nothing in ADSP that states receivers should simply 2230 reject mail from NXDOMAINs regardless of ADSP policy (which of 2231 course allows spammers to trivially bypass ADSP by sending email 2232 from nonexistent subdomains). 2234 3. ADSP has no operational advice on when to look up the ADSP 2235 record. 2237 4. ADSP has no support for using SPF as an auxiliary mechanism to 2238 DKIM. 2240 5. ADSP has no support for a slow rollout, i.e., no way to configure 2241 a percentage of email on which the receiver should apply the 2242 policy. This is important for large-volume senders. 2244 6. ADSP has no explicit support for an intermediate phase where the 2245 receiver quarantines (e.g., sends to the recipient's "spam" 2246 folder) rather than rejects the email. 2248 7. The binding between the "From" header domain and DKIM is too 2249 tight for ADSP; they must match exactly. 2251 A.6. Organizational Domain Discovery Issues 2253 Although protocols like ADSP are useful for "protecting" a specific 2254 domain name, they are not helpful at protecting subdomains. If one 2255 wished to protect "example.com" by requiring via ADSP that all mail 2256 bearing an RFC5322.From domain of "example.com" be signed, this would 2257 "protect" that domain; however, one could then craft an email whose 2258 RFC5322.From domain is "security.example.com", and ADSP would not 2259 provide any protection. One could use a DNS wildcard, but this can 2260 undesirably interfere with other DNS activity; one could add ADSP 2261 records as fraudulent domains are discovered, but this solution does 2262 not scale and is a purely reactive measure against abuse. 2264 The DNS does not provide a method by which the "domain of record", or 2265 the domain that was actually registered with a domain registrar, can 2266 be determined given an arbitrary domain name. Suggestions have been 2267 made that attempt to glean such information from SOA or NS resource 2268 records, but these too are not fully reliable, as the partitioning of 2269 the DNS is not always done at administrative boundaries. 2271 When seeking domain-specific policy based on an arbitrary domain 2272 name, one could "climb the tree", dropping labels off the left end of 2273 the name until the root is reached or a policy is discovered, but 2274 then one could craft a name that has a large number of nonsense 2275 labels; this would cause a Mail Receiver to attempt a large number of 2276 queries in search of a policy record. Sending many such messages 2277 constitutes an amplified denial-of-service attack. 2279 The Organizational Domain mechanism is a necessary component to the 2280 goals of DMARC. The method described in Section 3.15 is far from 2281 perfect but serves this purpose reasonably well without adding undue 2282 burden or semantics to the DNS. If a method is created to do so that 2283 is more reliable and secure than the use of a public suffix list, 2284 DMARC should be amended to use that method as soon as it is generally 2285 available. 2287 A.6.1. Public Suffix Lists 2289 A public suffix list for the purposes of determining the 2290 Organizational Domain can be obtained from various sources. The most 2291 common one is maintained by the Mozilla Foundation and made public at 2292 http://publicsuffix.org (http://publicsuffix.org). License terms 2293 governing the use of that list are available at that URI. 2295 Note that if operators use a variety of public suffix lists, 2296 interoperability will be difficult or impossible to guarantee. 2298 A.7. Removal of the "pct" Tag 2300 An earlier informational version of the DMARC protocol [RFC7489] 2301 included a "pct" tag and specified all integers from 0 to 100 2302 inclusive as valid values for the tag. The intent of the tag was to 2303 provide domain owners with a method to gradually change their 2304 preferred assessment policy (the p= tag) from 'none' to 'quarantine' 2305 or from 'quarantine' to 'reject' by requesting the stricter treatment 2306 for just a percentage of messages that produced DMARC results of 2307 "fail". 2309 Operational experience and mathematics (specifically the Probability 2310 Mass Function as applied to Binomial Distributions) showed that the 2311 pct tag was usually not accurately applied, unless the value 2312 specified was either "0" or "100" (the default), and the inaccuracies 2313 with other values varied widely from implementation to 2314 implementation. The default value was easily implemented, as it 2315 required no special processing on the part of the message receiver, 2316 while the value of "0" took on unintended significance as a value 2317 used by some intermediaries and mailbox providers as an indicator to 2318 deviate from standard handling of the message, usually by rewriting 2319 the RFC5322.From header in an effort to avoid DMARC failures 2320 downstream. 2322 These custom actions when the pct= tag was set to "0" proved valuable 2323 to the email community. In particular, header rewriting by an 2324 intermediary meant that a Domain Owner's aggregate reports could 2325 reveal to the Domain Owner how much of its traffic was routing 2326 through intermediaries that don't rewrite the RFC5322.From header. 2327 It required work on the part of the Domain Owner to compare aggregate 2328 reports from before and after the p= value was changed and pct= was 2329 included in the DMARC policy record with a value of "0", but the data 2330 was there. Consequently, knowing how much mail was subject to 2331 possible DMARC failure due to lack of RFC5322.From header rewriting 2332 by intermediaries could assist the Domain Owner in choosing whether 2333 or not to proceed from an applied policy of p=none to p=quarantine or 2334 p=reject. Armed with this knowledge, the Domain Owner could make an 2335 informed decision regarding subjecting its mail traffic to possible 2336 DMARC failures based on the Domain Owner's tolerance for such things. 2338 Because of the value provided by "pct=0" to Domain Owners, it was 2339 logical to keep this functionality in the protocol; at the same time 2340 it didn't make sense to support a tag named "pct" that had only two 2341 valid values. This version of the DMARC protocol therefore 2342 introduces the "t" tag as shorthand for "testing", with the valid 2343 values of "y" and "n", which are meant to be analogous in their 2344 application by mailbox providers and intermediaries to the "pct" tag 2345 values "0" and "100", respectively. 2347 Appendix B. Examples 2349 This section illustrates both the Domain Owner side and the Mail 2350 Receiver side of a DMARC exchange. 2352 B.1. Identifier Alignment Examples 2354 The following examples illustrate the DMARC mechanism's use of 2355 Identifier Alignment. For brevity's sake, only message headers are 2356 shown, as message bodies are not considered when conducting DMARC 2357 checks. 2359 B.1.1. SPF 2361 The following SPF examples assume that SPF produces a passing result. 2362 Alignment cannot exist if SPF does not produce a passing result. 2364 Example 1: SPF in alignment: 2366 MAIL FROM: 2368 From: sender@example.com 2369 Date: Fri, Feb 15 2002 16:54:30 -0800 2370 To: receiver@example.org 2371 Subject: here's a sample 2373 In this case, the RFC5321.MailFrom parameter and the RFC5322.From 2374 header field have identical DNS domains. Thus, the identifiers are 2375 in strict alignment. 2377 Example 2: SPF in alignment (parent): 2379 MAIL FROM: 2381 From: sender@example.com 2382 Date: Fri, Feb 15 2002 16:54:30 -0800 2383 To: receiver@example.org 2384 Subject: here's a sample 2386 In this case, the RFC5322.From header parameter includes a DNS domain 2387 that is a parent of the RFC5321.MailFrom domain. Thus, the 2388 identifiers are in relaxed alignment, because they both have the same 2389 Organizational Domain (example.com). 2391 Example 3: SPF not in alignment: 2393 MAIL FROM: 2395 From: sender@child.example.com 2396 Date: Fri, Feb 15 2002 16:54:30 -0800 2397 To: receiver@example.org 2398 Subject: here's a sample 2400 In this case, the RFC5321.MailFrom parameter includes a DNS domain 2401 that is neither the same as, a parent of, nor a child of the 2402 RFC5322.From domain. Thus, the identifiers are not in alignment. 2404 B.1.2. DKIM 2406 The examples below assume that the DKIM signatures pass verification. 2407 Alignment cannot exist with a DKIM signature that does not verify. 2409 Example 1: DKIM in alignment: 2411 DKIM-Signature: v=1; ...; d=example.com; ... 2412 From: sender@example.com 2413 Date: Fri, Feb 15 2002 16:54:30 -0800 2414 To: receiver@example.org 2415 Subject: here's a sample 2417 In this case, the DKIM "d=" parameter and the RFC5322.From header 2418 field have identical DNS domains. Thus, the identifiers are in 2419 strict alignment. 2421 Example 2: DKIM in alignment (parent): 2423 DKIM-Signature: v=1; ...; d=example.com; ... 2424 From: sender@child.example.com 2425 Date: Fri, Feb 15 2002 16:54:30 -0800 2426 To: receiver@example.org 2427 Subject: here's a sample 2429 In this case, the DKIM signature's "d=" parameter includes a DNS 2430 domain that is a parent of the RFC5322.From domain. Thus, the 2431 identifiers are in relaxed alignment, as they have the same 2432 Organizational Domain (example.com). 2434 Example 3: DKIM not in alignment: 2436 DKIM-Signature: v=1; ...; d=sample.net; ... 2437 From: sender@child.example.com 2438 Date: Fri, Feb 15 2002 16:54:30 -0800 2439 To: receiver@example.org 2440 Subject: here's a sample 2442 In this case, the DKIM signature's "d=" parameter includes a DNS 2443 domain that is neither the same as, a parent of, nor a child of the 2444 RFC5322.From domain. Thus, the identifiers are not in alignment. 2446 B.2. Domain Owner Example 2448 A Domain Owner that wants to use DMARC should have already deployed 2449 and tested SPF and DKIM. The next step is to publish a DNS record 2450 that advertises a DMARC policy for the Domain Owner's Organizational 2451 Domain. 2453 B.2.1. Entire Domain, Monitoring Only 2455 The owner of the domain "example.com" has deployed SPF and DKIM on 2456 its messaging infrastructure. The owner wishes to begin using DMARC 2457 with a policy that will solicit aggregate feedback from receivers 2458 without affecting how the messages are processed, in order to: 2460 * Confirm that its legitimate messages are authenticating correctly 2462 * Verify that all authorized message sources have implemented 2463 authentication measures 2465 * Determine how many messages from other sources would be affected 2466 by a blocking policy 2468 The Domain Owner accomplishes this by constructing a policy record 2469 indicating that: 2471 * The version of DMARC being used is "DMARC1" ("v=DMARC1;") 2473 * Receivers should not alter how they treat these messages because 2474 of this DMARC policy record ("p=none") 2476 * Aggregate feedback reports should be sent via email to the address 2477 "dmarc-feedback@example.com" ("rua=mailto:dmarc- 2478 feedback@example.com") 2480 * All messages from this Organizational Domain are subject to this 2481 policy (no "t" tag present, so the default of "n" applies). 2483 The DMARC policy record might look like this when retrieved using a 2484 common command-line tool: 2486 % dig +short TXT _dmarc.example.com. 2487 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com" 2489 To publish such a record, the DNS administrator for the Domain Owner 2490 creates an entry like the following in the appropriate zone file 2491 (following the conventional zone file format): 2493 ; DMARC record for the domain example.com 2495 _dmarc IN TXT ( "v=DMARC1; p=none; " 2496 "rua=mailto:dmarc-feedback@example.com" ) 2498 B.2.2. Entire Domain, Monitoring Only, Per-Message Reports 2500 The Domain Owner from the previous example has used the aggregate 2501 reporting to discover some messaging systems that had not yet 2502 implemented DKIM correctly, but they are still seeing periodic 2503 authentication failures. In order to diagnose these intermittent 2504 problems, they wish to request per-message failure reports when 2505 authentication failures occur. 2507 Not all Receivers will honor such a request, but the Domain Owner 2508 feels that any reports it does receive will be helpful enough to 2509 justify publishing this record. The default per-message report 2510 format ([RFC6591]) meets the Domain Owner's needs in this scenario. 2512 The Domain Owner accomplishes this by adding the following to its 2513 policy record from Appendix B.2: 2515 * Per-message failure reports should be sent via email to the 2516 address "auth-reports@example.com" ("ruf=mailto:auth- 2517 reports@example.com") 2519 The DMARC policy record might look like this when retrieved using a 2520 common command-line tool (the output shown would appear on a single 2521 line but is wrapped here for publication): 2523 % dig +short TXT _dmarc.example.com. 2524 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; 2525 ruf=mailto:auth-reports@example.com" 2527 To publish such a record, the DNS administrator for the Domain Owner 2528 might create an entry like the following in the appropriate zone file 2529 (following the conventional zone file format): 2531 ; DMARC record for the domain example.com 2533 _dmarc IN TXT ( "v=DMARC1; p=none; " 2534 "rua=mailto:dmarc-feedback@example.com; " 2535 "ruf=mailto:auth-reports@example.com" ) 2537 B.2.3. Per-Message Failure Reports Directed to Third Party 2539 The Domain Owner from the previous example is maintaining the same 2540 policy but now wishes to have a third party receive and process the 2541 per-message failure reports. Again, not all Receivers will honor 2542 this request, but those that do may implement additional checks to 2543 verify that the third party wishes to receive the failure reports for 2544 this domain. 2546 The Domain Owner needs to alter its policy record from Appendix B.2.2 2547 as follows: 2549 * Per-message failure reports should be sent via email to the 2550 address "auth-reports@thirdparty.example.net" ("ruf=mailto:auth- 2551 reports@thirdparty.example.net") 2553 The DMARC policy record might look like this when retrieved using a 2554 common command-line tool (the output shown would appear on a single 2555 line but is wrapped here for publication): 2557 % dig +short TXT _dmarc.example.com. 2558 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; 2559 ruf=mailto:auth-reports@thirdparty.example.net" 2561 To publish such a record, the DNS administrator for the Domain Owner 2562 might create an entry like the following in the appropriate zone file 2563 (following the conventional zone file format): 2565 ; DMARC record for the domain example.com 2567 _dmarc IN TXT ( "v=DMARC1; p=none; " 2568 "rua=mailto:dmarc-feedback@example.com; " 2569 "ruf=mailto:auth-reports@thirdparty.example.net" ) 2571 Because the address used in the "ruf" tag is outside the 2572 Organizational Domain in which this record is published, conforming 2573 Receivers will implement additional checks as described in Section 3 2574 of [DMARC-Aggregate-Reporting]. In order to pass these additional 2575 checks, the third party will need to publish an additional DNS record 2576 as follows: 2578 * Given the DMARC record published by the Domain Owner at 2579 "_dmarc.example.com", the DNS administrator for the third party 2580 will need to publish a TXT resource record at 2581 "example.com._report._dmarc.thirdparty.example.net" with the value 2582 "v=DMARC1;". 2584 The resulting DNS record might look like this when retrieved using a 2585 common command-line tool (the output shown would appear on a single 2586 line but is wrapped here for publication): 2588 % dig +short TXT example.com._report._dmarc.thirdparty.example.net 2589 "v=DMARC1;" 2591 To publish such a record, the DNS administrator for example.net might 2592 create an entry like the following in the appropriate zone file 2593 (following the conventional zone file format): 2595 ; zone file for thirdparty.example.net 2596 ; Accept DMARC failure reports on behalf of example.com 2598 example.com._report._dmarc IN TXT "v=DMARC1;" 2600 Mediators and other third parties should refer to Section 3 of 2601 [DMARC-Aggregate-Reporting] for the full details of this mechanism. 2603 B.2.4. Subdomain, Testing, and Multiple Aggregate Report URIs 2605 The Domain Owner has implemented SPF and DKIM in a subdomain used for 2606 pre-production testing of messaging services. It now wishes to 2607 express a severity of concern for messages from this subdomain that 2608 fail to authenticate to indicate to participating receivers that use 2609 of this domain is not valid. 2611 As a first step, it will express that it considers to be suspicious 2612 messages using this subdomain that fail authentication. The goal 2613 here will be to enable examination of messages sent to mailboxes 2614 hosted by participating receivers as method for troubleshooting any 2615 existing authentication issues. Aggregate feedback reports will be 2616 sent to a mailbox within the Organizational Domain, and to a mailbox 2617 at a third party selected and authorized to receive same by the 2618 Domain Owner. 2620 The Domain Owner will accomplish this by constructing a policy record 2621 indicating that: 2623 * The version of DMARC being used is "DMARC1" ("v=DMARC1;") 2625 * It is applied only to this subdomain (record is published at 2626 "_dmarc.test.example.com" and not "_dmarc.example.com") 2628 * Receivers are advised that the Domain Owner considers messages 2629 that fail to authenticate to be suspicious ("p=quarantine") 2631 * Aggregate feedback reports should be sent via email to the 2632 addresses "dmarc-feedback@example.com" and "example-tld- 2633 test@thirdparty.example.net" ("rua=mailto:dmarc- 2634 feedback@example.com, mailto:tld-test@thirdparty.example.net") 2636 * The Domain Owner desires only that an actor performing a DMARC 2637 verification check apply any special handling rules it might have 2638 in place, such as rewriting the RFC53322.From header; the Domain 2639 Owner is testing its setup at this point, and so does not want the 2640 handling policy to be applied. ("t=y") 2642 The DMARC policy record might look like this when retrieved using a 2643 common command-line tool (the output shown would appear on a single 2644 line but is wrapped here for publication): 2646 % dig +short TXT _dmarc.test.example.com 2647 "v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com, 2648 mailto:tld-test@thirdparty.example.net t=y" 2650 To publish such a record, the DNS administrator for the Domain Owner 2651 might create an entry like the following in the appropriate zone 2652 file: 2654 ; DMARC record for the domain test.example.com 2656 _dmarc IN TXT ( "v=DMARC1; p=quarantine; " 2657 "rua=mailto:dmarc-feedback@example.com," 2658 "mailto:tld-test@thirdparty.example.net;" 2659 "t=y" ) 2661 Once enough time has passed to allow for collecting enough reports to 2662 give the Domain Owner confidence that all legitimate email sent using 2663 the subdomain is properly authenticating and passing DMARC checks, 2664 then the Domain Owner can update the policy record to indicate that 2665 it considers authentication failures to be a clear indication that 2666 use of the subdomain is not valid. It would do this by altering the 2667 DNS record to advise receivers of its position on such messages 2668 ("p=reject"). 2670 After alteration, the DMARC policy record might look like this when 2671 retrieved using a common command-line tool (the output shown would 2672 appear on a single line but is wrapped here for publication): 2674 % dig +short TXT _dmarc.test.example.com 2675 "v=DMARC1; p=reject; rua=mailto:dmarc-feedback@example.com, 2676 mailto:tld-test@thirdparty.example.net" 2678 To publish such a record, the DNS administrator for the Domain Owner 2679 might create an entry like the following in the appropriate zone 2680 file: 2682 ; DMARC record for the domain test.example.com 2684 _dmarc IN TXT ( "v=DMARC1; p=reject; " 2685 "rua=mailto:dmarc-feedback@example.com," 2686 "mailto:tld-test@thirdparty.example.net" ) 2688 B.3. Mail Receiver Example 2690 A Mail Receiver that wants to use DMARC should already be checking 2691 SPF and DKIM, and possess the ability to collect relevant information 2692 from various email-processing stages to provide feedback to Domain 2693 Owners (possibly via Report Receivers). 2695 B.4. Processing of SMTP Time 2697 An optimal DMARC-enabled Mail Receiver performs authentication and 2698 Identifier Alignment checking during the SMTP [RFC5321] conversation. 2700 Prior to returning a final reply to the DATA command, the Mail 2701 Receiver's MTA has performed: 2703 1. An SPF check to determine an SPF-authenticated Identifier. 2705 2. DKIM checks that yield one or more DKIM-authenticated 2706 Identifiers. 2708 3. A DMARC policy lookup. 2710 The presence of an Author Domain DMARC record indicates that the Mail 2711 Receiver should continue with DMARC-specific processing before 2712 returning a reply to the DATA command. 2714 Given a DMARC record and the set of Authenticated Identifiers, the 2715 Mail Receiver checks to see if the Authenticated Identifiers align 2716 with the Author Domain (taking into consideration any strict versus 2717 relaxed options found in the DMARC record). 2719 For example, the following sample data is considered to be from a 2720 piece of email originating from the Domain Owner of "example.com": 2722 Author Domain: example.com 2723 SPF-authenticated Identifier: mail.example.com 2724 DKIM-authenticated Identifier: example.com 2725 DMARC record: 2726 "v=DMARC1; p=reject; aspf=r; 2727 rua=mailto:dmarc-feedback@example.com" 2729 In the above sample, both the SPF-authenticated Identifier and the 2730 DKIM-authenticated Identifier align with the Author Domain. The Mail 2731 Receiver considers the above email to pass the DMARC check, avoiding 2732 the "reject" policy that is requested to be applied to email that 2733 fails to pass the DMARC check. 2735 If no Authenticated Identifiers align with the Author Domain, then 2736 the Mail Receiver applies the DMARC-record-specified policy. 2737 However, before this action is taken, the Mail Receiver can consult 2738 external information to override the Domain Owner's Assessment 2739 Policy. 2740 For example, if the Mail Receiver knows that this particular email 2741 came from a known and trusted forwarder (that happens to break both 2742 SPF and DKIM), then the Mail Receiver may choose to ignore the Domain 2743 Owner's policy. 2745 The Mail Receiver is now ready to reply to the DATA command. If the 2746 DMARC check yields that the message is to be rejected, then the Mail 2747 Receiver replies with a 5xy code to inform the sender of failure. If 2748 the DMARC check cannot be resolved due to transient network errors, 2749 then the Mail Receiver replies with a 4xy code to inform the sender 2750 as to the need to reattempt delivery later. If the DMARC check 2751 yields a passing message, then the Mail Receiver continues on with 2752 email processing, perhaps using the result of the DMARC check as an 2753 input to additional processing modules such as a domain reputation 2754 query. 2756 Before exiting DMARC-specific processing, the Mail Receiver checks to 2757 see if the Author Domain DMARC record requests AFRF-based reporting. 2758 If so, then the Mail Receiver can emit an AFRF to the reporting 2759 address supplied in the DMARC record. 2761 At the exit of DMARC-specific processing, the Mail Receiver captures 2762 (through logging or direct insertion into a data store) the result of 2763 DMARC processing. Captured information is used to build feedback for 2764 Domain Owner consumption. This is not necessary if the Domain Owner 2765 has not requested aggregate reports, i.e., no "rua" tag was found in 2766 the policy record. 2768 B.5. Utilization of Aggregate Feedback: Example 2770 Aggregate feedback is consumed by Domain Owners to verify their 2771 understanding of how a given domain is being processed by the Mail 2772 Receiver. Aggregate reporting data on emails that pass all DMARC- 2773 supporting authentication checks is used by Domain Owners to verify 2774 that their authentication practices remain accurate. For example, if 2775 a third party is sending on behalf of a Domain Owner, the Domain 2776 Owner can use aggregate report data to verify ongoing authentication 2777 practices of the third party. 2779 Data on email that only partially passes underlying authentication 2780 checks provides visibility into problems that need to be addressed by 2781 the Domain Owner. For example, if either SPF or DKIM fails to pass, 2782 the Domain Owner is provided with enough information to either 2783 directly correct the problem or understand where authentication- 2784 breaking changes are being introduced in the email transmission path. 2785 If authentication-breaking changes due to email transmission path 2786 cannot be directly corrected, then the Domain Owner at least 2787 maintains an understanding of the effect of DMARC-based policies upon 2788 the Domain Owner's email. 2790 Data on email that fails all underlying authentication checks 2791 provides baseline visibility on how the Domain Owner's domain is 2792 being received at the Mail Receiver. Based on this visibility, the 2793 Domain Owner can begin deployment of authentication technologies 2794 across uncovered email sources, if the mail that is failing the 2795 checks was generated by or on behalf of the Domain Owner. Data 2796 regarding failing authentication checks can also allow the Domain 2797 Owner to come to an understanding of how its domain is being misused. 2799 (Aggregate report example should be moved to 2800 [DMARC-Aggregate-Reporting]) 2802 Appendix C. Change Log 2804 C.1. January 5, 2021 2806 C.1.1. Ticket 80 - DMARCbis SHould Have Clear and Concise Defintion of 2807 DMARC 2809 * Updated text for Abstract and Introduction sections. 2811 * Diffs are recorded here - https://github.com/ietf-wg-dmarc/draft- 2812 ietf-dmarc-dmarcbis/pull/1/files (https://github.com/ietf-wg- 2813 dmarc/draft-ietf-dmarc-dmarcbis/pull/1/files) 2815 C.2. February 4, 2021 2817 C.2.1. Ticket 1 - SPF RFC 4408 vs 7208 2819 * Some rearranging of text in the "SPF-Authenticated Identifiers" 2820 section 2822 * Clarification of the term "in alignment" in that same section 2824 * Diffs are here - https://github.com/ietf-wg-dmarc/draft-ietf- 2825 dmarc-dmarcbis/pull/3/files (https://github.com/ietf-wg-dmarc/ 2826 draft-ietf-dmarc-dmarcbis/pull/3/files) 2828 C.3. February 10, 2021 2830 C.3.1. Ticket 84 - Remove Erroneous References to RFC3986 2832 * Several references to RFC3986 changed to RFC7208 2834 * Diffs are here - https://github.com/ietf-wg-dmarc/draft-ietf- 2835 dmarc-dmarcbis/pull/4/files (https://github.com/ietf-wg-dmarc/ 2836 draft-ietf-dmarc-dmarcbis/pull/4/files) 2838 C.4. March 1, 2021 2840 C.4.1. Design Team Work Begins 2842 * Added change log section to document 2844 C.5. March 8, 2021 2846 C.5.1. Removed E. Gustafsson as editor 2848 * He withdrew as editor after a job change. 2850 C.5.2. Ticket 3 - Two tiny nits 2852 * Changes to wording in section 6.6.2, Determine Handling Policy, 2853 steps 3 and 4. 2855 * New text documented here - https://trac.ietf.org/trac/dmarc/ 2856 ticket/3#comment:6 (https://trac.ietf.org/trac/dmarc/ 2857 ticket/3#comment:6) 2859 * No change to section 6.6.3, Policy Discovery; ticket seems to pre- 2860 date current text, which appears to have answered the concern 2861 raised. 2863 C.5.3. Ticket 4 - Definition of "fo" parameter 2865 * Changes to wording in section 6.3, to bring clarity to use of 2866 colon-separated list as possible value to "fo" 2868 * New text documented here - https://trac.ietf.org/trac/dmarc/ 2869 ticket/4#comment:4 (https://trac.ietf.org/trac/dmarc/ 2870 ticket/4#comment:4) 2872 C.6. March 16, 2021 2874 C.6.1. Ticket 7 - ABNF for dmarc-record is slightly wrong 2876 * New text documented here - https://trac.ietf.org/trac/dmarc/ 2877 ticket/7 (https://trac.ietf.org/trac/dmarc/ticket/7) 2879 C.6.2. Ticket 26 - ABNF for pct allows "999" 2881 * Updated ABNF for dmarc-percent 2883 * New text documented here - https://trac.ietf.org/trac/dmarc/ 2884 ticket/26#comment:6 (https://trac.ietf.org/trac/dmarc/ 2885 ticket/26#comment:6) 2887 * Ticket 47, Remove pct= tag, rendered change obsolete 2889 C.7. March 23, 2021 2891 C.7.1. Ticket 75 - Using wording alternatives to 'disposition', 2892 'dispose', and the like 2894 * Changed disposition/dispose to "handling" 2896 * Diffs documented here - https://trac.ietf.org/trac/dmarc/ 2897 ticket/75#comment:3 (https://trac.ietf.org/trac/dmarc/ 2898 ticket/75#comment:3) 2900 C.7.2. Ticket 72 - Remove absolute requirement for p= tag in DMARC 2901 record 2903 * Changed from REQUIRED to RECOMMENDED, noted default with forward 2904 reference to discussion 2906 * Diffs documented here - https://trac.ietf.org/trac/dmarc/ 2907 ticket/72#comment:3 (https://trac.ietf.org/trac/dmarc/ 2908 ticket/72#comment:3) 2910 C.8. March 29, 2021 2912 C.8.1. Ticket 54 - Remove or expand limits on number of recipients per 2913 report 2915 * Removed limit 2917 * Diffs documented here - https://trac.ietf.org/trac/dmarc/ 2918 ticket/54#comment:5 (https://trac.ietf.org/trac/dmarc/ 2919 ticket/54#comment:5) 2921 C.9. April 12, 2021 2923 C.9.1. Ticket 50 - Remove ri= tag 2925 * Updated text to recommend against its usage, a la the ptr 2926 mechanism in RFC 7208 2928 * Diffs documented here - https://trac.ietf.org/trac/dmarc/ 2929 ticket/50#comment:5 (https://trac.ietf.org/trac/dmarc/ 2930 ticket/50#comment:5) 2932 C.9.2. Ticket 66 - Define what it means to have implemented DMARC 2934 * Proposed new text (taken straight from 2935 https://trac.ietf.org/trac/dmarc/ticket/66 2936 (https://trac.ietf.org/trac/dmarc/ticket/66) as replacement for 2937 current text in "Minimum Implemenatations" 2939 C.9.3. Ticket 96 - Tweaks to Abstract and Introduction 2941 * Changed phrase in Abstract to "an email author's domain name" 2943 * Changed phrase in Introduction to "reports about email use of the 2944 domain name" 2946 C.10. April 13, 2021 2948 C.10.1. Ticket 53 - Remove reporting message size chunking 2950 * Proposed text to remove all references to message size chunking 2952 * Data demonstrating lack of use of feature entered into ticket - 2953 https://trac.ietf.org/trac/dmarc/ticket/53#comment:4 2954 (https://trac.ietf.org/trac/dmarc/ticket/53#comment:4) 2956 C.10.2. Ticket 52 - Remove strict alignment (and adkim and aspf tags) 2957 * Proposed text to remove all references to strict alignment 2959 * Data demonstrating lack of use of feature entered into ticket - 2960 https://trac.ietf.org/trac/dmarc/ticket/52#comment:2 2961 (https://trac.ietf.org/trac/dmarc/ticket/52#comment:2) 2963 C.10.3. Ticket 47 - Remove pct= tag 2965 * Proposed text to remove all references to pct and message sampling 2967 * Data demonstrating lack of use of feature entered into ticket - 2968 https://trac.ietf.org/trac/dmarc/ticket/47#comment:4 2969 (https://trac.ietf.org/trac/dmarc/ticket/47#comment:4) 2971 C.10.4. Ticket 2 - Flow of operations text in dmarc-base 2973 * Update ASCII Art 2975 * Proposed text to replace description of ASCII Art 2977 * Proposed text to update Domain Owner Actions section 2979 C.11. April 14, 2021 2981 C.11.1. Ticket 107 - DMARCbis should take a stand on multi-valued From 2982 fields 2984 * Proposed text that limits processing to only those times when all 2985 domains are the same. 2987 C.11.2. Ticket 82 - Deprecate rf= and maybe fo= tag 2989 * Proposed text to deprecate rf= tag, while leaving fo= tag as is 2991 C.11.3. Ticket 85 - Proposed change to wording describing 'p' tag and 2992 values 2994 * The language expressing the semantics is proposed to be changed to 2995 be, in a sense, egocentric. How do I, the domain owner feel about 2996 (assess) the meaning of a DMARC failure? 2998 C.12. April 15, 2021 3000 C.12.1. Ticket 86 - A-R results for DMARC 3002 * Proposed text to add for polrec.p and polrec.domain methods for 3003 registry update. 3005 * Did not include polrec.pct due to proposal to remove pct tag 3006 (Ticket 47) 3008 C.12.2. Ticket 62 - Make aggregate reporting a normative MUST 3010 * Proposed text to do just that in Mail Receiver Actions, section 3011 titled "Send Aggregate Reports" 3013 C.13. April 19, 2021 3015 C.13.1. Ticket 109 - Sanity Check DMARCbis Document 3017 * Updated document to remove all "original text"/"proposed text" 3018 couplets in favor of one (hopefully coherent) document full of 3019 proposed text changes. 3021 * Noted which tickets were the cause of whatever rfcdiff output will 3022 show in tracker 3024 C.14. April 20, 2021 3026 C.14.1. Ticket 108 - Changes to DMARCbis for PSD 3028 * Incorporating requests for changes to DMARCbis made in text of 3029 "Experimental DMARC Extension for Public Suffix Domains" 3030 (https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ 3031 (https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/)) 3033 C.15. April 22, 2021 3035 C.15.1. Ticket 104 - Update the Security Considerations section 11.3 on 3036 DNS 3038 * Updated text. Diffs are here - https://github.com/ietf-wg-dmarc/ 3039 draft-ietf-dmarc-dmarcbis/pull/31/files (https://github.com/ietf- 3040 wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/31/files) 3042 C.16. June 16, 2021 3044 C.16.1. Publication of draft-ietf-dmarc-dmarcbis-02 3046 * Includes final resolution for tickets 4, 47, 50, 52, 53, 54, and 3047 82 3049 C.17. August 12, 2021 3051 C.17.1. Publication of draft-ietf-dmarc-dmarcbis-03 3052 * Removal of "pct" tag 3054 * Addition of "t" tag 3056 * Rearranging of some text and formatting for better readability and 3057 consistency. 3059 Acknowledgements 3061 DMARC and the draft version of this document submitted to the 3062 Independent Submission Editor were the result of lengthy efforts by 3063 an informal industry consortium: DMARC.org (see http://dmarc.org 3064 (http://dmarc.org)). Participating companies included Agari, 3065 American Greetings, AOL, Bank of America, Cloudmark, Comcast, 3066 Facebook, Fidelity Investments, Google, JPMorgan Chase & Company, 3067 LinkedIn, Microsoft, Netease, PayPal, ReturnPath, The Trusted Domain 3068 Project, and Yahoo!. Although the contributors and supporters are 3069 too numerous to mention, notable individual contributions were made 3070 by J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim 3071 Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen. 3072 The contributors would also like to recognize the invaluable input 3073 and guidance that was provided early on by J.D. Falk. 3075 Additional contributions within the IETF context were made by Kurt 3076 Anderson, Michael Jack Assels, Les Barstow, Anne Bennett, Jim Fenton, 3077 J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine, S. 3078 Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull. 3080 Authors' Addresses 3082 Todd M. Herr 3083 Valimail 3085 Email: todd.herr@valimail.com 3087 John Levine 3088 Standcore LLC 3090 Email: standards@standore.com