DMARC Aggregate Reporting
draft-ietf-dmarc-aggregate-reporting-15
| Document | Type | Active Internet-Draft (dmarc WG) | |
|---|---|---|---|
| Author | Alex Brotman | ||
| Last updated | 2024-04-25 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-dmarc-aggregate-reporting-15
DMARC A. Brotman (ed)
Internet-Draft Comcast, Inc.
Obsoletes: 7489 (if approved) 25 April 2024
Intended status: Standards Track
Expires: 27 October 2024
DMARC Aggregate Reporting
draft-ietf-dmarc-aggregate-reporting-15
Abstract
DMARC allows for domain holders to request aggregate reports from
receivers. This report is an XML document, and contains extensible
elements that allow for other types of data to be specified later.
The aggregate reports can be submitted to the domain holder's
specified destination as supported by the receiver.
This document (along with others) obsoletes [RFC7489].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 October 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Brotman (ed) Expires 27 October 2024 [Page 1]
Internet-Draft DMARC Aggregate Reporting April 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Handling Domains in Reports . . . . . . . . . . . . . 6
2.1.2. DKIM Signatures in Aggregate Reports . . . . . . . . 6
2.1.3. Unique Identifiers in Aggregate Reporting . . . . . . 7
2.1.4. Error field . . . . . . . . . . . . . . . . . . . . . 7
2.1.5. Policy Override Reason . . . . . . . . . . . . . . . 7
2.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Changes in Policy During Reporting Period . . . . . . . . 8
2.4. Recommended Reporting Periods . . . . . . . . . . . . . . 8
2.5. Report Request Discovery . . . . . . . . . . . . . . . . 9
2.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.1. Definition of Report-ID . . . . . . . . . . . . . . . 9
2.6.2. Email . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6.3. Other Methods . . . . . . . . . . . . . . . . . . . . 12
2.6.4. Handling of Duplicates . . . . . . . . . . . . . . . 12
3. Verifying External Destinations . . . . . . . . . . . . . . . 12
4. Extensible Reporting . . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5.1. Registration request for the DMARC namespace: . . . . . . 16
5.2. Registration request for the DMARC XML schema: . . . . . 16
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Report Recipients . . . . . . . . . . . . . . . . . . . . 16
6.2. Data Contained Within Reports . . . . . . . . . . . . . . 17
6.3. Feedback Leakage . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Appendix A. DMARC XML Schema . . . . . . . . . . . . . . . . 18
9. Appendix B. Sample Report . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
11. Normative References . . . . . . . . . . . . . . . . . . . . 28
12. Informative References . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
Brotman (ed) Expires 27 October 2024 [Page 2]
Internet-Draft DMARC Aggregate Reporting April 2024
1. Introduction
A key component of DMARC [I-D.ietf-dmarc-dmarcbis] is the ability for
domain holders to request that receivers provide various types of
reports. These reports allow domain holders to have insight into
which IP addresses are sending on their behalf, and some insight into
whether or not the volume may be legitimate.
These reports expose information relating to the DMARC policy, as
well as the outcome of SPF [RFC7208] & DKIM [RFC6376] validation.
1.1. Terminology
In many IETF documents, several words, when they are in all capitals
as shown below, are used to signify the requirements in the
specification. These capitalized words can bring significant clarity
and consistency to documents because their meanings are well defined.
This document defines how those words are interpreted in IETF
documents when the words are in all capitals.
* These words can be used as defined here, but using them is not
required. Specifically, normative text does not require the use
of these key words. They are used for clarity and consistency
when that is what's wanted, but a lot of normative text does not
use them and is still normative.
* The words have the meanings specified herein only when they are in
all capitals.
* When these words are not capitalized, they have their normal
English meanings and are not affected by this document.
Authors who follow these guidelines should incorporate this phrase
near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here.
2. DMARC Feedback
Providing Domain Owners with visibility into how Mail Receivers
implement and enforce the DMARC mechanism in the form of feedback is
critical to establishing and maintaining accurate authentication
deployments. When Domain Owners can see what effect their policies
and practices are having, they are better willing and able to use
quarantine and reject policies.
Brotman (ed) Expires 27 October 2024 [Page 3]
Internet-Draft DMARC Aggregate Reporting April 2024
2.1. Aggregate Reports
The DMARC aggregate feedback report is designed to provide Domain
Owners with precise insight into:
* authentication results,
* corrective action that needs to be taken by Domain Owners, and
* the effect of Domain Owner DMARC policy on email streams processed
by Mail Receivers.
Aggregate DMARC feedback provides visibility into real-world email
streams that Domain Owners need to make informed decisions regarding
the publication of DMARC policy. When Domain Owners know what
legitimate mail they are sending, what the authentication results are
on that mail, and what forged mail receivers are getting, they can
make better decisions about the policies they need and the steps they
need to take to enable those policies. When Domain Owners set
policies appropriately and understand their effects, Mail Receivers
can act on them confidently.
Visibility comes in the form of daily (or more frequent) Mail
Receiver-originated feedback reports that contain aggregate data on
message streams relevant to the Domain Owner. This information
includes data about messages that passed DMARC authentication as well
as those that did not.
A separate report should be generated for each Policy Domain
encountered during the reporting period. See below for further
explanation in "Handling Domains in Reports".
The report may include the following data:
* The DMARC policy discovered and applied, if any
* The selected message disposition
* The identifier evaluated by SPF and the SPF result, if any
* The identifier evaluated by DKIM and the DKIM result, if any
* For both DKIM and SPF, an indication of whether the identifier was
in alignment
* Sending and receiving domains
* The number of successful authentications
* The counts of messages based on all messages received, even if
their delivery is ultimately blocked by other filtering agents.
The format for these reports is defined in Appendix A.
DMARC Aggregate Reports MUST contain two primary sections; one
consisting of descriptive information (with two elements), and the
other a set of IP address-focused row-based data. Each report MUST
Brotman (ed) Expires 27 October 2024 [Page 4]
Internet-Draft DMARC Aggregate Reporting April 2024
contain data for only one Policy Domain. A single report MUST
contain data for one policy configuration. If multiple
configurations were observed during a single reporting period, a
reporting entity MAY choose to send multiple reports, otherwise the
reporting entity SHOULD note only the final configuration observed
during the period. See below for further information.
The informative section MUST contain two elements. One will be the
metadata section which MUST contain the fields related to org_name,
email, report_id, and date_range. Optional fields MAY include
extra_contact_info, an error field. The date_range field which will
contain begin and end fields as epoch timestamps. The other element
will be the policy_published, and record the policy configuration
observed by the receiving system. Mandatory fields are domain, p,
sp. Optional fields are fo, adkim, aspf, testing, and
discovery_method. There MAY be an optional third section for
extensions.
Within the data section, the report will contain row(s) of data
stating which IP addresses were seen to have delivered messages for
the Author Domain to the receiving system. For each IP address that
is being reported, there will be at least one record element, which
will then have each of a row, identifiers, and auth_results sub-
element. Within the row element, there MUST be source_ip and count.
There MUST also exist a policy_evaluated, with sub-elements of
disposition, dkim, and spf. There MAY be an element for reason,
meant to include any notes the reporter might want to include as to
why the disposition policy does not match the policy_published, such
as a Local Policy override (See Section 2.1.5, Policy Override
Reason). The dkim and spf elements MUST be the evaluated values as
they relate to DMARC, not the values the receiver may have used when
overriding the policy. Within the identifiers element, there MUST
exist the data that was used to apply policy for the given IP
address. There MUST be a header_from element, which will contain the
RFC5322.From domain from the message. There MAY be an optional
envelope_from element, which contains the RFC5321.MailFrom domain or
the RFC5321.Helo domain that the SPF check has been applied to. This
element MAY be existing but empty if the message had a null reverse-
path ([RFC5321], Section 4.5.5). There MAY be an optional
envelope_to element, which contains the RFC5321.RcptTo domain from
the message.
There MUST be an auth_results element within the record element.
This will contain the data related to authenticating the messages
associated with this sending IP address. The dkim sub-element is
optional as not all messages are signed, while there MUST be at least
one spf sub-element. These elements MUST have a domain that was used
during validation, as well as result. If validation is attempted for
Brotman (ed) Expires 27 October 2024 [Page 5]
Internet-Draft DMARC Aggregate Reporting April 2024
any DKIM signature, the results MUST be included in the report
(within reason, see "DKIM Signatures in Aggregate Reports" below for
handling numerous signatures). The dkim element MUST include a
selector element that was observed during validation. For the spf
element, the result element MUST contain a lower-case string where
the value is one of none/neutral/pass/fail/softfail/temperror/
permerror (See [RFC8601]). The dkim result MUST contain a lower-case
string where the value is one of
none/pass/fail/policy/neutral/temperror/permerror. Both the spf and
dkim results may optionally include a human_readable field meant for
the report to convey more descriptive information back to the domain
holder relating to evaluation failures. There MAY exist an optional
section for extensions.
2.1.1. Handling Domains in Reports
In the same report, there MUST be a single Policy Domain, though
there could be multiple RFC5322.From Domains. Each RFC5322.From
domain will create its own record within the report. Consider the
case where there are three domains with traffic volume to report:
example.com, foo.example.com, and bar.example.com. There will be
explicit DMARC records for example.com and bar.example.com, with
distinct policies. There is no explicit DMARC record for
foo.example.com, so it will be reliant on the policy described for
example.com. For a report period, there would now be two reports.
The first will be for bar.example.com, and contain only one record,
for bar.example.com. The second report would be for example domain
contain multiple record elements, one for example.com and one for
foo.example.com (and extensibly, other record elements for subdomains
which likewise did not have an explicit DMARC policy declared).
2.1.2. DKIM Signatures in Aggregate Reports
Within a single message, the possibility exists that there could be
multiple DKIM signatures. When validation of the message occurs,
some signatures may pass, while some may not. As these pertain to
DMARC, and especially to aggregate reporting, reporters may not find
it clear which DKIM signatures they should include in a report.
Signatures, regardless of outcome, could help the report ingester
determine the source of a message. However, there is a preference as
to which signatures are included.
1. A signature that passes DKIM, in strict alignment with the
RFC5322.From domain
2. A signature that passes DKIM, in relaxed alignment with the
RFC5322.From domain
3. Any other DKIM signatures that pass
4. DKIM signatures that do not pass
Brotman (ed) Expires 27 October 2024 [Page 6]
Internet-Draft DMARC Aggregate Reporting April 2024
A report SHOULD contain no more than 100 signatures for a given row,
in decreasing priority.
2.1.3. Unique Identifiers in Aggregate Reporting
There are a few places where a unique identifier is specified as part
of the body of the report, the subject, and so on. These unique
identifiers should be consistent per each report. Specified below,
the reader will see a Report-ID and unique-id. These are the fields
that MUST be identical when used.
2.1.4. Error field
A few examples of information contained within the error field(s):
* DMARC DNS record evaluation errors (invalid rua or sp, etc.)
* Multiple DMARC records at a given location
Be mindful that the error field is an unbounded string, but should
not contain an extremely large body. Provide enough information to
assist the domain owner with understanding some issues with their
authentication or DMARC declaration.
2.1.5. Policy Override Reason
The reason element, indicating an override of the DMARC policy,
consists of a mandatory type field and an optional comment field.
The type field MUST have one of the pre-defined values listed below.
The comment field is an unbounded string for providing further
details.
Possible values for the policy override type:
forwarded: The message was relayed via a known forwarder, or local
heuristics identified the message as likely having been forwarded.
There is no expectation that authentication would pass.
local_policy: The Mail Receiver's local policy exempted the message
from being subjected to the Domain Owner's requested policy action.
mailing_list: Local heuristics determined that the message arrived
via a mailing list, and thus authentication of the original message
was not expected to succeed.
other: Some policy exception not covered by the other entries in this
list occurred. Additional detail can be found in the
PolicyOverrideReason's "comment" field.
Brotman (ed) Expires 27 October 2024 [Page 7]
Internet-Draft DMARC Aggregate Reporting April 2024
sampled_out: The message was exempted from application of policy by
the testing mode ("t" tag) in the DMARC policy record.
trusted_forwarder: Message authentication failure was anticipated by
other evidence linking the message to a locally maintained list of
known and trusted forwarders.
2.2. Extensions
There MAY be optional sections for extensions within the document.
The absence or existence of this section SHOULD NOT create an error
when processing reports. This will be covered in a separate section.
2.3. Changes in Policy During Reporting Period
Note that Domain Owners or their agents may change the published
DMARC policy for a domain or subdomain at any time. From a Mail
Receiver's perspective, this will occur during a reporting period and
may be noticed during that period, at the end of that period when
reports are generated, or during a subsequent reporting period, all
depending on the Mail Receiver's implementation. Under these
conditions, it is possible that a Mail Receiver could do any of the
following:
* generate for such a reporting period a single aggregate report
that includes message dispositions based on the old policy, or a
mix of the two policies, even though the report only contains a
single "policy_published" element;
* generate multiple reports for the same period, one for each
published policy occurring during the reporting period;
Such policy changes are expected to be infrequent for any given
domain, whereas more stringent policy monitoring requirements on the
Mail Receiver would produce a very large burden at Internet scale.
Therefore, it is the responsibility of report consumers and Domain
Owners to be aware of this situation and allow for such mixed reports
during the propagation of the new policy to Mail Receivers.
2.4. Recommended Reporting Periods
Aggregate reports are most useful when they all cover a common time
period. By contrast, correlation of these reports from multiple
generators when they cover incongruent time periods is difficult or
impossible. Report generators SHOULD, wherever possible, adhere to
hour boundaries for the reporting period they are using. For
example, starting a per-day report at 00:00; starting per-hour
reports at 00:00, 01:00, 02:00; etc. Report generators using a
24-hour report period are strongly encouraged to begin that period at
Brotman (ed) Expires 27 October 2024 [Page 8]
Internet-Draft DMARC Aggregate Reporting April 2024
00:00 UTC, regardless of local timezone or time of report production,
in order to facilitate correlation.
2.5. Report Request Discovery
A Mail Receiver discovers reporting requests when it looks up a DMARC
policy record that corresponds to an RFC5322.From domain on received
mail. The presence of the "rua" tag specifies where to send
feedback.
2.6. Transport
The Mail Receiver, after preparing a report, MUST evaluate the
provided reporting URIs in the order given. Any reporting URI that
includes a size limitation exceeded by the generated report (after
compression and after any encoding required by the particular
transport mechanism) MUST NOT be used. An attempt MUST be made to
deliver an aggregate report to every remaining URI, up to the
Receiver's limits on supported URIs.
If transport is not possible because the services advertised by the
published URIs are not able to accept reports (e.g., the URI refers
to a service that is unreachable, or all provided URIs specify size
limits exceeded by the generated record), the Mail Receiver MAY send
a short report indicating that a report is available but could not be
sent. The Mail Receiver MAY cache that data and try again later, or
MAY discard data that could not be sent.
Where the URI specified in a "rua" tag does not specify otherwise, a
Mail Receiver generating a feedback report SHOULD employ a secure
transport mechanism.
2.6.1. Definition of Report-ID
This identifier MUST be unique among reports to the same domain to
aid receivers in identifying duplicate reports should they happen.
ridtxt = ("<" *(ALPHA / DIGIT / "." / "-") ["@" _(ALPHA / DIGIT / "."
/ "-")] ">") / (_(ALPHA / DIGIT / "." / "-") ["@" *(ALPHA / DIGIT /
"." / "-")])
The format specified here is not very strict as the key goal is
uniqueness.
Brotman (ed) Expires 27 October 2024 [Page 9]
Internet-Draft DMARC Aggregate Reporting April 2024
2.6.2. Email
The message generated by the Mail Receiver MUST be a [RFC5322]
message formatted per [RFC2045]. The aggregate report itself MUST be
included in one of the parts of the message. A human-readable
portion MAY be included as a MIME part (such as a text/plain part).
The aggregate data MUST be an XML file that SHOULD be subjected to
GZIP compression. Declining to apply compression can cause the
report to be too large for a receiver to process (the total message
size could exceed the receiver SMTP size limit); doing the
compression increases the chances of acceptance of the report at some
compute cost. The aggregate data MUST be present using the media
type "application/ gzip" if compressed (see [RFC6713]), and "text/
xml" otherwise. The filename MUST be constructed using the following
ABNF:
filename = receiver "!" policy-domain "!" begin-timestamp "!" end-
timestamp [ "!" unique-id ] "." extension
receiver = domain ; imported from [RFC5322]
policy-domain = domain
begin-timestamp = 1*DIGIT ; seconds since 00:00:00 UTC January 1,
1970 ; indicating start of the time range contained ; in the report
end-timestamp = 1*DIGIT ; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained ; in the report
unique-id = 1*(ALPHA / DIGIT)
extension = "xml" / "xml.gz"
The extension MUST be "xml" for a plain XML file, or "xml.gz" for an
XML file compressed using GZIP.
"unique-id" allows an optional unique ID generated by the Mail
Receiver to distinguish among multiple reports generated
simultaneously by different sources within the same Domain Owner.
If a report generator needs to re-send a report, the system MUST use
the same filename as the original report. This would allow the
receiver to overwrite the data from the original, or discard second
instance of the report.
Brotman (ed) Expires 27 October 2024 [Page 10]
Internet-Draft DMARC Aggregate Reporting April 2024
For example, this is a sample filename for the gzip file of a report
to the Domain Owner "example.com" from the Mail Receiver
"mail.receiver.example":
mail.receiver.example!example.com!1013662812!1013749130.gz
No specific MIME message structure is required. It is presumed that
the aggregate reporting address will be equipped to extract MIME
parts with the prescribed media type and filename and ignore the
rest.
Email streams carrying DMARC feedback data MUST conform to the DMARC
mechanism, thereby resulting in an aligned "pass" (see Section 3.1).
This practice minimizes the risk of report consumers processing
fraudulent reports.
The RFC5322.Subject field for individual report submissions MUST
conform to the following ABNF:
dmarc-subject = %s"Report" 1*FWS %s"Domain:" 1*FWS domain-name 1*FWS
; policy domain %s"Submitter:" 1*FWS domain-name 1*FWS ; report
generator [ %s"Report-ID:" 1*FWS ridtxt ] ; defined below
The first domain-name indicates the DNS domain name about which the
report was generated. The second domain-name indicates the DNS
domain name representing the Mail Receiver generating the report.
The purpose of the Report-ID: portion of the field is to enable the
Domain Owner to identify and ignore duplicate reports that might be
sent by a Mail Receiver.
For instance, this is a possible Subject field for a report to the
Domain Owner "example.com" from the Mail Receiver
"mail.receiver.example". It is line-wrapped as allowed by [RFC5322]:
Subject: Report Domain: example.com Submitter: mail.receiver.example
Report-ID: <2002.02.15.1>
This transport mechanism potentially encounters a problem when
feedback data size exceeds maximum allowable attachment sizes for
either the generator or the consumer.
Optionally, the report sender MAY choose to use the same ridtxt as a
part or whole of the RFC5322.Message-Id header included with the
report. Doing so may help receivers distinguish when a message is a
re-transmission or duplicate report.
Brotman (ed) Expires 27 October 2024 [Page 11]
Internet-Draft DMARC Aggregate Reporting April 2024
2.6.3. Other Methods
The specification as written allows for the addition of other
registered URI schemes to be supported in later versions.
2.6.4. Handling of Duplicates
There may be a situation where the report generator attempts to
deliver duplicate information to the receiver. This may manifest as
an exact duplicate of the report, or as duplicate information between
two reports. In these situations, the decision of how to handle the
duplicate data lies with the receiver. As noted above, the sender
MUST use the same unique identifiers when sending the report. This
allows the receiver to better understand when duplicates happen. A
few options on how to handle that duplicate information:
* Reject back to sender, ideally with a permfail error noting the
duplicate receipt
* Discard upon receipt
* Inspect the contents to evaluate the timestamps and reported data,
act as appropriate
* Accept the duplicate data
When accepting the data, that's likely in a situation where it's not
yet noticed, or a one-off experience. Long term, duplicate data is
not ideal. In the situation of a partial time frame overlap, there
is no clear way to distinguish the impact of the overlap. The
receiver would need to accept or reject the duplicate data in whole.
3. Verifying External Destinations
It is possible to specify destinations for the different reports that
are outside the authority of the Domain Owner making the request.
This allows domains that do not operate mail servers to request
reports and have them go someplace that is able to receive and
process them.
Without checks, this would allow a bad actor to publish a DMARC
policy record that requests that reports be sent to a victim address,
and then send a large volume of mail that will fail both DKIM and SPF
checks to a wide variety of destinations; the victim will in turn be
flooded with unwanted reports. Therefore, a verification mechanism
is included.
Brotman (ed) Expires 27 October 2024 [Page 12]
Internet-Draft DMARC Aggregate Reporting April 2024
When a Mail Receiver discovers a DMARC policy in the DNS, and the
Organizational Domain at which that record was discovered is not
identical to the Organizational Domain of the host part of the
authority component of a [RFC3986] specified in the "rua" tag, the
following verification steps MUST be taken:
1. Extract the host portion of the authority component of the URI.
Call this the "destination host", as it refers to a Report
Receiver.
2. Prepend the string "_report._dmarc".
3. Prepend the domain name from which the policy was retrieved,
after conversion to an A-label [RFC5890] if needed.
4. Query the DNS for a TXT record at the constructed name. If the
result of this request is a temporary DNS error of some kind
(e.g., a timeout), the Mail Receiver MAY elect to temporarily
fail the delivery so the verification test can be repeated later.
5. For each record returned, parse the result as a series of
"tag=value" pairs, i.e., the same overall format as the policy
record (see Section 5.4 in [I-D.ietf-dmarc-dmarcbis]). In
particular, the "v=DMARC1" tag is mandatory and MUST appear first
in the list. Discard any that do not pass this test.
6. If the result includes no TXT resource records that pass basic
parsing, a positive determination of the external reporting
relationship cannot be made; stop.
7. If at least one TXT resource record remains in the set after
parsing, then the external reporting arrangement was authorized
by the Report Receiver.
8. If a "rua" tag is thus discovered, replace the corresponding
value extracted from the domain's DMARC policy record with the
one found in this record. This permits the Report Receiver to
override the report destination. However, to prevent loops or
indirect abuse, the overriding URI MUST use the same destination
host from the first step.
For example, if a DMARC policy query for "blue.example.com" contained
"rua=mailto:reports@red.example.net"
(mailto:reports@red.example.net"), the host extracted from the latter
("red.example.net") does not match "blue.example.com", so this
procedure is enacted. A TXT query for
"blue.example.com._report._dmarc.red.example.net" is issued. If a
single reply comes back containing a tag of "v=DMARC1", then the
Brotman (ed) Expires 27 October 2024 [Page 13]
Internet-Draft DMARC Aggregate Reporting April 2024
relationship between the two is confirmed. Moreover,
"red.example.net" has the opportunity to override the report
destination requested by "blue.example.com" if needed.
Where the above algorithm fails to confirm that the external
reporting was authorized by the Report Receiver, the URI MUST be
ignored by the Mail Receiver generating the report. Further, if the
confirming record includes a URI whose host is again different than
the domain publishing that override, the Mail Receiver generating the
report MUST NOT generate a report to either the original or the
override URI. A Report Receiver publishes such a record in its DNS
if it wishes to receive reports for other domains.
A Report Receiver that is willing to receive reports for any domain
can use a wildcard DNS record. For example, a TXT resource record at
"*._report._dmarc.example.com" containing at least "v=DMARC1"
confirms that example.com is willing to receive DMARC reports for any
domain.
If the Report Receiver is overcome by volume, it can simply remove
the confirming DNS record. However, due to positive caching, the
change could take as long as the time-to-live (TTL) on the record to
go into effect.
A Mail Receiver might decide not to enact this procedure if, for
example, it relies on a local list of domains for which external
reporting addresses are permitted.
4. Extensible Reporting
DMARC reports allow for some extensibility, as defined by future
documents that utilize DMARC as a foundation. These extensions MUST
be properly formatted XML and meant to exist within the structure of
a DMARC report. Two positions of type <any> are provided in the
existing DMARC structure, one at file level, in an <extension>
element after <policy_published> and one at record level, after
<auth_results>. In either case, the extensions MUST contain a URI to
the definition of the extension so that the receiver understands how
to interpret the data.
At file level:
Brotman (ed) Expires 27 October 2024 [Page 14]
Internet-Draft DMARC Aggregate Reporting April 2024
<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
xmlns:ext="URI for an extension-supplied name space">
...
<policy_published>
<domain>example.com</domain>
<p>quarantine</p>
<sp>none</sp>
<testing>n</testing>
</policy_published>
<extension>
<ext:arc-override>never</ext:arc-override>
</extension>
Within the record element:
<record>
<row>
...
</row>
<identifiers>
...
</identifiers>
<auth_results>
...
</auth_results>
<ext:arc-results>
...
</ext:arc-results>
</record>
<record>
...
Here "arc-override" and "arc-results" are hypothetical element names
defined in the extension's name space.
Extension elements are optional. Any number of extensions is
allowed. If a processor is unable to handle an extension in a
report, it SHOULD ignore the data and continue to the next extension.
5. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. Two URI
assignments will be registered by the IANA.
Brotman (ed) Expires 27 October 2024 [Page 15]
Internet-Draft DMARC Aggregate Reporting April 2024
5.1. Registration request for the DMARC namespace:
URI: urn:ietf:params:xml:ns:dmarc-2.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: None. Namespace URIs do not represent an XML specification.
5.2. Registration request for the DMARC XML schema:
URI: urn:ietf:params:xml:schema:dmarc-2.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: See Appendix A. DMARC XML Schema in this document.
6. Privacy Considerations
This section will discuss exposure related to DMARC aggregate
reporting.
6.1. Report Recipients
A DMARC record can specify that reports should be sent to an
intermediary operating on behalf of the Domain Owner. This is done
when the Domain Owner contracts with an entity to monitor mail
streams for abuse and performance issues. Receipt by third parties
of such data may or may not be permitted by the Mail Receiver's
privacy policy, terms of use, or other similar governing document.
Domain Owners and Mail Receivers should both review and understand if
their own internal policies constrain the use and transmission of
DMARC reporting.
Some potential exists for report recipients to perform traffic
analysis, making it possible to obtain metadata about the Receiver's
traffic. In addition to verifying compliance with policies,
Receivers need to consider that before sending reports to a third
party.
Brotman (ed) Expires 27 October 2024 [Page 16]
Internet-Draft DMARC Aggregate Reporting April 2024
6.2. Data Contained Within Reports
Aggregate feedback reports contain aggregated data relating to
messages purportedly originating from the Domain Owner. The data
does not contain any identifying characteristics about individual
users. No personal information such as individual email addresses,
IP addresses of individuals, or the content of any messages, is
included in reports.
Mail Receivers should have no concerns in sending reports as they do
not contain personal information. In all cases, the data within the
reports relates to the domain-level authentication information
provided by mail servers sending messages on behalf of the Domain
Owner. This information is necessary to assist Domain Owners in
implementing and maintaining DMARC.
Domain Owners should have no concerns in receiving reports as they do
not contain personal information. The reports only contain
aggregated data related to the domain-level authentication details of
messages claiming to originate from their domain. This information
is essential for the proper implementation and operation of DMARC.
Domain Owners who are unable to receive reports for organizational
reasons, can choose to exclusively direct the reports to an external
processor.
6.3. Feedback Leakage
Providing feedback reporting to PSOs for a PSD [RFC9091] can, in some
cases, cause information to leak out of an organization to the PSO.
This leakage could potentially be utilized as part of a program of
pervasive surveillance (see [RFC7624]]). There are roughly three
cases to consider:
Single Organization PSDs (e.g., ".mil"): RUA reports based on PSD
DMARC have the potential to contain information about emails
related to entities managed by the organization. Since both the
PSO and the Organizational Domain Owners are common, there is no
additional privacy risk for either normal or non-existent domain
reporting due to PSD DMARC.
Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
Reports based on PSD DMARC will only be generated for domains that
do not publish a DMARC policy at the organizational or host level.
For domains that do publish the required DMARC policy records, the
feedback reporting addresses of the organization (or hosts) will
be used. The only direct risk of feedback leakage for these PSDs
are for Organizational Domains that are out of compliance with PSD
policy. Data on non-existent cousin domains would be sent to the
PSO.
Brotman (ed) Expires 27 October 2024 [Page 17]
Internet-Draft DMARC Aggregate Reporting April 2024
Multi-organization PSDs (e.g., ".com") that do not mandate DMARC
usage: Privacy risks for Organizational Domains that have not
deployed DMARC within such PSDs are significant. For non-DMARC
Organizational Domains, all DMARC feedback will be directed to the
PSO. Any non-DMARC Organizational Domain would have its Feedback
Reports redirected to the PSO. The content of such reports,
particularly for existing domains, is privacy sensitive.
PSOs will receive feedback on non-existent domains, which may be
similar to existing Organizational Domains. Feedback related to such
cousin domains have a small risk of carrying information related to
an actual Organizational Domain. To minimize this potential concern,
PSD DMARC feedback MUST be limited to Aggregate Reports. Feedback
Reports carry more detailed information and present a greater risk.
Due to the inherent privacy and security risks associated with DMARC
at the PSD level for Organizational Domains in multi-organization
PSDs that do not participate in DMARC, any feedback reporting related
to multi- organizational PSDs MUST be limited to non-existent domains
except in cases where the reporter knows that PSO requires use of
DMARC.
7. Security Considerations
* Aggregate reports are supposed to be processed automatically. An
attacker might attempt to compromise the integrity or availability
of the report processor by sending ill-formed reports. In
particular, the archive decompressor and XML parser are at risk to
resource exhaustion attacks (zip bomb or XML bomb).
* The data contained within aggregate reports may be forged. An
attacker might attempt to interfere by submitting false reports in
masses.
* See also the security considerations of dmarc-bis (Section 11).
8. Appendix A. DMARC XML Schema
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:dmarc-2.0"
xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
elementFormDefault="qualified">
<!-- The time range in UTC covered by messages in this report,
specified in seconds since epoch. -->
<xs:complexType name="DateRangeType">
<xs:all>
<xs:element name="begin" type="xs:integer"
Brotman (ed) Expires 27 October 2024 [Page 18]
Internet-Draft DMARC Aggregate Reporting April 2024
minOccurs="1" maxOccurs="1"/>
<xs:element name="end" type="xs:integer"
minOccurs="1" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- Report generator metadata. -->
<!--
org_name: Reporting Organization
email: Contact to be used when contacting
the Reporting Organization
extra_contact_info: Additional contact details
report_id: Unique Report-ID
date_range: Timestamps used when forming report data
error: Optional error messages when processing DMARC policy
-->
<xs:complexType name="ReportMetadataType">
<xs:all>
<xs:element name="org_name" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<xs:element name="email" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<xs:element name="extra_contact_info" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="report_id" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<xs:element name="date_range" type="DateRangeType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="error" type="xs:string"
minOccurs="0"/>
</xs:all>
</xs:complexType>
<!-- Alignment mode (relaxed or strict) for DKIM and SPF. -->
<xs:simpleType name="AlignmentType">
<xs:restriction base="xs:string">
<xs:enumeration value="r"/>
<xs:enumeration value="s"/>
</xs:restriction>
</xs:simpleType>
<!-- The policy actions specified by p and sp in the
DMARC record. -->
<xs:simpleType name="DispositionType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="quarantine"/>
Brotman (ed) Expires 27 October 2024 [Page 19]
Internet-Draft DMARC Aggregate Reporting April 2024
<xs:enumeration value="reject"/>
</xs:restriction>
</xs:simpleType>
<!-- The policy actions utilized on messages for this record. -->
<!--
"none": No action taken
"pass": No action, passing DMARC w/enforcing policy
"quarantine": Failed DMARC, message marked for quarantine
"reject": Failed DMARC, marked as reject
-->
<xs:simpleType name="ActionDispositionType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="pass"/>
<xs:enumeration value="quarantine"/>
<xs:enumeration value="reject"/>
</xs:restriction>
</xs:simpleType>
<!-- The methods used to discovery the policy used during
evaluation. The available values are "psl" and "treewalk",
where "psl" is the method from [@?RFC7489] and the "treewalk"
is described in [@?RefNeeded]. -->
<xs:simpleType name="DiscoveryType">
<xs:restriction base="xs:string">
<xs:enumeration value="psl"/>
<xs:enumeration value="treewalk"/>
</xs:restriction>
</xs:simpleType>
<!-- The published DMARC policy. Unspecified tags have their
default values. -->
<xs:complexType name="PolicyPublishedType">
<xs:all>
<!-- The domain at which the DMARC record was found. -->
<xs:element name="domain" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<!-- Method used to find/obtain DMARC policy -->
<xs:element name="discovery_method" type="DiscoveryType"
minOccurs="0" maxOccurs="1"/>
<!-- The DKIM alignment mode. -->
<xs:element name="adkim" type="AlignmentType"
minOccurs="0" maxOccurs="1"/>
<!-- The SPF alignment mode. -->
<xs:element name="aspf" type="AlignmentType"
minOccurs="0" maxOccurs="1"/>
<!-- The policy published for messages from the domain. -->
Brotman (ed) Expires 27 October 2024 [Page 20]
Internet-Draft DMARC Aggregate Reporting April 2024
<xs:element name="p" type="DispositionType"
minOccurs="1" maxOccurs="1"/>
<!-- The policy published for messages from subdomains. -->
<xs:element name="sp" type="DispositionType"
minOccurs="1" maxOccurs="1"/>
<!-- Whether testing mode was declared in the DMARC Record -->
<xs:element name="testing" type="TestingType"
minOccurs="0" maxOccurs="1"/>
<!-- Failure reporting options in effect. -->
<xs:element name="fo" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- Values for Testing mode attached to Policy -->
<xs:simpleType name="TestingType">
<xs:restriction base="xs:string">
<xs:enumeration value="n"/>
<xs:enumeration value="y"/>
</xs:restriction>
</xs:simpleType>
<!-- The DMARC-aligned authentication result. -->
<xs:simpleType name="DMARCResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
</xs:restriction>
</xs:simpleType>
<!-- Reasons that may affect DMARC disposition or execution
thereof. -->
<xs:simpleType name="PolicyOverrideType">
<xs:restriction base="xs:string">
<xs:enumeration value="forwarded"/>
<xs:enumeration value="sampled_out"/>
<xs:enumeration value="trusted_forwarder"/>
<xs:enumeration value="mailing_list"/>
<xs:enumeration value="local_policy"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
<!-- Override reason consists of pre-defined override type and
free-text comment. -->
<xs:complexType name="PolicyOverrideReason">
<xs:all>
<xs:element name="type" type="PolicyOverrideType"
Brotman (ed) Expires 27 October 2024 [Page 21]
Internet-Draft DMARC Aggregate Reporting April 2024
minOccurs="1" maxOccurs="1"/>
<xs:element name="comment" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- Taking into account everything else in the record,
the results of applying DMARC. If alignment fails
and the policy applied does not match the domain's
configured policy, the reason element MUST be specified -->
<xs:complexType name="PolicyEvaluatedType">
<xs:sequence>
<xs:element name="disposition" type="ActionDispositionType"/>
<xs:element name="dkim" type="DMARCResultType"/>
<xs:element name="spf" type="DMARCResultType"/>
<xs:element name="reason" type="PolicyOverrideReason"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- The Internet Protocol Address
from which messages were received -->
<xs:simpleType name="IPAddress">
<xs:restriction base="xs:string">
<!-- IPv4 -->
<xs:pattern value=
"((1?\d?\d|2[0-4]\d|25[0-5])\.){3}(1?\d?\d|2[0-4]\d|25[0-5])"/>
<!-- IPv6 -->
<xs:pattern value="([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}"/>
<!-- RFC 5952 zero compression IPv6 (lax) -->
<xs:pattern value="([A-Fa-f0-9]{1,4}:){1,7}:"/>
<xs:pattern value="([A-Fa-f0-9]{1,4}:){1,6}:[A-Fa-f0-9]{1,4}"/>
<xs:pattern value=
"([A-Fa-f0-9]{1,4}:){1,5}:[A-Fa-f\d]{1,4}:[A-Fa-f\d]{1,4}"/>
<xs:pattern value=
"([A-Fa-f\d]{1,4}:){1,4}:([A-Fa-f\d]{1,4}:){1,2}[A-Fa-f\d]{1,4}"/>
<xs:pattern value=
"([A-Fa-f\d]{1,4}:){1,3}:([A-Fa-f\d]{1,4}:){1,3}[A-Fa-f\d]{1,4}"/>
<xs:pattern value=
"([A-Fa-f\d]{1,4}:){1,2}:([A-Fa-f\d]{1,4}:){1,4}[A-Fa-f\d]{1,4}"/>
<xs:pattern value=
"[A-Fa-f\d]{1,4}::([A-Fa-f\d]{1,4}:){1,5}[A-Fa-f\d]{1,4}"/>
<xs:pattern value="::([A-Fa-f\d]{1,4}:){1,6}[A-Fa-f\d]{1,4}"/>
<xs:pattern value="::[A-Fa-f\d]{1,4}"/>
</xs:restriction>
</xs:simpleType>
Brotman (ed) Expires 27 October 2024 [Page 22]
Internet-Draft DMARC Aggregate Reporting April 2024
<xs:complexType name="RowType">
<xs:sequence>
<!-- The connecting IP. -->
<xs:element name="source_ip" type="IPAddress"
minOccurs="1" maxOccurs="1"/>
<!-- The number of messages for which the
PolicyEvaluatedType was applied. -->
<xs:element name="count" type="xs:integer"
minOccurs="1" maxOccurs="1"/>
<!-- The DMARC disposition applied to matching messages. -->
<xs:element name="policy_evaluated"
type="PolicyEvaluatedType"
minOccurs="1" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="IdentifierType">
<xs:all>
<!-- The envelope recipient domain. -->
<xs:element name="envelope_to" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<!-- The RFC5321.MailFrom domain or, if that value is empty,
the RFC5321.Helo domain. -->
<xs:element name="envelope_from" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<!-- The RFC5322.From domain. -->
<xs:element name="header_from" type="xs:string"
minOccurs="1" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- DKIM verification result, according to RFC 8601
Section 2.7.1. -->
<xs:simpleType name="DKIMResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
<xs:enumeration value="policy"/>
<xs:enumeration value="neutral"/>
<xs:enumeration value="temperror"/>
<xs:enumeration value="permerror"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="DKIMAuthResultType">
<xs:all>
<!-- The "d=" parameter in the signature. -->
Brotman (ed) Expires 27 October 2024 [Page 23]
Internet-Draft DMARC Aggregate Reporting April 2024
<xs:element name="domain" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<!-- The "s=" parameter in the signature. -->
<xs:element name="selector" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<!-- The DKIM verification result. -->
<xs:element name="result" type="DKIMResultType"
minOccurs="1" maxOccurs="1"/>
<!-- Any extra information (e.g., from
Authentication-Results). -->
<xs:element name="human_result" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- SPF domain scope. -->
<xs:simpleType name="SPFDomainScope">
<xs:restriction base="xs:string">
<xs:enumeration value="helo"/>
<xs:enumeration value="mfrom"/>
</xs:restriction>
</xs:simpleType>
<!-- SPF result. -->
<xs:simpleType name="SPFResultType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="neutral"/>
<xs:enumeration value="pass"/>
<xs:enumeration value="fail"/>
<xs:enumeration value="softfail"/>
<!-- "TempError" commonly implemented as "unknown". -->
<xs:enumeration value="temperror"/>
<!-- "PermError" commonly implemented as "error". -->
<xs:enumeration value="permerror"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="SPFAuthResultType">
<xs:all>
<!-- The checked domain. -->
<xs:element name="domain" type="xs:string"
minOccurs="1" maxOccurs="1"/>
<!-- The scope of the checked domain. -->
<xs:element name="scope" type="SPFDomainScope"
minOccurs="0" maxOccurs="1"/>
<!-- The SPF verification result. -->
<xs:element name="result" type="SPFResultType"
Brotman (ed) Expires 27 October 2024 [Page 24]
Internet-Draft DMARC Aggregate Reporting April 2024
minOccurs="1" maxOccurs="1"/>
<!-- Any extra information
(e.g., from Authentication-Results).
The information in the field below should be for a
person to be provided with additional information
that may be useful when debugging SPF authentication
issues. This could include broken records, invalid
DNS responses, etc.
-->
<xs:element name="human_result" type="xs:string"
minOccurs="0" maxOccurs="1"/>
</xs:all>
</xs:complexType>
<!-- This element contains DKIM and SPF results, uninterpreted
with respect to DMARC. -->
<xs:complexType name="AuthResultType">
<xs:sequence>
<!-- There may be no DKIM signatures, or multiple DKIM
signatures. -->
<xs:element name="dkim" type="DKIMAuthResultType"
minOccurs="0" maxOccurs="unbounded"/>
<!-- There will always be at least one SPF result. -->
<xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- This element contains all the authentication results that
were evaluated by the receiving system for the given set of
messages. -->
<xs:complexType name="RecordType">
<xs:sequence>
<xs:element name="row" type="RowType"/>
<xs:element name="identifiers" type="IdentifierType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="auth_results" type="AuthResultType"
minOccurs="1" maxOccurs="1"/>
<!-- Extension at row level-->
<xs:any processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ExtensionType">
<xs:sequence>
<xs:any processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
Brotman (ed) Expires 27 October 2024 [Page 25]
Internet-Draft DMARC Aggregate Reporting April 2024
</xs:sequence>
</xs:complexType>
<!-- Parent -->
<xs:element name="feedback">
<xs:complexType>
<xs:sequence>
<xs:element name="version"
minOccurs="0" maxOccurs="1" type="xs:decimal"/>
<xs:element name="report_metadata"
minOccurs="1" maxOccurs="1"
type="ReportMetadataType"/>
<xs:element name="policy_published"
minOccurs="1" maxOccurs="1"
type="PolicyPublishedType"/>
<!-- Extension at top level -->
<xs:element name="extension" type="ExtensionType"
minOccurs="0" maxOccurs="1"/>
<!-- One record per (IP, result, IDs Auths) tuples -->
<xs:element name="record" type="RecordType"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
9. Appendix B. Sample Report
Brotman (ed) Expires 27 October 2024 [Page 26]
Internet-Draft DMARC Aggregate Reporting April 2024
<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
<version>1.0</version>
<report_metadata>
<org_name>Sample Reporter</org_name>
<email>report_sender@example-reporter.com</email>
<extra_contact_info>...</extra_contact_info>
<report_id>3v98abbp8ya9n3va8yr8oa3ya</report_id>
<date_range>
<begin>161212415</begin>
<end>161221511</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>quarantine</p>
<sp>none</sp>
<testing>n</testing>
<discovery_method>treewalk</discovery_method>
</policy_published>
<record>
<row>
<source_ip>192.168.4.4</source_ip>
<count>123</count>
<policy_evaluated>
<disposition>pass</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<envelope_from>example.com</envelope_from>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>pass</result>
<selector>abc123</selector>
</dkim>
<spf>
<domain>example.com</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
</feedback>
Brotman (ed) Expires 27 October 2024 [Page 27]
Internet-Draft DMARC Aggregate Reporting April 2024
10. Acknowledgements
TBD
11. Normative References
[I-D.ietf-dmarc-dmarcbis]
Herr, T. and J. R. Levine, "Domain-based Message
Authentication, Reporting, and Conformance (DMARC)", Work
in Progress, Internet-Draft, draft-ietf-dmarc-dmarcbis-30,
28 February 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-dmarc-dmarcbis-30>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip'
Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012,
<https://www.rfc-editor.org/info/rfc6713>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
Brotman (ed) Expires 27 October 2024 [Page 28]
Internet-Draft DMARC Aggregate Reporting April 2024
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>.
12. Informative References
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC8601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 8601,
DOI 10.17487/RFC8601, May 2019,
<https://www.rfc-editor.org/info/rfc8601>.
[RFC9091] Kitterman, S. and T. Wicinski, Ed., "Experimental Domain-
Based Message Authentication, Reporting, and Conformance
(DMARC) Extension for Public Suffix Domains", RFC 9091,
DOI 10.17487/RFC9091, July 2021,
<https://www.rfc-editor.org/info/rfc9091>.
Author's Address
Alex Brotman
Comcast, Inc.
Email: alex_brotman@comcast.com
Brotman (ed) Expires 27 October 2024 [Page 29]