idnits 2.17.1 draft-ietf-dmarc-dmarcbis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 November 2020) is 1257 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC E. Gustafsson (ed) 3 Internet-Draft Google 4 Obsoletes: 7489 (if approved) T. Herr (ed) 5 Intended status: Standards Track Valimail 6 Expires: 14 May 2021 J. Levine (ed) 7 Standcore LLC 8 10 November 2020 10 Domain-based Message Authentication, Reporting, and Conformance (DMARC) 11 draft-ietf-dmarc-dmarcbis-00 13 Abstract 15 This document describes the Domain-based Message Authentication, 16 Reporting, and Conformance (DMARC) protocol. 18 DMARC is a scalable mechanism by which a mail-originating 19 organization can express domain-level policies and preferences for 20 message validation, disposition, and reporting. Mail-receiving 21 organizations can in turn use these expressions of policies and 22 preferences to inform their mail handling decisions should they 23 choose to do so. 25 This document obsoletes RFC 7489. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 14 May 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. High-Level Goals . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 5 64 2.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.4. Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 67 3.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 8 68 3.1.1. DKIM-Authenticated Identifiers . . . . . . . . . . . 9 69 3.1.2. SPF-Authenticated Identifiers . . . . . . . . . . . . 9 70 3.1.3. Alignment and Extension Technologies . . . . . . . . 10 71 3.2. Organizational Domain . . . . . . . . . . . . . . . . . . 10 72 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.1. Authentication Mechanisms . . . . . . . . . . . . . . . . 11 74 4.2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . 11 75 4.3. Flow Diagram . . . . . . . . . . . . . . . . . . . . . . 12 76 5. Use of RFC5322.From . . . . . . . . . . . . . . . . . . . . . 14 77 6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 6.1. DMARC Policy Record . . . . . . . . . . . . . . . . . . . 16 79 6.2. DMARC URIs . . . . . . . . . . . . . . . . . . . . . . . 16 80 6.3. General Record Format . . . . . . . . . . . . . . . . . . 17 81 6.4. Formal Definition . . . . . . . . . . . . . . . . . . . . 20 82 6.5. Domain Owner Actions . . . . . . . . . . . . . . . . . . 22 83 6.6. Mail Receiver Actions . . . . . . . . . . . . . . . . . . 22 84 6.6.1. Extract Author Domain . . . . . . . . . . . . . . . . 22 85 6.6.2. Determine Handling Policy . . . . . . . . . . . . . . 23 86 6.6.3. Policy Discovery . . . . . . . . . . . . . . . . . . 24 87 6.6.4. Message Sampling . . . . . . . . . . . . . . . . . . 26 88 6.6.5. Store Results of DMARC Processing . . . . . . . . . . 26 89 6.7. Policy Enforcement Considerations . . . . . . . . . . . . 26 90 7. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . 28 91 8. Minimum Implementations . . . . . . . . . . . . . . . . . . . 28 92 9. Other Topics . . . . . . . . . . . . . . . . . . . . . . . . 28 93 9.1. Issues Specific to SPF . . . . . . . . . . . . . . . . . 28 94 9.2. DNS Load and Caching . . . . . . . . . . . . . . . . . . 29 95 9.3. Rejecting Messages . . . . . . . . . . . . . . . . . . . 29 96 9.4. Identifier Alignment Considerations . . . . . . . . . . . 30 97 9.5. Interoperability Issues . . . . . . . . . . . . . . . . . 30 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 99 10.1. Authentication-Results Method Registry Update . . . . . 31 100 10.2. Authentication-Results Result Registry Update . . . . . 31 101 10.3. Feedback Report Header Fields Registry Update . . . . . 33 102 10.4. DMARC Tag Registry . . . . . . . . . . . . . . . . . . . 33 103 10.5. DMARC Report Format Registry . . . . . . . . . . . . . . 34 104 10.6. Underscored and Globally Scoped DNS Node Names 105 Registry . . . . . . . . . . . . . . . . . . . . . . . . 35 106 11. Security Considerations . . . . . . . . . . . . . . . . . . . 35 107 11.1. Authentication Methods . . . . . . . . . . . . . . . . . 35 108 11.2. Attacks on Reporting URIs . . . . . . . . . . . . . . . 36 109 11.3. DNS Security . . . . . . . . . . . . . . . . . . . . . . 36 110 11.4. Display Name Attacks . . . . . . . . . . . . . . . . . . 36 111 11.5. External Reporting Addresses . . . . . . . . . . . . . . 37 112 11.6. Secure Protocols . . . . . . . . . . . . . . . . . . . . 38 113 12. Normative References . . . . . . . . . . . . . . . . . . . . 38 114 13. Informative References . . . . . . . . . . . . . . . . . . . 39 115 Appendix A. Technology Considerations . . . . . . . . . . . . . 41 116 A.1. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 41 117 A.2. Method Exclusion . . . . . . . . . . . . . . . . . . . . 41 118 A.3. Sender Header Field . . . . . . . . . . . . . . . . . . . 42 119 A.4. Domain Existence Test . . . . . . . . . . . . . . . . . . 43 120 A.5. Issues with ADSP in Operation . . . . . . . . . . . . . . 43 121 A.6. Organizational Domain Discovery Issues . . . . . . . . . 44 122 A.6.1. Public Suffix Lists . . . . . . . . . . . . . . . . . 45 123 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 45 124 B.1. Identifier Alignment Examples . . . . . . . . . . . . . . 45 125 B.1.1. SPF . . . . . . . . . . . . . . . . . . . . . . . . . 45 126 B.1.2. DKIM . . . . . . . . . . . . . . . . . . . . . . . . 46 127 B.2. Domain Owner Example . . . . . . . . . . . . . . . . . . 47 128 B.2.1. Entire Domain, Monitoring Only . . . . . . . . . . . 47 129 B.2.2. Entire Domain, Monitoring Only, Per-Message 130 Reports . . . . . . . . . . . . . . . . . . . . . . . 48 131 B.2.3. Per-Message Failure Reports Directed to Third 132 Party . . . . . . . . . . . . . . . . . . . . . . . . 49 133 B.2.4. Subdomain, Sampling, and Multiple Aggregate Report 134 URIs . . . . . . . . . . . . . . . . . . . . . . . . 50 135 B.3. Mail Receiver Example . . . . . . . . . . . . . . . . . . 51 136 B.4. Processing of SMTP Time . . . . . . . . . . . . . . . . . 51 137 B.5. Utilization of Aggregate Feedback: Example . . . . . . . 53 138 B.6. mailto Transport Example . . . . . . . . . . . . . . . . 54 139 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 55 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 142 1. Introduction 144 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: 145 The source for this draft is maintained in GitHub at: 146 https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis 147 (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis) 149 The Sender Policy Framework ([RFC7208]) and DomainKeys Identified 150 Mail ([RFC6376]) protocols provide domain-level authentication, and 151 DMARC builds on these protocols. DMARC is designed to give 152 ADminstrative Management Domains (ADMDs) that originate email the 153 ability to publish in a DNS TXT record their email authentication 154 policies, specify preferred handling for mail that fails 155 authentication checks, and request reports about mail purportedly 156 originated by the ADMD, as determined by the RFC5322.From header in 157 the message. 159 As with SPF and DKIM, DMARC authentication checks result in verdicts 160 of "pass" or "fail". A DMARC pass verdict requires not only that SPF 161 or DKIM pass for the message in question, but also that the domain 162 validated by the SPF or DKIM check is aligned with the domain in the 163 RFC5322.From header. In the DMARC protocol, two domains are said to 164 be "in alignment" if they have the same Organizational Domain 165 (a.k.a., relaxed alignment) or they are identical (a.k.a., strict 166 alignment). 168 A DMARC pass verdict asserts only that the RFC5322.From domain has 169 been authenticated in that message; there is no explicit or implied 170 value assertion attributed to a message that receives such a verdict. 171 A mail-receiving organization that performs DMARC validation checks 172 on inbound mail can choose to use the results and the preferences 173 expressed by the originating domain for message disposition to inform 174 its mail handling decision for that message. For messages that pass 175 DMARC validation checks, the mail-receiving organization can be 176 confident in applying handling based on its known history for 177 similarly authenticated messages, whereas messages that fail such 178 checks cannot be reliably associated with a domain with a history of 179 sending DMARC-validated messages. 181 DMARC also describes a reporting framework in which mail-receiving 182 domains can generate regular reports containing data about messages 183 seen that claim to be from domains that publish DMARC policies, and 184 send those reports to the ADMD as requested by its DMARC policy 185 record. 187 Experience with DMARC has revealed some issues of interoperability 188 with email in general that require due consideration before 189 deployment, particularly with configurations that can cause mail to 190 be rejected. These are discussed in Section 9. 192 2. Requirements 194 Specification of DMARC is guided by the following high-level goals, 195 security dependencies, detailed requirements, and items that are 196 documented as out of scope. 198 2.1. High-Level Goals 200 DMARC has the following high-level goals: 202 * Allow Domain Owners to assert the preferred handling of 203 authentication failures, for messages purporting to have 204 authorship within the domain. 206 * Allow Domain Owners to verify their authentication deployment. 208 * Minimize implementation complexity for both senders and receivers, 209 as well as the impact on handling and delivery of legitimate 210 messages. 212 * Reduce the amount of successfully delivered spoofed email. 214 * Work at Internet scale. 216 2.2. Out of Scope 218 Several topics and issues are specifically out of scope for the 219 initial version of this work. These include the following: 221 * different treatment of messages that are not authenticated versus 222 those that fail authentication; 224 * evaluation of anything other than RFC5322.From; 226 * multiple reporting formats; 228 * publishing policy other than via the DNS; 230 * reporting or otherwise evaluating other than the last-hop IP 231 address; 233 * attacks in the RFC5322.From field, also known as "display name" 234 attacks; 236 * authentication of entities other than domains, since DMARC is 237 built upon SPF and DKIM, which authenticate domains; and 239 * content analysis. 241 2.3. Scalability 243 Scalability is a major issue for systems that need to operate in a 244 system as widely deployed as current SMTP email. For this reason, 245 DMARC seeks to avoid the need for third parties or pre-sending 246 agreements between senders and receivers. This preserves the 247 positive aspects of the current email infrastructure. 249 Although DMARC does not introduce third-party senders (namely 250 external agents authorized to send on behalf of an operator) to the 251 email-handling flow, it also does not preclude them. Such third 252 parties are free to provide services in conjunction with DMARC. 254 2.4. Anti-Phishing 256 DMARC is designed to prevent bad actors from sending mail that claims 257 to come from legitimate senders, particularly senders of 258 transactional email (official mail that is about business 259 transactions). One of the primary uses of this kind of spoofed mail 260 is phishing (enticing users to provide information by pretending to 261 be the legitimate service requesting the information). Thus, DMARC 262 is significantly informed by ongoing efforts to enact large-scale, 263 Internet-wide anti-phishing measures. 265 Although DMARC can only be used to combat specific forms of exact- 266 domain spoofing directly, the DMARC mechanism has been found to be 267 useful in the creation of reliable and defensible message streams. 269 DMARC does not attempt to solve all problems with spoofed or 270 otherwise fraudulent email. In particular, it does not address the 271 use of visually similar domain names ("cousin domains") or abuse of 272 the RFC5322.From human-readable . 274 3. Terminology and Definitions 276 This section defines terms used in the rest of the document. 278 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 279 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 280 "OPTIONAL" in this document are to be interpreted as described in BCP 281 14 [RFC2119] [RFC8174] when, and only when, they appear in all 282 capitals, as shown here. 284 Readers are encouraged to be familiar with the contents of [RFC5598]. 285 In particular, that document defines various roles in the messaging 286 infrastructure that can appear the same or separate in various 287 contexts. For example, a Domain Owner could, via the messaging 288 security mechanisms on which DMARC is based, delegate the ability to 289 send mail as the Domain Owner to a third party with another role. 290 This document does not address the distinctions among such roles; the 291 reader is encouraged to become familiar with that material before 292 continuing. 294 The following terms are also used: 296 Authenticated Identifiers: Domain-level identifiers that are 297 validated using authentication technologies are referred to as 298 "Authenticated Identifiers". See Section 4.1 for details about 299 the supported mechanisms. 301 Author Domain: The domain name of the apparent author, as extracted 302 from the RFC5322.From field. 304 Domain Owner: An entity or organization that owns a DNS domain. The 305 term "owns" here indicates that the entity or organization being 306 referenced holds the registration of that DNS domain. Domain 307 Owners range from complex, globally distributed organizations, to 308 service providers working on behalf of non-technical clients, to 309 individuals responsible for maintaining personal domains. This 310 specification uses this term as analogous to an Administrative 311 Management Domain as defined in [RFC5598]. It can also refer to 312 delegates, such as Report Receivers, when those are outside of 313 their immediate management domain. 315 Identifier Alignment: When the domain in the RFC5322.From address 316 matches a domain validated by SPF or DKIM (or both), it has 317 Identifier Alignment. 319 Mail Receiver: The entity or organization that receives and 320 processes email. Mail Receivers operate one or more Internet- 321 facing Mail Transport Agents (MTAs). 323 Organizational Domain: The domain that was registered with a domain 324 name registrar. In the absence of more accurate methods, 325 heuristics are used to determine this, since it is not always the 326 case that the registered domain name is simply a top-level DNS 327 domain plus one component (e.g., "example.com", where "com" is a 328 top-level domain). The Organizational Domain is determined by 329 applying the algorithm found in Section 3.2. 331 Report Receiver: An operator that receives reports from another 332 operator implementing the reporting mechanism described in this 333 document. Such an operator might be receiving reports about its 334 own messages, or reports about messages related to another 335 operator. This term applies collectively to the system components 336 that receive and process these reports and the organizations that 337 operate them. 339 3.1. Identifier Alignment 341 Email authentication technologies authenticate various (and 342 disparate) aspects of an individual message. For example, [RFC6376] 343 authenticates the domain that affixed a signature to the message, 344 while [RFC7208] can authenticate either the domain that appears in 345 the RFC5321.MailFrom (MAIL FROM) portion of [RFC5322] or the 346 RFC5321.EHLO/ HELO domain, or both. These may be different domains, 347 and they are typically not visible to the end user. 349 DMARC authenticates use of the RFC5322.From domain by requiring that 350 it match (be aligned with) an Authenticated Identifier. The 351 RFC5322.From domain was selected as the central identity of the DMARC 352 mechanism because it is a required message header field and therefore 353 guaranteed to be present in compliant messages, and most Mail User 354 Agents (MUAs) represent the RFC5322.From field as the originator of 355 the message and render some or all of this header field's content to 356 end users. 358 Thus, this field is the one used by end users to identify the source 359 of the message and therefore is a prime target for abuse. Many high- 360 profile email sources, such as email service providers, require that 361 the sending agent have authenticated before email can be generated. 362 Thus, for these mailboxes, the mechanism described in this document 363 provides recipient end users with strong evidence that the message 364 was indeed originated by the agent they associate with that mailbox, 365 if the end user knows that these various protections have been 366 provided. 368 Domain names in this context are to be compared in a case-insensitive 369 manner, per [RFC4343]. 371 It is important to note that Identifier Alignment cannot occur with a 372 message that is not valid per [RFC5322], particularly one with a 373 malformed, absent, or repeated RFC5322.From field, since in that case 374 there is no reliable way to determine a DMARC policy that applies to 375 the message. Accordingly, DMARC operation is predicated on the input 376 being a valid RFC5322 message object, and handling of such non- 377 compliant cases is outside of the scope of this specification. 378 Further discussion of this can be found in Section 6.6.1. 380 Each of the underlying authentication technologies that DMARC takes 381 as input yields authenticated domains as their outputs when they 382 succeed. From the perspective of DMARC, each can be operated in a 383 "strict" mode or a "relaxed" mode. A Domain Owner would normally 384 select strict mode if it wanted Mail Receivers to apply DMARC 385 processing only to messages bearing an RFC5322.From domain exactly 386 matching the domains those mechanisms will verify. Relaxed mode can 387 be used when the operator also wishes to affect message flows bearing 388 subdomains of the verified domains. 390 3.1.1. DKIM-Authenticated Identifiers 392 DMARC permits Identifier Alignment, based on the result of a DKIM 393 authentication, to be strict or relaxed. (Note that these are not 394 related to DKIM's "simple" and "relaxed" canonicalization modes.) 396 In relaxed mode, the Organizational Domains of both the [RFC6376]- 397 authenticated signing domain (taken from the value of the "d=" tag in 398 the signature) and that of the RFC5322.From domain must be equal if 399 the identifiers are to be considered aligned. In strict mode, only 400 an exact match between both of the Fully Qualified Domain Names 401 (FQDNs) is considered to produce Identifier Alignment. 403 To illustrate, in relaxed mode, if a validated DKIM signature 404 successfully verifies with a "d=" domain of "example.com", and the 405 RFC5322.From address is "alerts@news.example.com", the DKIM "d=" 406 domain and the RFC5322.From domain are considered to be "in 407 alignment". In strict mode, this test would fail, since the "d=" 408 domain does not exactly match the FQDN of the address. 410 However, a DKIM signature bearing a value of "d=com" would never 411 allow an "in alignment" result, as "com" should appear on all public 412 suffix lists (see Appendix A.6.1) and therefore cannot be an 413 Organizational Domain. 415 Identifier Alignment is required because a message can bear a valid 416 signature from any domain, including domains used by a mailing list 417 or even a bad actor. Therefore, merely bearing a valid signature is 418 not enough to infer authenticity of the Author Domain. 420 Note that a single email can contain multiple DKIM signatures, and it 421 is considered to be a DMARC "pass" if any DKIM signature is aligned 422 and verifies. 424 3.1.2. SPF-Authenticated Identifiers 426 DMARC permits Identifier Alignment, based on the result of an SPF 427 authentication, to be strict or relaxed. 429 In relaxed mode, the [RFC3986]-authenticated domain and RFC5322.From 430 domain must have the same Organizational Domain. In strict mode, 431 only an exact DNS domain match is considered to produce Identifier 432 Alignment. 434 Note that the RFC5321.HELO identity is not typically used in the 435 context of DMARC (except when required to "fake" an otherwise null 436 reverse-path), even though a "pure SPF" implementation according to 437 [RFC7208] would check that identifier. 439 For example, if a message passes an SPF check with an 440 RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address 441 portion of the RFC5322.From field contains "payments@example.com", 442 the Authenticated RFC5321.MailFrom domain identifier and the 443 RFC5322.From domain are considered to be "in alignment" in relaxed 444 mode, but not in strict mode. 446 3.1.3. Alignment and Extension Technologies 448 If in the future DMARC is extended to include the use of other 449 authentication mechanisms, the extensions will need to allow for 450 domain identifier extraction so that alignment with the RFC5322.From 451 domain can be verified. 453 3.2. Organizational Domain 455 The Organizational Domain is determined using the following 456 algorithm: 458 1. Acquire a "public suffix" list, i.e., a list of DNS domain names 459 reserved for registrations. Some country Top-Level Domains 460 (TLDs) make specific registration requirements, e.g., the United 461 Kingdom places company registrations under ".co.uk"; other TLDs 462 such as ".com" appear in the IANA registry of top-level DNS 463 domains. A public suffix list is the union of all of these. 464 Appendix A.6.1 contains some discussion about obtaining a public 465 suffix list. 467 2. Break the subject DNS domain name into a set of "n" ordered 468 labels. Number these labels from right to left; e.g., for 469 "example.com", "com" would be label 1 and "example" would be 470 label 2. 472 3. Search the public suffix list for the name that matches the 473 largest number of labels found in the subject DNS domain. Let 474 that number be "x". 476 4. Construct a new DNS domain name using the name that matched from 477 the public suffix list and prefixing to it the "x+1"th label from 478 the subject domain. This new name is the Organizational Domain. 480 Thus, since "com" is an IANA-registered TLD, a subject domain of 481 "a.b.c.d.example.com" would have an Organizational Domain of 482 "example.com". 484 The process of determining a suffix is currently a heuristic one. No 485 list is guaranteed to be accurate or current. 487 In addition to Mediators, mail that is sent by authorized, 488 independent third parties might not be sent with Identifier 489 Alignment, also preventing a "pass" result. 491 Issues specific to the use of policy mechanisms alongside DKIM are 492 further discussed in [RFC6377], particularly Section 5.2. 494 4. Overview 496 This section provides a general overview of the design and operation 497 of the DMARC environment. 499 4.1. Authentication Mechanisms 501 The following mechanisms for determining Authenticated Identifiers 502 are supported in this version of DMARC: 504 * [RFC6376], which provides a domain-level identifier in the content 505 of the "d=" tag of a validated DKIM-Signature header field. 507 * [RFC3986], which can authenticate both the domain found in an 508 [RFC5322] HELO/EHLO command (the HELO identity) and the domain 509 found in an SMTP MAIL command (the MAIL FROM identity). DMARC 510 uses the result of SPF authentication of the MAIL FROM identity. 511 Section 2.4 of [RFC7208] describes MAIL FROM processing for cases 512 in which the MAIL command has a null path. 514 4.2. Key Concepts 516 DMARC policies are published by the Domain Owner, and retrieved by 517 the Mail Receiver during the SMTP session, via the DNS. 519 DMARC's filtering function is based on whether the RFC5322.From field 520 domain is aligned with (matches) an authenticated domain name from 521 SPF or DKIM. When a DMARC policy is published for the domain name 522 found in the RFC5322.From field, and that domain name is not 523 validated through SPF or DKIM, the disposition of that message can be 524 affected by that DMARC policy when delivered to a participating 525 receiver. 527 It is important to note that the authentication mechanisms employed 528 by DMARC authenticate only a DNS domain and do not authenticate the 529 local-part of any email address identifier found in a message, nor do 530 they validate the legitimacy of message content. 532 DMARC's feedback component involves the collection of information 533 about received messages claiming to be from the Organizational Domain 534 for periodic aggregate reports to the Domain Owner. The parameters 535 and format for such reports are discussed in later sections of this 536 document. 538 A DMARC-enabled Mail Receiver might also generate per-message reports 539 that contain information related to individual messages that fail SPF 540 and/or DKIM. Per-message failure reports are a useful source of 541 information when debugging deployments (if messages can be determined 542 to be legitimate even though failing authentication) or in analyzing 543 attacks. The capability for such services is enabled by DMARC but 544 defined in other referenced material such as [RFC6591]. 546 A message satisfies the DMARC checks if at least one of the supported 547 authentication mechanisms: 549 1. produces a "pass" result, and 551 2. produces that result based on an identifier that is in alignment, 552 as defined in Section 3. 554 4.3. Flow Diagram 555 +---------------+ 556 | Author Domain |< . . . . . . . . . . . . . . . . . . . . . . . 557 +---------------+ . . . 558 | . . . 559 V V V . 560 +-----------+ +--------+ +----------+ +----------+ . 561 | MSA |<***>| DKIM | | DKIM | | SPF | . 562 | Service | | Signer | | Verifier | | Verifier | . 563 +-----------+ +--------+ +----------+ +----------+ . 564 | ^ ^ . 565 | ************** . 566 V * . 567 +------+ (~~~~~~~~~~~~) +------+ * . 568 | sMTA |------->( other MTAs )----->| rMTA | * . 569 +------+ (~~~~~~~~~~~~) +------+ * . 570 | * ........ 571 | * . 572 V * . 573 +-----------+ V V 574 +---------+ | MDA | +----------+ 575 | User |<--| Filtering |<***>| DMARC | 576 | Mailbox | | Engine | | Verifier | 577 +---------+ +-----------+ +----------+ 579 MSA = Mail Submission Agent 580 MDA = Mail Delivery Agent 582 The above diagram shows a simple flow of messages through a DMARC- 583 aware system. Solid lines denote the actual message flow, dotted 584 lines involve DNS queries used to retrieve message policy related to 585 the supported message authentication schemes, and asterisk lines 586 indicate data exchange between message-handling modules and message 587 authentication modules. "sMTA" is the sending MTA, and "rMTA" is the 588 receiving MTA. 590 In essence, the steps are as follows: 592 1. Domain Owner constructs an SPF policy and publishes it in its 593 DNS database as per [RFC7208]. Domain Owner also configures its 594 system for DKIM signing as described in [RFC6376]. Finally, 595 Domain Owner publishes via the DNS a DMARC message-handling 596 policy. 598 2. Author generates a message and hands the message to Domain 599 Owner's designated mail submission service. 601 3. Submission service passes relevant details to the DKIM signing 602 module in order to generate a DKIM signature to be applied to 603 the message. 605 4. Submission service relays the now-signed message to its 606 designated transport service for routing to its intended 607 recipient(s). 609 5. Message may pass through other relays but eventually arrives at 610 a recipient's transport service. 612 6. Recipient delivery service conducts SPF and DKIM authentication 613 checks by passing the necessary data to their respective 614 modules, each of which requires queries to the Author Domain's 615 DNS data (when identifiers are aligned; see below). 617 7. The results of these are passed to the DMARC module along with 618 the Author's domain. The DMARC module attempts to retrieve a 619 policy from the DNS for that domain. If none is found, the 620 DMARC module determines the Organizational Domain and repeats 621 the attempt to retrieve a policy from the DNS. (This is 622 described in further detail in Section 6.6.3.) 624 8. If a policy is found, it is combined with the Author's domain 625 and the SPF and DKIM results to produce a DMARC policy result (a 626 "pass" or "fail") and can optionally cause one of two kinds of 627 reports to be generated (not shown). 629 9. Recipient transport service either delivers the message to the 630 recipient inbox or takes other local policy action based on the 631 DMARC result (not shown). 633 10. When requested, Recipient transport service collects data from 634 the message delivery session to be used in providing feedback 635 (see Section 7). 637 5. Use of RFC5322.From 639 One of the most obvious points of security scrutiny for DMARC is the 640 choice to focus on an identifier, namely the RFC5322.From address, 641 which is part of a body of data that has been trivially forged 642 throughout the history of email. 644 Several points suggest that it is the most correct and safest thing 645 to do in this context: 647 * Of all the identifiers that are part of the message itself, this 648 is the only one guaranteed to be present. 650 * It seems the best choice of an identifier on which to focus, as 651 most MUAs display some or all of the contents of that field in a 652 manner strongly suggesting those data as reflective of the true 653 originator of the message. 655 The absence of a single, properly formed RFC5322.From field renders 656 the message invalid. Handling of such a message is outside of the 657 scope of this specification. 659 Since the sorts of mail typically protected by DMARC participants 660 tend to only have single Authors, DMARC participants generally 661 operate under a slightly restricted profile of RFC5322 with respect 662 to the expected syntax of this field. See Section 6.6 for details. 664 6. Policy 666 DMARC policies are published by Domain Owners and applied by Mail 667 Receivers. 669 A Domain Owner advertises DMARC participation of one or more of its 670 domains by adding a DNS TXT record (described in Section 6.1) to 671 those domains. In doing so, Domain Owners make specific requests of 672 Mail Receivers regarding the disposition of messages purporting to be 673 from one of the Domain Owner's domains and the provision of feedback 674 about those messages. 676 A Domain Owner may choose not to participate in DMARC evaluation by 677 Mail Receivers. In this case, the Domain Owner simply declines to 678 advertise participation in those schemes. For example, if the 679 results of path authorization checks ought not be considered as part 680 of the overall DMARC result for a given Author Domain, then the 681 Domain Owner does not publish an SPF policy record that can produce 682 an SPF pass result. 684 A Mail Receiver implementing the DMARC mechanism SHOULD make a best- 685 effort attempt to adhere to the Domain Owner's published DMARC policy 686 when a message fails the DMARC test. Since email streams can be 687 complicated (due to forwarding, existing RFC5322.From domain-spoofing 688 services, etc.), Mail Receivers MAY deviate from a Domain Owner's 689 published policy during message processing and SHOULD make available 690 the fact of and reason for the deviation to the Domain Owner via 691 feedback reporting, specifically using the "PolicyOverride" feature 692 of the aggregate report (see the DMARC reporting documents). 694 6.1. DMARC Policy Record 696 Domain Owner DMARC preferences are stored as DNS TXT records in 697 subdomains named "_dmarc". For example, the Domain Owner of 698 "example.com" would post DMARC preferences in a TXT record at 699 "_dmarc.example.com". Similarly, a Mail Receiver wishing to query 700 for DMARC preferences regarding mail with an RFC5322.From domain of 701 "example.com" would issue a TXT query to the DNS for the subdomain of 702 "_dmarc.example.com". The DNS-located DMARC preference data will 703 hereafter be called the "DMARC record". 705 DMARC's use of the Domain Name Service is driven by DMARC's use of 706 domain names and the nature of the query it performs. The query 707 requirement matches with the DNS, for obtaining simple parametric 708 information. It uses an established method of storing the 709 information, associated with the target domain name, namely an 710 isolated TXT record that is restricted to the DMARC context. Use of 711 the DNS as the query service has the benefit of reusing an extremely 712 well-established operations, administration, and management 713 infrastructure, rather than creating a new one. 715 Per [RFC1035], a TXT record can comprise several "character-string" 716 objects. Where this is the case, the module performing DMARC 717 evaluation MUST concatenate these strings by joining together the 718 objects in order and parsing the result as a single string. 720 6.2. DMARC URIs 722 [RFC3986] defines a generic syntax for identifying a resource. The 723 DMARC mechanism uses this as the format by which a Domain Owner 724 specifies the destination for the two report types that are 725 supported. 727 The place such URIs are specified (see Section 6.3) allows a list of 728 these to be provided. A report is normally sent to each listed URI 729 in the order provided by the Domain Owner. Receivers MAY impose a 730 limit on the number of URIs to which they will send reports but MUST 731 support the ability to send to at least two. The list of URIs is 732 separated by commas (ASCII 0x2C). 734 Each URI can have associated with it a maximum report size that may 735 be sent to it. This is accomplished by appending an exclamation 736 point (ASCII 0x21), followed by a maximum-size indication, before a 737 separating comma or terminating semicolon. 739 Thus, a DMARC URI is a URI within which any commas or exclamation 740 points are percent-encoded per [RFC3986], followed by an OPTIONAL 741 exclamation point and a maximum-size specification, and, if there are 742 additional reporting URIs in the list, a comma and the next URI. 744 For example, the URI "mailto:reports@example.com!50m" would request 745 that a report be sent via email to "reports@example.com" so long as 746 the report payload does not exceed 50 megabytes. 748 A formal definition is provided in Section 6.4. 750 6.3. General Record Format 752 DMARC records follow the extensible "tag-value" syntax for DNS-based 753 key records defined in DKIM [RFC6376]. 755 Section 10 creates a registry for known DMARC tags and registers the 756 initial set defined in this document. Only tags defined in this 757 document or in later extensions, and thus added to that registry, are 758 to be processed; unknown tags MUST be ignored. 760 The following tags are introduced as the initial valid DMARC tags: 762 adkim: (plain-text; OPTIONAL; default is "r".) Indicates whether 763 strict or relaxed DKIM Identifier Alignment mode is required by 764 the Domain Owner. See Section 3.1.1 for details. Valid values 765 are as follows: 767 r: relaxed mode 769 s: strict mode 771 aspf: (plain-text; OPTIONAL; default is "r".) Indicates whether 772 strict or relaxed SPF Identifier Alignment mode is required by the 773 Domain Owner. See Section 3.1.2 for details. Valid values are as 774 follows: 776 r: relaxed mode 778 s: strict mode 780 fo: Failure reporting options (plain-text; OPTIONAL; default is "0") 781 Provides requested options for generation of failure reports. 782 Report generators MAY choose to adhere to the requested options. 783 This tag's content MUST be ignored if a "ruf" tag (below) is not 784 also specified. The value of this tag is a colon-separated list 785 of characters that indicate failure reporting options as follows: 787 0: Generate a DMARC failure report if all underlying 788 authentication mechanisms fail to produce an aligned "pass" 789 result. 791 1: Generate a DMARC failure report if any underlying 792 authentication mechanism produced something other than an 793 aligned "pass" result. 795 d: Generate a DKIM failure report if the message had a signature 796 that failed evaluation, regardless of its alignment. DKIM- 797 specific reporting is described in [RFC6651]. 799 s: Generate an SPF failure report if the message failed SPF 800 evaluation, regardless of its alignment. SPF-specific 801 reporting is described in [RFC6652]. 803 p: Requested Mail Receiver policy (plain-text; REQUIRED for policy 804 records). Indicates the policy to be enacted by the Receiver at 805 the request of the Domain Owner. Policy applies to the domain 806 queried and to subdomains, unless subdomain policy is explicitly 807 described using the "sp" tag. This tag is mandatory for policy 808 records only, but not for third-party reporting records (as 809 discussed in the document(s) that discuss DMARC reporting in more 810 detail). Possible values are as follows: 812 none: The Domain Owner requests no specific action be taken 813 regarding delivery of messages. 815 quarantine: The Domain Owner wishes to have email that fails the 816 DMARC mechanism check be treated by Mail Receivers as 817 suspicious. Depending on the capabilities of the Mail 818 Receiver, this can mean "place into spam folder", "scrutinize 819 with additional intensity", and/or "flag as suspicious". 821 reject: The Domain Owner wishes for Mail Receivers to reject 822 email that fails the DMARC mechanism check. Rejection SHOULD 823 occur during the SMTP transaction. See Section 9.3 for some 824 discussion of SMTP rejection methods and their implications. 826 pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL; 827 default is 100). Percentage of messages from the Domain Owner's 828 mail stream to which the DMARC policy is to be applied. However, 829 this MUST NOT be applied to the DMARC-generated reports, all of 830 which must be sent and received unhindered. The purpose of the 831 "pct" tag is to allow Domain Owners to enact a slow rollout 832 enforcement of the DMARC mechanism. The prospect of "all or 833 nothing" is recognized as preventing many organizations from 834 experimenting with strong authentication-based mechanisms. See 835 Section 6.6.4 for details. Note that random selection based on 836 this percentage, such as the following pseudocode, is adequate: 838 if (random mod 100) < pct then selected = true else selected = 839 false 841 rf: Format to be used for message-specific failure reports (colon- 842 separated plain-text list of values; OPTIONAL; default is "afrf"). 843 The value of this tag is a list of one or more report formats as 844 requested by the Domain Owner to be used when a message fails both 845 [RFC3986] and [RFC6376] tests to report details of the individual 846 failure. The values MUST be present in the registry of reporting 847 formats defined in Section 10; a Mail Receiver observing a 848 different value SHOULD ignore it or MAY ignore the entire DMARC 849 record. For this version, only "afrf" (the auth-failure report 850 type defined in [RFC6591]) is presently supported. See the DMARC 851 reporting documents for details. For interoperability, the 852 Authentication Failure Reporting Format (AFRF) MUST be supported. 854 ri: Interval requested between aggregate reports (plain-text 32-bit 855 unsigned integer; OPTIONAL; default is 86400). Indicates a 856 request to Receivers to generate aggregate reports separated by no 857 more than the requested number of seconds. DMARC implementations 858 MUST be able to provide daily reports and SHOULD be able to 859 provide hourly reports when requested. However, anything other 860 than a daily report is understood to be accommodated on a best- 861 effort basis. 863 rua: Addresses to which aggregate feedback is to be sent (comma- 864 separated plain-text list of DMARC URIs; OPTIONAL). A comma or 865 exclamation point that is part of such a DMARC URI MUST be encoded 866 per Section 2.1 of [RFC3986] so as to distinguish it from the list 867 delimiter or an OPTIONAL size limit. The DMARC reporting 868 documents discuss considerations that apply when the domain name 869 of a URI differs from that of the domain advertising the policy. 870 See Section 11.5 for additional considerations. Any valid URI can 871 be specified. A Mail Receiver MUST implement support for a 872 "mailto:" URI, i.e., the ability to send a DMARC report via 873 electronic mail. If not provided, Mail Receivers MUST NOT 874 generate aggregate feedback reports. URIs not supported by Mail 875 Receivers MUST be ignored. The aggregate feedback report format 876 is described in the DMARC reporting documents. 878 ruf: Addresses to which message-specific failure information is to 879 be reported (comma-separated plain-text list of DMARC URIs; 880 OPTIONAL). If present, the Domain Owner is requesting Mail 881 Receivers to send detailed failure reports about messages that 882 fail the DMARC evaluation in specific ways (see the "fo" tag 883 above). The format of the message to be generated MUST follow the 884 format specified for the "rf" tag. The DMARC reporting documents 885 discuss considerations that apply when the domain name of a URI 886 differs from that of the domain advertising the policy. A Mail 887 Receiver MUST implement support for a "mailto:" URI, i.e., the 888 ability to send a DMARC report via electronic mail. If not 889 provided, Mail Receivers MUST NOT generate failure reports. See 890 Section 11.5 for additional considerations. 892 sp: Requested Mail Receiver policy for all subdomains (plain-text; 893 OPTIONAL). Indicates the policy to be enacted by the Receiver at 894 the request of the Domain Owner. It applies only to subdomains of 895 the domain queried and not to the domain itself. Its syntax is 896 identical to that of the "p" tag defined above. If absent, the 897 policy specified by the "p" tag MUST be applied for subdomains. 898 Note that "sp" will be ignored for DMARC records published on 899 subdomains of Organizational Domains due to the effect of the 900 DMARC policy discovery mechanism described in Section 6.6.3. 902 v: Version (plain-text; REQUIRED). Identifies the record retrieved 903 as a DMARC record. It MUST have the value of "DMARC1". The value 904 of this tag MUST match precisely; if it does not or it is absent, 905 the entire retrieved record MUST be ignored. It MUST be the first 906 tag in the list. 908 A DMARC policy record MUST comply with the formal specification found 909 in Section 6.4 in that the "v" tag MUST be present and MUST appear 910 first. Unknown tags MUST be ignored. Syntax errors in the remainder 911 of the record SHOULD be discarded in favor of default values (if any) 912 or ignored outright. 914 Note that given the rules of the previous paragraph, addition of a 915 new tag into the registered list of tags does not itself require a 916 new version of DMARC to be generated (with a corresponding change to 917 the "v" tag's value), but a change to any existing tags does require 918 a new version of DMARC. 920 6.4. Formal Definition 922 The formal definition of the DMARC format, using [RFC5234], is as 923 follows: 925 [FIXTHIS: Reference to [RFC3986] in code block] 926 dmarc-uri = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ] 927 ; "URI" is imported from [RFC3986]; commas (ASCII 928 ; 0x2C) and exclamation points (ASCII 0x21) 929 ; MUST be encoded; the numeric portion MUST fit 930 ; within an unsigned 64-bit integer 932 dmarc-record = dmarc-version dmarc-sep 933 [dmarc-request] 934 [dmarc-sep dmarc-srequest] 935 [dmarc-sep dmarc-auri] 936 [dmarc-sep dmarc-furi] 937 [dmarc-sep dmarc-adkim] 938 [dmarc-sep dmarc-aspf] 939 [dmarc-sep dmarc-ainterval] 940 [dmarc-sep dmarc-fo] 941 [dmarc-sep dmarc-rfmt] 942 [dmarc-sep dmarc-percent] 943 [dmarc-sep] 944 ; components other than dmarc-version and 945 ; dmarc-request may appear in any order 947 dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31 949 dmarc-sep = *WSP %x3b *WSP 951 dmarc-request = "p" *WSP "=" *WSP 952 ( "none" / "quarantine" / "reject" ) 954 dmarc-srequest = "sp" *WSP "=" *WSP 955 ( "none" / "quarantine" / "reject" ) 957 dmarc-auri = "rua" *WSP "=" *WSP 958 dmarc-uri *(*WSP "," *WSP dmarc-uri) 960 dmarc-furi = "ruf" *WSP "=" *WSP 961 dmarc-uri *(*WSP "," *WSP dmarc-uri) 963 dmarc-adkim = "adkim" *WSP "=" *WSP 964 ( "r" / "s" ) 966 dmarc-aspf = "aspf" *WSP "=" *WSP 967 ( "r" / "s" ) 969 dmarc-ainterval = "ri" *WSP "=" *WSP 1*DIGIT 971 dmarc-fo = "fo" *WSP "=" *WSP 972 ( "0" / "1" / "d" / "s" ) 973 *(*WSP ":" *WSP ( "0" / "1" / "d" / "s" )) 975 dmarc-rfmt = "rf" *WSP "=" *WSP Keyword *(*WSP ":" Keyword) 976 ; registered reporting formats only 978 dmarc-percent = "pct" *WSP "=" *WSP 979 1*3DIGIT 981 "Keyword" is imported from Section 4.1.2 of [RFC5321]. 983 A size limitation in a dmarc-uri, if provided, is interpreted as a 984 count of units followed by an OPTIONAL unit size ("k" for kilobytes, 985 "m" for megabytes, "g" for gigabytes, "t" for terabytes). Without a 986 unit, the number is presumed to be a basic byte count. Note that the 987 units are considered to be powers of two; a kilobyte is 2^10, a 988 megabyte is 2^20, etc. 990 6.5. Domain Owner Actions 992 To implement the DMARC mechanism, the only action required of a 993 Domain Owner is the creation of the DMARC policy record in the DNS. 994 However, in order to make meaningful use of DMARC, a Domain Owner 995 must at minimum either establish an address to receive reports, or 996 deploy authentication technologies and ensure Identifier Alignment. 997 Most Domain Owners will want to do both. 999 DMARC reports will be of significant size, and the addresses that 1000 receive them are publicly visible, so we encourage Domain Owners to 1001 set up dedicated email addresses to receive and process reports, and 1002 to deploy abuse countermeasures on those email addresses as 1003 appropriate. 1005 Authentication technologies are discussed in [RFC6376] (see also 1006 [RFC5585] and [RFC5863]) and [RFC7208]. 1008 6.6. Mail Receiver Actions 1010 This section describes receiver actions in the DMARC environment. 1012 6.6.1. Extract Author Domain 1014 The domain in the RFC5322.From field is extracted as the domain to be 1015 evaluated by DMARC. If the domain is encoded with UTF-8, the domain 1016 name must be converted to an A-label, as described in Section 2.3 of 1017 [RFC5890], for further processing. 1019 In order to be processed by DMARC, a message typically needs to 1020 contain exactly one RFC5322.From domain (a single From: field with a 1021 single domain in it). Not all messages meet this requirement, and 1022 handling of them is outside of the scope of this document. Typical 1023 exceptions, and the way they have been historically handled by DMARC 1024 participants, are as follows: 1026 * Messages with multiple RFC5322.From fields are typically rejected, 1027 since that form is forbidden under RFC 5322 [RFC5322]; 1029 * Messages bearing a single RFC5322.From field containing multiple 1030 addresses (and, thus, multiple domain names to be evaluated) are 1031 typically rejected because the sorts of mail normally protected by 1032 DMARC do not use this format; 1034 * Messages that have no RFC5322.From field at all are typically 1035 rejected, since that form is forbidden under RFC 5322 [RFC5322]; 1037 * Messages with an RFC5322.From field that contains no meaningful 1038 domains, such as RFC 5322 [RFC5322]'s "group" syntax, are 1039 typically ignored. 1041 The case of a syntactically valid multi-valued RFC5322.From field 1042 presents a particular challenge. The process in this case is to 1043 apply the DMARC check using each of those domains found in the 1044 RFC5322.From field as the Author Domain and apply the most strict 1045 policy selected among the checks that fail. 1047 6.6.2. Determine Handling Policy 1049 To arrive at a policy for an individual message, Mail Receivers MUST 1050 perform the following actions or their semantic equivalents. Steps 1051 2-4 MAY be done in parallel, whereas steps 5 and 6 require input from 1052 previous steps. 1054 The steps are as follows: 1056 1. Extract the RFC5322.From domain from the message (as above). 1058 2. Query the DNS for a DMARC policy record. Continue if one is 1059 found, or terminate DMARC evaluation otherwise. See 1060 Section 6.6.3 for details. 1062 3. Perform DKIM signature verification checks. A single email could 1063 contain multiple DKIM signatures. The results of this step are 1064 passed to the remainder of the algorithm and MUST include the 1065 value of the "d=" tag from each checked DKIM signature. 1067 4. Perform SPF validation checks. The results of this step are 1068 passed to the remainder of the algorithm and MUST include the 1069 domain name used to complete the SPF check. 1071 5. Conduct Identifier Alignment checks. With authentication checks 1072 and policy discovery performed, the Mail Receiver checks to see 1073 if Authenticated Identifiers fall into alignment as described in 1074 Section 3. If one or more of the Authenticated Identifiers align 1075 with the RFC5322.From domain, the message is considered to pass 1076 the DMARC mechanism check. All other conditions (authentication 1077 failures, identifier mismatches) are considered to be DMARC 1078 mechanism check failures. 1080 6. Apply policy. Emails that fail the DMARC mechanism check are 1081 disposed of in accordance with the discovered DMARC policy of the 1082 Domain Owner. See Section 6.3 for details. 1084 Heuristics applied in the absence of use by a Domain Owner of either 1085 SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be 1086 the case that the Domain Owner wishes a Message Receiver not to 1087 consider the results of that underlying authentication protocol at 1088 all. 1090 DMARC evaluation can only yield a "pass" result after one of the 1091 underlying authentication mechanisms passes for an aligned 1092 identifier. If neither passes and one or both of them fail due to a 1093 temporary error, the Receiver evaluating the message is unable to 1094 conclude that the DMARC mechanism had a permanent failure; they 1095 therefore cannot apply the advertised DMARC policy. When otherwise 1096 appropriate, Receivers MAY send feedback reports regarding temporary 1097 errors. 1099 Handling of messages for which SPF and/or DKIM evaluation encounter a 1100 permanent DNS error is left to the discretion of the Mail Receiver. 1102 6.6.3. Policy Discovery 1104 As stated above, the DMARC mechanism uses DNS TXT records to 1105 advertise policy. Policy discovery is accomplished via a method 1106 similar to the method used for SPF records. This method, and the 1107 important differences between DMARC and SPF mechanisms, are discussed 1108 below. 1110 To balance the conflicting requirements of supporting wildcarding, 1111 allowing subdomain policy overrides, and limiting DNS query load, the 1112 following DNS lookup scheme is employed: 1114 1. Mail Receivers MUST query the DNS for a DMARC TXT record at the 1115 DNS domain matching the one found in the RFC5322.From domain in 1116 the message. A possibly empty set of records is returned. 1118 2. Records that do not start with a "v=" tag that identifies the 1119 current version of DMARC are discarded. 1121 3. If the set is now empty, the Mail Receiver MUST query the DNS for 1122 a DMARC TXT record at the DNS domain matching the Organizational 1123 Domain in place of the RFC5322.From domain in the message (if 1124 different). This record can contain policy to be asserted for 1125 subdomains of the Organizational Domain. A possibly empty set of 1126 records is returned. 1128 4. Records that do not start with a "v=" tag that identifies the 1129 current version of DMARC are discarded. 1131 5. If the remaining set contains multiple records or no records, 1132 policy discovery terminates and DMARC processing is not applied 1133 to this message. 1135 6. If a retrieved policy record does not contain a valid "p" tag, or 1136 contains an "sp" tag that is not valid, then: 1138 1. if a "rua" tag is present and contains at least one 1139 syntactically valid reporting URI, the Mail Receiver SHOULD 1140 act as if a record containing a valid "v" tag and "p=none" 1141 was retrieved, and continue processing; 1143 2. otherwise, the Mail Receiver applies no DMARC processing to 1144 this message. 1146 If the set produced by the mechanism above contains no DMARC policy 1147 record (i.e., any indication that there is no such record as opposed 1148 to a transient DNS error), Mail Receivers SHOULD NOT apply the DMARC 1149 mechanism to the message. 1151 Handling of DNS errors when querying for the DMARC policy record is 1152 left to the discretion of the Mail Receiver. For example, to ensure 1153 minimal disruption of mail flow, transient errors could result in 1154 delivery of the message ("fail open"), or they could result in the 1155 message being temporarily rejected (i.e., an SMTP 4yx reply), which 1156 invites the sending MTA to try again after the condition has possibly 1157 cleared, allowing a definite DMARC conclusion to be reached ("fail 1158 closed"). 1160 6.6.4. Message Sampling 1162 If the "pct" tag is present in the policy record, the Mail Receiver 1163 MUST NOT enact the requested policy ("p" tag or "sp" tag") on more 1164 than the stated percent of the totality of affected messages. 1165 However, regardless of whether or not the "pct" tag is present, the 1166 Mail Receiver MUST include all relevant message data in any reports 1167 produced. 1169 If email is subject to the DMARC policy of "quarantine", the Mail 1170 Receiver SHOULD quarantine the message. If the email is not subject 1171 to the "quarantine" policy (due to the "pct" tag), the Mail Receiver 1172 SHOULD apply local message classification as normal. 1174 If email is subject to the DMARC policy of "reject", the Mail 1175 Receiver SHOULD reject the message (see Section 9.3). If the email 1176 is not subject to the "reject" policy (due to the "pct" tag), the 1177 Mail Receiver SHOULD treat the email as though the "quarantine" 1178 policy applies. This behavior allows Domain Owners to experiment 1179 with progressively stronger policies without relaxing existing 1180 policy. 1182 Mail Receivers implement "pct" via statistical mechanisms that 1183 achieve a close approximation to the requested percentage and provide 1184 a representative sample across a reporting period. 1186 6.6.5. Store Results of DMARC Processing 1188 The results of Mail Receiver-based DMARC processing should be stored 1189 for eventual presentation back to the Domain Owner in the form of 1190 aggregate feedback reports. Section 6.3 and the DMARC reporting 1191 docuents discuss aggregate feedback. 1193 6.7. Policy Enforcement Considerations 1195 Mail Receivers MAY choose to reject or quarantine email even if email 1196 passes the DMARC mechanism check. The DMARC mechanism does not 1197 inform Mail Receivers whether an email stream is "good". Mail 1198 Receivers are encouraged to maintain anti-abuse technologies to 1199 combat the possibility of DMARC-enabled criminal campaigns. 1201 Mail Receivers MAY choose to accept email that fails the DMARC 1202 mechanism check even if the Domain Owner has published a "reject" 1203 policy. Mail Receivers need to make a best effort not to increase 1204 the likelihood of accepting abusive mail if they choose not to comply 1205 with a Domain Owner's reject, against policy. At a minimum, addition 1206 of the Authentication-Results header field (see [RFC8601]) is 1207 RECOMMENDED when delivery of failing mail is done. When this is 1208 done, the DNS domain name thus recorded MUST be encoded as an 1209 A-label. 1211 Mail Receivers are only obligated to report reject or quarantine 1212 policy actions in aggregate feedback reports that are due to DMARC 1213 policy. They are not required to report reject or quarantine actions 1214 that are the result of local policy. If local policy information is 1215 exposed, abusers can gain insight into the effectiveness and delivery 1216 rates of spam campaigns. 1218 Final disposition of a message is always a matter of local policy. 1219 An operator that wishes to favor DMARC policy over SPF policy, for 1220 example, will disregard the SPF policy, since enacting an SPF- 1221 determined rejection prevents evaluation of DKIM; DKIM might 1222 otherwise pass, satisfying the DMARC evaluation. There is a trade- 1223 off to doing so, namely acceptance and processing of the entire 1224 message body in exchange for the enhanced protection DMARC provides. 1226 DMARC-compliant Mail Receivers typically disregard any mail-handling 1227 directive discovered as part of an authentication mechanism (e.g., 1228 Author Domain Signing Practices (ADSP), SPF) where a DMARC record is 1229 also discovered that specifies a policy other than "none". Deviating 1230 from this practice introduces inconsistency among DMARC operators in 1231 terms of handling of the message. However, such deviation is not 1232 proscribed. 1234 To enable Domain Owners to receive DMARC feedback without impacting 1235 existing mail processing, discovered policies of "p=none" SHOULD NOT 1236 modify existing mail disposition processing. 1238 Mail Receivers SHOULD also implement reporting instructions of DMARC, 1239 even in the absence of a request for DKIM reporting [RFC6651] or SPF 1240 reporting [RFC6652]. Furthermore, the presence of such requests 1241 SHOULD NOT affect DMARC reporting. 1243 7. DMARC Feedback 1245 Providing Domain Owners with visibility into how Mail Receivers 1246 implement and enforce the DMARC mechanism in the form of feedback is 1247 critical to establishing and maintaining accurate authentication 1248 deployments. When Domain Owners can see what effect their policies 1249 and practices are having, they are better willing and able to use 1250 quarantine and reject policies. 1252 The details of this feedback are described in a separate document. 1254 8. Minimum Implementations 1256 A minimum implementation of DMARC has the following characteristics: 1258 * Is able to send and/or receive reports at least daily; 1260 * Is able to send and/or receive reports using "mailto" URIs; 1262 * Other than in exceptional circumstances such as resource 1263 exhaustion, can generate or accept a report up to ten megabytes in 1264 size; 1266 * If acting as a Mail Receiver, fully implements the provisions of 1267 Section 6.6. 1269 9. Other Topics 1271 This section discusses some topics regarding choices made in the 1272 development of DMARC, largely to commit the history to record. 1274 9.1. Issues Specific to SPF 1276 Though DMARC does not inherently change the semantics of an SPF 1277 policy record, historically lax enforcement of such policies has led 1278 many to publish extremely broad records containing many large network 1279 ranges. Domain Owners are strongly encouraged to carefully review 1280 their SPF records to understand which networks are authorized to send 1281 on behalf of the Domain Owner before publishing a DMARC record. 1283 Some receiver architectures might implement SPF in advance of any 1284 DMARC operations. This means that a "-" prefix on a sender's SPF 1285 mechanism, such as "-all", could cause that rejection to go into 1286 effect early in handling, causing message rejection before any DMARC 1287 processing takes place. Operators choosing to use "-all" should be 1288 aware of this. 1290 9.2. DNS Load and Caching 1292 DMARC policies are communicated using the DNS and therefore inherit a 1293 number of considerations related to DNS caching. The inherent 1294 conflict between freshness and the impact of caching on the reduction 1295 of DNS-lookup overhead should be considered from the Mail Receiver's 1296 point of view. Should Domain Owners publish a DNS record with a very 1297 short TTL, Mail Receivers can be provoked through the injection of 1298 large volumes of messages to overwhelm the Domain Owner's DNS. 1299 Although this is not a concern specific to DMARC, the implications of 1300 a very short TTL should be considered when publishing DMARC policies. 1302 Conversely, long TTLs will cause records to be cached for long 1303 periods of time. This can cause a critical change to DMARC 1304 parameters advertised by a Domain Owner to go unnoticed for the 1305 length of the TTL (while waiting for DNS caches to expire). Avoiding 1306 this problem can mean shorter TTLs, with the potential problems 1307 described above. A balance should be sought to maintain 1308 responsiveness of DMARC preference changes while preserving the 1309 benefits of DNS caching. 1311 9.3. Rejecting Messages 1313 This proposal calls for rejection of a message during the SMTP 1314 session under certain circumstances. This is preferable to 1315 generation of a Delivery Status Notification ([RFC3464]), since 1316 fraudulent messages caught and rejected using DMARC would then result 1317 in annoying generation of such failure reports that go back to the 1318 RFC5321.MailFrom address. 1320 This synchronous rejection is typically done in one of two ways: 1322 * Full rejection, wherein the SMTP server issues a 5xy reply code as 1323 an indication to the SMTP client that the transaction failed; the 1324 SMTP client is then responsible for generating notification that 1325 delivery failed (see Section 4.2.5 of [RFC5321]). 1327 * A "silent discard", wherein the SMTP server returns a 2xy reply 1328 code implying to the client that delivery (or, at least, relay) 1329 was successfully completed, but then simply discarding the message 1330 with no further action. 1332 Each of these has a cost. For instance, a silent discard can help to 1333 prevent backscatter, but it also effectively means that the SMTP 1334 server has to be programmed to give a false result, which can 1335 confound external debugging efforts. 1337 Similarly, the text portion of the SMTP reply may be important to 1338 consider. For example, when rejecting a message, revealing the 1339 reason for the rejection might give an attacker enough information to 1340 bypass those efforts on a later attempt, though it might also assist 1341 a legitimate client to determine the source of some local issue that 1342 caused the rejection. 1344 In the latter case, when doing an SMTP rejection, providing a clear 1345 hint can be useful in resolving issues. A receiver might indicate in 1346 plain text the reason for the rejection by using the word "DMARC" 1347 somewhere in the reply text. Many systems are able to scan the SMTP 1348 reply text to determine the nature of the rejection. Thus, providing 1349 a machine-detectable reason for rejection allows the problems causing 1350 rejections to be properly addressed by automated systems. For 1351 example: 1353 550 5.7.1 Email rejected per DMARC policy for example.com 1355 If a Mail Receiver elects to defer delivery due to inability to 1356 retrieve or apply DMARC policy, this is best done with a 4xy SMTP 1357 reply code. 1359 9.4. Identifier Alignment Considerations 1361 The DMARC mechanism allows both DKIM and SPF-authenticated 1362 identifiers to authenticate email on behalf of a Domain Owner and, 1363 possibly, on behalf of different subdomains. If malicious or unaware 1364 users can gain control of the SPF record or DKIM selector records for 1365 a subdomain, the subdomain can be used to generate DMARC-passing 1366 email on behalf of the Organizational Domain. 1368 For example, an attacker who controls the SPF record for 1369 "evil.example.com" can send mail with an RFC5322.From field 1370 containing "foo@example.com" that can pass both authentication and 1371 the DMARC check against "example.com". 1373 The Organizational Domain administrator should be careful not to 1374 delegate control of subdomains if this is an issue, and to consider 1375 using the "strict" Identifier Alignment option if appropriate. 1377 9.5. Interoperability Issues 1379 DMARC limits which end-to-end scenarios can achieve a "pass" result. 1381 Because DMARC relies on [RFC7208] and/or [RFC6376] to achieve a 1382 "pass", their limitations also apply. 1384 Additional DMARC constraints occur when a message is processed by 1385 some Mediators, such as mailing lists. Transiting a Mediator often 1386 causes either the authentication to fail or Identifier Alignment to 1387 be lost. These transformations may conform to standards but will 1388 still prevent a DMARC "pass". 1390 In addition to Mediators, mail that is sent by authorized, 1391 independent third parties might not be sent with Identifier 1392 Alignment, also preventing a "pass" result. 1394 Issues specific to the use of policy mechanisms alongside DKIM are 1395 further discussed in [RFC6377], particularly Section 5.2. 1397 10. IANA Considerations 1399 This section describes actions completed by IANA. 1401 10.1. Authentication-Results Method Registry Update 1403 IANA has added the following to the "Email Authentication Methods" 1404 registry: 1406 Method: dmarc 1408 Defined: RFC 7489 1410 ptype: header 1412 Property: from 1414 Value: the domain portion of the RFC5322.From field 1416 Status: active 1418 Version: 1 1420 10.2. Authentication-Results Result Registry Update 1422 IANA has added the following in the "Email Authentication Result 1423 Names" registry: 1425 Code: none 1427 Existing/New Code: existing 1429 Defined: [RFC8601] 1431 Auth Method: dmarc (added) 1432 Meaning: No DMARC policy record was published for the aligned 1433 identifier, or no aligned identifier could be extracted. 1435 Status: active 1437 Code: pass 1439 Existing/New Code: existing 1441 Defined: [RFC8601] 1443 Auth Method: dmarc (added) 1445 Meaning: A DMARC policy record was published for the aligned 1446 identifier, and at least one of the authentication mechanisms 1447 passed. 1449 Status: active 1451 Code: fail 1453 Existing/New Code: existing 1455 Defined: [RFC8601] 1457 Auth Method: dmarc (added) 1459 Meaning: A DMARC policy record was published for the aligned 1460 identifier, and none of the authentication mechanisms passed. 1462 Status: active 1464 Code: temperror 1466 Existing/New Code: existing 1468 Defined: [RFC8601] 1470 Auth Method: dmarc (added) 1472 Meaning: A temporary error occurred during DMARC evaluation. A 1473 later attempt might produce a final result. 1475 Status: active 1477 Code: permerror 1479 Existing/New Code: existing 1480 Defined: [RFC8601] 1482 Auth Method: dmarc (added) 1484 Meaning: A permanent error occurred during DMARC evaluation, such as 1485 encountering a syntactically incorrect DMARC record. A later 1486 attempt is unlikely to produce a final result. 1488 Status: active 1490 10.3. Feedback Report Header Fields Registry Update 1492 The following has been added to the "Feedback Report Header Fields" 1493 registry: 1495 Field Name: Identity-Alignment 1497 Description: indicates whether the message about which a report is 1498 being generated had any identifiers in alignment as defined in RFC 1499 7489 1501 Multiple Appearances: No 1503 Related "Feedback-Type": auth-failure 1505 Reference: RFC 7489 1507 Status: current 1509 10.4. DMARC Tag Registry 1511 A new registry tree called "Domain-based Message Authentication, 1512 Reporting, and Conformance (DMARC) Parameters" has been created. 1513 Within it, a new sub-registry called the "DMARC Tag Registry" has 1514 been created. 1516 Names of DMARC tags must be registered with IANA in this new sub- 1517 registry. New entries are assigned only for values that have been 1518 documented in a manner that satisfies the terms of Specification 1519 Required, per [RFC8126]. Each registration must include the tag 1520 name; the specification that defines it; a brief description; and its 1521 status, which must be one of "current", "experimental", or 1522 "historic". The Designated Expert needs to confirm that the provided 1523 specification adequately describes the new tag and clearly presents 1524 how it would be used within the DMARC context by Domain Owners and 1525 Mail Receivers. 1527 To avoid version compatibility issues, tags added to the DMARC 1528 specification are to avoid changing the semantics of existing records 1529 when processed by implementations conforming to prior specifications. 1531 The initial set of entries in this registry is as follows: 1533 +----------+-----------+---------+------------------------------+ 1534 | Tag Name | Reference | Status | Description | 1535 +==========+===========+=========+==============================+ 1536 | adkim | RFC 7489 | current | DKIM alignment mode | 1537 +----------+-----------+---------+------------------------------+ 1538 | aspf | RFC 7489 | current | SPF alignment mode | 1539 +----------+-----------+---------+------------------------------+ 1540 | fo | RFC 7489 | current | Failure reporting options | 1541 +----------+-----------+---------+------------------------------+ 1542 | p | RFC 7489 | current | Requested handling policy | 1543 +----------+-----------+---------+------------------------------+ 1544 | pct | RFC 7489 | current | Sampling rate | 1545 +----------+-----------+---------+------------------------------+ 1546 | rf | RFC 7489 | current | Failure reporting format(s) | 1547 +----------+-----------+---------+------------------------------+ 1548 | ri | RFC 7489 | current | Aggregate Reporting interval | 1549 +----------+-----------+---------+------------------------------+ 1550 | rua | RFC 7489 | current | Reporting URI(s) for | 1551 | | | | aggregate data | 1552 +----------+-----------+---------+------------------------------+ 1553 | ruf | RFC 7489 | current | Reporting URI(s) for failure | 1554 | | | | data | 1555 +----------+-----------+---------+------------------------------+ 1556 | sp | RFC 7489 | current | Requested handling policy | 1557 | | | | for subdomains | 1558 +----------+-----------+---------+------------------------------+ 1559 | v | RFC 7489 | current | Specification version | 1560 +----------+-----------+---------+------------------------------+ 1562 Table 1: "DMARC Tag Registry" 1564 10.5. DMARC Report Format Registry 1566 Also within "Domain-based Message Authentication, Reporting, and 1567 Conformance (DMARC) Parameters", a new sub-registry called "DMARC 1568 Report Format Registry" has been created. 1570 Names of DMARC failure reporting formats must be registered with IANA 1571 in this registry. New entries are assigned only for values that 1572 satisfy the definition of Specification Required, per [RFC8126]. In 1573 addition to a reference to a permanent specification, each 1574 registration must include the format name; a brief description; and 1575 its status, which must be one of "current", "experimental", or 1576 "historic". The Designated Expert needs to confirm that the provided 1577 specification adequately describes the report format and clearly 1578 presents how it would be used within the DMARC context by Domain 1579 Owners and Mail Receivers. 1581 The initial entry in this registry is as follows: 1583 +--------+-----------+---------+----------------------------------+ 1584 | Format | Reference | Status | Description | 1585 | Name | | | | 1586 +========+===========+=========+==================================+ 1587 | afrf | RFC 7489 | current | Authentication Failure Reporting | 1588 | | | | Format (see [RFC6591]) | 1589 +--------+-----------+---------+----------------------------------+ 1591 Table 2: "DMARC Report Format Registry" 1593 10.6. Underscored and Globally Scoped DNS Node Names Registry 1595 Per [!@RFC8552], please add the following entry to the "Underscored 1596 and Globally Scoped DNS Node Names" registry: 1598 +---------+------------+-----------+ 1599 | RR Type | _NODE NAME | Reference | 1600 +=========+============+===========+ 1601 | TXT | _dmarc | RFC 7489 | 1602 +---------+------------+-----------+ 1604 Table 3: "Underscored and 1605 Globally Scoped DNS Node Names" 1606 registry 1608 11. Security Considerations 1610 This section discusses security issues and possible remediations 1611 (where available) for DMARC. 1613 11.1. Authentication Methods 1615 Security considerations from the authentication methods used by DMARC 1616 are incorporated here by reference. 1618 11.2. Attacks on Reporting URIs 1620 URIs published in DNS TXT records are well-understood possible 1621 targets for attack. Specifications such as [RFC1035] and [RFC2142] 1622 either expose or cause the exposure of email addresses that could be 1623 flooded by an attacker, for example; MX, NS, and other records found 1624 in the DNS advertise potential attack destinations; common DNS names 1625 such as "www" plainly identify the locations at which particular 1626 services can be found, providing destinations for targeted denial-of- 1627 service or penetration attacks. 1629 Thus, Domain Owners will need to harden these addresses against 1630 various attacks, including but not limited to: 1632 * high-volume denial-of-service attacks; 1634 * deliberate construction of malformed reports intended to identify 1635 or exploit parsing or processing vulnerabilities; 1637 * deliberate construction of reports containing false claims for the 1638 Submitter or Reported-Domain fields, including the possibility of 1639 false data from compromised but known Mail Receivers. 1641 11.3. DNS Security 1643 The DMARC mechanism and its underlying technologies (SPF, DKIM) 1644 depend on the security of the DNS. To reduce the risk of subversion 1645 of the DMARC mechanism due to DNS-based exploits, serious 1646 consideration should be given to the deployment of DNSSEC in parallel 1647 with the deployment of DMARC by both Domain Owners and Mail 1648 Receivers. 1650 Publication of data using DNSSEC is relevant to Domain Owners and 1651 third-party Report Receivers. DNSSEC-aware resolution is relevant to 1652 Mail Receivers and Report Receivers. 1654 11.4. Display Name Attacks 1656 A common attack in messaging abuse is the presentation of false 1657 information in the display-name portion of the RFC5322.From field. 1658 For example, it is possible for the email address in that field to be 1659 an arbitrary address or domain name, while containing a well-known 1660 name (a person, brand, role, etc.) in the display name, intending to 1661 fool the end user into believing that the name is used legitimately. 1662 The attack is predicated on the notion that most common MUAs will 1663 show the display name and not the email address when both are 1664 available. 1666 Generally, display name attacks are out of scope for DMARC, as 1667 further exploration of possible defenses against these attacks needs 1668 to be undertaken. 1670 There are a few possible mechanisms that attempt mitigation of these 1671 attacks, such as the following: 1673 * If the display name is found to include an email address (as 1674 specified in [RFC5322]), execute the DMARC mechanism on the domain 1675 name found there rather than the domain name discovered 1676 originally. However, this addresses only a very specific attack 1677 space, and spoofers can easily circumvent it by simply not using 1678 an email address in the display name. There are also known cases 1679 of legitimate uses of an email address in the display name with a 1680 domain different from the one in the address portion, e.g., 1682 From: "user@example.org via Bug Tracker" support@example.com 1683 (mailto:support@example.com) 1685 * In the MUA, only show the display name if the DMARC mechanism 1686 succeeds. This too is easily defeated, as an attacker could 1687 arrange to pass the DMARC tests while fraudulently using another 1688 domain name in the display name. 1690 * In the MUA, only show the display name if the DMARC mechanism 1691 passes and the email address thus validated matches one found in 1692 the receiving user's list of known addresses. 1694 11.5. External Reporting Addresses 1696 To avoid abuse by bad actors, reporting addresses generally have to 1697 be inside the domains about which reports are requested. In order to 1698 accommodate special cases such as a need to get reports about domains 1699 that cannot actually receive mail, The DMARC reporting documents 1700 describe a DNS-based mechanism for verifying approved external 1701 reporting. 1703 The obvious consideration here is an increased DNS load against 1704 domains that are claimed as external recipients. Negative caching 1705 will mitigate this problem, but only to a limited extent, mostly 1706 dependent on the default TTL in the domain's SOA record. 1708 Where possible, external reporting is best achieved by having the 1709 report be directed to domains that can receive mail and simply having 1710 it automatically forwarded to the desired external destination. 1712 Note that the addresses shown in the "ruf" tag receive more 1713 information that might be considered private data, since it is 1714 possible for actual email content to appear in the failure reports. 1715 The URIs identified there are thus more attractive targets for 1716 intrusion attempts than those found in the "rua" tag. Moreover, 1717 attacking the DNS of the subject domain to cause failure data to be 1718 routed fraudulently to an attacker's systems may be an attractive 1719 prospect. Deployment of [RFC4033] is advisable if this is a concern. 1721 The verification mechanism presented in the DMARC reporting docuemnts 1722 is currently not mandatory ("MUST") but strongly recommended 1723 ("SHOULD"). It is possible that it would be elevated to a "MUST" by 1724 later security review. 1726 11.6. Secure Protocols 1728 This document encourages use of secure transport mechanisms to 1729 prevent loss of private data to third parties that may be able to 1730 monitor such transmissions. Unencrypted mechanisms should be 1731 avoided. 1733 In particular, a message that was originally encrypted or otherwise 1734 secured might appear in a report that is not sent securely, which 1735 could reveal private information. 1737 12. Normative References 1739 [RFC1035] Mockapetris, P., "Domain names - implementation and 1740 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1741 November 1987, . 1743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1744 Requirement Levels", BCP 14, RFC 2119, 1745 DOI 10.17487/RFC2119, March 1997, 1746 . 1748 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1749 Resource Identifier (URI): Generic Syntax", STD 66, 1750 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1751 . 1753 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case 1754 Insensitivity Clarification", RFC 4343, 1755 DOI 10.17487/RFC4343, January 2006, 1756 . 1758 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1759 Specifications: ABNF", STD 68, RFC 5234, 1760 DOI 10.17487/RFC5234, January 2008, 1761 . 1763 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1764 DOI 10.17487/RFC5321, October 2008, 1765 . 1767 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1768 DOI 10.17487/RFC5322, October 2008, 1769 . 1771 [RFC5890] Klensin, J., "Internationalized Domain Names for 1772 Applications (IDNA): Definitions and Document Framework", 1773 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1774 . 1776 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1777 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1778 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1779 . 1781 [RFC6591] Fontana, H., "Authentication Failure Reporting Using the 1782 Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591, 1783 April 2012, . 1785 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail 1786 (DKIM) for Failure Reporting", RFC 6651, 1787 DOI 10.17487/RFC6651, June 2012, 1788 . 1790 [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) 1791 Authentication Failure Reporting Using the Abuse Reporting 1792 Format", RFC 6652, DOI 10.17487/RFC6652, June 2012, 1793 . 1795 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1796 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1797 DOI 10.17487/RFC7208, April 2014, 1798 . 1800 13. Informative References 1802 [Best-Guess-SPF] 1803 Kitterman, S., "Sender Policy Framework: Best guess record 1804 (FAQ entry)", May 2010, 1805 . 1807 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 1808 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 1809 . 1811 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1812 for Delivery Status Notifications", RFC 3464, 1813 DOI 10.17487/RFC3464, January 2003, 1814 . 1816 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1817 Rose, "DNS Security Introduction and Requirements", 1818 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1819 . 1821 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 1822 Identified Mail (DKIM) Service Overview", RFC 5585, 1823 DOI 10.17487/RFC5585, July 2009, 1824 . 1826 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1827 DOI 10.17487/RFC5598, July 2009, 1828 . 1830 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, 1831 "DomainKeys Identified Mail (DKIM) Author Domain Signing 1832 Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617, August 1833 2009, . 1835 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 1836 "DomainKeys Identified Mail (DKIM) Development, 1837 Deployment, and Operations", RFC 5863, 1838 DOI 10.17487/RFC5863, May 2010, 1839 . 1841 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 1842 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 1843 September 2011, . 1845 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1846 Writing an IANA Considerations Section in RFCs", BCP 26, 1847 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1848 . 1850 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1851 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1852 May 2017, . 1854 [RFC8601] Kucherawy, M., "Message Header Field for Indicating 1855 Message Authentication Status", RFC 8601, 1856 DOI 10.17487/RFC8601, May 2019, 1857 . 1859 Appendix A. Technology Considerations 1861 This section documents some design decisions that were made in the 1862 development of DMARC. Specifically, addressed here are some 1863 suggestions that were considered but not included in the design. 1864 This text is included to explain why they were considered and not 1865 included in this version. 1867 A.1. S/MIME 1869 S/MIME, or Secure Multipurpose Internet Mail Extensions, is a 1870 standard for encryption and signing of MIME data in a message. This 1871 was suggested and considered as a third security protocol for 1872 authenticating the source of a message. 1874 DMARC is focused on authentication at the domain level (i.e., the 1875 Domain Owner taking responsibility for the message), while S/MIME is 1876 really intended for user-to-user authentication and encryption. This 1877 alone appears to make it a bad fit for DMARC's goals. 1879 S/MIME also suffers from the heavyweight problem of Public Key 1880 Infrastructure, which means that distribution of keys used to verify 1881 signatures needs to be incorporated. In many instances, this alone 1882 is a showstopper. There have been consistent promises that PKI 1883 usability and deployment will improve, but these have yet to 1884 materialize. DMARC can revisit this choice after those barriers are 1885 addressed. 1887 S/MIME has extensive deployment in specific market segments 1888 (government, for example) but does not enjoy similar widespread 1889 deployment over the general Internet, and this shows no signs of 1890 changing. DKIM and SPF both are deployed widely over the general 1891 Internet, and their adoption rates continue to be positive. 1893 Finally, experiments have shown that including S/MIME support in the 1894 initial version of DMARC would neither cause nor enable a substantial 1895 increase in the accuracy of the overall mechanism. 1897 A.2. Method Exclusion 1899 It was suggested that DMARC include a mechanism by which a Domain 1900 Owner could tell Message Receivers not to attempt validation by one 1901 of the supported methods (e.g., "check DKIM, but not SPF"). 1903 Specifically, consider a Domain Owner that has deployed one of the 1904 technologies, and that technology fails for some messages, but such 1905 failures don't cause enforcement action. Deploying DMARC would cause 1906 enforcement action for policies other than "none", which would appear 1907 to exclude participation by that Domain Owner. 1909 The DMARC development team evaluated the idea of policy exception 1910 mechanisms on several occasions and invariably concluded that there 1911 was not a strong enough use case to include them. The specific 1912 target audience for DMARC does not appear to have concerns about the 1913 failure modes of one or the other being a barrier to DMARC's 1914 adoption. 1916 In the scenario described above, the Domain Owner has a few options: 1918 1. Tighten up its infrastructure to minimize the failure modes of 1919 the single deployed technology. 1921 2. Deploy the other supported authentication mechanism, to offset 1922 the failure modes of the first. 1924 3. Deploy DMARC in a reporting-only mode. 1926 A.3. Sender Header Field 1928 It has been suggested in several message authentication efforts that 1929 the Sender header field be checked for an identifier of interest, as 1930 the standards indicate this as the proper way to indicate a re- 1931 mailing of content such as through a mailing list. Most recently, it 1932 was a protocol-level option for DomainKeys, but on evolution to DKIM, 1933 this property was removed. 1935 The DMARC development team considered this and decided not to include 1936 support for doing so, for the following reasons: 1938 1. The main user protection approach is to be concerned with what 1939 the user sees when a message is rendered. There is no consistent 1940 behavior among MUAs regarding what to do with the content of the 1941 Sender field, if present. Accordingly, supporting checking of 1942 the Sender identifier would mean applying policy to an identifier 1943 the end user might never actually see, which can create a vector 1944 for attack against end users by simply forging a Sender field 1945 containing some identifier that DMARC will like. 1947 2. Although it is certainly true that this is what the Sender field 1948 is for, its use in this way is also unreliable, making it a poor 1949 candidate for inclusion in the DMARC evaluation algorithm. 1951 3. Allowing multiple ways to discover policy introduces unacceptable 1952 ambiguity into the DMARC evaluation algorithm in terms of which 1953 policy is to be applied and when. 1955 A.4. Domain Existence Test 1957 A common practice among MTA operators, and indeed one documented in 1958 [RFC5617], is a test to determine domain existence prior to any more 1959 expensive processing. This is typically done by querying the DNS for 1960 MX, A, or AAAA resource records for the name being evaluated and 1961 assuming that the domain is nonexistent if it could be determined 1962 that no such records were published for that domain name. 1964 The original pre-standardization version of this protocol included a 1965 mandatory check of this nature. It was ultimately removed, as the 1966 method's error rate was too high without substantial manual tuning 1967 and heuristic work. There are indeed use cases this work needs to 1968 address where such a method would return a negative result about a 1969 domain for which reporting is desired, such as a registered domain 1970 name that never sends legitimate mail and thus has none of these 1971 records present in the DNS. 1973 A.5. Issues with ADSP in Operation 1975 DMARC has been characterized as a "super-ADSP" of sorts. 1977 Contributors to DMARC have compiled a list of issues associated with 1978 ADSP, gained from operational experience, that have influenced the 1979 direction of DMARC: 1981 1. ADSP has no support for subdomains, i.e., the ADSP record for 1982 example.com does not explicitly or implicitly apply to 1983 subdomain.example.com. If wildcarding is not applied, then 1984 spammers can trivially bypass ADSP by sending from a subdomain 1985 with no ADSP record. 1987 2. Nonexistent subdomains are explicitly out of scope in ADSP. 1988 There is nothing in ADSP that states receivers should simply 1989 reject mail from NXDOMAINs regardless of ADSP policy (which of 1990 course allows spammers to trivially bypass ADSP by sending email 1991 from nonexistent subdomains). 1993 3. ADSP has no operational advice on when to look up the ADSP 1994 record. 1996 4. ADSP has no support for using SPF as an auxiliary mechanism to 1997 DKIM. 1999 5. ADSP has no support for a slow rollout, i.e., no way to configure 2000 a percentage of email on which the receiver should apply the 2001 policy. This is important for large-volume senders. 2003 6. ADSP has no explicit support for an intermediate phase where the 2004 receiver quarantines (e.g., sends to the recipient's "spam" 2005 folder) rather than rejects the email. 2007 7. The binding between the "From" header domain and DKIM is too 2008 tight for ADSP; they must match exactly. 2010 A.6. Organizational Domain Discovery Issues 2012 Although protocols like ADSP are useful for "protecting" a specific 2013 domain name, they are not helpful at protecting subdomains. If one 2014 wished to protect "example.com" by requiring via ADSP that all mail 2015 bearing an RFC5322.From domain of "example.com" be signed, this would 2016 "protect" that domain; however, one could then craft an email whose 2017 RFC5322.From domain is "security.example.com", and ADSP would not 2018 provide any protection. One could use a DNS wildcard, but this can 2019 undesirably interfere with other DNS activity; one could add ADSP 2020 records as fraudulent domains are discovered, but this solution does 2021 not scale and is a purely reactive measure against abuse. 2023 The DNS does not provide a method by which the "domain of record", or 2024 the domain that was actually registered with a domain registrar, can 2025 be determined given an arbitrary domain name. Suggestions have been 2026 made that attempt to glean such information from SOA or NS resource 2027 records, but these too are not fully reliable, as the partitioning of 2028 the DNS is not always done at administrative boundaries. 2030 When seeking domain-specific policy based on an arbitrary domain 2031 name, one could "climb the tree", dropping labels off the left end of 2032 the name until the root is reached or a policy is discovered, but 2033 then one could craft a name that has a large number of nonsense 2034 labels; this would cause a Mail Receiver to attempt a large number of 2035 queries in search of a policy record. Sending many such messages 2036 constitutes an amplified denial-of-service attack. 2038 The Organizational Domain mechanism is a necessary component to the 2039 goals of DMARC. The method described in Section 3.2 is far from 2040 perfect but serves this purpose reasonably well without adding undue 2041 burden or semantics to the DNS. If a method is created to do so that 2042 is more reliable and secure than the use of a public suffix list, 2043 DMARC should be amended to use that method as soon as it is generally 2044 available. 2046 A.6.1. Public Suffix Lists 2048 A public suffix list for the purposes of determining the 2049 Organizational Domain can be obtained from various sources. The most 2050 common one is maintained by the Mozilla Foundation and made public at 2051 http://publicsuffix.org (http://publicsuffix.org). License terms 2052 governing the use of that list are available at that URI. 2054 Note that if operators use a variety of public suffix lists, 2055 interoperability will be difficult or impossible to guarantee. 2057 Appendix B. Examples 2059 This section illustrates both the Domain Owner side and the Mail 2060 Receiver side of a DMARC exchange. 2062 B.1. Identifier Alignment Examples 2064 The following examples illustrate the DMARC mechanism's use of 2065 Identifier Alignment. For brevity's sake, only message headers are 2066 shown, as message bodies are not considered when conducting DMARC 2067 checks. 2069 B.1.1. SPF 2071 The following SPF examples assume that SPF produces a passing result. 2073 Example 1: SPF in alignment: 2075 MAIL FROM: 2077 From: sender@example.com 2078 Date: Fri, Feb 15 2002 16:54:30 -0800 2079 To: receiver@example.org 2080 Subject: here's a sample 2082 In this case, the RFC5321.MailFrom parameter and the RFC5322.From 2083 field have identical DNS domains. Thus, the identifiers are in 2084 alignment. 2086 Example 2: SPF in alignment (parent): 2088 MAIL FROM: 2090 From: sender@example.com 2091 Date: Fri, Feb 15 2002 16:54:30 -0800 2092 To: receiver@example.org 2093 Subject: here's a sample 2095 In this case, the RFC5322.From parameter includes a DNS domain that 2096 is a parent of the RFC5321.MailFrom domain. Thus, the identifiers 2097 are in alignment if relaxed SPF mode is requested by the Domain 2098 Owner, and not in alignment if strict SPF mode is requested. 2100 Example 3: SPF not in alignment: 2102 MAIL FROM: 2104 From: sender@child.example.com 2105 Date: Fri, Feb 15 2002 16:54:30 -0800 2106 To: receiver@example.org 2107 Subject: here's a sample 2109 In this case, the RFC5321.MailFrom parameter includes a DNS domain 2110 that is neither the same as nor a parent of the RFC5322.From domain. 2111 Thus, the identifiers are not in alignment. 2113 B.1.2. DKIM 2115 The examples below assume that the DKIM signatures pass verification. 2116 Alignment cannot exist with a DKIM signature that does not verify. 2118 Example 1: DKIM in alignment: 2120 DKIM-Signature: v=1; ...; d=example.com; ... 2121 From: sender@example.com 2122 Date: Fri, Feb 15 2002 16:54:30 -0800 2123 To: receiver@example.org 2124 Subject: here's a sample 2126 In this case, the DKIM "d=" parameter and the RFC5322.From field have 2127 identical DNS domains. Thus, the identifiers are in alignment. 2129 Example 2: DKIM in alignment (parent): 2131 DKIM-Signature: v=1; ...; d=example.com; ... 2132 From: sender@child.example.com 2133 Date: Fri, Feb 15 2002 16:54:30 -0800 2134 To: receiver@example.org 2135 Subject: here's a sample 2137 In this case, the DKIM signature's "d=" parameter includes a DNS 2138 domain that is a parent of the RFC5322.From domain. Thus, the 2139 identifiers are in alignment for relaxed mode, but not for strict 2140 mode. 2142 Example 3: DKIM not in alignment: 2144 DKIM-Signature: v=1; ...; d=sample.net; ... 2145 From: sender@child.example.com 2146 Date: Fri, Feb 15 2002 16:54:30 -0800 2147 To: receiver@example.org 2148 Subject: here's a sample 2150 In this case, the DKIM signature's "d=" parameter includes a DNS 2151 domain that is neither the same as nor a parent of the RFC5322.From 2152 domain. Thus, the identifiers are not in alignment. 2154 B.2. Domain Owner Example 2156 A Domain Owner that wants to use DMARC should have already deployed 2157 and tested SPF and DKIM. The next step is to publish a DNS record 2158 that advertises a DMARC policy for the Domain Owner's Organizational 2159 Domain. 2161 B.2.1. Entire Domain, Monitoring Only 2163 The owner of the domain "example.com" has deployed SPF and DKIM on 2164 its messaging infrastructure. The owner wishes to begin using DMARC 2165 with a policy that will solicit aggregate feedback from receivers 2166 without affecting how the messages are processed, in order to: 2168 * Confirm that its legitimate messages are authenticating correctly 2170 * Verify that all authorized message sources have implemented 2171 authentication measures 2173 * Determine how many messages from other sources would be affected 2174 by a blocking policy 2176 The Domain Owner accomplishes this by constructing a policy record 2177 indicating that: 2179 * The version of DMARC being used is "DMARC1" ("v=DMARC1;") 2181 * Receivers should not alter how they treat these messages because 2182 of this DMARC policy record ("p=none") 2184 * Aggregate feedback reports should be sent via email to the address 2185 "dmarc-feedback@example.com" ("rua=mailto:dmarc- 2186 feedback@example.com") 2188 * All messages from this Organizational Domain are subject to this 2189 policy (no "pct" tag present, so the default of 100% applies) 2191 The DMARC policy record might look like this when retrieved using a 2192 common command-line tool: 2194 % dig +short TXT _dmarc.example.com. 2195 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com" 2197 To publish such a record, the DNS administrator for the Domain Owner 2198 creates an entry like the following in the appropriate zone file 2199 (following the conventional zone file format): 2201 ; DMARC record for the domain example.com 2203 _dmarc IN TXT ( "v=DMARC1; p=none; " 2204 "rua=mailto:dmarc-feedback@example.com" ) 2206 B.2.2. Entire Domain, Monitoring Only, Per-Message Reports 2208 The Domain Owner from the previous example has used the aggregate 2209 reporting to discover some messaging systems that had not yet 2210 implemented DKIM correctly, but they are still seeing periodic 2211 authentication failures. In order to diagnose these intermittent 2212 problems, they wish to request per-message failure reports when 2213 authentication failures occur. 2215 Not all Receivers will honor such a request, but the Domain Owner 2216 feels that any reports it does receive will be helpful enough to 2217 justify publishing this record. The default per-message report 2218 format ([RFC6591]) meets the Domain Owner's needs in this scenario. 2220 The Domain Owner accomplishes this by adding the following to its 2221 policy record from Appendix B.2: 2223 * Per-message failure reports should be sent via email to the 2224 address "auth-reports@example.com" ("ruf=mailto:auth- 2225 reports@example.com") 2227 The DMARC policy record might look like this when retrieved using a 2228 common command-line tool (the output shown would appear on a single 2229 line but is wrapped here for publication): 2231 % dig +short TXT _dmarc.example.com. 2232 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; 2233 ruf=mailto:auth-reports@example.com" 2235 To publish such a record, the DNS administrator for the Domain Owner 2236 might create an entry like the following in the appropriate zone file 2237 (following the conventional zone file format): 2239 ; DMARC record for the domain example.com 2241 _dmarc IN TXT ( "v=DMARC1; p=none; " 2242 "rua=mailto:dmarc-feedback@example.com; " 2243 "ruf=mailto:auth-reports@example.com" ) 2245 B.2.3. Per-Message Failure Reports Directed to Third Party 2247 The Domain Owner from the previous example is maintaining the same 2248 policy but now wishes to have a third party receive and process the 2249 per-message failure reports. Again, not all Receivers will honor 2250 this request, but those that do may implement additional checks to 2251 validate that the third party wishes to receive the failure reports 2252 for this domain. 2254 The Domain Owner needs to alter its policy record from Appendix B.2.2 2255 as follows: 2257 * Per-message failure reports should be sent via email to the 2258 address "auth-reports@thirdparty.example.net" ("ruf=mailto:auth- 2259 reports@thirdparty.example.net") 2261 The DMARC policy record might look like this when retrieved using a 2262 common command-line tool (the output shown would appear on a single 2263 line but is wrapped here for publication): 2265 % dig +short TXT _dmarc.example.com. 2266 "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; 2267 ruf=mailto:auth-reports@thirdparty.example.net" 2269 To publish such a record, the DNS administrator for the Domain Owner 2270 might create an entry like the following in the appropriate zone file 2271 (following the conventional zone file format): 2273 ; DMARC record for the domain example.com 2275 _dmarc IN TXT ( "v=DMARC1; p=none; " 2276 "rua=mailto:dmarc-feedback@example.com; " 2277 "ruf=mailto:auth-reports@thirdparty.example.net" ) 2279 Because the address used in the "ruf" tag is outside the 2280 Organizational Domain in which this record is published, conforming 2281 Receivers will implement additional checks as described in the DMARC 2282 reporting documents. In order to pass these additional checks, the 2283 third party will need to publish an additional DNS record as follows: 2285 * Given the DMARC record published by the Domain Owner at 2286 "_dmarc.example.com", the DNS administrator for the third party 2287 will need to publish a TXT resource record at 2288 "example.com._report._dmarc.thirdparty.example.net" with the value 2289 "v=DMARC1;". 2291 The resulting DNS record might look like this when retrieved using a 2292 common command-line tool (the output shown would appear on a single 2293 line but is wrapped here for publication): 2295 % dig +short TXT example.com._report._dmarc.thirdparty.example.net 2296 "v=DMARC1;" 2298 To publish such a record, the DNS administrator for example.net might 2299 create an entry like the following in the appropriate zone file 2300 (following the conventional zone file format): 2302 ; zone file for thirdparty.example.net 2303 ; Accept DMARC failure reports on behalf of example.com 2305 example.com._report._dmarc IN TXT "v=DMARC1;" 2307 Intermediaries and other third parties should refer to the DMARC 2308 reporting documents for the full details of this mechanism. 2310 B.2.4. Subdomain, Sampling, and Multiple Aggregate Report URIs 2312 The Domain Owner has implemented SPF and DKIM in a subdomain used for 2313 pre-production testing of messaging services. It now wishes to 2314 request that participating receivers act to reject messages from this 2315 subdomain that fail to authenticate. 2317 As a first step, it will ask that a portion (1/4 in this example) of 2318 failing messages be quarantined, enabling examination of messages 2319 sent to mailboxes hosted by participating receivers. Aggregate 2320 feedback reports will be sent to a mailbox within the Organizational 2321 Domain, and to a mailbox at a third party selected and authorized to 2322 receive same by the Domain Owner. Aggregate reports sent to the 2323 third party are limited to a maximum size of ten megabytes. 2325 The Domain Owner will accomplish this by constructing a policy record 2326 indicating that: 2328 * The version of DMARC being used is "DMARC1" ("v=DMARC1;") 2330 * It is applied only to this subdomain (record is published at 2331 "_dmarc.test.example.com" and not "_dmarc.example.com") 2333 * Receivers should quarantine messages from this Organizational 2334 Domain that fail to authenticate ("p=quarantine") 2336 * Aggregate feedback reports should be sent via email to the 2337 addresses "dmarc-feedback@example.com" and "example-tld- 2338 test@thirdparty.example.net", with the latter subjected to a 2339 maximum size limit ("rua=mailto:dmarc-feedback@ 2340 example.com,mailto:tld-test@thirdparty.example.net!10m") 2342 * 25% of messages from this Organizational Domain are subject to 2343 action based on this policy ("pct=25") 2345 The DMARC policy record might look like this when retrieved using a 2346 common command-line tool (the output shown would appear on a single 2347 line but is wrapped here for publication): 2349 % dig +short TXT _dmarc.test.example.com 2350 "v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com, 2351 mailto:tld-test@thirdparty.example.net!10m; pct=25" 2353 To publish such a record, the DNS administrator for the Domain Owner 2354 might create an entry like the following in the appropriate zone 2355 file: 2357 ; DMARC record for the domain example.com 2359 _dmarc IN TXT ( "v=DMARC1; p=quarantine; " 2360 "rua=mailto:dmarc-feedback@example.com," 2361 "mailto:tld-test@thirdparty.example.net!10m; " 2362 "pct=25" ) 2364 B.3. Mail Receiver Example 2366 A Mail Receiver that wants to use DMARC should already be checking 2367 SPF and DKIM, and possess the ability to collect relevant information 2368 from various email-processing stages to provide feedback to Domain 2369 Owners (possibly via Report Receivers). 2371 B.4. Processing of SMTP Time 2373 An optimal DMARC-enabled Mail Receiver performs authentication and 2374 Identifier Alignment checking during the [RFC5322] conversation. 2376 Prior to returning a final reply to the DATA command, the Mail 2377 Receiver's MTA has performed: 2379 1. An SPF check to determine an SPF-authenticated Identifier. 2381 2. DKIM checks that yield one or more DKIM-authenticated 2382 Identifiers. 2384 3. A DMARC policy lookup. 2386 The presence of an Author Domain DMARC record indicates that the Mail 2387 Receiver should continue with DMARC-specific processing before 2388 returning a reply to the DATA command. 2390 Given a DMARC record and the set of Authenticated Identifiers, the 2391 Mail Receiver checks to see if the Authenticated Identifiers align 2392 with the Author Domain (taking into consideration any strict versus 2393 relaxed options found in the DMARC record). 2395 For example, the following sample data is considered to be from a 2396 piece of email originating from the Domain Owner of "example.com": 2398 Author Domain: example.com 2399 SPF-authenticated Identifier: mail.example.com 2400 DKIM-authenticated Identifier: example.com 2401 DMARC record: 2402 "v=DMARC1; p=reject; aspf=r; 2403 rua=mailto:dmarc-feedback@example.com" 2405 In the above sample, both the SPF-authenticated Identifier and the 2406 DKIM-authenticated Identifier align with the Author Domain. The Mail 2407 Receiver considers the above email to pass the DMARC check, avoiding 2408 the "reject" policy that is to be applied to email that fails to pass 2409 the DMARC check. 2411 If no Authenticated Identifiers align with the Author Domain, then 2412 the Mail Receiver applies the DMARC-record-specified policy. 2413 However, before this action is taken, the Mail Receiver can consult 2414 external information to override the Domain Owner's policy. For 2415 example, if the Mail Receiver knows that this particular email came 2416 from a known and trusted forwarder (that happens to break both SPF 2417 and DKIM), then the Mail Receiver may choose to ignore the Domain 2418 Owner's policy. 2420 The Mail Receiver is now ready to reply to the DATA command. If the 2421 DMARC check yields that the message is to be rejected, then the Mail 2422 Receiver replies with a 5xy code to inform the sender of failure. If 2423 the DMARC check cannot be resolved due to transient network errors, 2424 then the Mail Receiver replies with a 4xy code to inform the sender 2425 as to the need to reattempt delivery later. If the DMARC check 2426 yields a passing message, then the Mail Receiver continues on with 2427 email processing, perhaps using the result of the DMARC check as an 2428 input to additional processing modules such as a domain reputation 2429 query. 2431 Before exiting DMARC-specific processing, the Mail Receiver checks to 2432 see if the Author Domain DMARC record requests AFRF-based reporting. 2433 If so, then the Mail Receiver can emit an AFRF to the reporting 2434 address supplied in the DMARC record. 2436 At the exit of DMARC-specific processing, the Mail Receiver captures 2437 (through logging or direct insertion into a data store) the result of 2438 DMARC processing. Captured information is used to build feedback for 2439 Domain Owner consumption. This is not necessary if the Domain Owner 2440 has not requested aggregate reports, i.e., no "rua" tag was found in 2441 the policy record. 2443 B.5. Utilization of Aggregate Feedback: Example 2445 Aggregate feedback is consumed by Domain Owners to verify a Domain 2446 Owner's understanding of how the Domain Owner's domain is being 2447 processed by the Mail Receiver. Aggregate reporting data on emails 2448 that pass all DMARC-supporting authentication checks is used by 2449 Domain Owners to verify that authentication practices remain 2450 accurate. For example, if a third party is sending on behalf of a 2451 Domain Owner, the Domain Owner can use aggregate report data to 2452 verify ongoing authentication practices of the third party. 2454 Data on email that only partially passes underlying authentication 2455 checks provides visibility into problems that need to be addressed by 2456 the Domain Owner. For example, if either SPF or DKIM fails to pass, 2457 the Domain Owner is provided with enough information to either 2458 directly correct the problem or understand where authentication- 2459 breaking changes are being introduced in the email transmission path. 2460 If authentication-breaking changes due to email transmission path 2461 cannot be directly corrected, then the Domain Owner at least 2462 maintains an understanding of the effect of DMARC-based policies upon 2463 the Domain Owner's email. 2465 Data on email that fails all underlying authentication checks 2466 provides baseline visibility on how the Domain Owner's domain is 2467 being received at the Mail Receiver. Based on this visibility, the 2468 Domain Owner can begin deployment of authentication technologies 2469 across uncovered email sources. Additionally, the Domain Owner may 2470 come to an understanding of how its domain is being misused. 2472 B.6. mailto Transport Example 2474 A DMARC record can contain a "mailto" reporting address, such as: 2476 mailto:dmarc-feedback@example.com 2478 A sample aggregate report from the Mail Receiver at 2479 mail.receiver.example follows: 2481 DKIM-Signature: v=1; ...; d=mail.receiver.example; ... 2482 From: dmarc-reporting@mail.receiver.example 2483 Date: Fri, Feb 15 2002 16:54:30 -0800 2484 To: dmarc-feedback@example.com 2485 Subject: Report Domain: example.com 2486 Submitter: mail.receiver.example 2487 Report-ID: <2002.02.15.1> 2488 MIME-Version: 1.0 2489 Content-Type: multipart/alternative; 2490 boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00" 2491 Content-Language: en-us 2493 This is a multipart message in MIME format. 2495 ------=_NextPart_000_024E_01CC9B0A.AFE54C00 2496 Content-Type: text/plain; charset="us-ascii" 2497 Content-Transfer-Encoding: 7bit 2499 This is an aggregate report from mail.receiver.example. 2501 ------=_NextPart_000_024E_01CC9B0A.AFE54C00 2502 Content-Type: application/gzip 2503 Content-Transfer-Encoding: base64 2504 Content-Disposition: attachment; 2505 filename="mail.receiver.example!example.com! 2506 1013662812!1013749130.gz" 2508 2510 ------=_NextPart_000_024E_01CC9B0A.AFE54C00-- 2512 Not shown in the above example is that the Mail Receiver's feedback 2513 should be authenticated using SPF. Also, the value of the "filename" 2514 MIME parameter is wrapped for printing in this specification but 2515 would normally appear as one continuous string. 2517 Acknowledgements 2519 DMARC and the draft version of this document submitted to the 2520 Independent Submission Editor were the result of lengthy efforts by 2521 an informal industry consortium: DMARC.org (see http://dmarc.org 2522 (http://dmarc.org)). Participating companies included Agari, 2523 American Greetings, AOL, Bank of America, Cloudmark, Comcast, 2524 Facebook, Fidelity Investments, Google, JPMorgan Chase & Company, 2525 LinkedIn, Microsoft, Netease, PayPal, ReturnPath, The Trusted Domain 2526 Project, and Yahoo!. Although the contributors and supporters are 2527 too numerous to mention, notable individual contributions were made 2528 by J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim 2529 Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen. 2530 The contributors would also like to recognize the invaluable input 2531 and guidance that was provided early on by J.D. Falk. 2533 Additional contributions within the IETF context were made by Kurt 2534 Anderson, Michael Jack Assels, Les Barstow, Anne Bennett, Jim Fenton, 2535 J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine, S. 2536 Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull. 2538 Authors' Addresses 2540 Emil Gustafsson 2541 Google 2543 Email: emgu@google.com 2545 Todd M. Herr 2546 Valimail 2548 Email: todd.herr@valimail.com 2550 John Levine 2551 Standcore LLC 2553 Email: standards@standore.com