Rfc9989

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". ¶