Rfc9989

This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. ¶

DMARC permits the owner of an email's Author Domain to enable validation of the domain's use to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed validation and to request reports the use of the domain name. Mail-receiving organizations can use this information when evaluating handling choices for incoming mail. ¶

This document obsoletes RFCs 7489 and 9091. ¶

This is an Internet Standards Track document. ¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. ¶

Information the current status of this document, any errata, and how to provide feedback on it may be obtained at . ¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( ) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. ¶

Abusive email often includes unauthorized and deceptive use of a domain name in the "From" header field defined in Section 3.6.2 of [ RFC5322 ] and referred to as RFC5322.From. The domain typically belongs to an organization expected to be known to -- and presumably trusted by -- the recipient. The Sender Policy Framework (SPF) [ RFC7208 ] and DomainKeys Identified Mail (DKIM) [ RFC6376 ] protocols provide domain-level authentication but are not directly associated with the RFC5322.From domain, also known as the Author Domain ( Section 3.2.2 ) . DMARC leverages these two protocols, providing a method for Domain Owners to publish a DNS TXT record describing the email authentication policies for the Author Domain and to request specific handling for messages using that domain that fail validation checks. These DNS records are called DMARC Policy Records ( Section 3.2.6 ) . ¶

As with SPF and DKIM, DMARC validation results in a verdict of either "pass" or "fail". A DMARC result of "pass" requires not only an SPF or DKIM pass verdict for the email message but also and more importantly that the domain associated with the SPF or DKIM pass be "aligned" with the Author Domain in one of two modes -- "relaxed" or "strict". Domains are said to be in "relaxed alignment" if they have the same Organizational Domain ( Section 3.2.14 ) ; a domain's Organizational Domain is the domain at the top of the namespace hierarchy for that domain while having the same administrative authority as that domain. On the other hand, domains are in "strict alignment" if and only if they are identical. The choice of required alignment mode is left to the Domain Owner ( Section 3.2.7 ) that publishes a DMARC Policy Record. ¶

A DMARC pass for a message indicates only that the use of the Author Domain has been validated for that message as authorized by the Domain Owner. Such authorization does not carry an explicit or implicit value assertion that message or the Domain Owner, and so a DMARC pass by itself does not guarantee that delivery to the recipient's inbox would be safe or desirable. For a mail-receiving organization participating in DMARC, a message that passes DMARC validation is part of a message stream reliably associated with the Author Domain. Therefore, reputation assessment of that stream by the mail-receiving organization can assume the use of that Author Domain is authorized by the Domain Owner. ¶

On the other hand, a message that fails this validation is not necessarily associated with the Author Domain and so should not affect the Author Domain's reputation. The phrase "not necessarily associated" was purposely chosen here, as it is important to understand that some messages making authorized use of the Author Domain can still fail DMARC validation checks. [ RFC7960 ] and Section 7 of this document both reasons why such failures may happen. Because of this, a mail-receiving organization that performs DMARC validation can choose to honor the Domain Owner's requested message handling for validation failures, but it is not required to do so. DMARC is commonly used as one input to more complex filtering decisions, and so the mail-receiving organization might choose different actions entirely. ¶

DMARC, in the associated documents [ RFC9990 ] and [ RFC9991 ] , also specifies a reporting framework. Using it, a mail-receiving organization can generate regular reports messages that use Author Domains for which a DMARC Policy Record exists; those reports are sent to the address(es) specified by the Domain Owner in the DMARC Policy Record. Domain Owners can use these reports, especially the aggregate reports, not only to identify sources of mail attempting to fraudulently use their domain but also (and perhaps more importantly) to flag and fix gaps in their own authentication practices. However, as with honoring the Domain Owner's stated mail handling preference, a mail-receiving organization supporting DMARC is under no obligation to send requested reports; although, it is recommended that they do send aggregate reports. ¶

The use of DMARC creates some interoperability challenges that require due consideration before deployment, particularly with configurations that can cause mail to be rejected. These are discussed in Section 7 . ¶

The following sections describe topics that guide the specification of DMARC. ¶

DMARC has the following high-level goals: ¶

Allow Domain Owners ( Section 3.2.7 ) and Public Suffix Operators (PSOs) ( Section 3.2.16 ) to validate their email authentication deployments. ¶

Allow Domain Owners and PSOs to assert their desired message handling for validation failures on messages purporting to have authorship within the domain. ¶

Minimize implementation complexity for both senders and receivers. ¶

Reduce the amount of successfully delivered spoofed emails. ¶

Work at Internet scale. ¶

DMARC is designed to prevent the unauthorized use of the Author Domain ( Section 3.2.2 ) of an email message, a technique known as "spoofing". Such unauthorized usage can frequently be found in messages impersonating a domain belonging to a business entity, i.e., messages that are meant to entice the recipient to provide sensitive information, such as usernames, passwords, and financial account information. These spoofed messages are commonly referred to as "phishing". ¶

DMARC can only be used to combat specific forms of exact-domain spoofing directly. DMARC does not attempt to solve all problems with spoofed or otherwise fraudulent emails. In particular, it does not address the use of visually similar domain names or abuse of the RFC5322.From human-readable display name, as defined in Section 3.4 of [ RFC5322 ] . ¶

Scalability is a significant issue for systems that need to operate in an environment as widely deployed as current SMTP email. For this reason, DMARC seeks to avoid the need for third parties or pre-sending agreements between senders and receivers. This preserves the positive aspects of the current email infrastructure. ¶

Although DMARC does not introduce third-party senders (namely external agents authorized to send on behalf of an operator) to the email-handling flow, it also does not preclude them. Such third parties are free to provide services in conjunction with DMARC. ¶

Several topics and issues are specifically out of scope of this work. These include the following: ¶

Different treatment of messages that are not authenticated (e.g., those that have no DKIM signature or those sent using an Author Domain ( Section 3.2.2 ) for which no DMARC Policy Record ( Section 3.2.6 ) exists versus those that fail validation; ¶

Evaluation of anything other than the RFC5322.From header field; ¶

Multiple reporting formats; ¶

Publishing policy other than via the DNS; ¶

Reporting or otherwise evaluating other than the last-hop IP address; ¶

Attacks in the display name portions of the RFC5322.From header field, also known as "display name" attacks; ¶

Authentication of entities other than domains, since DMARC is built upon SPF and DKIM, which authenticate domains; and ¶

This section defines terms used in the rest of the document. ¶

The key words " MUST ", " MUST NOT ", " REQUIRED ", " SHALL ", " SHALL NOT ", " SHOULD ", " SHOULD NOT ", " RECOMMENDED ", " NOT RECOMMENDED ", " MAY ", and " OPTIONAL " in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here. ¶

Readers are encouraged to be familiar with the contents of [ RFC5598 ] . In particular, that document defines various roles in the messaging infrastructure that can appear the same or separate in various contexts. For example, a Domain Owner ( Section 3.2.7 ) could, via the messaging security mechanisms on which DMARC is based, delegate the ability to send mail as the Domain Owner to a third party with another role. This document does not address the distinctions among such roles; the reader is encouraged to become familiar with that material before continuing. ¶

The following sections define the terms used in this document. ¶

Authenticated Identifiers are those domain-level identifiers for which authorized use is validated using a supported authentication mechanism ( Section 4.3 ) . ¶

The Author Domain is the domain name of the apparent author as extracted from the RFC5322.From header field. ¶

The DKIM Signing Domain is the domain name that is the value of the "d" tag in a validated DKIM-Signature header field in an email message. ¶

SPF [ RFC7208 ] can validate the uses of both the domain found in an SMTP [ RFC5321 ] HELO/EHLO command (the HELO identity) and the domain found in an SMTP MAIL command (the MAIL FROM identity). DMARC relies solely on SPF validation of the MAIL FROM identity. Section 2.4 of [ RFC7208 ] describes the determination of the MAIL FROM identity for cases in which the SMTP MAIL command has a null path, i.e., the mailbox composed of the local-part "postmaster" and the HELO identity. ¶

The term "SPF Domain" when used in this document refers to an SPF-validated MAIL FROM identity. ¶

The DMARC Policy Domain is the domain name at which an applicable DMARC Policy Record ( Section 3.2.6 ) is discovered for the Author Domain ( Section 3.2.2 ) of an email message. ¶

A DMARC Policy Record is a DNS TXT record published by a Domain Owner ( Section 3.2.7 ) or Public Suffix Operator (PSO) ( Section 3.2.16 ) to enable validation of an Author Domain's ( Section 3.2.2 ) use, to indicate the Domain Owner's or PSO's message handling preference regarding failed validation, and optionally to request reports the use of the Author Domain. ¶

A Domain Owner is an entity or organization that has control of a given DNS domain, usually by holding its registration. Domain Owners range from complex, globally distributed organizations to service providers working on behalf of non-technical clients to individuals responsible for maintaining personal domains. This specification uses this term as analogous to an Administrative Management Domain (ADMD), as defined in [ RFC5598 ] . It can also refer to delegates, such as Report Consumers, when those are outside of their immediate management domain. ¶

The Domain Owner Assessment Policy is the message handling preference expressed in a DMARC Policy Record ( Section 3.2.6 ) by the Domain Owner ( Section 3.2.7 ) regarding failed validation of the Author Domain ( Section 3.2.2 ) . Possible values are described in Section 4.7 . ¶

Enforcement describes a state where the existing Domain Owner Assessment Policy ( Section 3.2.8 ) for an Organizational Domain ( Section 3.2.14 ) and all subdomains below it is not "p=none". This state means that the Organizational Domain and its subdomains can only be used as Author Domains ( Section 3.2.2 ) if they are properly validated using the DMARC mechanism. ¶

Historically, Domain Owner Assessment Policies of "p=quarantine" or "p=reject" have been higher value signals to Mail Receivers ( Section 3.2.11 ) . Messages with Author Domains for which such policies exist that are not validated using the DMARC mechanism will not reach the inbox at Mail Receivers that participate in DMARC and honor the Domain Owner's expressed handling preference. ¶

DMARC describes the concept of alignment between the Author Domain ( Section 3.2.2 ) and an Authenticated Identifier ( Section 3.2.1 ) and requires such Identifier Alignment between the two for a message to achieve a DMARC pass. DMARC defines two states for alignment. ¶

When the Author Domain ( Section 3.2.2 ) has the same Organizational Domain ( Section 3.2.14 ) as an Authenticated Identifier ( Section 3.2.1 ) , the two are said to be in relaxed alignment. ¶

When the Author Domain ( Section 3.2.2 ) is identical to an Authenticated Identifier ( Section 3.2.1 ) , the two are said to be in strict alignment. ¶

The Mail Receiver is the entity or organization that receives and processes email. Mail Receivers operate one or more Internet-facing Message Transfer Agents (MTAs). ¶

Monitoring Mode describes a state where the existing Domain Owner Assessment Policy ( Section 3.2.8 ) for an Organizational Domain ( Section 3.2.14 ) and all subdomains below it is "p=none", and the Domain Owner ( Section 3.2.7 ) is receiving aggregate reports for the Organizational Domain. While the use of the Organizational Domain and all its subdomains as Author Domains ( Section 3.2.2 ) can still be validated by a Mail Receiver ( Section 3.2.11 ) deploying the DMARC mechanism, the Domain Owner expresses no handling preference for messages that fail DMARC validation. However, the Domain Owner is using the content of the DMARC aggregate reports to make any needed adjustments to the authentication practices for its mail streams. ¶

For DMARC purposes, a non-existent domain is consistent with the term's meaning as described in [ RFC8020 ] . That is, if the response code received for a query for a domain name is NXDOMAIN, then the domain name and any possible subdomains do not exist. ¶

The Organizational Domain for any domain is akin to the ADMD described in [ RFC5598 ] . A domain's Organizational Domain is the domain at the top of the namespace hierarchy for that domain while having the same administrative authority as the domain. An Organizational Domain is determined by applying the algorithm found in Section 4.10 . ¶

Some domains allow the registration of subdomains that are "owned" by independent organizations. Real-world examples of these domains are ".com", ".org", ".us", and ".co.uk", to name just a few. These domains are called "Public Suffix Domains" (PSDs). For example, "ietf.org" is a registered domain name, and ".org" is its PSD. ¶

A PSO is an organization that manages operations within a PSD, particularly the DNS records published for names at and under that domain name. ¶

PSO-Controlled Domain Names are names in the DNS that are managed by a PSO. PSO-Controlled Domain Names may have one label (e.g., ".com") or more (e.g., ".co.uk"), depending on the PSO's policy. ¶

A Report Consumer is an operator that receives reports from another operator implementing the reporting mechanisms described in [ RFC9990 ] and [ RFC9991 ] . This term applies collectively to the system components that receive and process these reports and the organizations that operate those components. ¶

Report Consumers can receive reports concerning domains for which the Report Consumer is also the Domain Owner ( Section 3.2.7 ) or PSO ( Section 3.2.16 ) or concerning domains that belong to another operator entirely. The DMARC mechanism permits a Domain Owner to act as a Report Consumer for its domain(s) and/or to designate a third party to act as a Report Consumer. See Section 11.6 for further discussion of such designation. ¶

This section provides a general overview of the design and operation of the DMARC environment. ¶

DMARC permits a Domain Owner ( Section 3.2.7 ) or PSO ( Section 3.2.16 ) to enable validation of an Author Domain's ( Section 3.2.2 ) use in an email message, to indicate the Domain Owner's or PSO's message handling preference regarding failed validation, and to request reports use of the Author Domain. A domain's DMARC Policy Record ( Section 3.2.6 ) is published in the DNS as a TXT record at the name created by prepending the label "_dmarc" to the domain name and is retrieved through normal DNS queries. ¶

DMARC's validation mechanism produces a "pass" result if a DMARC Policy Record exists for the Author Domain of an email message and the Author Domain is aligned ( Section 3.2.10 ) with an Authenticated Identifier ( Section 3.2.1 ) from that message. When a DMARC Policy Record exists for the Author Domain and the DMARC mechanism does not produce a "pass" result, the Mail Receiver's ( Section 3.2.11 ) handling of that message can be influenced by the Domain Owner Assessment Policy ( Section 3.2.8 ) expressed in the DMARC Policy Record. ¶

It is important to note that the authentication mechanisms employed by DMARC only validate the usage of a DNS domain in an email message. They do not validate the local-part of any email address identifier found in that message, nor do such validations carry an explicit or implicit value assertion that message or the Domain Owner. ¶

DMARC's reporting component involves the collection of information received messages using the Author Domain for periodic aggregate reports to the Domain Owner or PSO. The parameters and format for such reports are discussed in [ RFC9990 ] . ¶

A Mail Receiver participating in DMARC might also generate per-message failure reports that contain information related to individual messages that fail DMARC validation checks. Per-message failure reports are useful sources of information when debugging deployments (if messages can be determined to be legitimate despite failing validation) or in analyzing attacks. The capability for such services is enabled by DMARC but defined in other referenced material such as [ RFC6591 ] and [ RFC9991 ] . ¶

One of the most obvious points of security scrutiny for DMARC is the choice to focus on an identifier, namely the RFC5322.From address, which is part of a body of data that has been trivially forged throughout the history of email. This field is the one used by end users to identify the source of the message, and so it has always been a prime target for abuse through such forgery and other means. That said, of all the identifiers that are part of the message itself, this is the only one required to be present. A message without a single, properly formed RFC5322.From header field does not comply with [ RFC5322 ] , and handling such a message is outside of the scope of this specification. ¶

The following mechanisms for determining Authenticated Identifiers ( Section 3.2.1 ) are supported in this version of DMARC: ¶

DMARC validates the authorized use of the Author Domain ( Section 3.2.2 ) by requiring either that it have the same Organizational Domain ( Section 3.2.14 ) as an Authenticated Identifier ( Section 3.2.1 ) (a condition known as "relaxed alignment" ( Section 3.2.10.1 ) ) or that it be identical to the Authenticated Identifier (a condition known as "strict alignment" ( Section 3.2.10.2 ) ). The choice of relaxed or strict alignment is left to the Domain Owner ( Section 3.2.7 ) and is expressed in the domain's DMARC Policy Record ( Section 3.2.6 ) . In practice, nearly all Domain Owners have found relaxed alignment sufficient to meet their needs. Domain name comparisons in this context are case-insensitive, per [ RFC4343 ] . ¶

The following table is meant to illustrate possible alignment conditions. ¶

It is important to note that Identifier Alignment cannot occur with a message that is not valid per [ RFC5322 ] , particularly one with a malformed, absent, or repeated RFC5322.From header field, since in that case, there is no reliable way to determine a DMARC Policy Record ( Section 3.2.6 ) that applies to the message. Accordingly, DMARC operation is predicated on the input being a valid message object [ RFC5322 ] . For non-compliant cases, handling is outside of the scope of this specification. Further discussion of this can be found in Section 11.5 . ¶

DKIM permits a Domain Owner to claim some responsibility for a message by associating the domain to the message. This association is done by inserting the domain as the value of the "d" tag in a DKIM-Signature header field, and the assertion of responsibility is validated through a cryptographic signature in the header field. If the cryptographic signature validates, then the DKIM Signing Domain is the DKIM-Authenticated Identifier. ¶

There is currently no generally accepted mechanism by which a Domain Owner may assert a list of third-party DKIM Signing Domains that are authorized to sign on behalf of a given Author Domain. Therefore, DMARC requires that Identifier Alignment is applied to the DKIM-Authenticated Identifier because a message can bear a valid signature from any domain, even one used by a bad actor. Only a DKIM-Authenticated Identifier that has Identifier Alignment with the Author Domain is enough to validate the authorized use of the Author Domain. ¶

A single email can contain multiple DKIM signatures, and it is considered to produce a DMARC "pass" result if any DKIM-Authenticated Identifier aligns with the Author Domain. ¶

SPF can validate the uses of both the domain found in an SMTP HELO/EHLO command (the HELO identity) and the domain found in an SMTP MAIL command (the MAIL FROM identity). DMARC relies solely on SPF validation of the MAIL FROM identity. If the use of the domain in the MAIL FROM identity is validated by SPF, then that domain is the SPF-Authenticated Identifier. ¶

There is currently no generally accepted mechanism by which a Domain Owner may assert a list of third-party domains that are authorized for use as the MAIL FROM identity for mail using a given Author Domain. Therefore, DMARC requires that Identifier Alignment is applied to the SPF-Authenticated Identifier because any Domain Owner, even a bad actor, can publish an SPF record for its domain and send an email that will obtain an SPF "pass" result. Only an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain is enough to validate the authorized use of the Author Domain. ¶

In the future, if DMARC is extended to include the use of other authentication mechanisms, the extensions MUST allow for the assignment of a domain as an Authenticated Identifier so that alignment with the Author Domain can be validated. ¶

A Domain Owner ( Section 3.2.7 ) or PSO ( Section 3.2.16 ) advertises DMARC participation of one or more of its domains by publishing DMARC Policy Records ( Section 3.2.6 ) that will apply to those domains. In doing so, Domain Owners and PSOs indicate their handling preference regarding failed validation for email messages using their domain in the RFC5322.From header field as well as their desire (if any) to receive feedback such messages in the form of aggregate and/or failure reports. ¶

DMARC Policy Records are stored as DNS TXT records with names starting with the label "_dmarc". For example, the Domain Owner of "example.com" would publish a DMARC Policy Record at the name "_dmarc.example.com", and a Mail Receiver ( Section 3.2.11 ) wishing to find the DMARC Policy Record for mail with an Author Domain ( Section 3.2.2 ) of "example.com" would issue a TXT query to the DNS for the name "_dmarc.example.com". A Domain Owner or PSO may choose not to participate in DMARC validation by Mail Receivers simply by not publishing a DMARC Policy Record for its Author Domain(s). ¶

DMARC Policy Records can also apply to subdomains of the name at which they are published in the DNS if the record is published at an Organizational Domain ( Section 3.2.14 ) for the subdomains. The Domain Owner Assessment Policy ( Section 3.2.8 ) that applies to the subdomains can be identical to the Domain Owner Assessment Policy that applies to the Organizational Domain but it does not have to be identical. Whether or not it is identical depends on the presence or absence of certain values in the DMARC Policy Record. See Section 4.7 for more details. ¶

DMARC's use of the Domain Name Service is driven by DMARC's use of domain names and the nature of the query it performs. The query requirement matches with the DNS for obtaining simple parametric information. It uses an established method of storing the information associated with the domain name targeted by a DNS query, specifically an isolated TXT record that is restricted to the DMARC context. Using the DNS as the query service has the benefit of reusing an extremely well-established operations, administration, and management infrastructure, rather than creating a new one. ¶

Per [ RFC1035 ] , a TXT record can comprise multiple "character-string" objects. Where this is the case, the module performing DMARC evaluation MUST concatenate these strings by joining together the objects in order and parsing the result as a single string. ¶

A Domain Owner can choose not to have some underlying authentication mechanisms apply to DMARC evaluation of its Author Domain(s). For example, if a Domain Owner only wants to use DKIM as the underlying authentication mechanism, then the Domain Owner does not publish an SPF record that can produce Identifier Alignment between an SPF-Authenticated Identifier and the Author Domain. Alternatively, if the Domain Owner wishes to rely solely on SPF, then it can send email messages that have no DKIM-Signature header field that would produce Identifier Alignment between a DKIM-Authenticated Identifier and the Author Domain. However, it is RECOMMENDED that Domain Owners use both DKIM and SPF as underlying authentication mechanisms for DMARC. ¶

A Mail Receiver implementing the DMARC mechanism gets the Domain Owner's or PSO's published Domain Owner Assessment Policy and can use it to inform its handling decisions for messages that undergo DMARC validation checks and do not produce a result of "pass". Mail handling considerations based on Domain Owner Assessment Policy enforcement are discussed below in Section 5.4 . ¶

[ RFC3986 ] defines a syntax for identifying a resource. The DMARC mechanism uses this as the format by which a Domain Owner ( Section 3.2.7 ) or PSO ( Section 3.2.16 ) specifies the destination(s) for the two report types that are supported. ¶

The DMARC Policy Record format ( Section 4.7 ) allows for a list of these URIs to be provided, with each URI separated by commas (ASCII 0x2c). A report SHOULD be sent to each listed URI provided in the DMARC Policy Record. ¶

A formal definition is provided in Section 4.8 . ¶

DMARC Policy Records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [ RFC6376 ] . ¶

Section 9 creates a registry for known DMARC tags and registers the initial set defined in this document. Only tags defined in that registry are to be processed; unknown tags MUST be ignored. ¶

The following tags are valid DMARC tags: ¶

(plain-text; OPTIONAL ; default is "r".) Indicates whether the Domain Owner ( Section 3.2.7 ) or PSO ( Section 3.2.16 ) requires strict or relaxed DKIM Identifier Alignment mode. See Section 4.4.1 for details. Valid values are as follows: ¶

(plain-text; OPTIONAL ; default is "r".) Indicates whether the Domain Owner or PSO requires strict or relaxed SPF Identifier Alignment mode. See Section 4.4.2 for details. Valid values are as follows: ¶

Failure reporting options (plain-text; OPTIONAL ; default is "0"). Provides requested options for the generation of failure reports. Report generators may choose to adhere to the requested options. This tag's content MUST be ignored if a "ruf" tag (below) is not also specified. This tag can include one or more of the values shown here, with the exception that "0" and "1" are mutually exclusive. If more than one value is assigned to the tag, the list of values should be separated by colons (e.g., fo=0:d), and the values may appear in the list in any order. Valid values and their meanings are as follows: ¶

Domain Owner Assessment Policy ( Section 3.2.8 ) for non-existent subdomains of the given Organizational Domain (plain-text; OPTIONAL ). For this tag, the definition of "non-existent subdomain" is the same as that used for "non-existent domains" in Section 3.2.13 . The policy expressed by this tag indicates the message handling preference of the Domain Owner or PSO for mail using non-existent subdomains of the prevailing Organizational Domain and not passing DMARC validation. It applies only to non-existent subdomains of the Organizational Domain queried and not to either existing subdomains or the domain itself. Its syntax is identical to that of the "p" tag defined below. If the "np" tag is absent, the policy specified by the "sp" tag (if the "sp" tag is present) or the policy specified by the "p" tag (if the "sp" tag is not present) MUST be applied for non-existent subdomains. ¶

Domain Owner Assessment Policy ( Section 3.2.8 ) (plain-text; RECOMMENDED for DMARC Policy Records). Indicates the message handling preference of the Domain Owner or PSO for mail using its domain but not passing DMARC validation. The policy applies to the domain queried and to subdomains, unless the subdomain policy is explicitly described using the "sp" or "np" tags. If this tag is not present in an otherwise syntactically valid DMARC Policy Record, then the record is treated as if it included "p=none" (see Section 4.10.1 ). This tag is not applicable for third-party reporting records (see [ RFC9990 ] and [ RFC9991 ] ). Possible values are as follows: ¶

A flag indicating whether the domain is a PSD (plain-text; OPTIONAL ; default is "u"). Possible values are as follows: ¶

Addresses to which aggregate feedback reports are to be sent (comma-separated plain-text list of DMARC Reporting URIs; OPTIONAL ). If present, the Domain Owner is requesting Mail Receivers to send aggregate feedback reports as defined in [ RFC9990 ] to the URIs listed. Any valid URI can be specified. A Mail Receiver that sends aggregate feedback reports MUST implement support for a "mailto:" URI, i.e., the ability to send a DMARC report via electronic mail. If the tag is not provided, Mail Receivers MUST NOT generate aggregate feedback reports for the domain. URIs involving schemes not supported by Mail Receivers MUST be ignored. [ RFC9990 ] also discusses considerations that apply when the domain name of a URI differs from the domain publishing the DMARC Policy Record. See Section 11.6 for additional considerations. ¶

Addresses to which message-specific failure information is to be reported (comma-separated plain-text list of DMARC URIs; OPTIONAL ). If present, the Domain Owner is requesting Mail Receivers to send detailed failure reports messages that fail the DMARC evaluation in specific ways (see the "fo" tag above) to the URIs listed. Depending on the value of the "fo" tag, the format for such reports is described in [ RFC9991 ] , [ RFC6651 ] , and [ RFC6652 ] . Any valid URI can be specified. A Mail Receiver sending failure reports MUST implement support for a "mailto:" URI, i.e., the ability to send message-specific failure information via electronic mail. If the tag is not provided, Mail Receivers MUST NOT generate failure reports for the domain. URIs involving schemes not supported by Mail Receivers MUST be ignored. [ RFC9990 ] discusses considerations that apply when the domain name of a URI differs from that of the domain advertising the policy. See Section 11.6 for additional considerations. ¶

Domain Owner Assessment Policy for all subdomains of the given Organizational Domain (plain-text; OPTIONAL ). Indicates the message handling preference of the Domain Owner or PSO for mail using an existing subdomain of the prevailing Organizational Domain and not passing DMARC validation. It applies only to existing subdomains of the message's Organizational Domain in the DNS hierarchy and not to the Organizational Domain itself. Its syntax is identical to that of the "p" tag defined above. If both the "sp" tag is absent and the "np" tag is either absent or not applicable, the policy specified by the "p" tag MUST be applied for subdomains. Note that "sp" will be ignored for DMARC Policy Records published on subdomains of Organizational Domains and PSDs due to the effect of the DMARC policy discovery ( Section 4.10.1 ) . ¶

DMARC policy test mode (plain-text; OPTIONAL ; default is "n"). For the Author Domain to which the DMARC Policy Record applies, the "t" tag serves as a signal to the actor performing DMARC validation checks as to whether or not the Domain Owner wishes the Domain Owner Assessment Policy declared in the "p", "sp", and/or "np" tags to actually be applied. This tag does not affect the generation of DMARC reports, and it has no effect on any policy ("p", "sp", or "np") that is "none". See Appendix A.6 for further discussion of the use of this tag. Possible values are as follows: ¶

Version (plain-text; REQUIRED ). Identifies the record retrieved as a DMARC Policy Record. This tag MUST be the first tag in the list. The tag value is case sensitive, and the only possible value is "DMARC1". If the tag is not the first in the list, the tag is absent, or the value is not "DMARC1", then the entire record MUST be ignored. ¶

A DMARC Policy Record MUST comply with the formal definition found in this section. Unknown tags MUST be ignored. Syntax errors in the remainder of the record MUST be discarded in favor of default values (if any) or ignored outright. ¶

Because unknown tags MUST be ignored, the addition of a new tag into the registered list of tags does not itself require a new version of DMARC to be generated (with a corresponding change to the "v" tag's value), but a change to any existing tags does require a new version of DMARC. ¶

The formal definition of the DMARC Policy Record format, using ABNF syntax as described in [ RFC5234 ] and [ RFC7405 ] , is as follows: ¶

In each dmarc-tag, the dmarc-value has a syntax that depends on the tag name. The ABNF rule for each dmarc-value is specified in the following table: ¶

The above diagram shows a typical flow of messages through a DMARC-aware system. Dashed lines (e.g., -->) denote the actual message flow, dotted lines (e.g., ) represent DNS queries used to retrieve message policy related to the supported message authentication schemes, and starred lines (e.g., ) indicate data exchange between message-handling modules and message authentication modules. ¶

Put simply, when a message reaches a DMARC-aware rMTA, a DNS query will be initiated to determine if a DMARC Policy Record exists that applies to the Author Domain. If a DMARC Policy Record is found, the rMTA will use the results of SPF and DKIM validation checks to determine the DMARC validation status. The DMARC validation status can then factor into the message handling decision made by the recipient's mail system. ¶

More details on specific actions for the parties involved can be found in Sections 5.1 and 5.3 . ¶

An Organizational Domain ( Section 3.2.14 ) serves two different purposes, depending on the context: ¶

The Organizational Domain of the Author Domain ( Section 3.2.2 ) establishes the DMARC Policy Record ( Section 3.2.6 ) for that domain when no DMARC Policy Record is published specifically for the Author Domain (see Section 4.10.1 ). ¶

The Organizational Domains of an Authenticated Identifier ( Section 3.2.1 ) and the Author Domain are used in determining Identifier Alignment between the two (see Section 4.10.2 ). ¶

[ RFC7489 ] defined an Organizational Domain as "The domain that was registered with a domain name registrar". [ RFC7489 ] discussed using a Public Suffix List (PSL) as the authoritative list of the parent domains for Organizational Domains and further described a method for determining the Organizational Domain of an Author Domain or an Authenticated Identifier. However, [ RFC7489 ] mandated no requirement for a specific PSL for Mail Receivers to use (though it did suggest the one found at ) nor did it provide any guidance for the frequency of regular retrieval of the PSL by Mail Receivers participating in DMARC. [ RFC7489 ] acknowledged the possibility of interoperability issues caused by Mail Receivers choosing different PSLs and even suggested that if a more reliable and secure method for determining the Organizational Domain could be created, that method should replace reliance on a PSL. ¶

This update to DMARC offers more flexibility to Domain Owners, especially those with large, complex organizations that might want to apply decentralized management to their DNS and their DMARC Policy Records. Rather than just using a PSL to help identify an Organizational Domain, this update defines a discovery technique known colloquially as the "DNS Tree Walk". The target of any DNS Tree Walk is discovery of a valid DMARC Policy Record, and its use in determining an Organizational Domain allows for publishing DMARC Policy Records at multiple points in the namespace. ¶

However, this flexibility comes at a possible cost. Since the DNS Tree Walk relies on the Mail Receiver making a series of DNS queries, the potential exists for an ill-intentioned Domain Owner to send mail with Author Domains with tens or even hundreds of labels for the purpose of executing a denial-of-service attack on the Mail Receiver. To guard against such abuse of the DNS, a shortcut is built into the process so that Author Domains with more than eight labels do not result in more than eight DNS queries. Observed data at the time of publication showed that Author Domains with up to seven labels were in usage, and so eight was chosen as the query limit to allow for some future expansion of the namespace that did not require updating this document. ¶

The generic steps for a DNS Tree Walk are as follows: ¶

Query the DNS for a TXT record that matches the format of a DMARC Policy Record at the starting point for the Tree Walk. The starting point for the DNS Tree Walk will depend on the ultimate target of the DNS Tree Walk. Sections 4.10.1 and 4.10.2 describe the possible starting points. A possibly empty set of records is returned. ¶

Records that do not start with a "v" tag that identifies the current version of DMARC are discarded. If multiple DMARC Policy Records are returned for a single target, they are all discarded. If a single record remains and it contains a "psd=n" or "psd=y" tag, stop. ¶

Break the subject DNS domain name into a set of ordered labels. Assign the count of labels to "x", and number the labels from right to left, e.g., for "a.mail.example.com", "x" would be assigned the value 4, "com" would be label 1, "example" would be label 2, "mail" would be label 3, and so forth. ¶

If x = 8, remove the left-most (highest-numbered) labels from the subject domain until 7 labels remain. The resulting DNS domain name is the new target for the lookup. ¶

Query the DNS for a DMARC Policy Record at the DNS domain name matching this new target. A possibly empty set of records is returned. ¶

Records that do not start with a "v" tag that identifies the current version of DMARC are discarded. If multiple DMARC Policy Records are returned for a single target, they are all discarded. If a single record remains and it contains a "psd=n" or "psd=y" tag, stop. ¶

Determine the target for the query by removing the left-most label from the target of the query. Repeat steps 5, 6, and 7 until the process stops or there are no more labels remaining. ¶

To illustrate, for a message with the arbitrary Author Domain of "a.b.c.d.e.f.g.h.i.j.mail.example.com", a full DNS Tree Walk would require the following eight queries to potentially locate the DMARC Policy Record or Organizational Domain: ¶

The DMARC Policy Record to be applied to an email message will be the record found at any of the following locations, listed from highest preference to lowest: ¶

Policy discovery first starts with a query for a valid DMARC Policy Record at the name created by prepending the label "_dmarc" to the Author Domain of the message being evaluated. If a valid DMARC Policy Record is found there, then this is the DMARC Policy Record to be applied to the message; however, this does not necessarily mean that the Author Domain is the Organizational Domain to be used in Identifier Alignment checks. Whether this is also the Organizational Domain is dependent on the value of the "psd" tag, if present, or some conditions described in Section 4.10.2 . ¶

If no valid DMARC Policy Record is found by the first query, then perform a DNS Tree Walk to find the Author Domain's Organizational Domain or its Public Suffix Domain. The starting point for this DNS Tree Walk is determined as follows: ¶

If the DMARC Policy Record to be applied is that of the Author Domain, then the Domain Owner Assessment Policy is taken from the "p" tag of the record. ¶

If the DMARC Policy Record to be applied is that of either the Organizational Domain or the PSD and the Author Domain is a subdomain of that domain, then the Domain Owner Assessment Policy is taken from the "sp" tag (if any) if the Author Domain exists or the "np" tag (if any) if the Author Domain does not exist. In the absence of applicable "sp" or "np" tags, the "p" tag policy is used for subdomains. ¶

If a retrieved DMARC Policy Record does not contain a valid "p" tag, or contains an "sp" or "np" tag that is not valid, then: ¶

If a "rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver MUST act as if a record containing "p=none" was retrieved and continue processing. ¶

Otherwise, the Mail Receiver applies no DMARC processing to this message. ¶

If the set produced by the DNS Tree Walk contains no DMARC Policy Record (i.e., any indication that there is no such record as opposed to a transient DNS error), Mail Receivers MUST NOT apply the DMARC mechanism to the message. ¶

Handling of DNS errors when querying for the DMARC Policy Record is left to the discretion of the Mail Receiver. For example, to ensure minimal disruption of mail flow, transient errors could result in delivery of the message ("fail open"), or they could result in the message being temporarily rejected (i.e., an SMTP 4yx ), which invites the sending MTA to try again after the condition has possibly cleared, allowing a definite DMARC conclusion to be reached ("fail closed"). ¶

It may be necessary to perform multiple DNS Tree Walks to determine if an Authenticated Identifier and an Author Domain are in alignment, meaning that they have either the same Organizational Domain (relaxed alignment) or that they're identical (strict alignment). DNS Tree Walks done to discover an Organizational Domain for use in Identifier Alignment Evaluation might start at any of the following locations: ¶

There is no need to perform Identifier Alignment Evaluations under any of the following conditions: ¶

To discover the Organizational Domain for a domain, perform the DNS Tree Walk described in Section 4.10 as needed for any of the domains in question. ¶

For each Tree Walk that retrieved valid DMARC Policy Records, select the Organizational Domain from the domains for which valid DMARC Policy Records were retrieved from the longest to the shortest: ¶

If a valid DMARC Policy Record contains the "psd" tag set to "n" ("psd=n"), this is the Organizational Domain, and the selection process is complete. ¶

If a valid DMARC Policy Record, other than the one for the domain where the Tree Walk started, contains the "psd" tag set to "y" ("psd=y"), the Organizational Domain is the domain one label below this one in the DNS hierarchy, and the selection process is complete. For example, if in the course of a Tree Walk a DMARC Policy Record is queried for at first "_dmarc.mail.example.com" and then "_dmarc.example.com", and a valid DMARC Policy Record containing the "psd" tag set to "y" is found at "_dmarc.example.com", then "mail.example.com" is the domain one label below "example.com" in the DNS hierarchy and is thus the Organizational Domain. ¶

Otherwise, select the DMARC Policy Record found at the name with the fewest number of labels. This is the Organizational Domain and the selection process is complete. ¶

If this process does not determine the Organizational Domain, then the initial target domain is the Organizational Domain. ¶

For example, given the starting domain "a.mail.example.com", a for the Organizational Domain would require a series of DNS queries for DMARC Policy Records starting with "_dmarc.a.mail.example.com" and finishing with "_dmarc.com". If there are DMARC Policy Records published at "_dmarc.mail.example.com" and "_dmarc.example.com", but not at "_dmarc.a.mail.example.com" or "_dmarc.com", then the Organizational Domain for this domain would be "example.com". ¶

As another example, given the starting domain "a.mail.example.com", if a for the Organizational Domain yields a DMARC Policy Record at "_dmarc.mail.example.com" with the "psd" tag set to "n", then the Organizational Domain for this domain would be "mail.example.com". ¶

As a last example, given the starting domain "a.mail.example.com", if a for the Organizational Domain only yields a DMARC Policy Record at "_dmarc.com" and that record contains the tag "psd=y", then the Organizational Domain for this domain would be "example.com". ¶

This section describes the actions for participating in DMARC for each of three unique entities -- Domain Owners, PSOs, and Mail Receivers. ¶

A Domain Owner ( Section 3.2.7 ) wishing to fully participate in DMARC will: ¶

The following sections describe how to achieve this. ¶

To configure SPF for DMARC, the Domain Owner MUST send mail that has an RFC5321.MailFrom domain that will produce an SPF-Authenticated Identifier ( Section 4.4.2 ) that has Identifier Alignment ( Section 4.4 ) with the Author Domain. ¶

To configure DKIM for DMARC, the Domain Owner MUST send mail that has a DKIM Signing Domain ( Section 3.2.3 ) that will produce a DKIM-Authenticated Identifier ( Section 4.4.1 ) that has Identifier Alignment ( Section 4.4 ) with the Author Domain. ¶

Proper consumption and analysis of DMARC aggregate reports are essential to any successful DMARC deployment for a Domain Owner. DMARC aggregate reports, which are defined in [ RFC9990 ] , contain valuable data for the Domain Owner, showing sources of mail using the Author Domain. ¶

Once SPF, DKIM, and the aggregate reports mailbox are all in place, it's time to publish a DMARC Policy Record. For best results, Domain Owners usually start with "p=none" (see Section 5.1.5 ) with the "rua" tag containing a URI that references the mailbox created in the step. This is commonly referred to as putting the Author Domain into Monitoring Mode ( Section 3.2.12 ) . If the Organizational Domain is different from the Author Domain, a record also needs to be published for the Organizational Domain. ¶

The reason for starting at "p=none" is to ensure that nothing's been missed in the initial SPF and DKIM deployments. In all but the most trivial setups, a Domain Owner can overlook a server here or be unaware of a third-party sending agreement there. Starting at "p=none", therefore, takes advantage of DMARC's aggregate reporting function, with the Domain Owner using the reports to audit its own mail streams' authentication configurations. ¶

While it is possible for a human to read aggregate reports, they are formatted in such a way that it is recommended that they be machine-parsed, so setting up a mailbox involves more than just the physical creation of that mailbox. Many third-party services exist that will process DMARC aggregate reports, or the Domain Owner can create its own set of tools. No matter which method is chosen, the ability to consume these reports and parse the data contained in them will go a long way to ensuring a successful deployment. ¶

DMARC aggregate reports can reveal to the Domain Owner mail streams using the Author Domain but not passing DMARC validation checks. These mail streams may be a combination of illegitimate uses of the domain, such as spoofing or other attempted abuse, and legitimate uses, as in the case of a mail stream created by an agent of the Domain Owner but one that is not passing due to Authenticated Identifiers being unaligned or missing entirely. For such legitimate uses, these shortcomings MUST be addressed prior to any attempt by the Domain Owner to publish a Domain Owner Assessment Policy ( Section 3.2.8 ) of Enforcement ( Section 3.2.9 ) for the Author Domain. ¶

Large, complex organizations frequently adopt a decentralized model for DNS management, whereby management of a subtree of the namespace is delegated to a local department by the central IT organization. In such situations, the "psd" tag makes it possible for those local departments to declare any arbitrary node in their subtree as an Organizational Domain. This would be accomplished by publishing a DMARC Policy Record at that node with the "psd" tag set to "n". The reasons that departments might declare their own Organizational Domains include a desire to have different policy settings or reporting URIs than the DMARC Policy Record published for the apex doma...