3.1. Aggregate Reports
このページは RFC 9990 の該当節を要約し, XML schema, report fields, IANA values を保持します.
Aggregate reports provide insight into authentication results, corrective actions, and the effects of Domain Owner policy on mail streams. A separate report MUST be generated for each DMARC Policy Domain. A report MUST contain data for only one DMARC Policy Domain and one policy configuration.
The XML content description from Section 3.1.1 is preserved below.
3.1.1. Description of the Content of the XML File
The format for these reports is defined in the XML Schema Definition
(XSD) in Appendix A. The XSD includes the possible values for some
of the elements below. Most of these values have a definition tied
to [RFC9989].
The format is also described in the following sections. Each section
describes a collection of sibling elements in the XML hierarchy.
There are pointers to where in the hierarchy each table fits.
If a document does not match the specified format, the document
evaluator SHOULD discard the report. The evaluator MAY choose to try
to utilize some of the data; however, if the format is in question,
the data may be as well. The report evaluator MAY choose to contact
the report generator so that they may be alerted to an issue with the
report format.
The column "#" specifies how many times an element may appear -- this
is sometimes referred to as multiplicity. The possible values are:
O: OPTIONAL, zero or one element
R: REQUIRED, exactly one element
*: OPTIONAL, zero or more elements
+: REQUIRED, one or more elements
Some elements contain text meant for humans and support an optional
"lang" attribute whose value indicates the language of its contents.
The default value is "en". Elements supporting this optional
attribute are marked with "[@lang]" at the start of their content
description in the following tables.
3.1.1.1. XML Root Element
DMARC aggregate feedback reports have the root element "feedback"
with its XML namespace set to the DMARC namespace.
+==============+===+===========================================+
| Element name | # | Content |
+==============+===+===========================================+
| feedback | R | First level elements; see Section 3.1.1.2 |
+--------------+---+-------------------------------------------+
Table 1: The XML Root Element
3.1.1.2. First Level Elements
The elements in this table MUST appear in the order listed.
+==================+===+============================================+
| Element name | # | Content |
+==================+===+============================================+
| version | O | MUST have the value 1.0. |
+------------------+---+--------------------------------------------+
| report_metadata | R | Report generator metadata; see |
| | | Section 3.1.1.3. |
+------------------+---+--------------------------------------------+
| policy_published | R | The DMARC policy configuration |
| | | observed by the receiving |
| | | system; see Section 3.1.1.5. |
+------------------+---+--------------------------------------------+
| extension | O | Allows for future |
| | | extensibility; see |
| | | Section 3.1.1.6. |
+------------------+---+--------------------------------------------+
| record | + | Record(s) of the feedback from |
| | | the report generator; see |
| | | Section 3.1.1.7. |
+------------------+---+--------------------------------------------+
Table 2: First Level Elements of the Aggregate Feedback Report
There MUST be at least one "record" element; these elements contain
data stating that 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.
3.1.1.3. Report Generator Metadata
+====================+===+=========================================+
| Element name | # | Content |
+====================+===+=========================================+
| org_name | R | Name of the Reporting Organization. |
+--------------------+---+-----------------------------------------+
| email | R | Contact to use when contacting the |
| | | Reporting Organization. |
+--------------------+---+-----------------------------------------+
| extra_contact_info | O | [@lang] Additional contact details. |
+--------------------+---+-----------------------------------------+
| report_id | R | Unique Report-ID; see Section 3.5.1. |
+--------------------+---+-----------------------------------------+
| date_range | R | The reporting period; see |
| | | Section 3.1.1.4. |
+--------------------+---+-----------------------------------------+
| error | O | [@lang] Error messages encountered when |
| | | processing the DMARC Policy Record; see |
| | | Section 3.1.5. |
+--------------------+---+-----------------------------------------+
| generator | O | The name and version of the report |
| | | generator; this can help the Report |
| | | Consumer find out where to report bugs. |
+--------------------+---+-----------------------------------------+
Table 3: Report Generator Metadata
3.1.1.4. Contents of the "date_range" Element
This element describes the time range in UTC defining the reporting
period of this report.
+==============+===+================================+
| Element name | # | Content |
+==============+===+================================+
| begin | R | Start of the reporting period. |
+--------------+---+--------------------------------+
| end | R | End of the reporting period. |
+--------------+---+--------------------------------+
Table 4: Contents of the "date_range" Element
* "begin" and "end" contain the number of seconds since the epoch.
The "begin" and "end" elements are meant to denote the reporting
period and not the first/last observed message from the reporting
period. When generating reports, these reporting periods SHOULD NOT
overlap. Typically, the reporting period will encompass a single UTC
day, beginning at 0000UTC.
3.1.1.5. Contents of the "policy_published" Element
This element provides information on the DMARC Policy Record
published for the Author Domain. The elements from "p" and onwards
contain the discovered or default value for the DMARC policy applied.
Unspecified tags have their default values.
+==================+===+=======================================+
| Element name | # | Content |
+==================+===+=======================================+
| domain | R | The DMARC Policy Domain. |
+------------------+---+---------------------------------------+
| discovery_method | O | The method used to discover the DMARC |
| | | Policy Record used during evaluation. |
+------------------+---+---------------------------------------+
| p | R | A Domain Owner Assessment Policy. |
+------------------+---+---------------------------------------+
| sp | O | A Domain Owner Assessment Policy. |
+------------------+---+---------------------------------------+
| np | O | A Domain Owner Assessment Policy. |
+------------------+---+---------------------------------------+
| fo | O | The value for the failure reporting |
| | | options. |
+------------------+---+---------------------------------------+
| adkim | O | The DKIM Identifier Alignment mode. |
+------------------+---+---------------------------------------+
| aspf | O | The SPF Identifier Alignment mode. |
+------------------+---+---------------------------------------+
| testing | O | The value of the "t" tag. |
+------------------+---+---------------------------------------+
Table 5: Contents of the "policy_published" Element
* "discovery_method" can have the value "psl" or "treewalk", where
"psl" is the method from [RFC7489] and "treewalk" is described in
[RFC9989].
* Many of the items above (p, sp, etc.) are defined in [RFC9989].
3.1.1.6. Contents of the "extension" Element
Use of extensions may cause elements to be added here. These
elements MUST be namespaced.
+==========================+===+==========================+
| Element name | # | Content |
+==========================+===+==========================+
| <any namespaced element> | * | File level elements |
| | | defined by an extension. |
+--------------------------+---+--------------------------+
Table 6: Contents of the "extension" Element
* "<any namespaced element>": Zero or more elements in the namespace
of the related extension declared in the XML root element.
3.1.1.7. Contents of the "record" Element
The report MUST contain one or more records 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.
This element contains all the authentication results that were
evaluated by the receiving system for the given set of messages.
An unlimited number of "record" elements may be specified.
Use of extensions may cause other elements to be added to the end of
the record; such elements MUST be namespaced.
One record (IP, result, authentication identifiers) per tuple.
The elements in this table MUST appear in the order listed.
+==============+===+============================================+
| Element name | # | Content |
+==============+===+============================================+
| row | R | See Section 3.1.1.8. |
+--------------+---+--------------------------------------------+
| identifiers | R | The data that was used to apply policy for |
| | | the given "row"; see Section 3.1.1.10. |
+--------------+---+--------------------------------------------+
| auth_results | R | The data related to authenticating the |
| | | messages associated with this sending IP |
| | | address; see Section 3.1.1.11. |
+--------------+---+--------------------------------------------+
| <any | * | Record level elements defined by an |
| namespaced | | extension. |
| element> | | |
+--------------+---+--------------------------------------------+
Table 7: Contents of the "record" Element
* "<any namespaced element>": Zero or more elements in the namespace
of the related extension declared in the XML root element.
3.1.1.8. Contents of the "row" Element
A "row" element contains the details of the connecting system, and
how many mail messages were received from it, for the particular
combination of the policy evaluated.
+==================+===+=======================================+
| Element name | # | Content |
+==================+===+=======================================+
| source_ip | R | The connecting IP address. |
| | | IPv4address or IPv6address as defined |
| | | in Section 3.2.2 of [RFC3986]. |
+------------------+---+---------------------------------------+
| count | R | Number of messages for which the |
| | | "policy_evaluated" was applied. |
+------------------+---+---------------------------------------+
| policy_evaluated | R | The DMARC disposition applied to |
| | | matching messages; see |
| | | Section 3.1.1.9. |
+------------------+---+---------------------------------------+
Table 8: Contents of the "row" Element
3.1.1.9. Contents of the "policy_evaluated" Element
This element describes the results of applying the DMARC policy. If
alignment fails and the policy applied does not match the DMARC
Policy Domain's configured policy, the "reason" element MUST be
included.
The elements in this table MUST appear in the order listed.
+==============+===+==========================================+
| Element name | # | Content |
+==============+===+==========================================+
| disposition | R | The result of applying the DMARC policy. |
+--------------+---+------------------------------------------+
| dkim | R | The result of the DKIM DMARC Identifier |
| | | Alignment test. |
+--------------+---+------------------------------------------+
| spf | R | The result of the SPF DMARC Identifier |
| | | Alignment test. |
+--------------+---+------------------------------------------+
| reason | * | Policy override reason; see |
| | | Section 3.1.1.14. |
+--------------+---+------------------------------------------+
Table 9: Contents of the "policy_evaluated" Element
* "spf" and "dkim" MUST be the evaluated values as they relate to
DMARC, not the values the receiver may have used when overriding
the policy.
* "reason" elements are meant to contain 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.
3.1.1.10. Contents of the "identifiers" Element
+===============+===+===========================================+
| Element name | # | Content |
+===============+===+===========================================+
| header_from | R | The RFC5322.From domain from the message. |
+---------------+---+-------------------------------------------+
| envelope_from | O | The RFC5321.MailFrom domain that the SPF |
| | | check has been applied to. |
+---------------+---+-------------------------------------------+
| envelope_to | O | The RFC5321.RcptTo domain from the |
| | | message. |
+---------------+---+-------------------------------------------+
Table 10: Contents of the "identifiers" Element
* "envelope_from" MAY exist but be empty if the message had a null
reverse-path (see Section 4.5.5 of [RFC5321]).
3.1.1.11. Contents of the "auth_results" Element
This element contains DKIM and SPF results, uninterpreted with
respect to DMARC.
If validation is attempted for any DKIM signature, the results MUST
be included in the report (within reason; see Section 3.1.3 ("DKIM
Signatures in Aggregate Reports") below for handling numerous
signatures).
The elements in this table MUST appear in the order listed.
+==============+===+=============================+
| Element name | # | Content |
+==============+===+=============================+
| dkim | * | DKIM authentication result; |
| | | see Section 3.1.1.12. |
+--------------+---+-----------------------------+
| spf | O | SPF authentication result; |
| | | see Section 3.1.1.13. |
+--------------+---+-----------------------------+
Table 11: Contents of the "auth_results" Element
3.1.1.12. Contents of the "dkim" Element
+==============+===+===============================================+
| Element name | # | Content |
+==============+===+===============================================+
| domain | R | The domain that was used during validation |
| | | (the "d=" tag in the signature). |
+--------------+---+-----------------------------------------------+
| selector | R | The selector that was used during validation |
| | | (the "s=" tag in the signature). |
+--------------+---+-----------------------------------------------+
| result | R | DKIM verification result; see below. |
+--------------+---+-----------------------------------------------+
| human_result | O | [@lang] More descriptive information to the |
| | | Domain Owner relating to evaluation failures. |
+--------------+---+-----------------------------------------------+
Table 12: Contents of the "dkim" Element
* "result" is a lowercase string where the value is one of the
results defined in Section 2.7.1 of [RFC8601].
3.1.1.13. Contents of the "spf" Element
Only the "MAIL FROM" identity (see Section 2.4 of [RFC7208]) is used
in DMARC.
+==============+===+===============================================+
| Element name | # | Content |
+==============+===+===============================================+
| domain | R | The domain that was used during validation. |
+--------------+---+-----------------------------------------------+
| scope | O | The source of the domain used during |
| | | validation. |
+--------------+---+-----------------------------------------------+
| result | R | SPF verification result; see below. |
+--------------+---+-----------------------------------------------+
| human_result | O | [@lang] More descriptive information to the |
| | | Domain Owner relating to evaluation failures. |
+--------------+---+-----------------------------------------------+
Table 13: Contents of the "spf" Element
* The only valid value for the "scope" element is "mfrom".
* "result" is a lowercase string where the value is one of the
results defined in Section 2.7.2 of [RFC8601].
3.1.1.14. Contents of the "reason" Element
The policy override reason consists of a pre-defined override type
and free-text comment; see Section 3.1.6.
+==============+===+============================================+
| Element name | # | Content |
+==============+===+============================================+
| type | R | The reason the DMARC policy was overridden |
+--------------+---+--------------------------------------------+
| comment | O | [@lang] Further details, if available. |
+--------------+---+--------------------------------------------+
Table 14: Contents of the "reason" Element
3.1.2. Handling Domains in Reports
In the same report, there MUST be a single DMARC 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 Policy Records for example.com and
bar.example.com, with distinct policies. There is no explicit DMARC
Policy 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 report will be for bar.example.com and contain only one
"record", for bar.example.com. The second report will be for
example.com and will contain multiple "record" elements, one for
example.com and one for foo.example.com (and by extension, other
"record" elements for subdomains that likewise did not have an
explicit DMARC Policy Record).
3.1.3. 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
A report SHOULD contain no more than 100 signatures for a given
"row", in decreasing priority.
3.1.4. 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.
3.1.5. Error Element
Here are a few examples of information contained within the "error"
element(s):
* DMARC Policy Record evaluation errors (invalid "rua", "sp", etc.)
* Multiple DMARC Policy Records at a given location
Be mindful that the "error" element 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 Policy Record.
3.1.6. Policy Override Reason
The "reason" element, indicating an override of the DMARC policy,
consists of a mandatory "type" element and an optional "comment"
element. The "type" element MUST have one of the pre-defined values
listed below. The "comment" element is an unbounded string for
providing further details.
Possible values for the policy override type:
"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 details can be found in the
"comment" element.
"policy_test_mode": 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.