Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting

4.1. Transport

Email streams carrying DMARC failure reports SHOULD provide be DMARC aligned.¶

Reporters MAY rate limit the number of failure reports sent to any recipient to avoid overloading recipient systems. Unaligned reports may in turn produce subsequent failure reports that could cause mail loops.¶

5.1. Feedback Report Header Fields Registry Update

IANA is requested to change the "Identity-Alignment" entry in the "Feedback Report Header Fields" registry to refer to this document.¶

6.1. Data Exposure Considerations

Failed-message reporting provides message-specific details pertaining to authentication failures. Individual reports can contain message content as well as trace header fields. Domain Owners are able to analyze individual reports and attempt to determine root causes of authentication mechanism failures, gain insight into misconfigurations or other problems with email and network infrastructure, or inspect messages for insight into abusive practices.¶

These reports may expose sender and recipient identifiers (e.g., RFC5322.From addresses), and although the [RFC6591] format used for failed-message reporting supports redaction, failed-message reporting is capable of exposing the entire message to the report recipient.¶

Domain Owners requesting reports will receive information about mail claiming to be from them, which includes mail that was not, in fact, from them. Information about the final destination of mail where it might otherwise be obscured by intermediate systems will therefore be exposed.¶

When message-forwarding arrangements exist, Domain Owners requesting reports will also receive information about mail forwarded to domains that were not originally part of their messages' recipient lists. This means that destination domains previously unknown to the Domain Owner may now become visible.¶

6.2. 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.¶

A.1. Entire Domain, Monitoring Only, Per-Message Reports

The owners of the domain "example.com" have deployed SPF and DKIM on their messaging infrastructure. As described in, Appendix B.2.1 of [I-D.ietf-dmarc-aggregate-reporting] they have used the aggregate reporting to discover some messaging systems that had not yet implemented DKIM correctly. However, they are still seeing periodic authentication failures. In order to diagnose these intermittent problems, they wish to request per-message failure reports when authentication failures occur.¶

Many Receivers will not honor such a request, but the Domain Owner feels that any reports it does receive will be helpful enough to justify publishing this record.¶

The Domain Owner accomplishes this by adding the following to its policy record:¶

Failure reports should be sent via email to the address "auth-reports@example.com" ("ruf=mailto:auth-reports@example.com")¶

The updated DMARC policy record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):¶

% dig +short TXT _dmarc.example.com.
  "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
   ruf=mailto:auth-reports@example.com"

To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file (following the conventional zone file format):¶

 DMARC record for the domain example.com

 _dmarc  IN TXT ( "v=DMARC1; p=none; "
                  "rua=mailto:dmarc-feedback@example.com; "
                  "ruf=mailto:auth-reports@example.com" )

A.2. Per-Message Failure Reports Directed to Third Party

The Domain Owner from the previous example is maintaining the same policy but now wishes to have a third party receive and process the per-message failure reports. Again, not all Receivers will honor this request, but those that do may implement additional checks to validate that the third party wishes to receive the failure reports for this domain.¶

The Domain Owner needs to alter its policy record from {#entire-domain-monitoring-only-per-message-reports} as follows:¶

Per-message failure reports should be sent via email to the address "auth-reports@thirdparty.example.net" ("ruf=mailto:auth-reports@thirdparty.example.net")¶

The DMARC policy record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):¶

% dig +short TXT _dmarc.example.com.
  "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
   ruf=mailto:auth-reports@thirdparty.example.net"

To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file (following the conventional zone file format):¶

; DMARC record for the domain example.com

 _dmarc IN TXT ( "v=DMARC1; p=none; "
                  "rua=mailto:dmarc-feedback@example.com; "
                  "ruf=mailto:auth-reports@thirdparty.example.net" )

Because the address used in the "ruf" tag is outside the Organizational Domain in which this record is published, conforming Receivers will implement additional checks as described in Section 4 of this document. In order to pass these additional checks, the third party will need to publish an additional DNS record as follows:¶

Given the DMARC record published by the Domain Owner at "_dmarc.example.com", the DNS administrator for the third party will need to publish a TXT resource record at "example.com._report._dmarc.thirdparty.example.net" with the value "v=DMARC1;"¶

The resulting DNS record might look like this when retrieved using a common command-line tool (the output shown would appear on a single line but is wrapped here for publication):¶

% dig +short TXT example.com._report._dmarc.thirdparty.example.net
  "v=DMARC1;"

To publish such a record, the DNS administrator for example.net might create an entry like the following in the appropriate zone file (following the conventional zone file format):¶

 zone file for thirdparty.example.net
; Accept DMARC failure reports on behalf of example.com

example.com._report._dmarc   IN   TXT    "v=DMARC1;"

Intermediaries and other third parties should refer to Section 4 for the full details of this mechanism.¶

C.1. 00 to 01

• Replace references to RFC7489 with references to I-D.ietf-dmarc-dmarcbis.¶

• Replace the 2nd paragraph in the Introduction with the text proposed by Ned for Ticket #55, which enjoys some consensus:
  https://mailarchive.ietf.org/arch/msg/dmarc/HptVyJ9SgrfxWRbeGwORagPrhCw¶

• Strike a spurious sentence about criticality of feedback, which was meant for feedback in general, not failure reports. In fact, failure reports are not critical to establishing and maintaining accurate authentication deployments. Still attributable to Ticket #55.¶

• Remove the content of section "Verifying External Destinations" and refer to I-D.ietf-dmarc-aggregate-reporting.¶

• Remove the content of section "Security Considerations" and refer to I-D.ietf-dmarc-dmarcbis.¶

• Slightly tweak the wording of the example in Appendix A.1 so that it makes sense standing alone.¶

• Remove the sentence containing "must include any URI(s)", as the issue arose <eref target="https://mailarchive.ietf.org/arch/msg/dmarc/mFk0qiTCy8tzghRvcxus01W_Blw"/>.¶

• Add paragraph in Security Considerations, noting that note that Organizational Domains are only an approximation...¶

• Add a Transport section, mentioning DMARC conformance and failure report mail loops (Ticket #28).¶

C.2. 01 to 02

• Add a sentence to make clear that counting failures is not the aim.¶

C.3. 02 to 03

• Updated references.¶

C.4. 03 to 04

• Add an example report.¶

• Remove the old Acknowledgements section.¶

• Add a IANA Consideration section¶

C.5. 04 to 05

• Convert to markdown¶

• Remove irrelevant material.¶