Enabling and reading DMARC reports

DMARC (RFC 7489) tells receiving servers what to do with mail whose From domain does not align with a passing SPF or DKIM result. The rua tag asks receivers to send aggregate reports, usually once a day, summarizing what they saw. Reports are the only reliable way to find legitimate senders that are not authenticated before you tighten the policy.

1. Publish a monitoring record

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

• p=none collects reports and changes nothing for delivery.
• rua is the address that receives aggregate reports. Use an alias or a plus address so reports are easy to filter. See subaddressing.
• adkim and aspf set alignment to relaxed (r) or strict (s). Relaxed is the default and the right starting point.

Check the record:

dig +short TXT _dmarc.example.com

If the rua address is on a different domain, that domain must authorize receiving reports for yours. Publish this record on the other domain:

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

2. Read a report

Reports are XML, normally sent as a gzip or zip attachment. Decompress one and format it for reading:

gunzip -c report.xml.gz | xmllint --format - | less

The file has three parts. report_metadata gives the reporting organization and date range. policy_published shows the policy your record announced. Each record describes a group of messages from one source:

<record>
  <row>
    <source_ip>203.0.113.50</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

The policy_evaluated block shows the DMARC result for those messages. A message passes DMARC if SPF or DKIM passes and aligns with the From domain. In the example, SPF passes and aligns, so the message passes DMARC even though DKIM fails.

Sort what you find into three groups:

• Your legitimate senders failing. Fix their SPF include or DKIM signing before you change the policy.
• Unknown sources with high counts. Usually spoofing. Enforcement will stop most of it.
• Forgotten services. A marketing tool or invoice system you no longer use may still send as your domain. Remove it or set it up correctly.

3. Move to quarantine

When every legitimate source passes for several weeks, start enforcing gradually:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com"

The pct tag applies the policy to that percentage of failing mail. Raise it in steps, for example 25, 50, then 100, watching the reports after each change. Quarantine usually means the receiver files the message in spam.

4. Move to reject

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

With p=reject, receivers that honor DMARC refuse messages that fail. Before you publish it, confirm the reports show no legitimate failures for the most recent weeks. Keep rua in place, because reports keep showing attempted spoofing. If your subdomains send mail, set sp= explicitly, since subdomains otherwise inherit the policy.

Tips

• Expect the first reports within a day or two. Full coverage can take several weeks, because some senders only send monthly.
• Do not treat a passing report as proof of delivery. DMARC does not guarantee that a receiver accepts a message.
• Look at DKIM failures after any change to a signing key. See rotating DKIM keys.
• Diagnose individual failures with troubleshooting delivery.