This guide assumes DMARC aggregate reports is already deployed and passing. It covers what breaks at scale and how mature teams operate it.
Edge cases that break a working setup#
- 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.
- Mail forwarded through mailing lists or personal forwarders, which alters headers and content.
- Acquisitions and rebrands that introduce domains nobody audited.
- Vendors silently changing their sending infrastructure.
Operating it as infrastructure#
- Assign an owner for each sending domain and each vendor relationship.
- Put DNS records under version control or a change-review process.
- Alert on authentication pass rate drops and reputation changes, not just outages.
- Run a quarterly audit against the setup steps below.
- Document runbooks for the three most common failures.
Reference: the baseline setup#
- 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>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.