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

7.1. 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 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 [URI] specified in the "rua" or "ruf" tag, the following verification steps are to be taken:

1. Extract the host portion of the authority component of the URI. Call this the "destination host".

2. Prepend the string "_report._dmarc" to the destination host to construct a DNS domain name for querying.

3. Issue a DNS A or AAAA RRset query for the constructed name. If a query returns a valid ANSWER response, the result is a list of IP addresses corresponding to the destination host.

4. Resolve the Organizational Domain of the destination host using the method described in Section 3.2.

5. If the domain from which the policy was retrieved is identical to the Organizational Domain of the destination host, the Mail Receiver SHOULD send the requested reports. Otherwise, the Mail Receiver MUST NOT send reports.

6. If no result is obtained after performing the above verification, the Mail Receiver MUST NOT send the report.

7.2. Aggregate Reports

The DMARC aggregate feedback report is designed to provide Domain Owners with precise insight into authentication results and compliance from Mail Receivers. Aggregate reports are sent as XML documents [XML] using a format specified below.

Aggregate reports contain data that is not especially sensitive. However, they can expose information about the domain's infrastructure and mail flow. Section 9 discusses privacy considerations.

7.2.1. Report Format

The report format is as follows:

The XML schema for aggregate feedback reports is defined in Appendix C. Aggregate reports MUST be formatted per this schema.

The following is an example of an aggregate report:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>mail.receiver.example</org_name>
    <email>[email protected]</email>
    <extra_contact_info>http://mail.receiver.example/dmarc/support</extra_contact_info>
    <report_id>9391651994964116463</report_id>
    <date_range>
      <begin>1335521200</begin>
      <end>1335607599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>72.150.241.94</source_ip>
      <count>2</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>fail</result>
        <human_result>fail (body has been altered)</human_result>
      </dkim>
      <dkim>
        <domain>example.net</domain>
        <result>pass</result>
        <human_result></human_result>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

7.2.2. Aggregate Report Data Elements

The following elements are included in aggregate reports:

• report_metadata: Metadata about the report itself, including the reporting organization, date range, and report ID.

• policy_published: The DMARC policy that was in effect for the domain during the reporting period.

• record: Contains data pertaining to a specific group of messages. Multiple record elements may be present in a single report.

• row: Data about the messages, including source IP, message count, and the policy evaluation result.

• identifiers: Domain-level identifiers extracted from the message.

• auth_results: The results of SPF and DKIM authentication checks.

7.3. Failure Reports

Failure reports can supply more detailed information about individual messages that fail authentication checks. These reports are formatted per [AFRF].

Failure reports are normally sent when all underlying authentication mechanisms fail to produce a DMARC-compliant result. However, the Domain Owner can request different failure reporting options using the "fo" tag described in Section 6.3.

The following elements are included in failure reports:

• Arrival-Date: The date and time the message was received.

• Authentication-Results: The authentication results for the message, including SPF and DKIM results.

• Delivery-Result: The action taken by the Mail Receiver.

• DKIM-Domain: The DKIM "d=" value(s).

• DKIM-Identity: The DKIM "i=" value(s).

• DKIM-Selector: The DKIM "s=" value(s).

• Reported-Domain: The domain from the RFC5322.From header field.

• Source-IP: The IP address of the connecting SMTP client.

• SPF-DNS: The SPF record retrieved from DNS.

Failure reports SHOULD include as much detail as possible without revealing information that might be useful to an attacker. If the body of the message is included, it SHOULD be redacted to protect user privacy.

---