4. Overview and Key Concepts
Cette page resume la section correspondante du RFC 9989 et conserve les tags DMARC, noms DNS, ABNF et valeurs IANA.
DMARC Policy Records are DNS TXT records under _dmarc. The v=DMARC1 tag is case sensitive and MUST be first. Default values include adkim=r, aspf=r, fo=0, psd=u, and t=n. Policy values are none, quarantine, and reject. The exact policy-record format, ABNF, flow diagram, and DNS Tree Walk rules from Sections 4.7-4.10 are preserved below.
4.7. DMARC Policy Record Format
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:
adkim: (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:
r: relaxed mode
s: strict mode
aspf: (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:
r: relaxed mode
s: strict mode
fo: 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:
0: Generate a DMARC failure report if all underlying
authentication mechanisms fail to produce an aligned "pass"
result.
1: Generate a DMARC failure report if any underlying
authentication mechanism fails to produce an aligned "pass"
result.
d: Generate a DKIM failure report if the message had a signature
that failed evaluation, regardless of its alignment. DKIM-
specific reporting is described in [RFC6651].
s: Generate an SPF failure report if the message failed SPF
evaluation, regardless of its alignment. SPF-specific
reporting is described in [RFC6652].
np: 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.
p: 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:
none: The Domain Owner offers no expression of preference.
quarantine: The Domain Owner considers such mail to be
suspicious. It is possible the mail is valid, although the
failure creates a significant concern.
reject: The Domain Owner considers all such failures to be a
clear indication that the use of the domain name is not valid.
See Section 7.2 for some discussion of SMTP rejection methods
and their implications.
psd: A flag indicating whether the domain is a PSD (plain-text;
OPTIONAL; default is "u"). Possible values are as follows:
y: PSOs include this tag with a value of "y" to indicate that the
domain is a PSD. If a record containing this tag with a value
of "y" is found during policy discovery, this information will
be used to determine the Organizational Domain and DMARC Policy
Domain applicable to the message in question.
n: The DMARC Policy Record is published for a domain that is not
a PSD, but it is the Organizational Domain for itself and its
subdomains.
u: The default indicates that the DMARC Policy Record is
published for a domain that is not a PSD and may or may not be
an Organizational Domain for itself and its subdomains. Use
the mechanism described in Section 4.10 for determining the
Organizational Domain for this domain.
rua: 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.
ruf: 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 about 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.
sp: 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).
t: 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:
y: A request that the actor performing the DMARC validation check
not apply the policy, but instead apply any special handling
rules it might have in place, such as rewriting the
RFC5322.From header field (see Appendix A.6). The Domain Owner
is currently testing its specified DMARC assessment policy and
has an expectation that the policy applied to any failing
messages will be one level below the specified policy. That
is, if the policy is "quarantine" and the value of the "t" tag
is "y", a policy of "none" will be applied to failing messages;
if the policy is "reject" and the value of the "t" tag is "y",
a policy of "quarantine" will be applied to failing messages,
irrespective of any other special handling rules that might be
triggered by the "t" tag having a value of "y".
n: The default is a request to apply the Domain Owner Assessment
Policy as specified to any message that produces a DMARC "fail"
result.
v: 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.
4.8. Formal Definition
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:
dmarc-uri = URI
; "URI" is imported from [RFC3986];
; commas (ASCII 0x2C) and exclamation
; points (ASCII 0x21) MUST be
; encoded
obs-dmarc-uri = dmarc-uri obs-dmarc-report-size
; Obsolete syntax, reporters should ignore the
; obs-dmarc-report-size if it is found in a
; DMARC Policy Record.
obs-dmarc-report-size = "!" 1*DIGIT [ "k" / "m" / "g" / "t" ]
dmarc-sep = *WSP ";" *WSP
equals = *WSP "=" *WSP
dmarc-record = dmarc-version *(dmarc-sep dmarc-tag) [dmarc-sep]
dmarc-tag = 1*ALPHA equals 1*dmarc-value
; any printing characters but semicolon
dmarc-value = %x20-3A / %x3C-7E
dmarc-version = "v" equals %s"DMARC1" ; case sensitive
; specialized syntax of DMARC values
dmarc-request = "none" / "quarantine" / "reject"
dmarc-yorn = "y" / "n"
dmarc-psd = "y" / "n" / "u"
dmarc-rors = "r" / "s"
dmarc-urilist = (dmarc-uri / obs-dmarc-uri)
*(*WSP "," *WSP (dmarc-uri / obs-dmarc-uri))
dmarc-fo = ("0" / "1") *(":" dmarc-afrf)
/ dmarc-afrf [":" ("0" / "1")] [":" dmarc-afrf]
/ *(dmarc-afrf ":") ("0" / "1")
dmarc-afrf = "d" / "s"
; each may appear at most once in dmarc-fo
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:
+==========+===============+
| Tag Name | Value Rule |
+==========+===============+
| p | dmarc-request |
+----------+---------------+
| t | dmarc-yorn |
+----------+---------------+
| psd | dmarc-psd |
+----------+---------------+
| np | dmarc-request |
+----------+---------------+
| sp | dmarc-request |
+----------+---------------+
| adkim | dmarc-rors |
+----------+---------------+
| aspf | dmarc-rors |
+----------+---------------+
| rua | dmarc-urilist |
+----------+---------------+
| ruf | dmarc-urilist |
+----------+---------------+
| fo | dmarc-fo |
+----------+---------------+
Table 2: Tag Names and
Values
4.9. Flow Diagram
+---------------+ +--------------------+
| Author Domain |< . . . . . . . . . . . . | Return-Path Domain |
+---------------+ . +--------------------+
| . ^
V V .
+-----------+ +--------+ +----------+ v
| MSA |<***>| DKIM | | DMARC | +----------+
| Service | | Signer | | Validator|<***>| SPF |
+-----------+ +--------+ +----------+ * | Validator|
| ^ * +----------+
| * *
V v *
+------+ (~~~~~~~~~~~~) +------+ * +----------+
| sMTA |------->( other MTAs )----->| rMTA | **>| DKIM |
+------+ (~~~~~~~~~~~~) +------+ | Validator|
| +----------+
| ^
V .
+-----------+ .
+---------+ | MDA | v
| User |<--| Filtering | +-----------+
| Mailbox | | Engine | | DKIM |
+---------+ +-----------+ | Signing |
| Domain(s) |
+-----------+
MSA = Mail Submission Agent
MDA = Mail Delivery Agent
sMTA = sending MTA
rMTA = receiving MTA
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.
4.10. DNS Tree Walk
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 <https://publicsuffix.org/>) 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:
1. 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.
2. 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.
3. 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.
4. If x < 8, remove the left-most (highest-numbered) label from the
subject domain. 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 next
lookup.
5. 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.
6. 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.
7. Determine the target for the next query by removing the left-most
label from the target of the previous 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:
* _dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com
* _dmarc.g.h.i.j.mail.example.com
* _dmarc.h.i.j.mail.example.com
* _dmarc.i.j.mail.example.com
* _dmarc.j.mail.example.com
* _dmarc.mail.example.com
* _dmarc.example.com
* _dmarc.com
4.10.1. DMARC Policy Discovery
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:
* The Author Domain
* The Organizational Domain of the Author Domain
* The PSD of the Author Domain
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 Author Domain has eight or fewer labels, the starting point
will be the immediate parent domain of the Author Domain.
* Otherwise, the starting point will be the name produced by
shortening the Author Domain as described starting in step 3 of
Section 4.10.
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 reply), which
invites the sending MTA to try again after the condition has possibly
cleared, allowing a definite DMARC conclusion to be reached ("fail
closed").
| Note: PSD policy is not used for Organizational Domains that
| have published a DMARC Policy Record. Specifically, this is
| not a mechanism to provide feedback addresses (rua/ruf) when an
| Organizational Domain has declined to do so.
4.10.2. Identifier Alignment Evaluation
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:
* The Author Domain of the message being evaluated.
* The SPF-Authenticated Identifier if there is an SPF "pass" result
for the message being evaluated.
* Any DKIM-Authenticated Identifier if one or more DKIM "pass"
results exist for the message being evaluated.
There is no need to perform Identifier Alignment Evaluations under
any of the following conditions:
* The Author Domain and the Authenticated Identifier(s) are all the
same domain, and there is a DMARC Policy Record published for that
domain. In this case, this common domain is treated as the
Organizational Domain. For example, if the common domain in
question is "mail.example.com", and there is a valid DMARC Policy
Record published at "_dmarc.mail.example.com", then
"mail.example.com" is the Organizational Domain.
* No applicable DMARC Policy Record is discovered for the Author
Domain. In this case, the DMARC mechanism does not apply to the
message in question.
* The DMARC Policy Record for the Author Domain indicates strict
alignment. In this case, a simple string comparison of the Author
Domain and the Authenticated Identifier(s) is all that is
required.
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:
1. 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.
2. 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.
3. 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 search
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 search 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 search 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".