Appendix B. 示例 (Examples)
Appendix B 的示例原样保留如下, 包括 SPF 和 DKIM 对齐示例、DMARC DNS zone-file 示例、第三方报告授权、SMTP 会话处理和 Tree Walk 示例. 示例中的邮件地址、DNS 记录、SMTP 命令、header field、DKIM tag、DMARC tag 和域名是协议样例数据, 必须保持原文, 以便读者可以逐字对照 RFC 原始流程.
这些示例展示 DMARC 交换的两个方面: 域所有者如何发布策略记录并请求报告, 邮件接收方如何依据 SPF、DKIM 和 DMARC 评估结果处理消息. SPF 示例重点比较 RFC5321.MailFrom 域与作者域之间的关系; DKIM 示例重点比较 DKIM-Signature 中 d= 域与作者域之间的关系. 严格对齐要求两个域完全相同, 宽松对齐允许它们共享同一组织域.
DNS 示例说明 _dmarc 记录如何表达 p, sp, rua, ruf, adkim, aspf, pct 等标签. 这些标签名和取值是 DMARC 语法的一部分, 不翻译. 读者应关注每个记录如何从监控模式逐步过渡到更强策略, 以及子域策略如何覆盖或继承组织域策略.
第三方报告授权示例说明当报告投递目标不在被报告域内时, 接收方如何通过额外 DNS 查询确认授权. SMTP 会话处理示例则展示接收方在消息进入时如何组合 SPF、DKIM 和 DMARC 结果, 并据此决定接受、隔离或拒绝. Tree Walk 示例用于解释策略发现过程如何沿 DNS 名称层级向上查找, 直到找到适用记录或达到公共后缀边界.
下方 text 块保留原始 RFC 示例. 中文导读提供阅读路径, 但不替代表格、命令和 DNS 记录本身. 实现者在编写测试向量时, 应直接使用原文中的字段和记录格式, 再结合本 RFC 正文中的规范性要求判断预期结果.
阅读本附录时, 可以按以下顺序理解示例. B.1 先展示 Identifier Alignment 的核心判断: SPF 通过时, 比较 RFC5321.MailFrom 域与 Author Domain; DKIM 通过时, 比较 DKIM-Signature 的 d= 域与 Author Domain. strict alignment 要求域完全一致, relaxed alignment 则允许它们共享同一 Organizational Domain. 这些示例刻意只展示相关邮件头字段和 SMTP 命令, 因为 DMARC 检查不依赖消息正文.
B.2 从 Domain Owner 视角展示 DMARC Policy Record 的发布过程. 监控模式通常使用 p=none 并配置 rua 收集 aggregate feedback, 以确认合法消息能通过认证, 检查授权发送源是否部署 SPF/DKIM, 并估计未来执行更强策略时会影响多少消息. 随后示例逐步展示如何对整个域, 子域和不同组织结构发布策略, 以及如何使用 pct, sp, np, adkim, aspf, fo, ruf 等 tag 调整策略范围, 对齐方式, 报告目标和失败报告触发条件.
B.3 和 B.4 展示 Mail Receiver 侧处理. 接收方需要在 SMTP 会话和消息处理期间组合 SPF, DKIM, RFC5322.From, DMARC policy discovery 和本地策略. 示例中的接受, 隔离或拒绝动作反映了 DMARC 评估结果与 Domain Owner Assessment Policy 的交互关系. 对实现者而言, 重要的是不要把示例里的域名和地址当成真实部署建议; 它们是为了展示状态转移, 对齐判断, DNS 查询和报告授权流程.
B.5 展示外部报告目标授权. 当 rua 或 ruf 指向不同 Organizational Domain 的主机时, 接收方必须通过指定的 DNS 名称查找确认记录. 该机制防止攻击者把大量 DMARC 报告重定向给未授权第三方. 示例中的 DNS label, TXT record 和 URI 展示授权记录如何绑定报告来源域和目标域.
B.6 和 B.7 展示 Tree Walk 和相关边界情况. Tree Walk 的目标是在 DNS 层次中找到适用的 DMARC Policy Record, 同时避免越过 Public Suffix 或不适用的组织边界. 这些示例对实现策略发现逻辑很有用, 尤其是在子域没有显式记录, 组织域发布了继承策略, 或 PSD DMARC 参与策略评估时. 示例中的 DNS 区域片段和查询结果必须保持英文和原始格式, 因为它们直接对应可测试的输入和输出.
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.