idnits 2.17.00 (12 Aug 2021) /tmp/idnits46599/draft-ietf-dmarc-dmarcbis-07.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 document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (6 April 2022) is 38 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: 8 October 2022 6 April 2022 8 Domain-based Message Authentication, Reporting, and Conformance (DMARC) 9 draft-ietf-dmarc-dmarcbis-07 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 message handling preference 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 8 October 2022. 42 Copyright Notice 44 Copyright (c) 2022 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 Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. High-Level Goals . . . . . . . . . . . . . . . . . . . . 6 61 2.2. Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . 6 62 2.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.4. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 7 64 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 7 65 3.1. Conventions Used in This Document . . . . . . . . . . . . 7 66 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.2.1. Authenticated Identifiers . . . . . . . . . . . . . . 8 68 3.2.2. Author Domain . . . . . . . . . . . . . . . . . . . . 8 69 3.2.3. Domain Owner . . . . . . . . . . . . . . . . . . . . 8 70 3.2.4. Identifier Alignment . . . . . . . . . . . . . . . . 8 71 3.2.5. Mail Receiver . . . . . . . . . . . . . . . . . . . . 8 72 3.2.6. Non-existent Domains . . . . . . . . . . . . . . . . 9 73 3.2.7. Organizational Domain . . . . . . . . . . . . . . . . 9 74 3.2.8. Public Suffix Domain (PSD) . . . . . . . . . . . . . 9 75 3.2.9. Public Suffix Operator (PSO) . . . . . . . . . . . . 9 76 3.2.10. PSO Controlled Domain Names . . . . . . . . . . . . . 9 77 3.2.11. Report Consumer . . . . . . . . . . . . . . . . . . . 10 78 4. Overview and Key Concepts . . . . . . . . . . . . . . . . . . 10 79 4.1. DMARC Basics . . . . . . . . . . . . . . . . . . . . . . 10 80 4.2. Use of RFC5322.From . . . . . . . . . . . . . . . . . . . 11 81 4.3. Authentication Mechanisms . . . . . . . . . . . . . . . . 12 82 4.4. Identifier Alignment Explained . . . . . . . . . . . . . 12 83 4.4.1. DKIM-Authenticated Identifiers . . . . . . . . . . . 13 84 4.4.2. SPF-Authenticated Identifiers . . . . . . . . . . . . 14 85 4.4.3. Alignment and Extension Technologies . . . . . . . . 14 86 4.5. Flow Diagram . . . . . . . . . . . . . . . . . . . . . . 14 87 4.6. DNS Tree Walk . . . . . . . . . . . . . . . . . . . . . . 16 88 4.7. DMARC Policy Discovery . . . . . . . . . . . . . . . . . 17 89 4.8. Organizational Domain Discovery . . . . . . . . . . . . . 18 90 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 5.1. DMARC Policy Record . . . . . . . . . . . . . . . . . . . 21 92 5.2. DMARC URIs . . . . . . . . . . . . . . . . . . . . . . . 21 93 5.3. General Record Format . . . . . . . . . . . . . . . . . . 22 94 5.4. Formal Definition . . . . . . . . . . . . . . . . . . . . 25 95 5.5. Domain Owner Actions . . . . . . . . . . . . . . . . . . 27 96 5.5.1. Publish an SPF Policy for an Aligned Domain . . . . . 27 97 5.5.2. Configure Sending System for DKIM Signing Using an 98 Aligned Domain . . . . . . . . . . . . . . . . . . . 27 99 5.5.3. Setup a Mailbox to Receive Aggregate Reports . . . . 27 100 5.5.4. Publish a DMARC Policy for the Author Domain and 101 Organizational Domain . . . . . . . . . . . . . . . . 28 102 5.5.5. Collect and Analyze Reports . . . . . . . . . . . . . 28 103 5.5.6. Decide If and When to Update DMARC Policy . . . . . . 28 104 5.6. PSO Actions . . . . . . . . . . . . . . . . . . . . . . . 28 105 5.7. Mail Receiver Actions . . . . . . . . . . . . . . . . . . 29 106 5.7.1. Extract Author Domain . . . . . . . . . . . . . . . . 29 107 5.7.2. Determine Handling Policy . . . . . . . . . . . . . . 29 108 5.7.3. Store Results of DMARC Processing . . . . . . . . . . 30 109 5.7.4. Send Aggregate Reports . . . . . . . . . . . . . . . 31 110 5.8. Policy Enforcement Considerations . . . . . . . . . . . . 31 111 6. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . 32 112 7. Other Topics . . . . . . . . . . . . . . . . . . . . . . . . 32 113 7.1. Issues Specific to SPF . . . . . . . . . . . . . . . . . 33 114 7.2. DNS Load and Caching . . . . . . . . . . . . . . . . . . 33 115 7.3. Rejecting Messages . . . . . . . . . . . . . . . . . . . 33 116 7.4. Identifier Alignment Considerations . . . . . . . . . . . 34 117 7.5. Interoperability Issues . . . . . . . . . . . . . . . . . 35 118 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 119 8.1. Authentication-Results Method Registry Update . . . . . . 35 120 8.2. Authentication-Results Result Registry Update . . . . . . 36 121 8.3. Feedback Report Header Fields Registry Update . . . . . . 37 122 8.4. DMARC Tag Registry . . . . . . . . . . . . . . . . . . . 38 123 8.5. DMARC Report Format Registry . . . . . . . . . . . . . . 39 124 8.6. Underscored and Globally Scoped DNS Node Names 125 Registry . . . . . . . . . . . . . . . . . . . . . . . . 40 126 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 127 9.1. Authentication Methods . . . . . . . . . . . . . . . . . 40 128 9.2. Attacks on Reporting URIs . . . . . . . . . . . . . . . . 41 129 9.3. DNS Security . . . . . . . . . . . . . . . . . . . . . . 41 130 9.4. Display Name Attacks . . . . . . . . . . . . . . . . . . 42 131 9.5. External Reporting Addresses . . . . . . . . . . . . . . 42 132 9.6. Secure Protocols . . . . . . . . . . . . . . . . . . . . 43 133 10. Normative References . . . . . . . . . . . . . . . . . . . . 43 134 11. Informative References . . . . . . . . . . . . . . . . . . . 45 135 Appendix A. Technology Considerations . . . . . . . . . . . . . 46 136 A.1. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 46 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 . . . . . . . . . 49 142 A.7. Removal of the "pct" Tag . . . . . . . . . . . . . . . . 51 144 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 52 145 B.1. Identifier Alignment Examples . . . . . . . . . . . . . . 52 146 B.1.1. SPF . . . . . . . . . . . . . . . . . . . . . . . . . 52 147 B.1.2. DKIM . . . . . . . . . . . . . . . . . . . . . . . . 53 148 B.2. Domain Owner Example . . . . . . . . . . . . . . . . . . 54 149 B.2.1. Entire Domain, Monitoring Only . . . . . . . . . . . 54 150 B.2.2. Entire Domain, Monitoring Only, Per-Message 151 Reports . . . . . . . . . . . . . . . . . . . . . . . 55 152 B.2.3. Per-Message Failure Reports Directed to Third 153 Party . . . . . . . . . . . . . . . . . . . . . . . . 56 154 B.2.4. Subdomain, Testing, and Multiple Aggregate Report 155 URIs . . . . . . . . . . . . . . . . . . . . . . . . 57 156 B.3. Mail Receiver Example . . . . . . . . . . . . . . . . . . 59 157 B.3.1. SMTP Session Example . . . . . . . . . . . . . . . . 59 158 B.4. Utilization of Aggregate Feedback: Example . . . . . . . 61 159 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 61 160 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 162 1. Introduction 164 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: 165 The source for this draft is maintained in GitHub at: 166 https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis 167 (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis) 169 Abusive email often includes unauthorized and deceptive use of a 170 domain name in the RFC5322.From header field. The domain typically 171 belongs to an organization expected to be known to - and presumably 172 trusted by - the recipient. The Sender Policy Framework (SPF) 173 [RFC7208] and DomainKeys Identified Mail (DKIM) [RFC6376] protocols 174 provide domain-level authentication but are not directly associated 175 with the RFC5322.From domain. DMARC leverages these two protocols, 176 providing a method for Domain Owners to publish a DNS record 177 describing the email authentication policies for the RFC5322.From 178 domain and to request specific handling for messages using that 179 domain that fail authentication checks. 181 As with SPF and DKIM, DMARC classes results as "pass" or "fail". In 182 order to get a DMARC result of "pass", a pass from either SPF or DKIM 183 is required. In addition, the passed domain must be "aligned" with 184 the RFC5322.From domain in one of two modes - "relaxed" or "strict". 185 The mode is expressed in the domain's DMARC policy record. Domains 186 are said to be "in relaxed alignment" if they have the same 187 "Organizational Domain", which is the domain at the top of the domain 188 hierarchy for the RFC5322.From domain while having the same 189 administrative authority as the RFC5322.From domain. Domains are "in 190 strict alignment" if and only if they are identical. 192 A DMARC pass indicates only that the RFC5322.From domain has been 193 authenticated for that message. Authentication does not carry an 194 explicit or implicit value assertion about that message or about the 195 Domain Owner. Furthermore, a mail-receiving organization that 196 performs DMARC verification can choose to honor the Domain Owner's 197 requested message handling for authentication failures, but it is 198 under no obligation to do so; it might choose different actions 199 entirely. 201 For a mail-receiving organization supporting DMARC, a message that 202 passes verification is part of a message stream that is reliably 203 associated with the RFC5322.From field Domain Owner. Therefore, 204 reputation assessment of that stream by the mail-receiving 205 organization is not encumbered by accounting for unauthorized use of 206 that domain in the RFC5322.From field. A message that fails this 207 verification is not necessarily associated with the Domain Owner's 208 domain and its reputation. 210 DMARC policy records can also cover non-existent sub-domains, below 211 the "Organizational Domain", as well as domains at the top of the 212 name hierarchy, controlled by Public Suffix Operators (PSOs). 214 DMARC, in the associated [DMARC-Aggregate-Reporting] and 215 [DMARC-Failure-Reporting] documents, also specifies a reporting 216 framework. Using it, a mail-receiving domain can generate regular 217 reports about messages that claim to be from a domain publishing 218 DMARC policies, sending those reports to the address(es) specified by 219 the Domain Owner in the latter's DMARC policy record. Domain Owners 220 can use these reports, especially the aggregate reports, to identify 221 not only sources of mail attempting to fraudulently use their domain, 222 but also (and perhaps more importantly) gaps in their own 223 authentication practices. However, as with honoring the Domain 224 Owner's stated mail handling preference, a mail-receiving 225 organization supporting DMARC is under no obligation to send 226 requested reports, although it is recommended that they do send 227 aggregate reports. 229 Use of DMARC creates some interoperability challenges that require 230 due consideration before deployment, particularly with configurations 231 that can cause mail to be rejected. These are discussed in 232 Section 7. 234 2. Requirements 236 Specification of DMARC is guided by the following high-level goals, 237 security dependencies, detailed requirements, and items that are 238 documented as out of scope. 240 2.1. High-Level Goals 242 DMARC has the following high-level goals: 244 * Allow Domain Owners and PSOs to assert their desired message 245 handling for authentication failures for messages purporting to 246 have authorship within the domain. 248 * Allow Domain Owners and PSOs to verify their authentication 249 deployment. 251 * Minimize implementation complexity for both senders and receivers, 252 as well as the impact on handling and delivery of legitimate 253 messages. 255 * Reduce the amount of successfully delivered spoofed email. 257 * Work at Internet scale. 259 2.2. Anti-Phishing 261 DMARC is designed to prevent bad actors from sending mail that claims 262 to come from legitimate senders, particularly senders of 263 transactional email (official mail that is about business 264 transactions). One of the primary uses of this kind of spoofed mail 265 is phishing (enticing users to provide information by pretending to 266 be the legitimate service requesting the information). Thus, DMARC 267 is significantly informed by ongoing efforts to enact large-scale, 268 Internet-wide anti-phishing measures. 270 Although DMARC can only be used to combat specific forms of exact- 271 domain spoofing directly, the DMARC mechanism has been found to be 272 useful in the creation of reliable and defensible message streams. 274 DMARC does not attempt to solve all problems with spoofed or 275 otherwise fraudulent email. In particular, it does not address the 276 use of visually similar domain names ("cousin domains") or abuse of 277 the RFC5322.From human-readable . 279 2.3. Scalability 281 Scalability is a major issue for systems that need to operate in a 282 system as widely deployed as current SMTP email. For this reason, 283 DMARC seeks to avoid the need for third parties or pre-sending 284 agreements between senders and receivers. This preserves the 285 positive aspects of the current email infrastructure. 287 Although DMARC does not introduce third-party senders (namely 288 external agents authorized to send on behalf of an operator) to the 289 email-handling flow, it also does not preclude them. Such third 290 parties are free to provide services in conjunction with DMARC. 292 2.4. Out of Scope 294 Several topics and issues are specifically out of scope for this 295 work. These include the following: 297 * Different treatment of messages that are not authenticated versus 298 those that fail authentication; 300 * Evaluation of anything other than RFC5322.From header field; 302 * Multiple reporting formats; 304 * Publishing policy other than via the DNS; 306 * Reporting or otherwise evaluating other than the last-hop IP 307 address; 309 * Attacks in the RFC5322.From header field, also known as "display 310 name" attacks; 312 * Authentication of entities other than domains, since DMARC is 313 built upon SPF and DKIM, which authenticate domains; and 315 * Content analysis. 317 3. Terminology and Definitions 319 This section defines terms used in the rest of the document. 321 3.1. Conventions Used in This Document 323 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 324 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 325 "OPTIONAL" in this document are to be interpreted as described in BCP 326 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 327 capitals, as shown here. 329 Readers are encouraged to be familiar with the contents of [RFC5598]. 330 In particular, that document defines various roles in the messaging 331 infrastructure that can appear the same or separate in various 332 contexts. For example, a Domain Owner could, via the messaging 333 security mechanisms on which DMARC is based, delegate the ability to 334 send mail as the Domain Owner to a third party with another role. 336 This document does not address the distinctions among such roles; the 337 reader is encouraged to become familiar with that material before 338 continuing. 340 3.2. Definitions 342 The following sections define terms used in this document. 344 3.2.1. Authenticated Identifiers 346 Domain-level identifiers that are verified using authentication 347 technologies are referred to as "Authenticated Identifiers". See 348 Section 4.3 for details about the supported mechanisms. 350 3.2.2. Author Domain 352 The domain name of the apparent author, as extracted from the 353 RFC5322.From header field. 355 3.2.3. Domain Owner 357 An entity or organization that owns a DNS domain. The term "owns" 358 here indicates that the entity or organization being referenced holds 359 the registration of that DNS domain. Domain Owners range from 360 complex, globally distributed organizations, to service providers 361 working on behalf of non-technical clients, to individuals 362 responsible for maintaining personal domains. This specification 363 uses this term as analogous to an Administrative Management Domain as 364 defined in [RFC5598]. It can also refer to delegates, such as Report 365 Consumers, when those are outside of their immediate management 366 domain. 368 3.2.4. Identifier Alignment 370 When the domain in the address in the RFC5322.From header field has 371 the same Organizational Domain as a domain verified by an 372 authenticated identifier, it has Identifier Alignment. (see 373 Section 3.2.7) 375 3.2.5. Mail Receiver 377 The entity or organization that receives and processes email. Mail 378 Receivers operate one or more Internet-facing Mail Transport Agents 379 (MTAs). 381 3.2.6. Non-existent Domains 383 For DMARC purposes, a non-existent domain is consistent with the 384 meaning of the term as described in [RFC8020]. That is, if the 385 response code received for a query for a domain name is NXDOMAIN, 386 then the domain name and all the names under it do not exist. 388 3.2.7. Organizational Domain 390 The Organizational Domain is typically a domain that was registered 391 with a domain name registrar. More formally, it is any Public Suffix 392 Domain plus one label. The Organizational Domain for the domain in 393 the RFC5322.From domain is determined by applying the algorithm found 394 in Section 4.8. 396 3.2.8. Public Suffix Domain (PSD) 398 The global Internet Domain Name System (DNS) is documented in 399 numerous RFCs. It defines a tree of names starting with root, ".", 400 immediately below which are Top-Level Domain names such as ".com" and 401 ".us". The domain name structure consists of a tree of names, each 402 of which is made of a sequence of words ("labels") separated by 403 period characters. The root of the tree is simply called ".". The 404 Internet community at large, through processes and policies external 405 to this work, selects points in this tree at which to register domain 406 names "owned" by independent organizations. Real-world examples of 407 these points are ".com", ".org", ".us", and ".gov.uk". Names at 408 which such registrations occur are called "Public Suffix Domains 409 (PSDs)", and a registration consists of a label selected by the 410 registrant to which a desirable PSD is appended. For example, 411 "ietf.org" is a registered domain name, and ".org" is its PSD. 413 3.2.9. Public Suffix Operator (PSO) 415 A Public Suffix Operator is an organization that manages operations 416 within a PSD, particularly the DNS records published for names at and 417 under that domain name. 419 3.2.10. PSO Controlled Domain Names 421 PSO-Controlled Domain Names are names in the DNS that are managed by 422 a PSO and are not available for use as Organizational Domains. PSO- 423 Controlled Domain Names may have one (e.g., ".com") or more (e.g., 424 ".co.uk") name components, depending on PSD policy. 426 3.2.11. Report Consumer 428 An operator that receives reports from another operator implementing 429 the reporting mechanisms described in this document and/or the 430 documents [DMARC-Aggregate-Reporting] and [DMARC-Failure-Reporting]. 431 Such an operator might be receiving reports about messages related to 432 a domain for which it is the Domain Owner or PSO, or reports about 433 messages related to another operator's domain. This term applies 434 collectively to the system components that receive and process these 435 reports and the organizations that operate them. 437 4. Overview and Key Concepts 439 This section provides a general overview of the design and operation 440 of the DMARC environment. 442 4.1. DMARC Basics 444 DMARC permits a Domain Owner or PSO to enable verification of a 445 domain's use in an email message, to indicate the Domain Owner's or 446 PSO's message handling preference regarding failed verification, and 447 to request reports about use of the domain name. All information 448 about a Domain Owner's or PSO's DMARC policy is published and 449 retrieved via the DNS. 451 DMARC's verification function is based on whether the RFC5322.From 452 domain is aligned with a domain name used in a supported 453 authentication mechanism, as described in Section 4.3. When a DMARC 454 policy exists for the domain name found in the RFC5322.From header 455 field, and that domain name is not verified through an aligned 456 supported authentication mechanism, the handling of that message can 457 be affected based on the DMARC policy when delivered to a 458 participating Mail Receiver. 460 A message satisfies the DMARC checks if at least one of the supported 461 authentication mechanisms: 463 1. produces a "pass" result, and 465 2. produces that result based on an identifier that is in alignment, 466 as described in Section 4.4. 468 It is important to note that the authentication mechanisms employed 469 by DMARC authenticate only a DNS domain and do not authenticate the 470 local-part of any email address identifier found in a message, nor do 471 they validate the legitimacy of message content. 473 DMARC's feedback component involves the collection of information 474 about received messages claiming to be from the Author Domain for 475 periodic aggregate reports to the Domain Owner or PSO. The 476 parameters and format for such reports are discussed in 477 [DMARC-Aggregate-Reporting] 479 A DMARC-enabled Mail Receiver might also generate per-message reports 480 that contain information related to individual messages that fail 481 authentication checks. Per-message failure reports are a useful 482 source of information when debugging deployments (if messages can be 483 determined to be legitimate even though failing authentication) or in 484 analyzing attacks. The capability for such services is enabled by 485 DMARC but defined in other referenced material such as [RFC6591] and 486 [DMARC-Failure-Reporting] 488 4.2. Use of RFC5322.From 490 One of the most obvious points of security scrutiny for DMARC is the 491 choice to focus on an identifier, namely the RFC5322.From address, 492 which is part of a body of data that has been trivially forged 493 throughout the history of email. This field is the one used by end 494 users to identify the source of the message, and so it has always 495 been a prime target for abuse through such forgery and other means. 497 Several points suggest that it is the most correct and safest thing 498 to do in this context: 500 * Of all the identifiers that are part of the message itself, this 501 is the only one guaranteed to be present. 503 * It seems the best choice of an identifier on which to focus, as 504 most MUAs display some or all of the contents of that field in a 505 manner strongly suggesting those data as reflective of the true 506 originator of the message. 508 * Many high-profile email sources, such as email service providers, 509 require that the sending agent have authenticated before email can 510 be generated. Thus, for these mailboxes, the mechanism described 511 in this document provides recipient end users with strong evidence 512 that the message was indeed originated by the agent they associate 513 with that mailbox, if the end user knows that these various 514 protections have been provided. 516 * The absence of a single, properly formed RFC5322.From header field 517 renders the message invalid. Handling of such a message is 518 outside of the scope of this specification. 520 Since the sorts of mail typically protected by DMARC participants 521 tend to only have single Authors, DMARC participants generally 522 operate under a slightly restricted profile of RFC5322 with respect 523 to the expected syntax of this field. See Section 5.7 for details. 525 4.3. Authentication Mechanisms 527 The following mechanisms for determining Authenticated Identifiers 528 are supported in this version of DMARC: 530 * DKIM, [RFC6376], which provides a domain-level identifier in the 531 content of the "d=" tag of a verified DKIM-Signature header field. 533 * SPF, [RFC7208], which can authenticate both the domain found in an 534 SMTP [RFC5321] HELO/EHLO command (the HELO identity) and the 535 domain found in an SMTP MAIL command (the MAIL FROM identity). As 536 noted earlier, however, DMARC relies solely on SPF authentication 537 of the domain found in SMTP MAIL FROM command. Section 2.4 of 538 [RFC7208] describes MAIL FROM processing for cases in which the 539 MAIL command has a null path. 541 4.4. Identifier Alignment Explained 543 Email authentication technologies authenticate various (and 544 disparate) aspects of an individual message. For example, DKIM 545 [RFC6376] authenticates the domain that affixed a signature to the 546 message, while SPF [RFC7208] can authenticate either the domain that 547 appears in the RFC5321.MailFrom (MAIL FROM) portion of an SMTP 548 [RFC5321] conversation or the RFC5321.EHLO/HELO domain, or both. 549 These may be different domains, and they are typically not visible to 550 the end user. 552 DMARC authenticates use of the RFC5322.From domain by requiring 553 either that it have the same Organizational Domain as an 554 Authenticated Identifier (a condition known as "relaxed alignment") 555 or that it be identical to the domain of the Authenticated Identifier 556 (a condition known as "strict alignment"). The choice of relaxed or 557 strict alignment is left to the Domain Owner and is expressed in the 558 domain's DMARC policy record. Domain names in this context are to be 559 compared in a case-insensitive manner, per [RFC4343]. 561 It is important to note that Identifier Alignment cannot occur with a 562 message that is not valid per [RFC5322], particularly one with a 563 malformed, absent, or repeated RFC5322.From header field, since in 564 that case there is no reliable way to determine a DMARC policy that 565 applies to the message. Accordingly, DMARC operation is predicated 566 on the input being a valid RFC5322 message object, and handling of 567 such non-compliant cases is outside of the scope of this 568 specification. Further discussion of this can be found in 569 Section 5.7.1. 571 Each of the underlying authentication technologies that DMARC takes 572 as input yields authenticated domains as their outputs when they 573 succeed. 575 4.4.1. DKIM-Authenticated Identifiers 577 DMARC requires Identifier Alignment based on the result of a DKIM 578 authentication because a message can bear a valid signature from any 579 domain, including domains used by a mailing list or even a bad actor. 580 Therefore, merely bearing a valid signature is not enough to infer 581 authenticity of the Author Domain. 583 DMARC permits Identifier Alignment based on the result of a DKIM 584 authentication to be strict or relaxed. (Note that these terms are 585 not related to DKIM's "simple" and "relaxed" canonicalization modes.) 587 In relaxed mode, the Organizational Domains of both the DKIM- 588 authenticated signing domain (taken from the value of the d= tag in 589 the signature) and that of the RFC5322.From domain must be equal if 590 the identifiers are to be considered to be aligned. In strict mode, 591 only an exact match between both Fully Qualified Domain Names (FQDNs) 592 is considered to produce Identifier Alignment. 594 To illustrate, in relaxed mode, if a verified DKIM signature 595 successfully verifies with a "d=" domain of "example.com", and the 596 RFC5322.From address is "alerts@news.example.com", the DKIM "d=" 597 domain and the RFC5322.From domain are considered to be "in 598 alignment", because both domains have the same Organizational Domain 599 of "example.com". In strict mode, this test would fail because the 600 d= domain does not exactly match the RFC5322.From domain. 602 However, a DKIM signature bearing a value of "d=com" would never 603 allow an "in alignment" result, as "com" should be identified as a 604 PSD and therefore cannot be an Organizational Domain. 606 Note that a single email can contain multiple DKIM signatures, and it 607 is considered to produce a DMARC "pass" result if any DKIM signature 608 is aligned and verifies. 610 4.4.2. SPF-Authenticated Identifiers 612 DMARC permits Identifier Alignment based on the result of an SPF 613 authentication. As with DKIM, Identifier Alignement can be either 614 strict or relaxed. 616 In relaxed mode, the Organizational Domains of the SPF-authenticated 617 domain and RFC5322.From domain must be equal if the identifiers are 618 to be considered to be aligned. In strict mode, the two FQDNs must 619 match exactly in order for them to be considered to be aligned. 621 For example, in relaxed mode, if a message passes an SPF check with 622 an RFC5321.MailFrom domain of "cbg.bounces.example.com", and the 623 address portion of the RFC5322.From header field contains 624 "payments@example.com", the Authenticated RFC5321.MailFrom domain 625 identifier and the RFC5322.From domain are considered to be "in 626 alignment" because they have the same Organizational Domain 627 ("example.com"). In strict mode, this test would fail because the 628 two domains are not identical. 630 The reader should note that SPF alignment checks in DMARC rely solely 631 on the RFC5321.MailFrom domain. This differs from section 2.3 of 632 [RFC7208], which recommends that SPF checks be done on not only the 633 "MAIL FROM" but also on a separate check of the "HELO" identity. 635 4.4.3. Alignment and Extension Technologies 637 If in the future DMARC is extended to include the use of other 638 authentication mechanisms, the extensions will need to allow for 639 domain identifier extraction so that alignment with the RFC5322.From 640 domain can be verified. 642 4.5. Flow Diagram 643 +---------------+ +--------------------+ 644 | Author Domain |< . . . . . . . . . . . . | Return-Path Domain | 645 +---------------+ . +--------------------+ 646 | . ^ 647 V V . 648 +-----------+ +--------+ +----------+ v 649 | MSA |<***>| DKIM | | DMARC | +----------+ 650 | Service | | Signer | | Verifier |<***>| SPF | 651 +-----------+ +--------+ +----------+ * | Verifier | 652 | ^ * +----------+ 653 | * * 654 V v * 655 +------+ (~~~~~~~~~~~~) +------+ * +----------+ 656 | sMTA |------->( other MTAs )----->| rMTA | **>| DKIM | 657 +------+ (~~~~~~~~~~~~) +------+ | Verifier | 658 | +----------+ 659 | ^ 660 V . 661 +-----------+ . 662 +---------+ | MDA | v 663 | User |<--| Filtering | +-----------+ 664 | Mailbox | | Engine | | DKIM | 665 +---------+ +-----------+ | Signing | 666 | Domain(s) | 667 +-----------+ 669 MSA = Mail Submission Agent 670 MDA = Mail Delivery Agent 672 The above diagram shows a simple flow of messages through a DMARC- 673 aware system. Solid lines denote the actual message flow, dotted 674 lines involve DNS queries used to retrieve message policy related to 675 the supported message authentication schemes, and asterisk lines 676 indicate data exchange between message-handling modules and message 677 authentication modules. "sMTA" is the sending MTA, and "rMTA" is the 678 receiving MTA. 680 Put simply, when a message reaches a DMARC-aware rMTA, a DNS query 681 will be initiated to determine if a DMARC policy exists that applies 682 to the author domain. If a policy is found, the rMTA will use the 683 results of SPF and DKIM verification checks to determine the ultimate 684 DMARC authentication status. The DMARC status can then factor into 685 the message handling decision made by the recipient's mail sytsem. 687 More details on specific actions for the parties involved can be 688 found in Section 5.5 and Section 5.7. 690 4.6. DNS Tree Walk 692 The DMARC protocol defines a method for communicating information 693 through the publishing of records in DNS. Both the content of the 694 records and their location in the DNS hierarchy are used for two 695 purposes: policy discovery (see Section 4.7) and Organizational 696 Domain determination (see Section 4.8). 698 The relevant DMARC record for these purposes is not necessarily the 699 DMARC policy record found in DNS at the same level as the name label 700 for the domain in question. Instead, some domains will inherit their 701 DMARC policy records from parent domains one level or more above them 702 in the DNS hierarchy. Similarly, the Organizational Domain may be 703 found at a higher level in the DNS hierarchy. 705 These records are discovered through the technique described here, 706 known colloquially as the "DNS Tree Walk". The target of any DNS 707 Tree Walk is a valid DMARC policy record, but the rules defining 708 required content for that record depend on the reason for performing 709 the Tree Walk. 711 To prevent possible abuse of the DNS, a shortcut is built into the 712 process so that domains that have more than five labels do not result 713 in more than five DNS queries. 715 The generic steps for a DNS Tree Walk are as follows: 717 1. Query the DNS for a DMARC TXT record at the DNS domain matching 718 the one found in the domain(s) described above. A possibly empty 719 set of records is returned. 721 2. Records that do not start with a "v=" tag that identifies the 722 current version of DMARC are discarded. If multiple DMARC 723 records are returned, they are all discarded. 725 3. Determine the target for additional queries (if needed; see the 726 note in Section 4.8), using steps 4 through 8 below. 728 4. Break the subject DNS domain name into a set of "n" ordered 729 labels. Number these labels from right to left; e.g., for 730 "a.mail.example.com", "com" would be label 1, "example" would be 731 label 2, "mail.example.com" would be label 3, and so forth. 733 5. Count the number of labels found in the subject DNS domain. Let 734 that number be "x". If x < 5, remove the left-most (highest- 735 numbered) label from the subject domain. If x >= 5, remove the 736 left-most (highest-numbered) labels from the subject domain until 737 4 labels remain. The resulting DNS domain name is the new target 738 for subsequent lookups. 740 6. Query the DNS for a DMARC TXT record at the DNS domain matching 741 this new target in place of the RFC5322.From domain in the 742 message. A possibly empty set of records is returned. 744 7. Records that do not start with a "v=" tag that identifies the 745 current version of DMARC are discarded. If multiple DMARC 746 records are returned for a single target, they are all discarded. 748 8. Determine the target for additional queries by removing a single 749 label from the target domain as described in step 5 and repeating 750 steps 6 and 7 until there are no more labels remaining. 752 To illustrate, for a message with the arbitrary RFC5322.From domain 753 of "a.b.c.d.e.mail.example.com", a full DNS Tree Walk would require 754 the following five queries, in order to locate the policy or 755 Organizational Domain: 757 * _dmarc.a.b.c.d.e.mail.example.com 759 * _dmarc.e.mail.example.com 761 * _dmarc.mail.example.com 763 * _dmarc.example.com 765 * _dmarc.com 767 4.7. DMARC Policy Discovery 769 For policy discovery, a DNS Tree Walk starts at the point in the DNS 770 hierarchy that matches the domain in the RFC5322.From header of the 771 message. The DMARC policy to be applied to the message will be the 772 record found at one of these three locations: 774 * The RFC5322.From domain 776 * The Organizational Domain (as determined by a separate DNS Tree 777 Walk) of the RFC5322.From domain 779 * The Public Suffix Domain of the RFC5322.From domain 780 If the DMARC policy to be applied is that of the RFC5322.From domain, 781 then the DMARC policy is taken from the p= tag of the record. If the 782 DMARC policy is taken from either the Organizational Domain or the 783 Public Suffix Domain and that domain is different than the 784 RFC5322.From domain, then the DMARC policy is taken from the sp= tag 785 (if any) if the RFC5322.From domain exists and the np= tag (if any) 786 if the RFC5322.From domain does not exist. In the absence of 787 applicable sp= or np= tags, the p= tag policy is used for subdomains. 789 If a retrieved policy record does not contain a valid "p" tag, or 790 contains an "sp" tag that is not valid, then: 792 * If a "rua" tag is present and contains at least one syntactically 793 valid reporting URI, the Mail Receiver SHOULD act as if a record 794 containing a valid "v" tag and "p=none" was retrieved, and 795 continue processing; 797 * Otherwise, the Mail Receiver applies no DMARC processing to this 798 message. 800 If the set produced by the DNS Tree Walk contains no DMARC policy 801 record (i.e., any indication that there is no such record as opposed 802 to a transient DNS error), Mail Receivers MUST NOT apply the DMARC 803 mechanism to the message. 805 Handling of DNS errors when querying for the DMARC policy record is 806 left to the discretion of the Mail Receiver. For example, to ensure 807 minimal disruption of mail flow, transient errors could result in 808 delivery of the message ("fail open"), or they could result in the 809 message being temporarily rejected (i.e., an SMTP 4yx reply), which 810 invites the sending MTA to try again after the condition has possibly 811 cleared, allowing a definite DMARC conclusion to be reached ("fail 812 closed"). 814 Note: PSD policy is not used for Organizational Domains that have 815 published a DMARC policy. Specifically, this is not a mechanism to 816 provide feedback addresses (rua/ruf) when an Organizational Domain 817 has declined to do so. 819 4.8. Organizational Domain Discovery 821 For Organizational Domain discovery, it may be necessary to perform 822 multiple DNS Tree Walks in order to determine if any two domains are 823 in alignment. This means that a DNS Tree Walk to discover an 824 Organizational Domain might start at any of the following locations: 826 * The domain in the RFC5322.From header of the message. 828 * The RFC5321.MailFrom domain if there is an SPF pass result for the 829 message. 831 * Any DKIM d= domain if there is a DKIM pass result for the message 832 for that domain. 834 Note: There is no need to perform Tree Walk searches for 835 Organizational Domains under any of the following conditions: 837 * The RFC5322.From domain and the RFC5321.MailFrom domain (if SPF 838 authenticated), and/or the DKIM d= domain (if present and 839 authenticated) are all the same and that domain has a DMARC 840 record. In this case, this common domain is treated as the 841 Organizational Domain. 843 * No applicable DMARC policy is discovered for the RFC5322.From 844 domain during the first tree walk. In this case, the DMARC 845 mechanism does not apply to the message in question. 847 * There is no SPF pass result and no DKIM pass result for the 848 message. In this case, there can be no DMARC pass result, and so 849 the Organizational Domain of any domain is not required to be 850 discovered. 852 * The record for the RFC5322.From domain indicates strict alignment. 853 In this case, a simple string compare between the RFC5322.From 854 domain and the RFC5321.MailFrom domain (if SPF authenticated), 855 and/or the DKIM d= domain (if present and authenticated) is all 856 that is required. 858 To discover the Organizational Domain for a domain, perform the DNS 859 Tree Walk described in Section 4.6 as needed for any of the domains 860 in question. 862 Select the Organizational Domain from the domains for which valid 863 DMARC records were retrieved from the longest to the shortest: 865 1. If a valid DMARC record contains the psd= tag set to 'n' (psd=n), 866 this is the Organizational Domain and the selection process is 867 complete. 869 2. If a valid DMARC record contains the psd= tag set to 'y' (psd=y), 870 the Organizational Domain is the domain one label below this one 871 in the DNS hierarchy, and the selection process is complete. 873 3. If the selection process completes and all records contain 874 (either explicitly or implicitly, since this is the default) the 875 psd= tag set to 'u' (psd=u), select the record for the domain 876 with the fewest number of labels. This is the Organizational 877 Domain and the selection process is complete. 879 If this process does not determine the Organizational Domain, then 880 the initial target domain is the Organizational Domain. 882 For example, given the starting domain "a.mail.example.com", a search 883 for the Organizational Domain would require a series of DNS queries 884 for DMARC records starting with "_dmarc.a.mail.example.com" and 885 finishing with "_dmarc.com". If there are DMARC records for 886 "_dmarc.mail.example.com" and "_dmarc.example.com", but not for 887 "_dmarc.a.mail.example.com" or "_dmarc.com", then the Organizational 888 Domain for this domain would be "example.com". 890 As another example, given the starting domain "a.mail.example.com", 891 if a search for the Organizational Domain only yields a DMARC record 892 at "_dmarc.com" and that record contains the tag psd=y, then the 893 Organizational Domain for this domain would be "example.com". 895 5. Policy 897 A Domain Owner or PSO advertises DMARC participation of one or more 898 of its domains by adding a DNS TXT record (described in Section 5.1) 899 to those domains. In doing so, Domain Owners and PSOs indicate their 900 handling preference regarding failed authentication for email 901 messages making use of their domain in the RFC5322.From header field 902 as well as their desire for feedback about those messages. Mail 903 Receivers in turn can take into account the Domain Owner's stated 904 preference when making handling decisions about email messages that 905 fail DMARC authentication checks. 907 A Domain Owner or PSO may choose not to participate in DMARC 908 evaluation by Mail Receivers simply by not publishing an appropriate 909 DNS TXT record for its domain(s). A Domain Owner can also choose to 910 not have some underlying authentication technologies apply to DMARC 911 evaluation of its domain(s). In this case, the Domain Owner simply 912 declines to advertise participation in those schemes. For example, 913 if the results of path authorization checks ought not be considered 914 as part of the overall DMARC result for a given Author Domain, then 915 the Domain Owner does not publish an SPF policy record that can 916 produce an SPF pass result. 918 A Mail Receiver implementing the DMARC mechanism SHOULD make a best- 919 effort attempt to adhere to the Domain Owner's or PSO's published 920 DMARC Domain Owner Assessment Policy when a message fails the DMARC 921 test. Since email streams can be complicated (due to forwarding, 922 existing RFC5322.From domain-spoofing services, etc.), Mail Receivers 923 MAY deviate from a published Domain Owner Assessment Policy during 924 message processing and SHOULD make available the fact of and reason 925 for the deviation to the Domain Owner via feedback reporting, 926 specifically using the "PolicyOverride" feature of the aggregate 927 report defined in [DMARC-Aggregate-Reporting] 929 5.1. DMARC Policy Record 931 Domain Owner and PSO DMARC preferences are stored as DNS TXT records 932 in subdomains named "_dmarc". For example, the Domain Owner of 933 "example.com" would post DMARC preferences in a TXT record at 934 "_dmarc.example.com". Similarly, a Mail Receiver wishing to query 935 for DMARC preferences regarding mail with an RFC5322.From domain of 936 "example.com" would issue a TXT query to the DNS for the subdomain of 937 "_dmarc.example.com". The DNS-located DMARC preference data will 938 hereafter be called the "DMARC record". 940 DMARC's use of the Domain Name Service is driven by DMARC's use of 941 domain names and the nature of the query it performs. The query 942 requirement matches with the DNS, for obtaining simple parametric 943 information. It uses an established method of storing the 944 information, associated with the target domain name, namely an 945 isolated TXT record that is restricted to the DMARC context. Use of 946 the DNS as the query service has the benefit of reusing an extremely 947 well-established operations, administration, and management 948 infrastructure, rather than creating a new one. 950 Per [RFC1035], a TXT record can comprise several "character-string" 951 objects. Where this is the case, the module performing DMARC 952 evaluation MUST concatenate these strings by joining together the 953 objects in order and parsing the result as a single string. 955 5.2. DMARC URIs 957 [RFC3986] defines a generic syntax for identifying a resource. The 958 DMARC mechanism uses this as the format by which a Domain Owner or 959 PSO specifies the destination for the two report types that are 960 supported. 962 The place such URIs are specified (see Section 5.3) allows a list of 963 these to be provided. The list of URIs is separated by commas (ASCII 964 0x2c). A report SHOULD be sent to each listed URI provided in the 965 DMARC record. 967 A formal definition is provided in Section 5.4. 969 5.3. General Record Format 971 DMARC records follow the extensible "tag-value" syntax for DNS-based 972 key records defined in DKIM [RFC6376]. 974 Section 8 creates a registry for known DMARC tags and registers the 975 initial set defined in this document. Only tags defined in that 976 registry are to be processed; unknown tags MUST be ignored. 978 The following tags are valid DMARC tags: 980 adkim: (plain-text; OPTIONAL; default is "r".) Indicates whether 981 strict or relaxed DKIM Identifier Alignment mode is required by 982 the Domain Owner. See Section 4.4.1 for details. Valid values 983 are as follows: 985 r: relaxed mode 987 s: strict mode 989 aspf: (plain-text; OPTIONAL; default is "r".) Indicates whether 990 strict or relaxed SPF Identifier Alignment mode is required by the 991 Domain Owner. See Section 4.4.2 for details. Valid values are as 992 follows: 994 r: relaxed mode 996 s: strict mode 998 fo: Failure reporting options (plain-text; OPTIONAL; default is "0") 999 Provides requested options for generation of failure reports. 1000 Report generators MAY choose to adhere to the requested options. 1001 This tag's content MUST be ignored if a "ruf" tag (below) is not 1002 also specified. Failure reporting options are shown below. The 1003 value of this tag is either "0", "1", or a colon-separated list of 1004 the options represented by alphabetic characters. The valid 1005 values and their meanings are: 1007 0: Generate a DMARC failure report if all underlying 1008 authentication mechanisms fail to produce an aligned "pass" 1009 result. 1011 1: Generate a DMARC failure report if any underlying 1012 authentication mechanism produced something other than an 1013 aligned "pass" result. 1015 d: Generate a DKIM failure report if the message had a signature 1016 that failed evaluation, regardless of its alignment. DKIM- 1017 specific reporting is described in [RFC6651]. 1019 s: Generate an SPF failure report if the message failed SPF 1020 evaluation, regardless of its alignment. SPF-specific 1021 reporting is described in [RFC6652]. 1023 np: Domain Owner Assessment Policy for non-existent subdomains 1024 (plain-text; OPTIONAL). Indicates the message handling preference 1025 that the Domain Owner or PSO has for mail using non-existent 1026 subdomains of the domain queried. It applies only to non-existent 1027 subdomains of the domain queried and not to either existing 1028 subdomains or the domain itself. Its syntax is identical to that 1029 of the "p" tag defined below. If the "np" tag is absent, the 1030 policy specified by the "sp" tag (if the "sp" tag is present) or 1031 the policy specified by the "p" tag, if the "sp" tag is not 1032 present, MUST be applied for non-existent subdomains. Note that 1033 "np" will be ignored for DMARC records published on subdomains of 1034 Organizational Domains and PSDs due to the effect of the DMARC 1035 policy discovery mechanism described in Section 4.7. 1037 p: Domain Owner Assessment Policy (plain-text; RECOMMENDED for 1038 policy records). Indicates the message handling preference the 1039 Domain Owner or PSO has for mail using its domain but not passing 1040 DMARC verification. Policy applies to the domain queried and to 1041 subdomains, unless subdomain policy is explicitly described using 1042 the "sp" or "np" tags. If this tag is not present in an otherwise 1043 syntactically valid DMARC record, then the record is treated as if 1044 it included "p=none" (see Section 4.7). This tag is not 1045 applicable for third-party reporting records (see 1046 [DMARC-Aggregate-Reporting] and [DMARC-Failure-Reporting]) 1047 Possible values are as follows: 1049 none: The Domain Owner offers no expression of preference. 1051 quarantine: The Domain Owner considers such mail to be 1052 suspicious. It is possible the mail is valid, although the 1053 failure creates a significant concern. 1055 reject: The Domain Owner considers all such failures to be a 1056 clear indication that the use of the domain name is not valid. 1057 See Section 7.3 for some discussion of SMTP rejection methods 1058 and their implications. 1060 psd: A flag indicating whether the domain is a PSD. (plain-text; 1061 OPTIONAL; default is 'u'). Possible values are: 1063 y: PSOs MUSTinclude this tag with a value of 'y' to indicate that 1064 the domain is a PSD. If a record containing this tag with a 1065 value of 'y' is found during policy discovery, this information 1066 will be used to determine the Organizational Domain and policy 1067 domain applicable to the message in question. 1069 n: The DMARC policy record is published for a PSD, but it is the 1070 Organizational Domain for itself and its subdomain. There is 1071 no need to put psd=n in a DMARC record, except in the very 1072 unusual case of a parent PSD publishing a DMARC record without 1073 the requisite psd=y tag. 1075 u: The default, indicating that the DMARC policy record is 1076 published for a domain that is not a PSD. Use the mechanism 1077 described in Section 4.8 for determining the Organizational 1078 Domain. There is no need to explicitly publish psd=u in a 1079 DMARC record. 1081 rua: Addresses to which aggregate feedback is to be sent (comma- 1082 separated plain-text list of DMARC URIs; OPTIONAL). 1083 [DMARC-Aggregate-Reporting] discusses considerations that apply 1084 when the domain name of a URI differs from that of the domain 1085 advertising the policy. See Section 9.5 for additional 1086 considerations. Any valid URI can be specified. A Mail Receiver 1087 MUST implement support for a "mailto:" URI, i.e., the ability to 1088 send a DMARC report via electronic mail. If the tag is not 1089 provided, Mail Receivers MUST NOT generate aggregate feedback 1090 reports for the domain. URIs not supported by Mail Receivers MUST 1091 be ignored. The aggregate feedback report format is described in 1092 [DMARC-Aggregate-Reporting] 1094 ruf: Addresses to which message-specific failure information is to 1095 be reported (comma-separated plain-text list of DMARC URIs; 1096 OPTIONAL). If present, the Domain Owner or PSO is requesting Mail 1097 Receivers to send detailed failure reports about messages that 1098 fail the DMARC evaluation in specific ways (see the "fo" tag 1099 above). The format of the message to be generated MUST follow the 1100 format specified for the "rf" tag. [DMARC-Aggregate-Reporting] 1101 discusses considerations that apply when the domain name of a URI 1102 differs from that of the domain advertising the policy. A Mail 1103 Receiver MUST implement support for a "mailto:" URI, i.e., the 1104 ability to send a DMARC report via electronic mail. If the tag is 1105 not provided, Mail Receivers MUST NOT generate failure reports for 1106 the domain. See Section 9.5 for additional considerations. 1108 sp: Domain Owner Assessment Policy for all subdomains (plain-text; 1109 OPTIONAL). Indicates the message handling preference the Domain 1110 Owner or PSO has for mail using an existing subdomain of the 1111 domain queried but not passing DMARC verification. It applies 1112 only to subdomains of the domain queried and not to the domain 1113 itself. Its syntax is identical to that of the "p" tag defined 1114 above. If both the "sp" tag is absent and the "np" tag is either 1115 absent or not applicable, the policy specified by the "p" tag MUST 1116 be applied for subdomains. Note that "sp" will be ignored for 1117 DMARC records published on subdomains of Organizational Domains 1118 due to the effect of the DMARC policy discovery mechanism 1119 described in Section 4.7. 1121 t: DMARC policy test mode (plain-text; OPTIONAL; default is 'n'). 1122 For the RFC5322.From domain to which the DMARC record applies, the 1123 "t" tag serves as a signal to the actor performing DMARC 1124 verification checks as to whether or not the domain owner wishes 1125 the assessment policy declared in the "p=", "sp=", and/or "np=" 1126 tags to actually be applied. This parameter does not affect the 1127 generation of DMARC reports. Possible values are as follows: 1129 y: A request that the actor performing the DMARC verification 1130 check not apply the policy, but instead apply any special 1131 handling rules it might have in place, such as rewriting the 1132 RFC5322.From header. The domain owner is currently testing its 1133 specified DMARC assessment policy. 1135 n: The default, a request to apply the policy as specified to any 1136 message that produces a DMARC "fail" result. 1138 v: Version (plain-text; REQUIRED). Identifies the record retrieved 1139 as a DMARC record. It MUST have the value of "DMARC1". The value 1140 of this tag MUST match precisely; if it does not or it is absent, 1141 the entire retrieved record MUST be ignored. It MUST be the first 1142 tag in the list. 1144 A DMARC policy record MUST comply with the formal specification found 1145 in Section 5.4 in that the "v" tag MUST be present and MUST appear 1146 first. Unknown tags MUST be ignored. Syntax errors in the remainder 1147 of the record SHOULD be discarded in favor of default values (if any) 1148 or ignored outright. 1150 Note that given the rules of the previous paragraph, addition of a 1151 new tag into the registered list of tags does not itself require a 1152 new version of DMARC to be generated (with a corresponding change to 1153 the "v" tag's value), but a change to any existing tags does require 1154 a new version of DMARC. 1156 5.4. Formal Definition 1158 The formal definition of the DMARC format, using [RFC5234], is as 1159 follows: 1161 dmarc-uri = URI 1162 ; "URI" is imported from [RFC3986]; commas (ASCII 1163 ; 0x2C) and exclamation points (ASCII 0x21) 1164 ; MUST be encoded 1166 dmarc-record = dmarc-version dmarc-sep *(dmarc-tag dmarc-sep) 1168 dmarc-tag = dmarc-request / 1169 dmarc-test / 1170 dmarc-psd / 1171 dmarc-sprequest / 1172 dmarc-nprequest / 1173 dmarc-adkim / 1174 dmarc-aspf / 1175 dmarc-auri / 1176 dmarc-furi / 1177 dmarc-fo / 1178 dmarc-rfmt 1179 ; components other than dmarc-version and 1180 ; dmarc-request may appear in any order 1182 dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31 1184 dmarc-sep = *WSP %x3b *WSP 1186 dmarc-request = "p" *WSP "=" *WSP 1187 ( "none" / "quarantine" / "reject" ) 1189 dmarc-test = "t" *WSP "=" ( "y" / "n" ) 1191 dmarc-psd = "psd" *WSP "=" ( "y" / "n" ) 1193 dmarc-sprequest = "sp" *WSP "=" *WSP 1194 ( "none" / "quarantine" / "reject" ) 1196 dmarc-nprequest = "np" *WSP "=" *WSP 1197 ( "none" / "quarantine" / "reject" ) 1199 dmarc-adkim = "adkim" *WSP "=" *WSP ( "r" / "s" ) 1201 dmarc-aspf = "aspf" *WSP "=" *WSP ( "r" / "s" ) 1203 dmarc-auri = "rua" *WSP "=" *WSP 1204 dmarc-uri *(*WSP "," *WSP dmarc-uri) 1206 dmarc-furi = "ruf" *WSP "=" *WSP 1207 dmarc-uri *(*WSP "," *WSP dmarc-uri) 1209 dmarc-fo = "fo" *WSP "=" *WSP 1210 ( "0" / "1" / ( "d" / "s" / "d:s" / "s:d" ) ) 1212 dmarc-rfmt = "rf" *WSP "=" *WSP Keyword *(*WSP ":" Keyword) 1213 ; registered reporting formats only 1215 "Keyword" is imported from Section 4.1.2 of [RFC5321]. 1217 5.5. Domain Owner Actions 1219 This section describes Domain Owner actions to implement the DMARC 1220 mechanism. 1222 5.5.1. Publish an SPF Policy for an Aligned Domain 1224 Because DMARC relies on SPF [RFC7208] and DKIM [RFC6376], in order to 1225 take full advantage of DMARC, a Domain Owner SHOULD first ensure that 1226 SPF and DKIM authentication are properly configured. As a first step 1227 the Domain Owner SHOULD choose a domain to use as the 1228 RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail, 1229 one that aligns with the Author Domain, and then publish an SPF 1230 policy in DNS for that domain. The SPF record SHOULD be constructed 1231 at a minimum to ensure an SPF pass verdict for all known sources of 1232 mail for the RFC5321.MailFrom domain. 1234 5.5.2. Configure Sending System for DKIM Signing Using an Aligned 1235 Domain 1237 While it is possible to secure a DMARC pass verdict based on only SPF 1238 or DKIM, it is commonly accepted best practice to ensure that both 1239 authentication mechanisms are in place in order to guard against 1240 failure of just one of them. The Domain Owner SHOULD choose a DKIM- 1241 Signing domain (i.e., the d= domain in the DKIM-Signature header) 1242 that aligns with the Author Domain. 1244 5.5.3. Setup a Mailbox to Receive Aggregate Reports 1246 Proper consumption and analysis of DMARC aggregate reports is the key 1247 to any successful DMARC deployment for a Domain Owner. DMARC 1248 aggregate reports, which are XML documents and are defined in 1249 [DMARC-Aggregate-Reporting], contain valuable data for the Domain 1250 Owner, showing sources of mail using the Author Domain. Depending on 1251 how mature the Domain Owner's DMARC rollout is, some of these sources 1252 could be legitimate ones that were overlooked during the initial 1253 deployment of SPF and/or DKIM. 1255 Because the aggregate reports are XML documents, it is recommended 1256 that they be machine-parsed, so setting up a mailbox involves more 1257 than just the physical creation of that mailbox. Many third-party 1258 services exist that will process DMARC aggregate reports, or the 1259 Domain Owner can create its own set of tools. No matter which method 1260 is chosen, the ability to parse these reports and consume the data 1261 contained in them will go a long way to ensuring a successful 1262 deployment. 1264 5.5.4. Publish a DMARC Policy for the Author Domain and Organizational 1265 Domain 1267 Once SPF, DKIM, and the aggregate reports mailbox are all in place, 1268 it's time to publish a DMARC record. For best results, Domain Owners 1269 SHOULD start with "p=none", with the rua tag containg a URI that 1270 references the mailbox created in the previous step. If the 1271 Organizational Domain is different than the Author Domain, a record 1272 also needs to be published for the Organizational Domain. 1274 5.5.5. Collect and Analyze Reports 1276 The reason for starting at "p=none" is to ensure that nothing's been 1277 missed in the initial SPF and DKIM deployments. In all but the most 1278 trivial setups, it is possible for a Domain Owner to overlook a 1279 server here or be unaware of a third party sending agreeement there. 1280 Starting at "p=none", therefore, takes advantage of DMARC's aggregate 1281 reporting function, with the Domain Owner using the reports to audit 1282 its own mail streams' authentication configurations. 1284 5.5.6. Decide If and When to Update DMARC Policy 1286 Once the Domain Owner is satisfied that it is properly authenticating 1287 all of its mail, then it is time to decide if it is appropriate to 1288 change the p= value in its DMARC record to p=quarantine or p=reject. 1289 Depending on its cadence for sending mail, it may take many months of 1290 consuming DMARC aggregate reports before a Domain Owner reaches the 1291 point where it is sure that it is properly authenticating all of its 1292 mail, and the decision on which p= value to use will depend on its 1293 needs. 1295 5.6. PSO Actions 1297 In addition to the DMARC Domain Owner actions, if a PSO publishes a 1298 DMARC record it MUST include the psd tag (see Section 5.3) with a 1299 value of 'y' ("psd=y"). 1301 5.7. Mail Receiver Actions 1303 This section describes receiver actions in the DMARC environment. 1305 5.7.1. Extract Author Domain 1307 The domain in the RFC5322.From header field is extracted as the 1308 domain to be evaluated by DMARC. If the domain is encoded with UTF- 1309 8, the domain name must be converted to an A-label, as described in 1310 Section 2.3 of [RFC5890], for further processing. 1312 In order to be processed by DMARC, a message typically needs to 1313 contain exactly one RFC5322.From domain (a single From: field with a 1314 single domain in it). Not all messages meet this requirement, and 1315 the handling of those that are forbidden under [RFC5322] or that 1316 contain no meaningful domains is outside the scope of this document. 1318 The case of a syntactically valid multi-valued RFC5322.From header 1319 field presents a particular challenge. When a single RFC5322.From 1320 header field contains multiple addresses, it is possible that there 1321 may be multiple domains used in those addresses. The process in this 1322 case is to only proceed with DMARC checking if the domain is 1323 identical for all of the addresses in a multi-valued RFC5322.From 1324 header field. Multi-valued RFC5322.From header fields with multiple 1325 domains MUST be exempt from DMARC checking. 1327 Note that Public Suffix Domains are not exempt from DMARC policy 1328 application and reporting. 1330 5.7.2. Determine Handling Policy 1332 To arrive at a policy for an individual message, Mail Receivers MUST 1333 perform the following actions or their semantic equivalents. Steps 1334 2-4 MAY be done in parallel, whereas steps 5 and 6 require input from 1335 previous steps. 1337 The steps are as follows: 1339 1. Extract the RFC5322.From domain from the message (as above). 1341 2. Query the DNS for a DMARC policy record. Continue if one is 1342 found, or terminate DMARC evaluation otherwise. See Section 4.7 1343 for details. 1345 3. Perform DKIM signature verification checks. A single email could 1346 contain multiple DKIM signatures. The results of this step are 1347 passed to the remainder of the algorithm, MUST include "pass" or 1348 "fail", and if "fail", SHOULD include information about the 1349 reasons for failure. The results MUST further include the value 1350 of the "d=" and "s=" tags from each checked DKIM signature. 1352 4. Perform SPF verification checks. The results of this step are 1353 passed to the remainder of the algorithm, MUST include "pass" or 1354 "fail", and if "fail", SHOULD include information about the 1355 reasons for failure. The results MUST further include the domain 1356 name used to complete the SPF check. 1358 5. Conduct Identifier Alignment checks. With authentication checks 1359 and policy discovery performed, the Mail Receiver checks to see 1360 if Authenticated Identifiers fall into alignment as described in 1361 Section 4.4. If one or more of the Authenticated Identifiers 1362 align with the RFC5322.From domain, the message is considered to 1363 pass the DMARC mechanism check. All other conditions 1364 (authentication failures, identifier mismatches) are considered 1365 to be DMARC mechanism check failures. 1367 6. Apply policy, if appropriate. Emails that fail the DMARC 1368 mechanism check are handled in accordance with the discovered 1369 DMARC policy of the Domain Owner and any local policy rules 1370 enforced by the Mail Receiver. See Section 5.3 for details. 1372 DMARC evaluation can only yield a "pass" result after one of the 1373 underlying authentication mechanisms passes for an aligned 1374 identifier. If neither passes and one or both of them fail due to a 1375 temporary error, the Mail Receiver evaluating the message is unable 1376 to conclude that the DMARC mechanism had a permanent failure; they 1377 therefore cannot apply the advertised DMARC policy. When otherwise 1378 appropriate, Mail Receivers MAY send feedback reports regarding 1379 temporary errors. 1381 Handling of messages for which SPF and/or DKIM evaluation encounter a 1382 permanent DNS error is left to the discretion of the Mail Receiver. 1384 5.7.3. Store Results of DMARC Processing 1386 The results of Mail Receiver-based DMARC processing should be stored 1387 for eventual presentation back to the Domain Owner in the form of 1388 aggregate feedback reports. Section 5.3 and 1389 [DMARC-Aggregate-Reporting] discuss aggregate feedback. 1391 5.7.4. Send Aggregate Reports 1393 For a Domain Owner, DMARC aggregate reports provide data about all 1394 mailstreams making use of its domain in email, to include not only 1395 illegitimate uses but also, and perhaps more importantly, all 1396 legitimate uses. Domain Owners can use aggregate reports to ensure 1397 that all legitimate uses of their domain for sending email are 1398 properly authenticated, and once they are, express a stricter message 1399 handling preference in the p= tag in their DMARC policy records from 1400 none to quarantine to reject, if appropriate. In turn, DMARC policy 1401 records with p= tag values of 'quarantine' or 'reject' are higher 1402 value signals to Mail Receivers, ones that can assist Mail Receivers 1403 with handling decisions for a message in ways that p= tag values of 1404 'none' cannot. 1406 Given the above, in order to ensure maximum usefulness for DMARC 1407 across the email ecosystem, Mail Receivers SHOULD generate and send 1408 aggregate reports with a frequency of at least once every 24 hours. 1410 5.8. Policy Enforcement Considerations 1412 Mail Receivers MAY choose to reject or quarantine email even if email 1413 passes the DMARC mechanism check. The DMARC mechanism does not 1414 inform Mail Receivers whether an email stream is "good"; a DMARC 1415 result of "pass" only means that the domain in the RFC5322.From 1416 header has been verified by the DMARC mechanism. Mail Receivers are 1417 encouraged to maintain anti-abuse technologies to combat the 1418 possibility of DMARC-enabled criminal campaigns. 1420 Mail Receivers MAY choose to accept email that fails the DMARC 1421 mechanism check even if the published Domain Owner Assessment Policy 1422 is "reject". Mail Receivers need to make a best effort not to 1423 increase the likelihood of accepting abusive mail if they choose not 1424 to honor the published Domain Owner Assessment Policy. At a minimum, 1425 addition of the Authentication-Results header field (see [RFC8601]) 1426 is RECOMMENDED when delivery of failing mail is done. When this is 1427 done, the DNS domain name thus recorded MUST be encoded as an 1428 A-label. 1430 Mail Receivers are only obligated to report reject or quarantine 1431 policy actions in aggregate feedback reports that are due to 1432 published DMARC Domain Owner Assessment Policy. They are not 1433 required to report reject or quarantine actions that are the result 1434 of local policy. If local policy information is exposed, abusers can 1435 gain insight into the effectiveness and delivery rates of spam 1436 campaigns. 1438 Final handling of a message is always a matter of local policy. An 1439 operator that wishes to favor DMARC policy over SPF policy, for 1440 example, will disregard the SPF policy, since enacting an SPF- 1441 determined rejection prevents evaluation of DKIM; DKIM might 1442 otherwise pass, satisfying the DMARC evaluation. There is a trade- 1443 off to doing so, namely acceptance and processing of the entire 1444 message body in exchange for the enhanced protection DMARC provides. 1446 DMARC-compliant Mail Receivers typically disregard any mail-handling 1447 directive discovered as part of an authentication mechanism (e.g., 1448 Author Domain Signing Practices (ADSP), SPF) where a DMARC record is 1449 also discovered that specifies a policy other than "none". Deviating 1450 from this practice introduces inconsistency among DMARC operators in 1451 terms of handling of the message. However, such deviation is not 1452 proscribed. 1454 To enable Domain Owners to receive DMARC feedback without impacting 1455 existing mail processing, discovered policies of "p=none" SHOULD NOT 1456 modify existing mail handling processes. 1458 Mail Receivers MUST also implement reporting instructions of DMARC, 1459 even in the absence of a request for DKIM reporting [RFC6651] or SPF 1460 reporting [RFC6652]. Furthermore, the presence of such requests 1461 SHOULD NOT affect DMARC reporting. 1463 6. DMARC Feedback 1465 Providing Domain Owners with visibility into how Mail Receivers 1466 implement and enforce the DMARC mechanism in the form of feedback is 1467 critical to establishing and maintaining accurate authentication 1468 deployments. When Domain Owners can see what effect their policies 1469 and practices are having, they are better willing and able to use 1470 quarantine and reject policies. 1472 The details of this feedback are described in 1473 [DMARC-Aggregate-Reporting] 1475 Operational note for PSD DMARC: For PSOs, feedback for non-existent 1476 domains is desirable and useful, just as it is for org-level DMARC 1477 operators. See Section 4 of [RFC9091] for discussion of Privacy 1478 Considerations for PSD DMARC 1480 7. Other Topics 1482 This section discusses some topics regarding choices made in the 1483 development of DMARC, largely to commit the history to record. 1485 7.1. Issues Specific to SPF 1487 Though DMARC does not inherently change the semantics of an SPF 1488 policy record, historically lax enforcement of such policies has led 1489 many to publish extremely broad records containing many large network 1490 ranges. Domain Owners are strongly encouraged to carefully review 1491 their SPF records to understand which networks are authorized to send 1492 on behalf of the Domain Owner before publishing a DMARC record. 1494 Some Mail Receiver architectures might implement SPF in advance of 1495 any DMARC operations. This means that a "-" prefix on a sender's SPF 1496 mechanism, such as "-all", could cause that rejection to go into 1497 effect early in handling, causing message rejection before any DMARC 1498 processing takes place. Operators choosing to use "-all" should be 1499 aware of this. 1501 7.2. DNS Load and Caching 1503 DMARC policies are communicated using the DNS and therefore inherit a 1504 number of considerations related to DNS caching. The inherent 1505 conflict between freshness and the impact of caching on the reduction 1506 of DNS-lookup overhead should be considered from the Mail Receiver's 1507 point of view. Should Domain Owners or PSOs publish a DNS record 1508 with a very short TTL, Mail Receivers can be provoked through the 1509 injection of large volumes of messages to overwhelm the publisher's 1510 DNS. Although this is not a concern specific to DMARC, the 1511 implications of a very short TTL should be considered when publishing 1512 DMARC policies. 1514 Conversely, long TTLs will cause records to be cached for long 1515 periods of time. This can cause a critical change to DMARC 1516 parameters advertised by a Domain Owner or PSO to go unnoticed for 1517 the length of the TTL (while waiting for DNS caches to expire). 1518 Avoiding this problem can mean shorter TTLs, with the potential 1519 problems described above. A balance should be sought to maintain 1520 responsiveness of DMARC preference changes while preserving the 1521 benefits of DNS caching. 1523 7.3. Rejecting Messages 1525 This protocol calls for rejection of a message during the SMTP 1526 session under certain circumstances. This is preferable to 1527 generation of a Delivery Status Notification [RFC3464], since 1528 fraudulent messages caught and rejected using DMARC would then result 1529 in annoying generation of such failure reports that go back to the 1530 RFC5321.MailFrom address. 1532 This synchronous rejection is typically done in one of two ways: 1534 * Full rejection, wherein the SMTP server issues a 5xy reply code as 1535 an indication to the SMTP client that the transaction failed; the 1536 SMTP client is then responsible for generating notification that 1537 delivery failed (see Section 4.2.5 of [RFC5321]). 1539 * A "silent discard", wherein the SMTP server returns a 2xy reply 1540 code implying to the client that delivery (or, at least, relay) 1541 was successfully completed, but then simply discarding the message 1542 with no further action. 1544 Each of these has a cost. For instance, a silent discard can help to 1545 prevent backscatter, but it also effectively means that the SMTP 1546 server has to be programmed to give a false result, which can 1547 confound external debugging efforts. 1549 Similarly, the text portion of the SMTP reply may be important to 1550 consider. For example, when rejecting a message, revealing the 1551 reason for the rejection might give an attacker enough information to 1552 bypass those efforts on a later attempt, though it might also assist 1553 a legitimate client to determine the source of some local issue that 1554 caused the rejection. 1556 In the latter case, when doing an SMTP rejection, providing a clear 1557 hint can be useful in resolving issues. A Mail Receiver might 1558 indicate in plain text the reason for the rejection by using the word 1559 "DMARC" somewhere in the reply text. For example: 1561 550 5.7.1 Email rejected per DMARC policy for example.com 1563 Many systems are able to scan the SMTP reply text to determine the 1564 nature of the rejection. Thus, providing a machine-detectable reason 1565 for rejection allows the problems causing rejections to be properly 1566 addressed by automated systems. 1568 If a Mail Receiver elects to defer delivery due to inability to 1569 retrieve or apply DMARC policy, this is best done with a 4xy SMTP 1570 reply code. 1572 7.4. Identifier Alignment Considerations 1574 The DMARC mechanism allows both DKIM and SPF-authenticated 1575 identifiers to authenticate email on behalf of a Domain Owner and, 1576 possibly, on behalf of different subdomains. If malicious or unaware 1577 users can gain control of the SPF record or DKIM selector records for 1578 a subdomain, the subdomain can be used to generate DMARC-passing 1579 email on behalf of the Organizational Domain. 1581 For example, an attacker who controls the SPF record for 1582 "evil.example.com" can send mail with an RFC5322.From header field 1583 containing "foo@example.com" that can pass both authentication and 1584 the DMARC check against "example.com". 1586 The Organizational Domain administrator should be careful not to 1587 delegate control of subdomains if this is an issue, and to consider 1588 using the "strict" Identifier Alignment option if appropriate. 1590 7.5. Interoperability Issues 1592 DMARC limits which end-to-end scenarios can achieve a "pass" result. 1594 Because DMARC relies on SPF [RFC7208] and/or DKIM [RFC6376] to 1595 achieve a "pass", their limitations also apply. 1597 Additional DMARC constraints occur when a message is processed by 1598 some Mediators, such as mailing lists. Transiting a Mediator often 1599 causes either the authentication to fail or Identifier Alignment to 1600 be lost. These transformations may conform to standards but will 1601 still prevent a DMARC "pass". 1603 In addition to Mediators, mail that is sent by authorized, 1604 independent third parties might not be sent with Identifier 1605 Alignment, also preventing a "pass" result. 1607 Issues specific to the use of policy mechanisms alongside DKIM are 1608 further discussed in [RFC6377], particularly Section 5.2. 1610 8. IANA Considerations 1612 This section describes actions completed by IANA. 1614 8.1. Authentication-Results Method Registry Update 1616 IANA has added the following to the "Email Authentication Methods" 1617 registry: 1619 +======+===========+======+==========+==============+======+========+ 1620 |Method| Defined |ptype | Property |Value |Status|Version | 1621 +======+===========+======+==========+==============+======+========+ 1622 |dmarc | [RFC7489] |header| from |the domain |active|1 | 1623 | | | | |portion of the| | | 1624 | | | | |RFC5322.From | | | 1625 | | | | |header field | | | 1626 +------+-----------+------+----------+--------------+------+--------+ 1627 |dmarc | [RFC7489] |polrec| p |the p= value |active|1 | 1628 | | | | |read from the | | | 1629 | | | | |discovered | | | 1630 | | | | |policy record | | | 1631 +------+-----------+------+----------+--------------+------+--------+ 1632 |dmarc | [RFC7489] |polrec| domain |the domain at |active|1 | 1633 | | | | |which the | | | 1634 | | | | |policy record | | | 1635 | | | | |was | | | 1636 | | | | |discovered, if| | | 1637 | | | | |different from| | | 1638 | | | | |the | | | 1639 | | | | |RFC5322.From | | | 1640 | | | | |domain | | | 1641 +------+-----------+------+----------+--------------+------+--------+ 1643 Table 1: "Authentication-Results Method Registry Update" 1645 8.2. Authentication-Results Result Registry Update 1647 IANA has added the following in the "Email Authentication Result 1648 Names" registry: 1650 +===========+===========+===========+=======+================+======+ 1651 | Code | Existing/ | Defined |Auth |Meaning |Status| 1652 | | New Code | |Method | | | 1653 +===========+===========+===========+=======+================+======+ 1654 | none | existing | [RFC8601] |dmarc |No DMARC policy |active| 1655 | | | |(added)|record was | | 1656 | | | | |published for | | 1657 | | | | |the aligned | | 1658 | | | | |identifier, or | | 1659 | | | | |no aligned | | 1660 | | | | |identifier could| | 1661 | | | | |be extracted. | | 1662 +-----------+-----------+-----------+-------+----------------+------+ 1663 | pass | existing | [RFC8601] |dmarc |A DMARC policy |active| 1664 | | | |(added)|record was | | 1665 | | | | |published for | | 1666 | | | | |the aligned | | 1667 | | | | |identifier, and | | 1668 | | | | |at least one of | | 1669 | | | | |the | | 1670 | | | | |authentication | | 1671 | | | | |mechanisms | | 1672 | | | | |passed. | | 1673 +-----------+-----------+-----------+-------+----------------+------+ 1674 | fail | existing | [RFC8601] |dmarc |A DMARC policy |active| 1675 | | | |(added)|record was | | 1676 | | | | |published for | | 1677 | | | | |the aligned | | 1678 | | | | |identifier, and | | 1679 | | | | |none of the | | 1680 | | | | |authentication | | 1681 | | | | |mechanisms | | 1682 | | | | |passed. | | 1683 +-----------+-----------+-----------+-------+----------------+------+ 1684 | temperror | existing | [RFC8601] |dmarc |A temporary |active| 1685 | | | |(added)|error occurred | | 1686 | | | | |during DMARC | | 1687 | | | | |evaluation. A | | 1688 | | | | |later attempt | | 1689 | | | | |might produce a | | 1690 | | | | |final result. | | 1691 +-----------+-----------+-----------+-------+----------------+------+ 1692 | permerror | existing | [RFC8601] |dmarc |A permanent |active| 1693 | | | |(added)|error occurred | | 1694 | | | | |during DMARC | | 1695 | | | | |evaluation, such| | 1696 | | | | |as encountering | | 1697 | | | | |a syntactically | | 1698 | | | | |incorrect DMARC | | 1699 | | | | |record. A later| | 1700 | | | | |attempt is | | 1701 | | | | |unlikely to | | 1702 | | | | |produce a final | | 1703 | | | | |result. | | 1704 +-----------+-----------+-----------+-------+----------------+------+ 1706 Table 2: "Authentication-Results Result Registry Update" 1708 8.3. Feedback Report Header Fields Registry Update 1710 The following has been added to the "Feedback Report Header Fields" 1711 registry: 1713 Field Name: Identity-Alignment 1714 Description: indicates whether the message about which a report is 1715 being generated had any identifiers in alignment as defined in RFC 1716 7489 1718 Multiple Appearances: No 1720 Related "Feedback-Type": auth-failure 1722 Reference: RFC 7489 1724 Status: current 1726 8.4. DMARC Tag Registry 1728 A new registry tree called "Domain-based Message Authentication, 1729 Reporting, and Conformance (DMARC) Parameters" has been created. 1730 Within it, a new sub-registry called the "DMARC Tag Registry" has 1731 been created. 1733 Names of DMARC tags must be registered with IANA in this new sub- 1734 registry. New entries are assigned only for values that have been 1735 documented in a manner that satisfies the terms of Specification 1736 Required, per [RFC8126]. Each registration must include the tag 1737 name; the specification that defines it; a brief description; and its 1738 status, which must be one of "current", "experimental", or 1739 "historic". The Designated Expert needs to confirm that the provided 1740 specification adequately describes the new tag and clearly presents 1741 how it would be used within the DMARC context by Domain Owners and 1742 Mail Receivers. 1744 To avoid version compatibility issues, tags added to the DMARC 1745 specification are to avoid changing the semantics of existing records 1746 when processed by implementations conforming to prior specifications. 1748 The initial set of entries in this registry is as follows: 1750 +=======+===========+==========+=============================+ 1751 | Tag | Reference | Status | Description | 1752 | Name | | | | 1753 +=======+===========+==========+=============================+ 1754 | adkim | RFC 7489 | current | DKIM alignment mode | 1755 +-------+-----------+----------+-----------------------------+ 1756 | aspf | RFC 7489 | current | SPF alignment mode | 1757 +-------+-----------+----------+-----------------------------+ 1758 | fo | RFC 7489 | current | Failure reporting options | 1759 +-------+-----------+----------+-----------------------------+ 1760 | np | RFC 7489 | current | Requested handling policy | 1761 | | | | for non-existent subdomains | 1762 +-------+-----------+----------+-----------------------------+ 1763 | p | RFC 7489 | current | Requested handling policy | 1764 +-------+-----------+----------+-----------------------------+ 1765 | pct | RFC 7489 | historic | Sampling rate | 1766 +-------+-----------+----------+-----------------------------+ 1767 | psd | RFC 7489 | current | Indicates whether policy | 1768 | | | | record is published by a | 1769 | | | | Public Suffix Domain | 1770 +-------+-----------+----------+-----------------------------+ 1771 | rf | RFC 7489 | historic | Failure reporting format(s) | 1772 +-------+-----------+----------+-----------------------------+ 1773 | ri | RFC 7489 | historic | Aggregate Reporting | 1774 | | | | interval | 1775 +-------+-----------+----------+-----------------------------+ 1776 | rua | RFC 7489 | current | Reporting URI(s) for | 1777 | | | | aggregate data | 1778 +-------+-----------+----------+-----------------------------+ 1779 | ruf | RFC 7489 | current | Reporting URI(s) for | 1780 | | | | failure data | 1781 +-------+-----------+----------+-----------------------------+ 1782 | sp | RFC 7489 | current | Requested handling policy | 1783 | | | | for subdomains | 1784 +-------+-----------+----------+-----------------------------+ 1785 | t | RFC 7489 | current | Test mode for the specified | 1786 | | | | policy | 1787 +-------+-----------+----------+-----------------------------+ 1788 | v | RFC 7489 | current | Specification version | 1789 +-------+-----------+----------+-----------------------------+ 1791 Table 3: "DMARC Tag Registry" 1793 8.5. DMARC Report Format Registry 1795 Also within "Domain-based Message Authentication, Reporting, and 1796 Conformance (DMARC) Parameters", a new sub-registry called "DMARC 1797 Report Format Registry" has been created. 1799 Names of DMARC failure reporting formats must be registered with IANA 1800 in this registry. New entries are assigned only for values that 1801 satisfy the definition of Specification Required, per [RFC8126]. In 1802 addition to a reference to a permanent specification, each 1803 registration must include the format name; a brief description; and 1804 its status, which must be one of "current", "experimental", or 1805 "historic". The Designated Expert needs to confirm that the provided 1806 specification adequately describes the report format and clearly 1807 presents how it would be used within the DMARC context by Domain 1808 Owners and Mail Receivers. 1810 The initial entry in this registry is as follows: 1812 +========+===========+=========+==================================+ 1813 | Format | Reference | Status | Description | 1814 | Name | | | | 1815 +========+===========+=========+==================================+ 1816 | afrf | RFC 7489 | current | Authentication Failure Reporting | 1817 | | | | Format (see [RFC6591]) | 1818 +--------+-----------+---------+----------------------------------+ 1820 Table 4: "DMARC Report Format Registry" 1822 8.6. Underscored and Globally Scoped DNS Node Names Registry 1824 Per [RFC8552], please add the following entry to the "Underscored and 1825 Globally Scoped DNS Node Names" registry: 1827 +=========+============+===========+ 1828 | RR Type | _NODE NAME | Reference | 1829 +=========+============+===========+ 1830 | TXT | _dmarc | RFC 7489 | 1831 +---------+------------+-----------+ 1833 Table 5: "Underscored and 1834 Globally Scoped DNS Node Names" 1835 registry 1837 9. Security Considerations 1839 This section discusses security issues and possible remediations 1840 (where available) for DMARC. 1842 9.1. Authentication Methods 1844 Security considerations from the authentication methods used by DMARC 1845 are incorporated here by reference. 1847 9.2. Attacks on Reporting URIs 1849 URIs published in DNS TXT records are well-understood possible 1850 targets for attack. Specifications such as [RFC1035] and [RFC2142] 1851 either expose or cause the exposure of email addresses that could be 1852 flooded by an attacker, for example; MX, NS, and other records found 1853 in the DNS advertise potential attack destinations; common DNS names 1854 such as "www" plainly identify the locations at which particular 1855 services can be found, providing destinations for targeted denial-of- 1856 service or penetration attacks. 1858 Thus, Domain Owners will need to harden these addresses against 1859 various attacks, including but not limited to: 1861 * high-volume denial-of-service attacks; 1863 * deliberate construction of malformed reports intended to identify 1864 or exploit parsing or processing vulnerabilities; 1866 * deliberate construction of reports containing false claims for the 1867 Submitter or Reported-Domain fields, including the possibility of 1868 false data from compromised but known Mail Receivers. 1870 9.3. DNS Security 1872 The DMARC mechanism and its underlying technologies (SPF, DKIM) 1873 depend on the security of the DNS. Examples of how hostile parties 1874 can have an adverse impact on DNS traffic include: 1876 * If they can snoop on DNS traffic, they can get an idea of who is 1877 sending mail. 1879 * If they can block outgoing or reply DNS messages, they can prevent 1880 systems from discovering senders' DMARC policies, causing 1881 recipients to assume p=none by default. 1883 * If they can send forged response packets, they can make aligned 1884 mail appear unaligned or vice-versa. 1886 None of these threats are unique to DMARC, and they can be addressed 1887 using a variety of techniques, including, but not limited to: 1889 * Signing DNS records with DNSSEC [RFC4033], which enables 1890 recipients to detect and discard forged responses. 1892 * DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484] can mitigate 1893 snooping and forged responses. 1895 9.4. Display Name Attacks 1897 A common attack in messaging abuse is the presentation of false 1898 information in the display-name portion of the RFC5322.From header 1899 field. For example, it is possible for the email address in that 1900 field to be an arbitrary address or domain name, while containing a 1901 well-known name (a person, brand, role, etc.) in the display name, 1902 intending to fool the end user into believing that the name is used 1903 legitimately. The attack is predicated on the notion that most 1904 common MUAs will show the display name and not the email address when 1905 both are available. 1907 Generally, display name attacks are out of scope for DMARC, as 1908 further exploration of possible defenses against these attacks needs 1909 to be undertaken. 1911 There are a few possible mechanisms that attempt mitigation of these 1912 attacks, such as the following: 1914 * If the display name is found to include an email address (as 1915 specified in [RFC5322]), execute the DMARC mechanism on the domain 1916 name found there rather than the domain name discovered 1917 originally. However, this addresses only a very specific attack 1918 space, and spoofers can easily circumvent it by simply not using 1919 an email address in the display name. There are also known cases 1920 of legitimate uses of an email address in the display name with a 1921 domain different from the one in the address portion, e.g., 1923 From: "user@example.org via Bug Tracker" support@example.com 1924 (mailto:support@example.com) 1926 * In the MUA, only show the display name if the DMARC mechanism 1927 succeeds. This too is easily defeated, as an attacker could 1928 arrange to pass the DMARC tests while fraudulently using another 1929 domain name in the display name. 1931 * In the MUA, only show the display name if the DMARC mechanism 1932 passes and the email address thus verified matches one found in 1933 the receiving user's list of known addresses. 1935 9.5. External Reporting Addresses 1937 To avoid abuse by bad actors, reporting addresses generally have to 1938 be inside the domains about which reports are requested. In order to 1939 accommodate special cases such as a need to get reports about domains 1940 that cannot actually receive mail, Section 3 of 1941 [DMARC-Aggregate-Reporting] describes a DNS-based mechanism for 1942 verifying approved external reporting. 1944 The obvious consideration here is an increased DNS load against 1945 domains that are claimed as external recipients. Negative caching 1946 will mitigate this problem, but only to a limited extent, mostly 1947 dependent on the default TTL in the domain's SOA record. 1949 Where possible, external reporting is best achieved by having the 1950 report be directed to domains that can receive mail and simply having 1951 it automatically forwarded to the desired external destination. 1953 Note that the addresses shown in the "ruf" tag receive more 1954 information that might be considered private data, since it is 1955 possible for actual email content to appear in the failure reports. 1956 The URIs identified there are thus more attractive targets for 1957 intrusion attempts than those found in the "rua" tag. Moreover, 1958 attacking the DNS of the subject domain to cause failure data to be 1959 routed fraudulently to an attacker's systems may be an attractive 1960 prospect. Deployment of [RFC4033] is advisable if this is a concern. 1962 9.6. Secure Protocols 1964 This document encourages use of secure transport mechanisms to 1965 prevent loss of private data to third parties that may be able to 1966 monitor such transmissions. Unencrypted mechanisms should be 1967 avoided. 1969 In particular, a message that was originally encrypted or otherwise 1970 secured might appear in a report that is not sent securely, which 1971 could reveal private information. 1973 10. Normative References 1975 [DMARC-Aggregate-Reporting] 1976 Brotman, A., Ed., "DMARC Aggregate Reporting", February 1977 2021, . 1980 [DMARC-Failure-Reporting] 1981 Jones, S.M., Ed. and A. Vesely, Ed., "DMARC Failure 1982 Reporting", February 2021, 1983 . 1986 [RFC1035] Mockapetris, P., "Domain names - implementation and 1987 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1988 November 1987, . 1990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1991 Requirement Levels", BCP 14, RFC 2119, 1992 DOI 10.17487/RFC2119, March 1997, 1993 . 1995 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1996 Resource Identifier (URI): Generic Syntax", STD 66, 1997 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1998 . 2000 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case 2001 Insensitivity Clarification", RFC 4343, 2002 DOI 10.17487/RFC4343, January 2006, 2003 . 2005 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2006 Specifications: ABNF", STD 68, RFC 5234, 2007 DOI 10.17487/RFC5234, January 2008, 2008 . 2010 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2011 DOI 10.17487/RFC5321, October 2008, 2012 . 2014 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2015 DOI 10.17487/RFC5322, October 2008, 2016 . 2018 [RFC5890] Klensin, J., "Internationalized Domain Names for 2019 Applications (IDNA): Definitions and Document Framework", 2020 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2021 . 2023 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 2024 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 2025 RFC 6376, DOI 10.17487/RFC6376, September 2011, 2026 . 2028 [RFC6591] Fontana, H., "Authentication Failure Reporting Using the 2029 Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591, 2030 April 2012, . 2032 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail 2033 (DKIM) for Failure Reporting", RFC 6651, 2034 DOI 10.17487/RFC6651, June 2012, 2035 . 2037 [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) 2038 Authentication Failure Reporting Using the Abuse Reporting 2039 Format", RFC 6652, DOI 10.17487/RFC6652, June 2012, 2040 . 2042 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 2043 Authorizing Use of Domains in Email, Version 1", RFC 7208, 2044 DOI 10.17487/RFC7208, April 2014, 2045 . 2047 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 2048 Message Authentication, Reporting, and Conformance 2049 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 2050 . 2052 [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource 2053 Records through "Underscored" Naming of Attribute Leaves", 2054 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 2055 . 2057 [RFC9091] Kitterman, S. and T. Wicinski, Ed., "Experimental Domain- 2058 Based Message Authentication, Reporting, and Conformance 2059 (DMARC) Extension for Public Suffix Domains", RFC 9091, 2060 DOI 10.17487/RFC9091, July 2021, 2061 . 2063 11. Informative References 2065 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 2066 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 2067 . 2069 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 2070 for Delivery Status Notifications", RFC 3464, 2071 DOI 10.17487/RFC3464, January 2003, 2072 . 2074 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2075 Rose, "DNS Security Introduction and Requirements", 2076 RFC 4033, DOI 10.17487/RFC4033, March 2005, 2077 . 2079 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 2080 DOI 10.17487/RFC5598, July 2009, 2081 . 2083 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 2084 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 2085 September 2011, . 2087 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 2088 and P. Hoffman, "Specification for DNS over Transport 2089 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2090 2016, . 2092 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 2093 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 2094 November 2016, . 2096 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2097 Writing an IANA Considerations Section in RFCs", BCP 26, 2098 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2099 . 2101 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2102 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2103 May 2017, . 2105 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 2106 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 2107 . 2109 [RFC8601] Kucherawy, M., "Message Header Field for Indicating 2110 Message Authentication Status", RFC 8601, 2111 DOI 10.17487/RFC8601, May 2019, 2112 . 2114 Appendix A. Technology Considerations 2116 This section documents some design decisions that were made in the 2117 development of DMARC. Specifically addressed here are some 2118 suggestions that were considered but not included in the design, with 2119 explanatory text regarding the decision. 2121 A.1. S/MIME 2123 S/MIME, or Secure Multipurpose Internet Mail Extensions, is a 2124 standard for encryption and signing of MIME data in a message. This 2125 was suggested and considered as a third security protocol for 2126 authenticating the source of a message. 2128 DMARC is focused on authentication at the domain level (i.e., the 2129 Domain Owner taking responsibility for the message), while S/MIME is 2130 really intended for user-to-user authentication and encryption. This 2131 alone appears to make it a bad fit for DMARC's goals. 2133 S/MIME also suffers from the heavyweight problem of Public Key 2134 Infrastructure, which means that distribution of keys used to verify 2135 signatures needs to be incorporated. In many instances, this alone 2136 is a showstopper. There have been consistent promises that PKI 2137 usability and deployment will improve, but these have yet to 2138 materialize. DMARC can revisit this choice after those barriers are 2139 addressed. 2141 S/MIME has extensive deployment in specific market segments 2142 (government, for example) but does not enjoy similar widespread 2143 deployment over the general Internet, and this shows no signs of 2144 changing. DKIM and SPF both are deployed widely over the general 2145 Internet, and their adoption rates continue to be positive. 2147 Finally, experiments have shown that including S/MIME support in the 2148 initial version of DMARC would neither cause nor enable a substantial 2149 increase in the accuracy of the overall mechanism. 2151 A.2. Method Exclusion 2153 It was suggested that DMARC include a mechanism by which a Domain 2154 Owner could tell Mail Receivers not to attempt verification by one of 2155 the supported methods (e.g., "check DKIM, but not SPF"). 2157 Specifically, consider a Domain Owner that has deployed one of the 2158 technologies, and that technology fails for some messages, but such 2159 failures don't cause enforcement action. Deploying DMARC would cause 2160 enforcement action for policies other than "none", which would appear 2161 to exclude participation by that Domain Owner. 2163 The DMARC development team evaluated the idea of policy exception 2164 mechanisms on several occasions and invariably concluded that there 2165 was not a strong enough use case to include them. The specific 2166 target audience for DMARC does not appear to have concerns about the 2167 failure modes of one or the other being a barrier to DMARC's 2168 adoption. 2170 In the scenario described above, the Domain Owner has a few options: 2172 1. Tighten up its infrastructure to minimize the failure modes of 2173 the single deployed technology. 2175 2. Deploy the other supported authentication mechanism, to offset 2176 the failure modes of the first. 2178 3. Deploy DMARC in a reporting-only mode. 2180 A.3. Sender Header Field 2182 It has been suggested in several message authentication efforts that 2183 the Sender header field be checked for an identifier of interest, as 2184 the standards indicate this as the proper way to indicate a re- 2185 mailing of content such as through a mailing list. Most recently, it 2186 was a protocol-level option for DomainKeys, but on evolution to DKIM, 2187 this property was removed. 2189 The DMARC development team considered this and decided not to include 2190 support for doing so, for the following reasons: 2192 1. The main user protection approach is to be concerned with what 2193 the user sees when a message is rendered. There is no consistent 2194 behavior among MUAs regarding what to do with the content of the 2195 Sender field, if present. Accordingly, supporting checking of 2196 the Sender identifier would mean applying policy to an identifier 2197 the end user might never actually see, which can create a vector 2198 for attack against end users by simply forging a Sender field 2199 containing some identifier that DMARC will like. 2201 2. Although it is certainly true that this is what the Sender field 2202 is for, its use in this way is also unreliable, making it a poor 2203 candidate for inclusion in the DMARC evaluation algorithm. 2205 3. Allowing multiple ways to discover policy introduces unacceptable 2206 ambiguity into the DMARC evaluation algorithm in terms of which 2207 policy is to be applied and when. 2209 A.4. Domain Existence Test 2211 A previous version of this protocol used the test specified in 2212 [RFC5321] to determine a domain's existence. This test requires up 2213 to three DNS lookups for the MX, A, and AAAA RRs for the name in 2214 question. 2216 This version of the protocol relies solely on the test for existence 2217 as defined in [RFC8020]. If a query for a name returns NXDOMAIN, 2218 then the name does not exist. 2220 A.5. Issues with ADSP in Operation 2222 DMARC has been characterized as a "super-ADSP" of sorts. 2224 Contributors to DMARC have compiled a list of issues associated with 2225 ADSP, gained from operational experience, that have influenced the 2226 direction of DMARC: 2228 1. ADSP has no support for subdomains, i.e., the ADSP record for 2229 example.com does not explicitly or implicitly apply to 2230 subdomain.example.com. If wildcarding is not applied, then 2231 spammers can trivially bypass ADSP by sending from a subdomain 2232 with no ADSP record. 2234 2. Nonexistent subdomains are explicitly out of scope in ADSP. 2235 There is nothing in ADSP that states Mail Receivers should simply 2236 reject mail from NXDOMAINs regardless of ADSP policy (which of 2237 course allows spammers to trivially bypass ADSP by sending email 2238 from nonexistent subdomains). 2240 3. ADSP has no operational advice on when to look up the ADSP 2241 record. 2243 4. ADSP has no support for using SPF as an auxiliary mechanism to 2244 DKIM. 2246 5. ADSP has no support for a slow rollout, i.e., no way to configure 2247 a percentage of email on which the Mail Receiver should apply the 2248 policy. This is important for large-volume senders. 2250 6. ADSP has no explicit support for an intermediate phase where the 2251 Mail Receiver quarantines (e.g., sends to the recipient's "spam" 2252 folder) rather than rejects the email. 2254 7. The binding between the "From" header domain and DKIM is too 2255 tight for ADSP; they must match exactly. 2257 A.6. Organizational Domain Discovery Issues 2259 An earlier informational version of the DMARC protocol [RFC7489] 2260 noted that the DNS does not provide a method by which the "domain of 2261 record", or the domain that was actually registered with a domain 2262 registrar, can be determined given an arbitrary domain name. That 2263 version further mentioned suggestions that have been made that 2264 attempt to glean such information from SOA or NS resource records, 2265 but these too are not fully reliable, as the partitioning of the DNS 2266 is not always done at administrative boundaries. 2268 That previous version posited that one could "climb the tree" to find 2269 the Organizational Domain, but expressed concern that an attacker 2270 could exploit this for a denial-of-service attack through sending a 2271 high number of messages each with a relatively large number of 2272 nonsense labels, causing a Mail Receiver to perform a large number of 2273 DNS queries in search of a policy record. This version defines a 2274 method for performing a DNS Tree Walk, described in Section 4.6, and 2275 further mitigates the risk of the denial-of-service attack by 2276 expressly limiting the number of DNS queries to execute regardless of 2277 the number of labels in the domain name. 2279 As a matter of historical record, the method for finding the 2280 Organizational Domain described in [RFC7489] is preserved here: 2282 1. Acquire a "public suffix" list (PSL), i.e., a list of DNS domain 2283 names reserved for registrations. Some country Top-Level Domains 2284 (TLDs) make specific registration requirements, e.g., the United 2285 Kingdom places company registrations under ".co.uk"; other TLDs 2286 such as ".com" appear in the IANA registry of top-level DNS 2287 domains. A PSL is the union of all of these. 2289 A PSL can be obtained from various sources. The most common one 2290 is maintained by the Mozilla Foundation and made public at 2291 http://publicsuffix.org (http://publicsuffix.org). License terms 2292 governing the use of that list are available at that URI. 2294 Note that if operators use a variety of public suffix lists, 2295 interoperability will be difficult or impossible to guarantee. 2297 2. Break the subject DNS domain name into a set of "n" ordered 2298 labels. Number these labels from right to left; e.g., for 2299 "example.com", "com" would be label 1 and "example" would be 2300 label 2. 2302 3. Search the public suffix list for the name that matches the 2303 largest number of labels found in the subject DNS domain. Let 2304 that number be "x". 2306 4. Construct a new DNS domain name using the name that matched from 2307 the public suffix list and prefixing to it the "x+1"th label from 2308 the subject domain. This new name is the Organizational Domain. 2310 Thus, since "com" is an IANA-registered TLD, a subject domain of 2311 "a.b.c.d.example.com" would have an Organizational Domain of 2312 "example.com". 2314 The process of determining a suffix is currently a heuristic one. No 2315 list is guaranteed to be accurate or current. 2317 A.7. Removal of the "pct" Tag 2319 An earlier informational version of the DMARC protocol [RFC7489] 2320 included a "pct" tag and specified all integers from 0 to 100 2321 inclusive as valid values for the tag. The intent of the tag was to 2322 provide domain owners with a method to gradually change their 2323 preferred assessment policy (the p= tag) from 'none' to 'quarantine' 2324 or from 'quarantine' to 'reject' by requesting the stricter treatment 2325 for just a percentage of messages that produced DMARC results of 2326 "fail". 2328 Operational experience showed that the pct tag was usually not 2329 accurately applied, unless the value specified was either "0" or 2330 "100" (the default), and the inaccuracies with other values varied 2331 widely from implementation to implementation. The default value was 2332 easily implemented, as it required no special processing on the part 2333 of the Mail Receiver, while the value of "0" took on unintended 2334 significance as a value used by some intermediaries and mailbox 2335 providers as an indicator to deviate from standard handling of the 2336 message, usually by rewriting the RFC5322.From header in an effort to 2337 avoid DMARC failures downstream. 2339 These custom actions when the pct= tag was set to "0" proved valuable 2340 to the email community. In particular, header rewriting by an 2341 intermediary meant that a Domain Owner's aggregate reports could 2342 reveal to the Domain Owner how much of its traffic was routing 2343 through intermediaries that don't rewrite the RFC5322.From header. 2344 It required work on the part of the Domain Owner to compare aggregate 2345 reports from before and after the p= value was changed and pct= was 2346 included in the DMARC policy record with a value of "0", but the data 2347 was there. Consequently, knowing how much mail was subject to 2348 possible DMARC failure due to lack of RFC5322.From header rewriting 2349 by intermediaries could assist the Domain Owner in choosing whether 2350 or not to proceed from an applied policy of p=none to p=quarantine or 2351 p=reject. Armed with this knowledge, the Domain Owner could make an 2352 informed decision regarding subjecting its mail traffic to possible 2353 DMARC failures based on the Domain Owner's tolerance for such things. 2355 Because of the value provided by "pct=0" to Domain Owners, it was 2356 logical to keep this functionality in the protocol; at the same time 2357 it didn't make sense to support a tag named "pct" that had only two 2358 valid values. This version of the DMARC protocol therefore 2359 introduces the "t" tag as shorthand for "testing", with the valid 2360 values of "y" and "n", which are meant to be analogous in their 2361 application by mailbox providers and intermediaries to the "pct" tag 2362 values "0" and "100", respectively. 2364 Appendix B. Examples 2366 This section illustrates both the Domain Owner side and the Mail 2367 Receiver side of a DMARC exchange. 2369 B.1. Identifier Alignment Examples 2371 The following examples illustrate the DMARC mechanism's use of 2372 Identifier Alignment. For brevity's sake, only message headers are 2373 shown, as message bodies are not considered when conducting DMARC 2374 checks. 2376 B.1.1. SPF 2378 The following SPF examples assume that SPF produces a passing result. 2379 Alignment cannot exist if SPF does not produce a passing result. 2381 Example 1: SPF in alignment: 2383 MAIL FROM: 2385 From: sender@example.com 2386 Date: Fri, Feb 15 2002 16:54:30 -0800 2387 To: receiver@example.org 2388 Subject: here's a sample 2390 In this case, the RFC5321.MailFrom parameter and the RFC5322.From 2391 header field have identical DNS domains. Thus, the identifiers are 2392 in strict alignment. 2394 Example 2: SPF in alignment (parent): 2396 MAIL FROM: 2398 From: sender@example.com 2399 Date: Fri, Feb 15 2002 16:54:30 -0800 2400 To: receiver@example.org 2401 Subject: here's a sample 2403 In this case, the RFC5322.From header parameter includes a DNS domain 2404 that is a parent of the RFC5321.MailFrom domain. Thus, the 2405 identifiers are in relaxed alignment, because they both have the same 2406 Organizational Domain (example.com). 2408 Example 3: SPF not in alignment: 2410 MAIL FROM: 2412 From: sender@child.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 RFC5321.MailFrom parameter includes a DNS domain 2418 that is neither the same as, a parent of, nor a child of the 2419 RFC5322.From domain. Thus, the identifiers are not in alignment. 2421 B.1.2. DKIM 2423 The examples below assume that the DKIM signatures pass verification. 2424 Alignment cannot exist with a DKIM signature that does not verify. 2426 Example 1: DKIM in alignment: 2428 DKIM-Signature: v=1; ...; d=example.com; ... 2429 From: sender@example.com 2430 Date: Fri, Feb 15 2002 16:54:30 -0800 2431 To: receiver@example.org 2432 Subject: here's a sample 2434 In this case, the DKIM "d=" parameter and the RFC5322.From header 2435 field have identical DNS domains. Thus, the identifiers are in 2436 strict alignment. 2438 Example 2: DKIM in alignment (parent): 2440 DKIM-Signature: v=1; ...; d=example.com; ... 2441 From: sender@child.example.com 2442 Date: Fri, Feb 15 2002 16:54:30 -0800 2443 To: receiver@example.org 2444 Subject: here's a sample 2446 In this case, the DKIM signature's "d=" parameter includes a DNS 2447 domain that is a parent of the RFC5322.From domain. Thus, the 2448 identifiers are in relaxed alignment, as they have the same 2449 Organizational Domain (example.com). 2451 Example 3: DKIM not in alignment: 2453 DKIM-Signature: v=1; ...; d=sample.net; ... 2454 From: sender@child.example.com 2455 Date: Fri, Feb 15 2002 16:54:30 -0800 2456 To: receiver@example.org 2457 Subject: here's a sample 2459 In this case, the DKIM signature's "d=" parameter includes a DNS 2460 domain that is neither the same as, a parent of, nor a child of the 2461 RFC5322.From domain. Thus, the identifiers are not in alignment. 2463 B.2. Domain Owner Example 2465 A Domain Owner that wants to use DMARC should have already deployed 2466 and tested SPF and DKIM. The next step is to publish a DNS record 2467 that advertises a DMARC policy for the Domain Owner's Organizational 2468 Domain. 2470 B.2.1. Entire Domain, Monitoring Only 2472 The owner of the domain "example.com" has deployed SPF and DKIM on 2473 its messaging infrastructure. The owner wishes to begin using DMARC 2474 with a policy that will solicit aggregate feedback from Mail 2475 Receivers without affecting how the messages are processed, in order 2476 to: 2478 * Confirm that its legitimate messages are authenticating correctly 2480 * Verify that all authorized message sources have implemented 2481 authentication measures 2483 * Determine how many messages from other sources would be affected 2484 by a blocking policy 2486 The Domain Owner accomplishes this by constructing a policy record 2487 indicating that: 2489 * The version of DMARC being used is "DMARC1" ("v=DMARC1;") 2491 * Mail Receivers should not alter how they treat these messages 2492 because of this DMARC policy record ("p=none") 2494 * Aggregate feedback reports should be sent via email to the address 2495 "dmarc-feedback@example.com" ("rua=mailto:dmarc- 2496 feedback@example.com") 2498 * All messages from this Organizational Domain are subject to this 2499 policy (no "t" tag present, so the default of "n" applies). 2501 The DMARC policy record might look like this when retrieved using a 2502 common command-line tool: 2504 % dig +short TXT _dmarc.example.com. 2505 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com" 2507 To publish such a record, the DNS administrator for the Domain Owner 2508 creates an entry like the following in the appropriate zone file 2509 (following the conventional zone file format): 2511 ; DMARC record for the domain example.com 2513 _dmarc IN TXT ( "v=DMARC1; p=none; " 2514 "rua=mailto:dmarc-feedback@example.com" ) 2516 B.2.2. Entire Domain, Monitoring Only, Per-Message Reports 2518 The Domain Owner from the previous example has used the aggregate 2519 reporting to discover some messaging systems that had not yet 2520 implemented DKIM correctly, but they are still seeing periodic 2521 authentication failures. In order to diagnose these intermittent 2522 problems, they wish to request per-message failure reports when 2523 authentication failures occur. 2525 Not all Mail Receivers will honor such a request, but the Domain 2526 Owner feels that any reports it does receive will be helpful enough 2527 to justify publishing this record. The default per-message report 2528 format ([RFC6591]) meets the Domain Owner's needs in this scenario. 2530 The Domain Owner accomplishes this by adding the following to its 2531 policy record from Appendix B.2.1: 2533 * Per-message failure reports should be sent via email to the 2534 address "auth-reports@example.com" ("ruf=mailto:auth- 2535 reports@example.com") 2537 The DMARC policy record might look like this when retrieved using a 2538 common command-line tool (the output shown would appear on a single 2539 line but is wrapped here for publication): 2541 % dig +short TXT _dmarc.example.com. 2542 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; 2543 ruf=mailto:auth-reports@example.com" 2545 To publish such a record, the DNS administrator for the Domain Owner 2546 might create an entry like the following in the appropriate zone file 2547 (following the conventional zone file format): 2549 ; DMARC record for the domain example.com 2551 _dmarc IN TXT ( "v=DMARC1; p=none; " 2552 "rua=mailto:dmarc-feedback@example.com; " 2553 "ruf=mailto:auth-reports@example.com" ) 2555 B.2.3. Per-Message Failure Reports Directed to Third Party 2557 The Domain Owner from the previous example is maintaining the same 2558 policy but now wishes to have a third party serve as a Report 2559 Consumer. Again, not all Mail Receivers will honor this request, but 2560 those that do may implement additional checks to verify that the 2561 third party wishes to receive the failure reports for this domain. 2563 The Domain Owner needs to alter its policy record from Appendix B.2.2 2564 as follows: 2566 * Per-message failure reports should be sent via email to the 2567 address "auth-reports@thirdparty.example.net" ("ruf=mailto:auth- 2568 reports@thirdparty.example.net") 2570 The DMARC policy record might look like this when retrieved using a 2571 common command-line tool (the output shown would appear on a single 2572 line but is wrapped here for publication): 2574 % dig +short TXT _dmarc.example.com. 2575 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; 2576 ruf=mailto:auth-reports@thirdparty.example.net" 2578 To publish such a record, the DNS administrator for the Domain Owner 2579 might create an entry like the following in the appropriate zone file 2580 (following the conventional zone file format): 2582 ; DMARC record for the domain example.com 2584 _dmarc IN TXT ( "v=DMARC1; p=none; " 2585 "rua=mailto:dmarc-feedback@example.com; " 2586 "ruf=mailto:auth-reports@thirdparty.example.net" ) 2588 Because the address used in the "ruf" tag is outside the 2589 Organizational Domain in which this record is published, conforming 2590 Mail Receivers will implement additional checks as described in 2591 Section 3 of [DMARC-Aggregate-Reporting]. In order to pass these 2592 additional checks, the Report Consumer's Domain Owner will need to 2593 publish an additional DNS record as follows: 2595 * Given the DMARC record published by the Domain Owner at 2596 "_dmarc.example.com", the DNS administrator for the Report 2597 Consumer will need to publish a TXT resource record at 2598 "example.com._report._dmarc.thirdparty.example.net" with the value 2599 "v=DMARC1;". 2601 The resulting DNS record might look like this when retrieved using a 2602 common command-line tool (the output shown would appear on a single 2603 line but is wrapped here for publication): 2605 % dig +short TXT example.com._report._dmarc.thirdparty.example.net 2606 "v=DMARC1;" 2608 To publish such a record, the DNS administrator for example.net might 2609 create an entry like the following in the appropriate zone file 2610 (following the conventional zone file format): 2612 ; zone file for thirdparty.example.net 2613 ; Accept DMARC failure reports on behalf of example.com 2615 example.com._report._dmarc IN TXT "v=DMARC1;" 2617 Mediators and other third parties should refer to Section 3 of 2618 [DMARC-Aggregate-Reporting] for the full details of this mechanism. 2620 B.2.4. Subdomain, Testing, and Multiple Aggregate Report URIs 2622 The Domain Owner has implemented SPF and DKIM in a subdomain used for 2623 pre-production testing of messaging services. It now wishes to 2624 express a handling preference for messages from this subdomain that 2625 fail to authenticate to indicate to participating Mail Receivers that 2626 use of this domain is not valid. 2628 As a first step, it will express that it considers to be suspicious 2629 messages using this subdomain that fail authentication. The goal 2630 here will be to enable examination of messages sent to mailboxes 2631 hosted by participating Mail Receivers as method for troubleshooting 2632 any existing authentication issues. Aggregate feedback reports will 2633 be sent to a mailbox within the Organizational Domain, and to a 2634 mailbox at a Report Consumer selected and authorized to receive same 2635 by the Domain Owner. 2637 The Domain Owner will accomplish this by constructing a policy record 2638 indicating that: 2640 * The version of DMARC being used is "DMARC1" ("v=DMARC1;") 2642 * It is applied only to this subdomain (record is published at 2643 "_dmarc.test.example.com" and not "_dmarc.example.com") 2645 * Mail Receivers are advised that the Domain Owner considers 2646 messages that fail to authenticate to be suspicious 2647 ("p=quarantine") 2649 * Aggregate feedback reports should be sent via email to the 2650 addresses "dmarc-feedback@example.com" and "example-tld- 2651 test@thirdparty.example.net" ("rua=mailto:dmarc- 2652 feedback@example.com, mailto:tld-test@thirdparty.example.net") 2654 * The Domain Owner desires only that an actor performing a DMARC 2655 verification check apply any special handling rules it might have 2656 in place, such as rewriting the RFC53322.From header; the Domain 2657 Owner is testing its setup at this point, and so does not want the 2658 handling policy to be applied. ("t=y") 2660 The DMARC policy record might look like this when retrieved using a 2661 common command-line tool (the output shown would appear on a single 2662 line but is wrapped here for publication): 2664 % dig +short TXT _dmarc.test.example.com 2665 "v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com, 2666 mailto:tld-test@thirdparty.example.net; t=y" 2668 To publish such a record, the DNS administrator for the Domain Owner 2669 might create an entry like the following in the appropriate zone 2670 file: 2672 ; DMARC record for the domain test.example.com 2674 _dmarc IN TXT ( "v=DMARC1; p=quarantine; " 2675 "rua=mailto:dmarc-feedback@example.com," 2676 "mailto:tld-test@thirdparty.example.net;" 2677 "t=y" ) 2679 Once enough time has passed to allow for collecting enough reports to 2680 give the Domain Owner confidence that all legitimate email sent using 2681 the subdomain is properly authenticating and passing DMARC checks, 2682 then the Domain Owner can update the policy record to indicate that 2683 it considers authentication failures to be a clear indication that 2684 use of the subdomain is not valid. It would do this by altering the 2685 DNS record to advise Mail Receivers of its position on such messages 2686 ("p=reject") and removing the testing flag ("t=y"). 2688 After alteration, the DMARC policy record might look like this when 2689 retrieved using a common command-line tool (the output shown would 2690 appear on a single line but is wrapped here for publication): 2692 % dig +short TXT _dmarc.test.example.com 2693 "v=DMARC1; p=reject; rua=mailto:dmarc-feedback@example.com, 2694 mailto:tld-test@thirdparty.example.net" 2696 To publish such a record, the DNS administrator for the Domain Owner 2697 might create an entry like the following in the appropriate zone 2698 file: 2700 ; DMARC record for the domain test.example.com 2702 _dmarc IN TXT ( "v=DMARC1; p=reject; " 2703 "rua=mailto:dmarc-feedback@example.com," 2704 "mailto:tld-test@thirdparty.example.net" ) 2706 B.3. Mail Receiver Example 2708 A Mail Receiver that wants to use DMARC should already be checking 2709 SPF and DKIM, and possess the ability to collect relevant information 2710 from various email-processing stages to provide feedback to Domain 2711 Owners (possibly via Report Consumers). 2713 B.3.1. SMTP Session Example 2715 An optimal DMARC-enabled Mail Receiver performs authentication and 2716 Identifier Alignment checking during the SMTP [RFC5321] conversation. 2718 Prior to returning a final reply to the DATA command, the Mail 2719 Receiver's MTA has performed: 2721 1. An SPF check to determine an SPF-authenticated Identifier. 2723 2. DKIM checks that yield one or more DKIM-authenticated 2724 Identifiers. 2726 3. A DMARC policy lookup. 2728 The presence of an Author Domain DMARC record indicates that the Mail 2729 Receiver should continue with DMARC-specific processing before 2730 returning a reply to the DATA command. 2732 Given a DMARC record and the set of Authenticated Identifiers, the 2733 Mail Receiver checks to see if the Authenticated Identifiers align 2734 with the Author Domain (taking into consideration any strict versus 2735 relaxed options found in the DMARC record). 2737 For example, the following sample data is considered to be from a 2738 piece of email originating from the Domain Owner of "example.com": 2740 Author Domain: example.com 2741 SPF-authenticated Identifier: mail.example.com 2742 DKIM-authenticated Identifier: example.com 2743 DMARC record: 2744 "v=DMARC1; p=reject; aspf=r; 2745 rua=mailto:dmarc-feedback@example.com" 2747 In the above sample, both the SPF-authenticated Identifier and the 2748 DKIM-authenticated Identifier align with the Author Domain. The Mail 2749 Receiver considers the above email to pass the DMARC check, avoiding 2750 the "reject" policy that is requested to be applied to email that 2751 fails to pass the DMARC check. 2753 If no Authenticated Identifiers align with the Author Domain, then 2754 the Mail Receiver applies the DMARC-record-specified policy. 2755 However, before this action is taken, the Mail Receiver can consult 2756 external information to override the Domain Owner's Assessment 2757 Policy. For example, if the Mail Receiver knows that this particular 2758 email came from a known and trusted forwarder (that happens to break 2759 both SPF and DKIM), then the Mail Receiver may choose to ignore the 2760 Domain Owner's policy. 2762 The Mail Receiver is now ready to reply to the DATA command. If the 2763 DMARC check yields that the message is to be rejected, then the Mail 2764 Receiver replies with a 5xy code to inform the sender of failure. If 2765 the DMARC check cannot be resolved due to transient network errors, 2766 then the Mail Receiver replies with a 4xy code to inform the sender 2767 as to the need to reattempt delivery later. If the DMARC check 2768 yields a passing message, then the Mail Receiver continues on with 2769 email processing, perhaps using the result of the DMARC check as an 2770 input to additional processing modules such as a domain reputation 2771 query. 2773 Before exiting DMARC-specific processing, the Mail Receiver checks to 2774 see if the Author Domain DMARC record requests AFRF-based reporting. 2775 If so, then the Mail Receiver can emit an AFRF to the reporting 2776 address supplied in the DMARC record. 2778 At the exit of DMARC-specific processing, the Mail Receiver captures 2779 (through logging or direct insertion into a data store) the result of 2780 DMARC processing. Captured information is used to build feedback for 2781 Domain Owner consumption. This is not necessary if the Domain Owner 2782 has not requested aggregate reports, i.e., no "rua" tag was found in 2783 the policy record. 2785 B.4. Utilization of Aggregate Feedback: Example 2787 Aggregate feedback is consumed by Domain Owners to verify their 2788 understanding of how a given domain is being processed by the Mail 2789 Receiver. Aggregate reporting data on emails that pass all DMARC- 2790 supporting authentication checks is used by Domain Owners to verify 2791 that their authentication practices remain accurate. For example, if 2792 a third party is sending on behalf of a Domain Owner, the Domain 2793 Owner can use aggregate report data to verify ongoing authentication 2794 practices of the third party. 2796 Data on email that only partially passes underlying authentication 2797 checks provides visibility into problems that need to be addressed by 2798 the Domain Owner. For example, if either SPF or DKIM fails to pass, 2799 the Domain Owner is provided with enough information to either 2800 directly correct the problem or understand where authentication- 2801 breaking changes are being introduced in the email transmission path. 2802 If authentication-breaking changes due to email transmission path 2803 cannot be directly corrected, then the Domain Owner at least 2804 maintains an understanding of the effect of DMARC-based policies upon 2805 the Domain Owner's email. 2807 Data on email that fails all underlying authentication checks 2808 provides baseline visibility on how the Domain Owner's domain is 2809 being received at the Mail Receiver. Based on this visibility, the 2810 Domain Owner can begin deployment of authentication technologies 2811 across uncovered email sources, if the mail that is failing the 2812 checks was generated by or on behalf of the Domain Owner. Data 2813 regarding failing authentication checks can also allow the Domain 2814 Owner to come to an understanding of how its domain is being misused. 2816 Acknowledgements 2818 DMARC and the draft version of this document submitted to the 2819 Independent Submission Editor were the result of lengthy efforts by 2820 an informal industry consortium: DMARC.org (see http://dmarc.org 2821 (http://dmarc.org)). Participating companies included Agari, 2822 American Greetings, AOL, Bank of America, Cloudmark, Comcast, 2823 Facebook, Fidelity Investments, Google, JPMorgan Chase & Company, 2824 LinkedIn, Microsoft, Netease, PayPal, ReturnPath, The Trusted Domain 2825 Project, and Yahoo!. Although the contributors and supporters are 2826 too numerous to mention, notable individual contributions were made 2827 by J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim 2828 Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen. 2829 The contributors would also like to recognize the invaluable input 2830 and guidance that was provided early on by J.D. Falk. 2832 Additional contributions within the IETF context were made by Kurt 2833 Anderson, Michael Jack Assels, Les Barstow, Anne Bennett, Jim Fenton, 2834 J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine, S. 2835 Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull. 2837 Authors' Addresses 2839 Todd M. Herr 2840 Valimail 2841 Email: todd.herr@valimail.com 2843 John Levine 2844 Standcore LLC 2845 Email: standards@standore.com