Why Your DMARC Reports Look Scary

You published a DMARC record with rua= reporting. A few days later, you open your first aggregate report and see dozens of IP addresses sending email as your domain — many of which you don't recognize. Before you panic, here's what's actually going on.

What DMARC aggregate reports contain

DMARC aggregate reports are XML files sent daily by mailbox providers. Each report covers a 24-hour period and contains:

• The source IP addresses of servers that sent mail claiming to be from your domain
• Whether each message passed or failed SPF, DKIM, and DMARC
• How many messages came from each source
• What policy was applied (none, quarantine, reject)

Common benign senders you'll see

Most "unknown" senders in your DMARC reports are legitimate. Here are the most common ones:

• Mailing lists: When someone forwards your email through a mailing list, the list server re-sends it. SPF fails (different server), and DKIM may break (if the list modifies headers or body). This is normal.
• Email forwarding: If a recipient auto-forwards your email to another address, the forwarding server sends it from a different IP. SPF fails because the forwarding server isn't in your SPF record.
• Security scanners: Services like Barracuda, Mimecast, and Proofpoint may re-send messages through their infrastructure for scanning, changing the source IP.
• Internal tools you forgot about: CRM systems, monitoring alerts, CI/CD pipelines, old WordPress sites — any system sending email as your domain.
• Partner systems: Vendors or partners sending on your behalf (invoicing, support tickets) that use your domain in the From address.

When to worry

Not everything in your reports is benign. Watch for these red flags:

• High volume from unknown IPs: If you see thousands of messages from IPs you can't identify, someone may be spoofing your domain
• Messages from hosting providers: IPs belonging to AWS, DigitalOcean, or other hosting services (that you don't use) sending as your domain
• Geographic anomalies: Sending IPs from countries where you don't operate
• Consistent DKIM failures with your own selector: If messages signed with your DKIM key are failing, the key may be compromised or misconfigured

How to interpret alignment failures

A message can pass SPF and DKIM but still fail DMARC if the domains don't align. Common scenarios:

• Envelope sender mismatch: Your marketing tool sends from bounce.marketingtool.com (envelope) but you@yourdomain.com (From). SPF passes for the marketing tool's domain, but fails DMARC alignment because the domains don't match.
• DKIM signed with wrong domain: Your service signs with d=serviceprovider.com instead of d=yourdomain.com. DKIM passes, but DMARC alignment fails.

The fix is usually configuring your sending services to use your domain for authentication (custom envelope sender, DKIM signing with your domain).

What to do next

1. Identify every source IP in your reports (use reverse DNS lookups and IP ownership databases)
2. Categorize each source: legitimate (fix authentication), benign (forwarding, lists), or suspicious (investigate)
3. Fix alignment for legitimate senders before enforcing DMARC policy
4. Don't move to p=quarantine until you understand every significant sender in your reports