Reports are the only way to see who is sending as your domain, including vendors you forgot and attackers you never knew about. Moving to p=reject safely depends on reading them.
How to implement DMARC aggregate reports#
- Publish rua=mailto: pointing to a dedicated mailbox or a report processor.
- Collect reports for at least two weeks before drawing conclusions.
- Group sources by IP owner and match each to a known vendor.
- Fix alignment for legitimate sources; treat unknown high-volume sources as spoofing.
- Track pass rate weekly and tighten policy as it approaches 100%.
<record>
<row><source_ip>203.0.113.10</source_ip><count>412</count>
<policy_evaluated><disposition>none</disposition><dkim>pass</dkim><spf>fail</spf></policy_evaluated></row>
<identifiers><header_from>example.com</header_from></identifiers>
</record>How to verify it worked#
Send a test message to seed mailboxes at Gmail, Outlook, and Yahoo, then inspect the Authentication-Results and delivery headers. Repeat after any DNS or sending-platform change.
Common mistakes#
- Reading raw XML by hand and giving up after day two.
- Ignoring low-volume unknown sources that turn out to be your own systems.
- Expecting RUF reports; most large providers no longer send them.
Frequently asked questions#
How do I read a DMARC report?
Each record lists a source IP, message count, SPF and DKIM results, and alignment. Use an analyzer to aggregate by source; the goal is to name every IP range.
Why do I see mail from IPs I do not recognize?
Common causes are forwarding, a vendor you forgot, an employee's personal tool, or spoofing. Volume and geography usually tell them apart.