rfc9989v1.txt   rfc9989.txt 
skipping to change at line 543 skipping to change at line 543
3.2.15. Public Suffix Domain (PSD) 3.2.15. Public Suffix Domain (PSD)
Some domains allow the registration of subdomains that are "owned" by Some domains allow the registration of subdomains that are "owned" by
independent organizations. Real-world examples of these domains are independent organizations. Real-world examples of these domains are
".com", ".org", ".us", and ".co.uk", to name just a few. These ".com", ".org", ".us", and ".co.uk", to name just a few. These
domains are called "Public Suffix Domains" (PSDs). For example, domains are called "Public Suffix Domains" (PSDs). For example,
"ietf.org" is a registered domain name, and ".org" is its PSD. "ietf.org" is a registered domain name, and ".org" is its PSD.
3.2.16. Public Suffix Operator (PSO) 3.2.16. Public Suffix Operator (PSO)
A Public Suffix Operator is an organization that manages operations A PSO is an organization that manages operations within a PSD,
within a PSD, particularly the DNS records published for names at and particularly the DNS records published for names at and under that
under that domain name. domain name.
3.2.17. PSO-Controlled Domain Names 3.2.17. PSO-Controlled Domain Names
PSO-Controlled Domain Names are names in the DNS that are managed by PSO-Controlled Domain Names are names in the DNS that are managed by
a PSO. PSO-Controlled Domain Names may have one label (e.g., ".com") a PSO. PSO-Controlled Domain Names may have one label (e.g., ".com")
or more (e.g., ".co.uk"), depending on the PSD's policy. or more (e.g., ".co.uk"), depending on the PSO's policy.
3.2.18. Report Consumer 3.2.18. Report Consumer
A Report Consumer is an operator that receives reports from another A Report Consumer is an operator that receives reports from another
operator implementing the reporting mechanisms described in [RFC9990] operator implementing the reporting mechanisms described in [RFC9990]
and [RFC9991]. This term applies collectively to the system and [RFC9991]. This term applies collectively to the system
components that receive and process these reports and the components that receive and process these reports and the
organizations that operate those components. organizations that operate those components.
Report Consumers can receive reports concerning domains for which the Report Consumers can receive reports concerning domains for which the
Report Consumer is also the Domain Owner (Section 3.2.7) or PSO Report Consumer is also the Domain Owner (Section 3.2.7) or PSO
(Section 3.2.16) or concerning domains that belong to another (Section 3.2.16) or concerning domains that belong to another
operator entirely. The DMARC mechanism permits a Domain Owner to act operator entirely. The DMARC mechanism permits a Domain Owner to act
as a Report Consumer for its domain(s) and/or to designate third as a Report Consumer for its domain(s) and/or to designate a third
parties to so act. See Section 11.6 for further discussion of such party to act as a Report Consumer. See Section 11.6 for further
designation. discussion of such designation.
4. Overview and Key Concepts 4. Overview and Key Concepts
This section provides a general overview of the design and operation This section provides a general overview of the design and operation
of the DMARC environment. of the DMARC environment.
4.1. DMARC Basics 4.1. DMARC Basics
DMARC permits a Domain Owner (Section 3.2.7) or PSO (Section 3.2.16) 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 to enable validation of an Author Domain's (Section 3.2.2) use in an
skipping to change at line 765 skipping to change at line 765
(Section 3.2.2) of "example.com" would issue a TXT query to the DNS (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 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 to participate in DMARC validation by Mail Receivers simply by
not publishing a DMARC Policy Record for its Author Domain(s). not publishing a DMARC Policy Record for its Author Domain(s).
DMARC Policy Records can also apply to subdomains of the name at 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 which they are published in the DNS if the record is published at an
Organizational Domain (Section 3.2.14) for the subdomains. The Organizational Domain (Section 3.2.14) for the subdomains. The
Domain Owner Assessment Policy (Section 3.2.8) that applies to the Domain Owner Assessment Policy (Section 3.2.8) that applies to the
subdomains can be identical to the Domain Owner Assessment Policy subdomains can be identical to the Domain Owner Assessment Policy
that applies to the Organizational Domain or different, depending on that applies to the Organizational Domain but it does not have to be
the presence or absence of certain values in the DMARC Policy Record. identical. Whether or not it is identical depends on the presence or
See Section 4.7 for more details. 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 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 domain names and the nature of the query it performs. The query
requirement matches with the DNS for obtaining simple parametric requirement matches with the DNS for obtaining simple parametric
information. It uses an established method of storing the information. It uses an established method of storing the
information associated with the domain name targeted by a DNS query, information associated with the domain name targeted by a DNS query,
specifically an isolated TXT record that is restricted to the DMARC specifically an isolated TXT record that is restricted to the DMARC
context. Using the DNS as the query service has the benefit of context. Using the DNS as the query service has the benefit of
reusing an extremely well-established operations, administration, and reusing an extremely well-established operations, administration, and
management infrastructure, rather than creating a new one. management infrastructure, rather than creating a new one.
skipping to change at line 808 skipping to change at line 809
it to inform its handling decisions for messages that undergo DMARC it to inform its handling decisions for messages that undergo DMARC
validation checks and do not produce a result of "pass". Mail validation checks and do not produce a result of "pass". Mail
handling considerations based on Domain Owner Assessment Policy handling considerations based on Domain Owner Assessment Policy
enforcement are discussed below in Section 5.4. enforcement are discussed below in Section 5.4.
4.6. DMARC Reporting URIs 4.6. DMARC Reporting URIs
[RFC3986] defines a syntax for identifying a resource. The DMARC [RFC3986] defines a syntax for identifying a resource. The DMARC
mechanism uses this as the format by which a Domain Owner 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) (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 for the two report types that are supported.
format (Section 4.7) allows for a list of these URIs to be provided,
with each URI separated by commas (ASCII 0x2c). 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. A formal definition is provided in Section 4.8.
4.7. DMARC Policy Record Format 4.7. DMARC Policy Record Format
DMARC Policy Records follow the extensible "tag-value" syntax for DMARC Policy Records follow the extensible "tag-value" syntax for
DNS-based key records defined in DKIM [RFC6376]. DNS-based key records defined in DKIM [RFC6376].
Section 9 creates a registry for known DMARC tags and registers the Section 9 creates a registry for known DMARC tags and registers the
initial set defined in this document. Only tags defined in that initial set defined in this document. Only tags defined in that
skipping to change at line 961 skipping to change at line 965
Receivers MUST NOT generate failure reports for the domain. URIs Receivers MUST NOT generate failure reports for the domain. URIs
involving schemes not supported by Mail Receivers MUST be ignored. involving schemes not supported by Mail Receivers MUST be ignored.
[RFC9990] discusses considerations that apply when the domain name [RFC9990] discusses considerations that apply when the domain name
of a URI differs from that of the domain advertising the policy. of a URI differs from that of the domain advertising the policy.
See Section 11.6 for additional considerations. See Section 11.6 for additional considerations.
sp: Domain Owner Assessment Policy for all subdomains of the given sp: Domain Owner Assessment Policy for all subdomains of the given
Organizational Domain (plain-text; OPTIONAL). Indicates the Organizational Domain (plain-text; OPTIONAL). Indicates the
message handling preference of the Domain Owner or PSO for mail message handling preference of the Domain Owner or PSO for mail
using an existing subdomain of the prevailing Organizational using an existing subdomain of the prevailing Organizational
Domain for and not passing DMARC validation. It applies only to Domain and not passing DMARC validation. It applies only to
existing subdomains of the message's Organizational Domain in the existing subdomains of the message's Organizational Domain in the
DNS hierarchy and not to the Organizational Domain itself. Its DNS hierarchy and not to the Organizational Domain itself. Its
syntax is identical to that of the "p" tag defined above. If both 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 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 applicable, the policy specified by the "p" tag MUST be applied
for subdomains. Note that "sp" will be ignored for DMARC Policy for subdomains. Note that "sp" will be ignored for DMARC Policy
Records published on subdomains of Organizational Domains and PSDs Records published on subdomains of Organizational Domains and PSDs
due to the effect of the DMARC policy discovery (Section 4.10.1). due to the effect of the DMARC policy discovery (Section 4.10.1).
t: DMARC policy test mode (plain-text; OPTIONAL; default is "n"). t: DMARC policy test mode (plain-text; OPTIONAL; default is "n").
skipping to change at line 1009 skipping to change at line 1013
v: Version (plain-text; REQUIRED). Identifies the record retrieved v: Version (plain-text; REQUIRED). Identifies the record retrieved
as a DMARC Policy Record. This tag MUST be the first tag in the 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 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 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 tag is absent, or the value is not "DMARC1", then the entire
record MUST be ignored. record MUST be ignored.
4.8. Formal Definition 4.8. Formal Definition
A DMARC Policy Record MUST comply with the formal definition of same A DMARC Policy Record MUST comply with the formal definition found in
found in this section. Unknown tags MUST be ignored. Syntax errors this section. Unknown tags MUST be ignored. Syntax errors in the
in the remainder of the record MUST be discarded in favor of default remainder of the record MUST be discarded in favor of default values
values (if any) or ignored outright. (if any) or ignored outright.
Because unknown tags MUST be ignored, the addition of a new tag into 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 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 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 value), but a change to any existing tags does require a new version
of DMARC. of DMARC.
The formal definition of the DMARC Policy Record format, using ABNF The formal definition of the DMARC Policy Record format, using ABNF
syntax as described in [RFC5234] and [RFC7405], is as follows: syntax as described in [RFC5234] and [RFC7405], is as follows:
skipping to change at line 1058 skipping to change at line 1062
; specialized syntax of DMARC values ; specialized syntax of DMARC values
dmarc-request = "none" / "quarantine" / "reject" dmarc-request = "none" / "quarantine" / "reject"
dmarc-yorn = "y" / "n" dmarc-yorn = "y" / "n"
dmarc-psd = "y" / "n" / "u" dmarc-psd = "y" / "n" / "u"
dmarc-rors = "r" / "s" dmarc-rors = "r" / "s"
dmarc-urilist = (dmarc-uri / obs-dmarc-uri) *(*WSP "," *WSP (dmarc-uri / obs-dmarc-uri)) dmarc-urilist = (dmarc-uri / obs-dmarc-uri)
*(*WSP "," *WSP (dmarc-uri / obs-dmarc-uri))
dmarc-fo = ("0" / "1") *(":" dmarc-afrf) dmarc-fo = ("0" / "1") *(":" dmarc-afrf)
/ dmarc-afrf [":" ("0" / "1")] [":" dmarc-afrf] / dmarc-afrf [":" ("0" / "1")] [":" dmarc-afrf]
/ *(dmarc-afrf ":") ("0" / "1") / *(dmarc-afrf ":") ("0" / "1")
dmarc-afrf = "d" / "s" dmarc-afrf = "d" / "s"
; each may appear at most once in dmarc-fo ; each may appear at most once in dmarc-fo
In each dmarc-tag, the dmarc-value has a syntax that depends on the 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 tag name. The ABNF rule for each dmarc-value is specified in the
skipping to change at line 1128 skipping to change at line 1133
+-----------+ . +-----------+ .
+---------+ | MDA | v +---------+ | MDA | v
| User |<--| Filtering | +-----------+ | User |<--| Filtering | +-----------+
| Mailbox | | Engine | | DKIM | | Mailbox | | Engine | | DKIM |
+---------+ +-----------+ | Signing | +---------+ +-----------+ | Signing |
| Domain(s) | | Domain(s) |
+-----------+ +-----------+
MSA = Mail Submission Agent MSA = Mail Submission Agent
MDA = Mail Delivery Agent MDA = Mail Delivery Agent
sMTA = sending MTA
rMTA = receiving MTA
The above diagram shows a typical flow of messages through a DMARC- The above diagram shows a typical flow of messages through a DMARC-
aware system. Dashed lines (e.g., -->) denote the actual message aware system. Dashed lines (e.g., -->) denote the actual message
flow, dotted lines (e.g., < . . >) represent DNS queries used to flow, dotted lines (e.g., < . . >) represent DNS queries used to
retrieve message policy related to the supported message retrieve message policy related to the supported message
authentication schemes, and starred lines (e.g., <**>) indicate data authentication schemes, and starred lines (e.g., <**>) indicate data
exchange between message-handling modules and message authentication exchange between message-handling modules and message authentication
modules. "sMTA" is the sending MTA, and "rMTA" is the receiving MTA. modules.
Put simply, when a message reaches a DMARC-aware rMTA, a DNS query 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 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 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 rMTA will use the results of SPF and DKIM validation checks to
determine the DMARC validation status. The DMARC validation status determine the DMARC validation status. The DMARC validation status
can then factor into the message handling decision made by the can then factor into the message handling decision made by the
recipient's mail system. recipient's mail system.
More details on specific actions for the parties involved can be More details on specific actions for the parties involved can be
skipping to change at line 1180 skipping to change at line 1187
guidance for the frequency of regular retrieval of the PSL by Mail guidance for the frequency of regular retrieval of the PSL by Mail
Receivers participating in DMARC. [RFC7489] acknowledged the Receivers participating in DMARC. [RFC7489] acknowledged the
possibility of interoperability issues caused by Mail Receivers possibility of interoperability issues caused by Mail Receivers
choosing different PSLs and even suggested that if a more reliable choosing different PSLs and even suggested that if a more reliable
and secure method for determining the Organizational Domain could be and secure method for determining the Organizational Domain could be
created, that method should replace reliance on a PSL. created, that method should replace reliance on a PSL.
This update to DMARC offers more flexibility to Domain Owners, This update to DMARC offers more flexibility to Domain Owners,
especially those with large, complex organizations that might want to especially those with large, complex organizations that might want to
apply decentralized management to their DNS and their DMARC Policy apply decentralized management to their DNS and their DMARC Policy
Records. Rather than just using a Public Suffix List to help Records. Rather than just using a PSL to help identify an
identify an Organizational Domain, this update defines a discovery Organizational Domain, this update defines a discovery technique
technique known colloquially as the "DNS Tree Walk". The target of known colloquially as the "DNS Tree Walk". The target of any DNS
any DNS Tree Walk is discovery of a valid DMARC Policy Record, and Tree Walk is discovery of a valid DMARC Policy Record, and its use in
its use in determining an Organizational Domain allows for publishing determining an Organizational Domain allows for publishing DMARC
DMARC Policy Records at multiple points in the namespace. Policy Records at multiple points in the namespace.
However, this flexibility comes at a possible cost. Since the DNS However, this flexibility comes at a possible cost. Since the DNS
Tree Walk relies on the Mail Receiver making a series of DNS queries, 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 the potential exists for an ill-intentioned Domain Owner to send mail
with Author Domains with tens or even hundreds of labels for the with Author Domains with tens or even hundreds of labels for the
purpose of executing a denial-of-service attack on the Mail Receiver. 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 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 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 result in more than eight DNS queries. Observed data at the time of
publication showed that Author Domains with up to seven labels were publication showed that Author Domains with up to seven labels were
skipping to change at line 1273 skipping to change at line 1280
4.10.1. DMARC Policy Discovery 4.10.1. DMARC Policy Discovery
The DMARC Policy Record to be applied to an email message will be the 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 record found at any of the following locations, listed from highest
preference to lowest: preference to lowest:
* The Author Domain * The Author Domain
* The Organizational Domain of the Author Domain * The Organizational Domain of the Author Domain
* The Public Suffix Domain of the Author Domain * The PSD of the Author Domain
Policy discovery first starts with a query for a valid DMARC Policy Policy discovery first starts with a query for a valid DMARC Policy
Record at the name created by prepending the label "_dmarc" to the Record at the name created by prepending the label "_dmarc" to the
Author Domain of the message being evaluated. If a valid DMARC Author Domain of the message being evaluated. If a valid DMARC
Policy Record is found there, then this is the DMARC Policy Record to Policy Record is found there, then this is the DMARC Policy Record to
be applied to the message; however, this does not necessarily mean be applied to the message; however, this does not necessarily mean
that the Author Domain is the Organizational Domain to be used in that the Author Domain is the Organizational Domain to be used in
Identifier Alignment checks. Whether this is also the Organizational Identifier Alignment checks. Whether this is also the Organizational
Domain is dependent on the value of the "psd" tag, if present, or Domain is dependent on the value of the "psd" tag, if present, or
some conditions described in Section 4.10.2. some conditions described in Section 4.10.2.
skipping to change at line 1302 skipping to change at line 1309
* Otherwise, the starting point will be the name produced by * Otherwise, the starting point will be the name produced by
shortening the Author Domain as described starting in step 3 of shortening the Author Domain as described starting in step 3 of
Section 4.10. Section 4.10.
If the DMARC Policy Record to be applied is that of the Author 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" Domain, then the Domain Owner Assessment Policy is taken from the "p"
tag of the record. tag of the record.
If the DMARC Policy Record to be applied is that of either the If the DMARC Policy Record to be applied is that of either the
Organizational Domain or the Public Suffix Domain and the Author Organizational Domain or the PSD and the Author Domain is a subdomain
Domain is a subdomain of that domain, then the Domain Owner of that domain, then the Domain Owner Assessment Policy is taken from
Assessment Policy is taken from the "sp" tag (if any) if the Author the "sp" tag (if any) if the Author Domain exists or the "np" tag (if
Domain exists or the "np" tag (if any) if the Author Domain does not any) if the Author Domain does not exist. In the absence of
exist. In the absence of applicable "sp" or "np" tags, the "p" tag applicable "sp" or "np" tags, the "p" tag policy is used for
policy is used for subdomains. subdomains.
If a retrieved DMARC Policy Record does not contain a valid "p" tag, 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: or contains an "sp" or "np" tag that is not valid, then:
* If a "rua" tag is present and contains at least one syntactically * If a "rua" tag is present and contains at least one syntactically
valid reporting URI, the Mail Receiver MUST act as if a record valid reporting URI, the Mail Receiver MUST act as if a record
containing "p=none" was retrieved and continue processing. containing "p=none" was retrieved and continue processing.
* Otherwise, the Mail Receiver applies no DMARC processing to this * Otherwise, the Mail Receiver applies no DMARC processing to this
message. message.
skipping to change at line 1333 skipping to change at line 1340
Handling of DNS errors when querying for the DMARC Policy Record is Handling of DNS errors when querying for the DMARC Policy Record is
left to the discretion of the Mail Receiver. For example, to ensure left to the discretion of the Mail Receiver. For example, to ensure
minimal disruption of mail flow, transient errors could result in minimal disruption of mail flow, transient errors could result in
delivery of the message ("fail open"), or they could result in the delivery of the message ("fail open"), or they could result in the
message being temporarily rejected (i.e., an SMTP 4yx reply), which message being temporarily rejected (i.e., an SMTP 4yx reply), which
invites the sending MTA to try again after the condition has possibly invites the sending MTA to try again after the condition has possibly
cleared, allowing a definite DMARC conclusion to be reached ("fail cleared, allowing a definite DMARC conclusion to be reached ("fail
closed"). closed").
Note: PSD policy is not used for Organizational Domains that have | Note: PSD policy is not used for Organizational Domains that
published a DMARC Policy Record. Specifically, this is not a | have published a DMARC Policy Record. Specifically, this is
mechanism to provide feedback addresses (rua/ruf) when an | not a mechanism to provide feedback addresses (rua/ruf) when an
Organizational Domain has declined to do so. | Organizational Domain has declined to do so.
4.10.2. Identifier Alignment Evaluation 4.10.2. Identifier Alignment Evaluation
It may be necessary to perform multiple DNS Tree Walks to determine It may be necessary to perform multiple DNS Tree Walks to determine
if an Authenticated Identifier and an Author Domain are in alignment, if an Authenticated Identifier and an Author Domain are in alignment,
meaning that they have either the same Organizational Domain (relaxed meaning that they have either the same Organizational Domain (relaxed
alignment) or that they're identical (strict alignment). DNS Tree alignment) or that they're identical (strict alignment). DNS Tree
Walks done to discover an Organizational Domain for use in Identifier Walks done to discover an Organizational Domain for use in Identifier
Alignment Evaluation might start at any of the following locations: Alignment Evaluation might start at any of the following locations:
* The Author Domain of the message being evaluated. * The Author Domain of the message being evaluated.
* The SPF-Authenticated Identifier if there is an SPF "pass" result * The SPF-Authenticated Identifier if there is an SPF "pass" result
for the message being evaluated. for the message being evaluated.
* Any DKIM-Authenticated Identifier if one or more DKIM "pass" * Any DKIM-Authenticated Identifier if one or more DKIM "pass"
results exist for the message being evaluated. results exist for the message being evaluated.
Note: There is no need to perform Identifier Alignment Evaluations There is no need to perform Identifier Alignment Evaluations under
under any of the following conditions: any of the following conditions:
* The Author Domain and the Authenticated Identifier(s) are all the * The Author Domain and the Authenticated Identifier(s) are all the
same domain, and there is a DMARC Policy Record published for that same domain, and there is a DMARC Policy Record published for that
domain. In this case, this common domain is treated as the domain. In this case, this common domain is treated as the
Organizational Domain. For example, if the common domain in Organizational Domain. For example, if the common domain in
question is "mail.example.com", and there is a valid DMARC Policy question is "mail.example.com", and there is a valid DMARC Policy
Record published at "_dmarc.mail.example.com", then Record published at "_dmarc.mail.example.com", then
"mail.example.com" is the Organizational Domain. "mail.example.com" is the Organizational Domain.
* No applicable DMARC Policy Record is discovered for the Author * No applicable DMARC Policy Record is discovered for the Author
skipping to change at line 1434 skipping to change at line 1441
5. DMARC Participation 5. DMARC Participation
This section describes the actions for participating in DMARC for This section describes the actions for participating in DMARC for
each of three unique entities -- Domain Owners, PSOs, and Mail each of three unique entities -- Domain Owners, PSOs, and Mail
Receivers. Receivers.
5.1. Domain Owner Actions 5.1. Domain Owner Actions
A Domain Owner (Section 3.2.7) wishing to fully participate in DMARC A Domain Owner (Section 3.2.7) wishing to fully participate in DMARC
will publish a DMARC Policy Record (Section 3.2.6) to cover each will:
Author Domain (Section 3.2.2) and corresponding Organizational Domain
(Section 3.2.14) to which DMARC validation should apply; will send * Publish a DMARC Policy Record (Section 3.2.6) to cover each Author
email that produces at least one -- preferably two -- Authenticated Domain (Section 3.2.2) and corresponding Organizational Domain
Identifiers (Section 3.2.1) that align with the Author Domain; will (Section 3.2.14) to which DMARC validation should apply;
receive and monitor the content of DMARC aggregate reports; and will
correct any authentication shortcomings in mail making authorized use * Send email that produces at least one -- preferably two --
of its domains. Authenticated Identifiers (Section 3.2.1) that align with the
Author Domain;
* Receive and monitor the content of DMARC aggregate reports;
* Correct authentication shortcomings in mail making authorized use
of its domains.
The following sections describe how to achieve this. The following sections describe how to achieve this.
5.1.1. Publish an SPF Record for an Aligned Domain 5.1.1. Publish an SPF Record for an Aligned Domain
To configure SPF for DMARC, the Domain Owner MUST send mail that has To configure SPF for DMARC, the Domain Owner MUST send mail that has
an RFC5321.MailFrom domain that will produce an SPF-Authenticated an RFC5321.MailFrom domain that will produce an SPF-Authenticated
Identifier (Section 4.4.2) that has Identifier Alignment Identifier (Section 4.4.2) that has Identifier Alignment
(Section 4.4) with the Author Domain. (Section 4.4) with the Author Domain.
skipping to change at line 1766 skipping to change at line 1779
aggregate report defined in [RFC9990]. aggregate report defined in [RFC9990].
To enable Domain Owners to receive DMARC feedback without impacting To enable Domain Owners to receive DMARC feedback without impacting
existing mail processing, discovered policies of "p=none" MUST NOT existing mail processing, discovered policies of "p=none" MUST NOT
modify existing mail handling processes. modify existing mail handling processes.
6. DMARC Feedback 6. DMARC Feedback
DMARC feedback is described in [RFC9990]. DMARC feedback is described in [RFC9990].
As an operational note for Public Suffix Operators, feedback for non- As an operational note for PSOs, feedback for non-existent domains
existent domains can be desirable and useful, just as it can be for can be desirable and useful, just as it can be for Organizational
Organizational Domains. Therefore, both such entities should Domains. Therefore, both such entities should consider including
consider including "rua=" tags in any DMARC Policy Records they "rua=" tags in any DMARC Policy Records they publish for themselves.
publish for themselves. See Section 10 for discussion of privacy See Section 10 for discussion of privacy considerations.
considerations.
7. Other Topics 7. Other Topics
This section discusses some topics regarding choices made in the This section discusses some topics regarding choices made in the
development of DMARC, largely to commit the history to record. development of DMARC, largely to commit the history to record.
7.1. Issues Specific to SPF 7.1. Issues Specific to SPF
Though DMARC does not inherently change the semantics of an SPF Though DMARC does not inherently change the semantics of an SPF
policy record, historically lax enforcement of such policies has led policy record, historically lax enforcement of such policies has led
skipping to change at line 2299 skipping to change at line 2311
9.5. Underscored and Globally Scoped DNS Node Names Registry Update 9.5. Underscored and Globally Scoped DNS Node Names Registry Update
The names of DNS Resource Records (RRs) beginning with an underscore The names of DNS Resource Records (RRs) beginning with an underscore
character that are globally scoped (as per [RFC8552]) are registered character that are globally scoped (as per [RFC8552]) are registered
with IANA in the "Underscored and Globally Scoped DNS Node Names" with IANA in the "Underscored and Globally Scoped DNS Node Names"
registry within the "Domain Name System (DNS) Parameters" registry registry within the "Domain Name System (DNS) Parameters" registry
group. group.
In addition to a reference to a permanent specification, each In addition to a reference to a permanent specification, each
registration contains the DNS Resource Record (RR) type and Node registration contains the DNS RR type and Node Name. The designated
Name. The designated expert needs to confirm that the provided expert needs to confirm that the provided specification adequately
specification adequately describes the Node Name and clearly presents describes the Node Name and clearly presents how it would be used
how it would be used within the DMARC context by Domain Owners and within the DMARC context by Domain Owners and Mail Receivers.
Mail Receivers.
IANA has updated the reference for following entry to point to this IANA has updated the reference for following entry to point to this
document (instead of [RFC7489]): document (instead of [RFC7489]):
+=========+============+===========+ +=========+============+===========+
| RR Type | _NODE NAME | Reference | | RR Type | _NODE NAME | Reference |
+=========+============+===========+ +=========+============+===========+
| TXT | _dmarc | RFC 9989 | | TXT | _dmarc | RFC 9989 |
+---------+------------+-----------+ +---------+------------+-----------+
skipping to change at line 2711 skipping to change at line 2722
[RFC9991] Jones, S. M., Ed. and A. Vesely, Ed., "Domain-Based [RFC9991] Jones, S. M., Ed. and A. Vesely, Ed., "Domain-Based
Message Authentication, Reporting, and Conformance (DMARC) Message Authentication, Reporting, and Conformance (DMARC)
Failure Reporting", RFC 9991, DOI 10.17487/RFC9991, May Failure Reporting", RFC 9991, DOI 10.17487/RFC9991, May
2026, <https://www.rfc-editor.org/info/rfc9991>. 2026, <https://www.rfc-editor.org/info/rfc9991>.
12.2. Informative References 12.2. Informative References
[M3AUTH] Messaging Malware Mobile Anti-Abuse Working Group [M3AUTH] Messaging Malware Mobile Anti-Abuse Working Group
(M3AAWG), "M3AAWG Email Authentication Recommended Best (M3AAWG), "M3AAWG Email Authentication Recommended Best
Practices", <https://www.m3aawg.org/sites/default/files/ Practices",
<https://www.m3aawg.org/sites/default/files/doc_files/
m3aawg-email-authentication-recommended-best-practices- m3aawg-email-authentication-recommended-best-practices-
09-2020.pdf>. 09-2020.pdf>.
[M3SPF] Messaging Malware Mobile Anti-Abuse Working Group [M3SPF] Messaging Malware Mobile Anti-Abuse Working Group
(M3AAWG), "M3AAWG Best Practices for Managing SPF (M3AAWG), "M3AAWG Best Practices for Managing SPF
Records", <https://www.m3aawg.org/Managing-SPF-Records>. Records",
<https://www.m3aawg.org/sites/default/files/doc_files/
m3aawg_managing-spf_records-2017-08.pdf>.
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
<https://www.rfc-editor.org/info/rfc2142>. <https://www.rfc-editor.org/info/rfc2142>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>. <https://www.rfc-editor.org/info/rfc2308>.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
skipping to change at line 2898 skipping to change at line 2912
policy is to be applied and when. policy is to be applied and when.
A.4. Domain Existence Test A.4. Domain Existence Test
The presence of the "np" tag in this specification seemingly implies The presence of the "np" tag in this specification seemingly implies
that there would be an agreed-upon standard for determining a that there would be an agreed-upon standard for determining a
domain's existence. domain's existence.
Since the DMARC mechanism is focused on email, one might think that Since the DMARC mechanism is focused on email, one might think that
the definition of "resolvable" in [RFC5321] applies. Using that the definition of "resolvable" in [RFC5321] applies. Using that
definition, only names that resolve to MX Resource Records (RRs), A definition, only names that resolve to MX RRs, A RRs, or AAAA RRs are
RRs, or AAAA RRs are deemed to be resolvable and to exist in the DNS. deemed to be resolvable and to exist in the DNS. This is a common
This is a common practice among Mail Receivers to determine whether practice among Mail Receivers to determine whether or not to accept a
or not to accept a mail message before performing other more mail message before performing other more expensive processing.
expensive processing.
The DMARC mechanism makes no such requirement for the existence of The DMARC mechanism makes no such requirement for the existence of
specific DNS RRs in order for a domain to exist; instead, if any RR specific DNS RRs in order for a domain to exist; instead, if any RR
exists for a domain, then the domain exists. To use the terminology exists for a domain, then the domain exists. To use the terminology
from [RFC2308], an "NXDOMAIN" response (rcode "Name Error") to a DNS from [RFC2308], an "NXDOMAIN" response (rcode "Name Error") to a DNS
query means that the domain name does not exist, while a "NODATA" query means that the domain name does not exist, while a "NODATA"
response (rcode "NOERROR") means that the given Resource Record type response (rcode "NOERROR") means that the given RR type queried for
queried for does not exist, but the domain name does. does not exist, but the domain name does.
Furthermore, in keeping with [RFC8020], if a query for a name returns Furthermore, in keeping with [RFC8020], if a query for a name returns
NXDOMAIN, then not only does the name not exist, every name below it NXDOMAIN, then not only does the name not exist, every name below it
in the DNS hierarchy also does not exist. in the DNS hierarchy also does not exist.
A.5. Organizational Domain Discovery Issues A.5. Organizational Domain Discovery Issues
An earlier Informational version of the DMARC mechanism [RFC7489] An earlier informational version of the DMARC mechanism [RFC7489]
noted that the DNS does not provide a method by which the "domain of noted that the DNS does not provide a method by which the "domain of
record", or the domain that was actually registered with a domain record", or the domain that was actually registered with a domain
registrar, can be determined given an arbitrary domain name. That registrar, can be determined given an arbitrary domain name. That
version further mentioned suggestions that have been made that version further mentioned suggestions that have been made that
attempt to glean such information from SOA or NS Resource Records, attempt to glean such information from SOA or NS RRs, but these too
but these too are not fully reliable, as the partitioning of the DNS are not fully reliable, as the partitioning of the DNS is not always
is not always done at administrative boundaries. done at administrative boundaries.
That previous version posited that one could "climb the tree" to find That previous version posited that one could "climb the tree" to find
the Organizational Domain but expressed concern that an attacker the Organizational Domain but expressed concern that an attacker
could exploit this for a denial-of-service attack through sending a could exploit this for a denial-of-service attack through sending a
high number of messages, each with a relatively large number of high number of messages, each with a relatively large number of
nonsense labels, causing a Mail Receiver to perform a large number of nonsense labels, causing a Mail Receiver to perform a large number of
DNS queries in search of a DMARC Policy Record. This version defines DNS queries in search of a DMARC Policy Record. This version defines
a method for performing a DNS Tree Walk (Section 4.10) and further a method for performing a DNS Tree Walk (Section 4.10) and further
mitigates the risk of the denial-of-service attack by expressly mitigates the risk of the denial-of-service attack by expressly
limiting the number of DNS queries to execute regardless of the limiting the number of DNS queries to execute regardless of the
skipping to change at line 2963 skipping to change at line 2976
accurately applied, unless the value specified was either 0 or 100 accurately applied, unless the value specified was either 0 or 100
(the default), and the inaccuracies with other values varied widely (the default), and the inaccuracies with other values varied widely
from one implementation to another. The default value was easily from one implementation to another. The default value was easily
implemented, as it required no special processing on the part of the implemented, as it required no special processing on the part of the
Mail Receiver, while the value of 0 took on unintended significance Mail Receiver, while the value of 0 took on unintended significance
as a value used by some intermediaries and mailbox providers as an as a value used by some intermediaries and mailbox providers as an
indicator to deviate from standard handling of the message, usually indicator to deviate from standard handling of the message, usually
by rewriting the RFC5322.From header field in an effort to avoid by rewriting the RFC5322.From header field in an effort to avoid
DMARC failures downstream. DMARC failures downstream.
These custom actions when the "pct" tag was set to 0 proved value to These custom actions when the "pct" tag was set to 0 proved valuable
the email community. In particular, header field rewriting by an to the email community. In particular, header field rewriting by an
intermediary meant that a Domain Owner's aggregate reports could intermediary meant that a Domain Owner's aggregate reports could
reveal to the Domain Owner how much of its traffic was routing reveal to the Domain Owner how much of its traffic was routing
through intermediaries that don't rewrite the RFC5322.From header through intermediaries that don't rewrite the RFC5322.From header
field. Such information wasn't explicit in the aggregate reports field. Such information wasn't explicit in the aggregate reports
received; rather, sussing it out required work on the part of the received; rather, sussing it out required work on the part of the
Domain Owner to compare aggregate reports from before and after the Domain Owner to compare aggregate reports from before and after the
"p" value was changed and "pct=0" was included in the DMARC Policy "p" value was changed and "pct=0" was included in the DMARC Policy
Record, but the data was there. Consequently, knowing how much mail Record, but the data was there. Consequently, knowing how much mail
was subject to possible DMARC failure due to a lack of RFC5322.From was subject to possible DMARC failure due to a lack of RFC5322.From
header field rewriting by intermediaries could assist the Domain header field rewriting by intermediaries could assist the Domain
skipping to change at line 3144 skipping to change at line 3157
The Domain Owner from the previous example has used the aggregate The Domain Owner from the previous example has used the aggregate
reporting to discover some messaging systems that had not yet reporting to discover some messaging systems that had not yet
implemented DKIM correctly, but they are still seeing periodic implemented DKIM correctly, but they are still seeing periodic
authentication failures. To diagnose these intermittent problems, authentication failures. To diagnose these intermittent problems,
they wish to request per-message failure reports when authentication they wish to request per-message failure reports when authentication
failures occur. failures occur.
Not all Mail Receivers will honor such a request, but the Domain Not all Mail Receivers will honor such a request, but the Domain
Owner feels that any reports it does receive will be helpful enough Owner feels that any reports it does receive will be helpful enough
to justify publishing this record. The default per-message failure to justify publishing this record. The default per-message failure
report format [RFC6591] meets the Domain Owner's needs in this report format [RFC9991] meets the Domain Owner's needs in this
scenario. scenario.
The Domain Owner accomplishes this by adding the following to its The Domain Owner accomplishes this by adding the following to its
DMARC Policy Record from Appendix B.2.1: DMARC Policy Record from Appendix B.2.1:
* Per-message failure reports are sent via email to the address * Per-message failure reports are sent via email to the address
"auth-reports@example.com" ("ruf=mailto:auth-reports@example.com") "auth-reports@example.com" ("ruf=mailto:auth-reports@example.com")
To publish such a record, the DNS administrator for the Domain Owner To publish such a record, the DNS administrator for the Domain Owner
might create an entry like the following in the appropriate zone file might create an entry like the following in the appropriate zone file
skipping to change at line 3196 skipping to change at line 3209
Because the address used in the "ruf" tag is outside the Because the address used in the "ruf" tag is outside the
Organizational Domain in which this record is published, conforming Organizational Domain in which this record is published, conforming
Mail Receivers MUST implement additional checks as described in Mail Receivers MUST implement additional checks as described in
Section 3 of [RFC9990]. To pass these additional checks, the Report Section 3 of [RFC9990]. To pass these additional checks, the Report
Consumer's Domain Owner will need to publish an additional DMARC Consumer's Domain Owner will need to publish an additional DMARC
Policy Record as follows: Policy Record as follows:
* Given the DMARC Policy Record published by the Domain Owner at * Given the DMARC Policy Record published by the Domain Owner at
"_dmarc.example.com", the DNS administrator for the Report "_dmarc.example.com", the DNS administrator for the Report
Consumer will need to publish a TXT Resource Record at Consumer will need to publish a TXT RR at
"example.com._report._dmarc.thirdparty.example.net" with the value "example.com._report._dmarc.thirdparty.example.net" with the value
"v=DMARC1;" to authorize receipt of the reports. "v=DMARC1;" to authorize receipt of the reports.
To publish such a record, the DNS administrator for example.net might To publish such a record, the DNS administrator for example.net might
create an entry like the following in the appropriate zone file create an entry like the following in the appropriate zone file
(following the conventional zone file format): (following the conventional zone file format):
; zone file for thirdparty.example.net ; zone file for thirdparty.example.net
; Accept DMARC reports on behalf of example.com ; Accept DMARC reports on behalf of example.com
example.com._report._dmarc IN TXT "v=DMARC1;" example.com._report._dmarc IN TXT "v=DMARC1;"
skipping to change at line 3626 skipping to change at line 3639
These definitions were updated: These definitions were updated:
* Organizational Domain * Organizational Domain
* Report Receiver (renamed to Report Consumer) * Report Receiver (renamed to Report Consumer)
C.3. Policy Discovery and Organizational Domain Determination C.3. Policy Discovery and Organizational Domain Determination
The algorithms for DMARC policy discovery and for determining the The algorithms for DMARC policy discovery and for determining the
Organizational Domain have been changed. Specifically, reliance on a Organizational Domain have been changed. Specifically, reliance on a
Public Suffix List (PSL) has been replaced by a technique called a PSL has been replaced by a technique called a "DNS Tree Walk", and
"DNS Tree Walk", and the methodology for the DNS Tree Walk is the methodology for the DNS Tree Walk is explained in detail in this
explained in detail in this document. document.
The DNS Tree Walk also incorporates PSD policy discovery, which was The DNS Tree Walk also incorporates PSD policy discovery, which was
introduced in [RFC9091]. That RFC was an Experimental RFC, and the introduced in [RFC9091]. That RFC was an Experimental RFC, and the
results of that experiment were that the RFC was not implemented as results of that experiment were that the RFC was not implemented as
written. Instead, this document redefines the algorithm for PSD written. Instead, this document redefines the algorithm for PSD
policy discovery and thus obsoletes [RFC9091]. Specifically, the DNS policy discovery and thus obsoletes [RFC9091]. Specifically, the DNS
Tree Walk defined in this document obviates the need for a PSD DMARC Tree Walk defined in this document obviates the need for a PSD DMARC
registry, and that PSD DMARC registry is what made [RFC9091] an registry, and that PSD DMARC registry is what made [RFC9091] an
Experimental RFC. Experimental RFC.
skipping to change at line 3667 skipping to change at line 3680
C.5. Tags C.5. Tags
Several tags have been added to the "DMARC Policy Record Format" Several tags have been added to the "DMARC Policy Record Format"
section of this document since [RFC7489] was published, and at the section of this document since [RFC7489] was published, and at the
same time, several others were removed. same time, several others were removed.
C.5.1. Tags Added C.5.1. Tags Added
np: Policy for non-existent domains (imported from [RFC9091]). np: Policy for non-existent domains (imported from [RFC9091]).
psd: Flag indicating whether a domain is a Public Suffix Domain. psd: Flag indicating whether a domain is a PSD.
t: Replacement for some "pct" tag functionality. See Appendix A.6 t: Replacement for some "pct" tag functionality. See Appendix A.6
for further discussion. for further discussion.
C.5.2. Tags Removed C.5.2. Tags Removed
pct: Tag requesting application of the DMARC policy to only a pct: Tag requesting application of the DMARC policy to only a
percentage of messages. See Appendix A.6 for discussion. percentage of messages. See Appendix A.6 for discussion.
rf: Tag specifying requested format of failure reports. rf: Tag specifying requested format of failure reports.
skipping to change at line 3707 skipping to change at line 3720
C.7. Report Generator Recommendations C.7. Report Generator Recommendations
In the cases where a DMARC Policy Record specifies multiple In the cases where a DMARC Policy Record specifies multiple
destinations for either aggregate reports or failure reports, destinations for either aggregate reports or failure reports,
[RFC7489] stated: [RFC7489] stated:
| Receivers MAY impose a limit on the number of URIs to which they | Receivers MAY impose a limit on the number of URIs to which they
| will send reports but MUST support the ability to send to at least | will send reports but MUST support the ability to send to at least
| two. | two.
Section 4.6 of this document says: Section 4.6 of this document includes this text:
| A report SHOULD be sent to each listed URI provided in the DMARC | A report SHOULD be sent to each listed URI provided in the DMARC
| Policy Record. | Policy Record.
C.8. Removal of RFC 7489, Appendix A.5 C.8. Removal of RFC 7489, Appendix A.5
One of the appendices in [RFC7489], specifically Appendix A.5, has One of the appendices in [RFC7489], specifically Appendix A.5, has
been removed from the text with this update. The appendix was titled been removed from the text with this update. The appendix was titled
"Issues with ADSP in Operation", and it contained a list of issues "Issues with ADSP in Operation", and it contained a list of issues
associated with ADSP that influenced the direction of DMARC. The associated with ADSP that influenced the direction of DMARC. The
skipping to change at line 3783 skipping to change at line 3796
text identified in this erratum no longer exists. text identified in this erratum no longer exists.
C.9.8. RFC Errata, Erratum ID 6485, RFC 7489, Section 7.2.1.1 C.9.8. RFC Errata, Erratum ID 6485, RFC 7489, Section 7.2.1.1
See <https://www.rfc-editor.org/errata/eid6485>. This erratum is See <https://www.rfc-editor.org/errata/eid6485>. This erratum is
addressed in [RFC9990]. addressed in [RFC9990].
C.9.9. RFC Errata, Erratum ID 6729, RFC 7489, Section 3.2 C.9.9. RFC Errata, Erratum ID 6729, RFC 7489, Section 3.2
See <https://www.rfc-editor.org/errata/eid6729>. This erratum is in See <https://www.rfc-editor.org/errata/eid6729>. This erratum is in
reference to a search of the Public Suffix List (PSL) as part of reference to a search of the PSL as part of finding a DMARC Policy
finding a DMARC Policy Record (a.k.a., Domain Owner Assessment Record (a.k.a., Domain Owner Assessment Policy). The PSL is no
Policy). The PSL is no longer relied upon for this practice, and the longer relied upon for this practice, and the text at issue has been
text at issue has been removed from this document. removed from this document.
C.9.10. RFC Errata, Erratum ID 7099, RFC 7489, Section 7.2.1.1 C.9.10. RFC Errata, Erratum ID 7099, RFC 7489, Section 7.2.1.1
See <https://www.rfc-editor.org/errata/eid7099>. This erratum is See <https://www.rfc-editor.org/errata/eid7099>. This erratum is
addressed in [RFC9990]. addressed in [RFC9990].
C.9.11. RFC Errata, Erratum ID 7100, RFC 7489, Section 7.2.1.1 C.9.11. RFC Errata, Erratum ID 7100, RFC 7489, Section 7.2.1.1
See <https://www.rfc-editor.org/errata/eid7100>. This erratum is See <https://www.rfc-editor.org/errata/eid7100>. This erratum is
addressed in [RFC9990]. addressed in [RFC9990].
skipping to change at line 3847 skipping to change at line 3860
Mike Hammer, Steven M. Jones, Scott Kitterman, Murray S. Kucherawy, Mike Hammer, Steven M. Jones, Scott Kitterman, Murray S. Kucherawy,
Barry Leiba, Alessandro Vesely, and Tim Wicinski. Barry Leiba, Alessandro Vesely, and Tim Wicinski.
The authors and contributors also recognize that this document would The authors and contributors also recognize that this document would
not have been possible without the work done by those who had a hand not have been possible without the work done by those who had a hand
in producing [RFC7489]. The Acknowledgements section from that in producing [RFC7489]. The Acknowledgements section from that
document is preserved in full below. document is preserved in full below.
Acknowledgements - RFC 7489 Acknowledgements - RFC 7489
DMARC and the earlier draft version of this document that was DMARC and the draft version of this document submitted to the
submitted to the Independent Submission Editor were the result of Independent Submission Editor were the result of lengthy efforts by
lengthy efforts by an informal industry consortium: DMARC.org (see an informal industry consortium: DMARC.org (see <https://dmarc.org>).
<https://dmarc.org>). Participating companies included Agari, Participating companies included Agari, American Greetings, AOL, Bank
American Greetings, AOL, Bank of America, Cloudmark, Comcast, of America, Cloudmark, Comcast, Facebook, Fidelity Investments,
Facebook, Fidelity Investments, Google, JPMorgan Chase & Company, Google, JPMorgan Chase & Company, LinkedIn, Microsoft, Netease,
LinkedIn, Microsoft, Netease, PayPal, ReturnPath, The Trusted Domain PayPal, ReturnPath, The Trusted Domain Project, and Yahoo!. Although
Project, and Yahoo!. Although the contributors and supporters are the contributors and supporters are too numerous to mention, notable
too numerous to mention, notable individual contributions were made individual contributions were made by J. Trent Adams, Michael Adkins,
by J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim Monica Chew, Dave Crocker, Tim Draegen, Steve Jones, Franck Martin,
Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen. Brett McDowell, and Paul Midgen. The contributors would also like to
The contributors would also like to recognize the invaluable input recognize the invaluable input and guidance that was provided early
and guidance that was provided early on by J.D. Falk. on by J.D. Falk.
Additional contributions within the IETF context were made by Kurt Additional contributions within the IETF context were made by Kurt
Andersen, Michael Jack Assels, Les Barstow, Anne Bennett, Jim Fenton, Andersen, Michael Jack Assels, Les Barstow, Anne Bennett, Jim Fenton,
J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine, J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine,
S. Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull. S. Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull.
Authors' Addresses Authors' Addresses
Todd M. Herr (editor) Todd M. Herr (editor)
Valimail Valimail
 End of changes. 32 change blocks. 
97 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.48.