Appendix B. Examples
Cette page resume la section correspondante du RFC 9989 et conserve les tags DMARC, noms DNS, ABNF et valeurs IANA.
The examples from Appendix B are preserved below, including SPF and DKIM alignment examples, DMARC DNS zone-file examples, third-party reporting authorization, SMTP session processing, and Tree Walk examples.
Appendix B. Examples
This section illustrates both the Domain Owner side and the Mail
Receiver side of a DMARC exchange.
B.1. Identifier Alignment Examples
The following examples illustrate the DMARC mechanism's use of
Identifier Alignment. For brevity's sake, only message header fields
and relevant SMTP commands are shown, as message bodies are not
considered when conducting DMARC checks.
B.1.1. SPF
The following SPF examples assume that SPF produces a passing result.
Alignment cannot exist if SPF does not produce a passing result.
Example 1: SPF in Strict Alignment:
MAIL FROM: <[email protected]>
From: [email protected]
Date: Fri, Feb 15 2002 16:54:30 -0800
To: [email protected]
Subject: here's a sample
In this case, the RFC5321.MailFrom domain and the Author Domain are
identical. Thus, the identifiers are in strict alignment.
Example 2: SPF in Relaxed Alignment:
MAIL FROM: <[email protected]>
From: [email protected]
Date: Fri, Feb 15 2002 16:54:30 -0800
To: [email protected]
Subject: here's a sample
In this case, the Author Domain (example.com) is a parent of the
RFC5321.MailFrom domain. Thus, the identifiers are in relaxed
alignment because they both have the same Organizational Domain
(example.com).
Example 3: No SPF Identifier Alignment:
MAIL FROM: <[email protected]>
From: [email protected]
Date: Fri, Feb 15 2002 16:54:30 -0800
To: [email protected]
Subject: here's a sample
In this case, the RFC5321.MailFrom domain is neither the same as, a
parent of, nor a child of the Author Domain. Thus, the identifiers
are not in alignment.
B.1.2. DKIM
The examples below assume that the DKIM signatures pass validation.
Alignment cannot exist with a DKIM signature that does not validate.
Example 1: DKIM in Strict Alignment:
DKIM-Signature: v=1; ...; d=example.com; ...
From: [email protected]
Date: Fri, Feb 15 2002 16:54:30 -0800
To: [email protected]
Subject: here's a sample
In this case, the DKIM "d" tag and the Author Domain have identical
DNS domains. Thus, the identifiers are in strict alignment.
Example 2: DKIM in Relaxed Alignment:
DKIM-Signature: v=1; ...; d=example.com; ...
From: [email protected]
Date: Fri, Feb 15 2002 16:54:30 -0800
To: [email protected]
Subject: here's a sample
In this case, the DKIM signature's "d" tag includes a DNS domain that
is a parent of the Author Domain. Thus, the identifiers are in
relaxed alignment, as they have the same Organizational Domain
(example.com).
Example 3: No DKIM Identifier Alignment:
DKIM-Signature: v=1; ...; d=example.net; ...
From: [email protected]
Date: Fri, Feb 15 2002 16:54:30 -0800
To: [email protected]
Subject: here's a sample
In this case, the DKIM signature's "d" tag includes a DNS domain that
is neither the same as, a parent of, nor a child of the Author
Domain. Thus, the identifiers are not in alignment.
B.2. Domain Owner Example
A Domain Owner that wants to use DMARC should have already deployed
and tested SPF and DKIM. The next step is to publish a DMARC Policy
Record for the Domain Owner's Organizational Domain.
B.2.1. Entire Domain, Monitoring Mode
The Domain Owner for "example.com" has deployed SPF and DKIM on its
messaging infrastructure. The Domain Owner wishes to begin using
DMARC with a policy that will solicit aggregate feedback from Mail
Receivers without affecting how the messages are processed in order
to:
* Confirm that its legitimate messages are authenticating correctly
* Validate that all authorized message sources have implemented
authentication measures
* Determine how many messages from other sources would be affected
by publishing a Domain Owner Assessment Policy at Enforcement
The Domain Owner accomplishes this by constructing a DMARC Policy
Record indicating that:
* The version of DMARC being used is "DMARC1" ("v=DMARC1;")
* Mail Receivers should not alter how they treat these messages
because of this DMARC Policy Record ("p=none")
* Aggregate feedback reports are sent via email to the address
"[email protected]" ("rua=mailto:dmarc-
[email protected]")
* All messages from this Organizational Domain are subject to this
policy (no "t" tag present, so the default of "n" applies)
To publish such a record, the DNS administrator for the Domain Owner
creates an entry like the following in the appropriate zone file
(following the conventional zone file format):
; DMARC Policy Record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:[email protected]" )
B.2.2. Entire Domain, Monitoring Mode, Per-Message Failure Reports
The Domain Owner from the previous example has used the aggregate
reporting to discover some messaging systems that had not yet
implemented DKIM correctly, but they are still seeing periodic
authentication failures. To diagnose these intermittent problems,
they wish to request per-message failure reports when authentication
failures occur.
Not all Mail Receivers will honor such a request, but the Domain
Owner feels that any reports it does receive will be helpful enough
to justify publishing this record. The default per-message failure
report format [RFC9991] meets the Domain Owner's needs in this
scenario.
The Domain Owner accomplishes this by adding the following to its
DMARC Policy Record from Appendix B.2.1:
* Per-message failure reports are sent via email to the address
"[email protected]" ("ruf=mailto:[email protected]")
To publish such a record, the DNS administrator for the Domain Owner
might create an entry like the following in the appropriate zone file
(following the conventional zone file format):
; DMARC Policy Record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:[email protected]; "
"ruf=mailto:[email protected]" )
B.2.3. Per-Message Failure Reports Directed to Third Party
The Domain Owner from the previous example is maintaining the same
policy but now wishes to have a third party serve as a Report
Consumer. Again, not all Mail Receivers will honor this request, but
those that do MUST implement additional checks to validate that the
third party authorizes reception of failure reports on behalf of this
domain.
The Domain Owner needs to alter its DMARC Policy Record from
Appendix B.2.2 as follows:
* Per-message failure reports are sent via email to the address
"[email protected]" ("ruf=mailto:auth-
[email protected]")
To publish such a record, the DNS administrator for the Domain Owner
might create an entry like the following in the appropriate zone file
(following the conventional zone file format):
; DMARC Policy Record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:[email protected]; "
"ruf=mailto:[email protected]" )
Because the address used in the "ruf" tag is outside the
Organizational Domain in which this record is published, conforming
Mail Receivers MUST implement additional checks as described in
Section 3 of [RFC9990]. To pass these additional checks, the Report
Consumer's Domain Owner will need to publish an additional DMARC
Policy Record as follows:
* Given the DMARC Policy Record published by the Domain Owner at
"_dmarc.example.com", the DNS administrator for the Report
Consumer will need to publish a TXT RR at
"example.com._report._dmarc.thirdparty.example.net" with the value
"v=DMARC1;" to authorize receipt of the reports.
To publish such a record, the DNS administrator for example.net might
create an entry like the following in the appropriate zone file
(following the conventional zone file format):
; zone file for thirdparty.example.net
; Accept DMARC reports on behalf of example.com
example.com._report._dmarc IN TXT "v=DMARC1;"
B.2.4. Overriding Destination Addresses
The third-party Report Consumer can also publish "rua" and "ruf" tags
in order to override the specific address published by example.com
with a different address in the same third-party domain. This may be
necessary if the third-party Report Consumer has changed its email
address or wants to guard against typos in the DMARC Policy Record of
the Author Domain. Intermediaries and other third parties should
refer to Section 3 of [RFC9990] for the full details of this
mechanism.
The third-party Report Consumer accomplishes this by adding the
following to its DMARC Policy Record from Appendix B.2.3:
* The override address for aggregate reports is "aggregate-
[email protected]" ("rua=mailto:aggregate-
[email protected]")
* The override address for failure reports is "failure-
[email protected]" ("ruf=mailto:failure-
[email protected]")
To publish such a record, the DNS administrator for example.net might
create an entry like the following in the appropriate zone file
(following the conventional zone file format):
; zone file for thirdparty.example.net
; Accept DMARC reports on behalf of example.com
; Override destination mailboxes
example.com._report._dmarc IN TXT (
"v=DMARC1; "
"rua=mailto:[email protected]; "
"ruf=mailto:[email protected]" )
In this case, only the "ruf" tag is actually overridden, because in
the previous example, failure reporting is the only reporting type
that was directed to the third-party Report Consumer.
B.2.5. Subdomain, Testing, and Multiple Aggregate Report URIs
The Domain Owner has implemented SPF and DKIM in a subdomain used for
pre-production testing of messaging services. It now wishes to
express a handling preference for messages from this subdomain that
fail DMARC validation to indicate to participating Mail Receivers
that use of this domain is not valid.
As a first step, it will express that it considers messages using
this subdomain that fail DMARC validation to be suspicious. The goal
here will be to enable examination of messages sent to mailboxes
hosted by participating Mail Receivers as a method for
troubleshooting any existing authentication issues. Aggregate
feedback reports will be sent to a mailbox within the Organizational
Domain and to a mailbox at a Report Consumer selected and authorized
to receive them by the Domain Owner.
The Domain Owner will accomplish this by constructing a DMARC Policy
Record indicating that:
* The version of DMARC being used is "DMARC1" ("v=DMARC1;")
* It is applied only to this subdomain (the DMARC Policy Record is
published at "_dmarc.test.example.com" and not
"_dmarc.example.com")
* Mail Receivers are advised that the Domain Owner considers
messages that fail to authenticate to be suspicious
("p=quarantine")
* Aggregate feedback reports are sent via email to the addresses
"[email protected]" and "example-tld-
[email protected]" ("rua=mailto:dmarc-
[email protected], mailto:example-tld-
[email protected]")
* The Domain Owner desires only that an actor performing a DMARC
validation check apply any special handling rules it might have in
place, such as rewriting the RFC53322.From header field; the
Domain Owner is testing its setup at this point and so does not
want the Domain Owner Assessment Policy to be applied ("t=y").
To publish such a record, the DNS administrator for the Domain Owner
might create an entry like the following in the appropriate zone file
(following the conventional zone file format):
; DMARC Policy Record for the domain test.example.com
_dmarc IN TXT ( "v=DMARC1; p=quarantine; "
"rua=mailto:[email protected],"
"mailto:[email protected]; "
"t=y" )
Once enough time has passed to allow for collecting enough reports to
give the Domain Owner confidence that all authorized email sent using
the subdomain is properly authenticating and passing DMARC validation
checks, then the Domain Owner can update the DMARC Policy Record to
indicate that it considers validation failures to be a clear
indication that use of the subdomain is not valid. It would do this
by altering the record to advise Mail Receivers of its position on
such messages ("p=reject") and removing the testing flag ("t=y").
To publish such a record, the DNS administrator for the Domain Owner
might create an entry like the following in the appropriate zone file
(following the conventional zone file format):
; DMARC Policy Record for the domain test.example.com
_dmarc IN TXT ( "v=DMARC1; p=reject; "
"rua=mailto:[email protected],"
"mailto:[email protected]" )
B.3. Mail Receiver Example
A Mail Receiver that wants to participate in DMARC should already be
checking SPF and DKIM and possess the ability to collect relevant
information from various email-processing stages to provide feedback
to Domain Owners (possibly via Report Consumers).
B.3.1. SMTP Session Example
An optimal DMARC-enabled Mail Receiver performs validation and
Identifier Alignment checking during the SMTP [RFC5321] conversation.
Before returning a final reply to the DATA command, the Mail
Receiver's MTA has performed:
1. An SPF check to determine an SPF-Authenticated Identifier.
2. DKIM checks that yield one or more DKIM-Authenticated
Identifiers.
3. A DMARC Policy Record lookup.
The presence of an Author Domain DMARC Policy Record indicates that
the Mail Receiver should continue with DMARC-specific processing
before returning a reply to the DATA command.
Given a DMARC Policy Record and the set of Authenticated Identifiers,
the Mail Receiver checks to see if the Authenticated Identifiers
align with the Author Domain (taking into consideration any strict
versus relaxed options found in the DMARC Policy Record).
For example, the following sample data is considered to be from a
piece of email originating from the Domain Owner of "example.com":
Author Domain: example.com
SPF-authenticated Identifier: mail.example.com
DKIM-authenticated Identifier: example.com
DMARC Policy Record:
"v=DMARC1; p=reject; aspf=r;
rua=mailto:[email protected]"
In the above sample, the SPF-Authenticated Identifier and the DKIM-
Authenticated Identifier both align with the Author Domain. The Mail
Receiver considers the above email to pass the DMARC check, avoiding
the "reject" policy that is requested to be applied to email that
fails the DMARC validation check.
If no Authenticated Identifiers align with the Author Domain, then
the Mail Receiver applies the Domain Owner Assessment Policy.
However, before this action is taken, the Mail Receiver can consult
external information to override the Domain Owner Assessment Policy.
For example, if the Mail Receiver knows that this particular email
came from a known and trusted forwarder (that happens to break both
SPF and DKIM), then the Mail Receiver may choose to ignore the Domain
Owner Assessment Policy.
The Mail Receiver is now ready to reply to the DATA command. If the
DMARC check yields that the message is to be rejected, then the Mail
Receiver replies with a 5xy code to inform the sender of failure. If
the DMARC check cannot be resolved due to transient network errors,
then the Mail Receiver replies with a 4xy code to inform the sender
as to the need to reattempt delivery later. If the DMARC check
yields a passing message, then the Mail Receiver continues with email
processing, perhaps using the result of the DMARC check as an input
to additional processing modules such as a domain reputation query.
Before exiting DMARC-specific processing, the Mail Receiver checks to
see if the Author Domain DMARC Policy Record requests reporting based
on an Authentication Failure Reporting Format (AFRF). If so, then
the Mail Receiver can emit an AFRF to the reporting address supplied
in the DMARC Policy Record.
At the exit of DMARC-specific processing, the Mail Receiver captures
(through logging or direct insertion into a data store) the result of
DMARC processing. Captured information is used to build feedback for
Domain Owner consumption. This is unnecessary if the Domain Owner
has not requested aggregate reports, i.e., no "rua" tag was found in
the policy record.
B.4. Organizational and Policy Domain Tree Walk Examples
If an Author Domain has no DMARC Policy Record, a Mail Receiver uses
a Tree Walk to find the DMARC Policy.
If the DMARC Policy Record allows relaxed alignment and the SPF- or
DKIM-Authenticated Identifiers are different from the Author Domain,
a Mail Receiver uses a Tree Walk to discover the respective
Organizational Domains to determine Identifier Alignment.
B.4.1. Simple Organizational and Policy Example
A Mail Receiver receives an email with:
* Author Domain: example.com
* RFC5321.MailFrom Domain: example.com
* DKIM-Authenticated Identifier: signing.example.com
In this example, "_dmarc.example.com" and
"_dmarc.signing.example.com" both have DMARC Policy Records, while
"_dmarc.com" does not. If SPF or DKIM yield "pass" results, they
still have to be aligned to support a DMARC pass. Since not all
domains are the same, if the alignment is relaxed, then the Tree Walk
is performed to determine the Organizational Domain for each.
To determine the Organizational Domain for the Author Domain, query
"_dmarc.example.com" and "_dmarc.com"; "example.com" is the last
element of the DNS tree with a DMARC Policy Record, so it is the
Organizational Domain for "example.com".
For the RFC5321.MailFrom domain, the Organizational Domain already
found for "example.com" is "example.com", so SPF is aligned.
To determine the Organizational Domain for the DKIM-Authenticated
Identifier, query "_dmarc.signing.example.com", "_dmarc.example.com",
and "_dmarc.com". Both "signing.example.com" and "example.com" have
DMARC Policy Records, but "example.com" is the highest element in the
tree with a DMARC Policy Record (it has the fewest labels), so
"example.com" is the Organizational Domain. Since this is also the
Organizational Domain for the Author Domain, DKIM is aligned for
relaxed alignment.
Since both SPF and DKIM are aligned, they can be used to determine if
the message has a DMARC "pass" result. If the result is not "pass",
then the policy domain's DMARC Policy Record is used to determine the
appropriate policy. In this case, since the RFC5322.From domain has
a DMARC Policy Record, that is the policy domain.
B.4.2. Deep Tree Walk Example
A Mail Receiver receives an email with:
* Author Domain: a.b.c.d.e.f.g.h.i.j.k.example.com
* RFC5321.MailFrom Domain: example.com
* DKIM-Authenticated Identifier: signing.example.com
Both "_dmarc.example.com" and "_dmarc.signing.example.com" have DMARC
Policy Records, while "_dmarc.com" does not. If SPF or DKIM yield
"pass" results, they still have to be aligned to support a DMARC
pass. Since not all domains are the same, if the alignment is
relaxed, then the Tree Walk is performed to determine the
Organizational Domain for each.
To determine the Organizational Domain for the Author Domain, query
"_dmarc.a.b.c.d.e.f.g.h.i.j.k.example.com"; then query
"_dmarc.g.h.i.j.k.example.com" (skipping the intermediate names);
then query "_dmarc.h.i.j.k.example.com", "_dmarc.i.j.k.example.com",
"_dmarc.j.k.example.com", "_dmarc.k.example.com",
"_dmarc.example.com", and "_dmarc.com". None of
"a.b.c.d.e.f.g.h.i.j.k.example.com", "g.h.i.j.k.example.com",
"h.i.j.k.example.com", "i.j.k.example.com", "j.k.example.com", or
"k.example.com" have a DMARC Policy Record.
Since "example.com" is the last element of the DNS tree with a DMARC
Policy Record, it is the Organizational Domain for
"a.b.c.d.e.f.g.h.i.j.k.example.com".
For the RFC5321.MailFrom domain, the Organizational Domain already
found for "example.com" is "example.com". SPF is aligned.
For the DKIM-Authenticated Identifier, query
"_dmarc.signing.example.com", "_dmarc.example.com", and "_dmarc.com".
Both "signing.example.com" and "example.com" have DMARC Policy
Records, but "example.com" is the highest element in the tree with a
DMARC Policy Record, so "example.com" is the Organizational Domain.
Since this is also the Organizational Domain for the Author Domain,
DKIM is aligned for relaxed alignment.
Since both SPF and DKIM are aligned, they can be used to determine if
the message has a DMARC "pass" result. If the results for both are
not "pass", then the policy domain's DMARC Policy Record is used to
determine the appropriate policy. In this case, the Author Domain
does not have a DMARC Policy Record, so the policy domain is the
highest element in the DNS tree with a DMARC Policy Record,
example.com.
B.4.3. Example with a PSD DMARC Policy Record
In rare cases, a PSD publishes a DMARC Policy Record with a "psd"
tag, which the Tree Walk must take into account.
A Mail Receiver receives an email with:
* Author Domain: giant.bank.example
* RFC5321.MailFrom Domain: mail.giant.bank.example
* DKIM-Authenticated Identifier: mail.mega.bank.example
In this case, "_dmarc.bank.example" has a DMARC Policy Record that
includes the "psd=y" tag, and "_dmarc.example" does not have a DMARC
Policy Record. While "_dmarc.giant.bank.example" has a DMARC Policy
Record without a "psd" tag, "_dmarc.mega.bank.example" and
"_dmarc.mail.mega.bank.example" have no DMARC Policy Records.
Since the three domains are all different, Tree Walks find their
Organizational Domains to see which are aligned.
For the Author Domain "giant.bank.example", the Tree Walk finds both
the DMARC Policy Record at "_dmarc.giant.bank.example" and then the
DMARC Policy Record at "_dmarc.bank.example" and stops because of the
"psd=y" flag. The Organizational Domain is "giant.bank.example"
because it is the domain directly below the one with "psd=y". Since
the Organizational Domain has a DMARC Policy Record, it is also the
policy domain.
For the RFC5321.MailFrom domain "mail.giant.bank.example", the Tree
Walk finds no DMARC Policy Record at "_dmarc.mail.giant.bank.example"
but does find both the DMARC Policy Record at
"_dmarc.giant.bank.example" and then the DMARC Policy Record at
"_dmarc.bank.example" and stops because of the "psd=y" flag. Again,
the Organizational Domain is "giant.bank.example" because it is the
domain directly below the one with "psd=y". Since this is the same
Organizational Domain as the Author Domain, SPF is aligned.
For the DKIM-Authenticated Identifier "mail.mega.bank.example", the
Tree Walk finds no DMARC Policy Records at
"_dmarc.mail.mega.bank.example" or "_dmarc.mega.bank.example", then
finds the DMARC Policy Record at "_dmarc.bank.example", and stops
because of the "psd=y" flag. The Organizational Domain is
"mega.bank.example", so DKIM is not aligned.
Since SPF is aligned, it can be used to determine if the message has
a DMARC "pass" result. If the result is not "pass", then the policy
domain's DMARC Policy Record is used to determine the appropriate
policy.
B.5. Utilization of Aggregate Feedback: Example
Aggregate feedback is consumed by Domain Owners to enable their
understanding of how a given domain is being processed by the Mail
Receiver. Aggregate reporting data on emails that pass all
underlying authentication checks is used by Domain Owners to validate
that their authentication practices remain accurate. For example, if
a third party is sending on behalf of a Domain Owner, the Domain
Owner can use aggregate report data to validate ongoing
authentication practices of the third party.
Data on email that only partially passes underlying authentication
checks provides visibility into problems that need to be addressed by
the Domain Owner. For example, if either SPF or DKIM fails to
produce an Authenticated Identifier, the Domain Owner is provided
with enough information to either directly correct the problem or
understand where authentication-breaking changes are being introduced
in the email transmission path. If authentication-breaking changes
due to the email transmission path cannot be directly corrected, then
the Domain Owner at least maintains an understanding of the effect of
DMARC-based policies upon the Domain Owner's email.
Data on email that fails all underlying authentication checks
provides baseline visibility on how the Domain Owner's domain is
being received at the Mail Receiver. Based on this visibility, the
Domain Owner can begin deployment of authentication technologies
across uncovered email sources if the mail that is failing the checks
was generated by or on behalf of the Domain Owner. Data regarding
failing authentication checks can also allow the Domain Owner to come
to an understanding of how its domain is being misused.