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.
Mistake 1: Reading raw XML by hand and giving up after day two#
Why it hurts: this undermines DMARC aggregate reports at the point where mailbox providers make their decision, and it is rarely surfaced by your own tooling until placement drops.
Fix: Publish rua=mailto: pointing to a dedicated mailbox or a report processor.
Mistake 2: Ignoring low-volume unknown sources that turn out to be your own systems#
Why it hurts: this undermines DMARC aggregate reports at the point where mailbox providers make their decision, and it is rarely surfaced by your own tooling until placement drops.
Fix: Collect reports for at least two weeks before drawing conclusions.
Mistake 3: Expecting RUF reports; most large providers no longer send them#
Why it hurts: this undermines DMARC aggregate reports at the point where mailbox providers make their decision, and it is rarely surfaced by your own tooling until placement drops.
Fix: Group sources by IP owner and match each to a known vendor.
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.