4. Verifying External Destinations
このページは RFC 9990 の該当節を要約し, XML schema, report fields, IANA values を保持します.
The external destination verification algorithm is preserved below. It protects third parties from report flooding by requiring authorization through _report._dmarc DNS records.
4. 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.
When a Mail Receiver discovers a DMARC Policy Record 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. If the length of the constructed name exceed DNS limits, a
positive determination of the external reporting relationship
cannot be made; stop.
5. 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.
6. For each record returned, parse the result as a series of
"tag=value" pairs, i.e., the same overall format as the DMARC
Policy Record (see Section 4.7 of [RFC9989]). In particular, the
"v=DMARC1" tag is mandatory and MUST appear first in the list.
Discard any that do not pass this test. A trailing ";" is
optional.
7. If the result includes no TXT resource records that pass basic
parsing, a positive determination of the external reporting
relationship cannot be made; stop.
8. If at least one TXT resource record remains in the set after
parsing, then the external reporting arrangement was authorized
by the Report Consumer.
9. 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 Consumer 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 the DMARC Policy Record for "blue.example.com"
contained "rua=mailto:[email protected]", the Organizational
Domain 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
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 Consumer, 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 Consumer publishes such a record in its DNS
if it wishes to receive reports for other domains.
A Report Consumer 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 Consumer 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.
If the DNS query length is excessively long (Step 4 above), the
Domain Owner may need to consider using a shorter domain name or
coordinate with another party that may allow for a shorter DNS label.