April 10, 2026

What to Do With Your DMARC Reports (A Checklist for Indie Developers)

6 min readdmarchow-toindie-developers

Your DMARC reports are telling you four things. Here's how to act on each one.

This isn't a post about what the fields mean; there's already a good explainer on that. This is a checklist. You opened a report (or pasted it into the DMARC analyzer), you can see the data, and now you're not sure what to do with it. Start here.

1. Find senders you didn't authorize

Scan the source IP list. For each IP, ask: did I set up a service that would send from here?

Your known senders are things like Google Workspace, your transactional email provider (Resend, SendGrid, Mailgun, Postmark), and your marketing tool if you use one. Every IP on the list should map to one of those.

If you see an IP you don't recognize:

Look up the ASN. If it's an ESP you use, you probably just missed adding their SPF include or DKIM key.
If it's not an ESP you recognize at all, and the volume is significant (more than a handful of messages), treat it as a spoofing signal worth investigating.
If the volume is tiny (1-2 messages) and the IP is a consumer ISP, it's probably a misforwarded email, not a threat, just noise.

Verdict: Any unrecognized sender with more than ~10 messages over multiple days is worth a closer look.

2. Check SPF and DKIM alignment on your known senders

For each source you recognize, look at dkim_aligned and spf_aligned. DMARC passes when either one is aligned, so your legitimate senders should have at least one of these passing, ideally both.

If one is failing on a sender you control:

SPF failing: your ESP's sending IP isn't covered by your SPF record. Add their include: mechanism. Check the SPF checker to confirm the fix.
DKIM failing: the ESP isn't signing with a key under your domain, or the DKIM record is wrong. Check the ESP's DNS setup guide; most have a step to add a CNAME or TXT record under your domain.
Both failing: the sender isn't authorized at all. Either you forgot to set them up properly when you added the service, or the service changed its infrastructure.

A legitimate sender that's consistently failing alignment is the most actionable finding in any DMARC report. It means your emails from that service are at risk of being filtered once you tighten your policy.

3. Look at volume spikes on failing sources

Volume matters. One failing message is noise. Five hundred failing messages from a source you don't recognize is something else.

Sort your records by message count. If a source you can't explain has high volume and consistently fails alignment, that's the closest thing DMARC gives you to a spoofing alert: it means someone is sending large quantities of mail pretending to be from your domain.

What to do if you find a high-volume unrecognized sender:

Look up the IP and ASN. Check if it belongs to a known ESP or hosting provider.
If you can identify the service, decide whether you want to authorize it (add to SPF/DKIM) or block it (move toward p=reject).
If you can't identify it, note the IP range and check whether it shows up in subsequent reports. Persistent high-volume senders you don't own are worth investigating.

4. Decide whether you're ready to move past p=none

This is what your reports are ultimately for. p=none is monitoring mode: it shows you the data but doesn't block anything. Moving to p=quarantine or p=reject means failing mail actually gets filtered.

Here's a simple decision tree:

Stay at p=none if:

You still have senders failing alignment that you haven't diagnosed yet
You added a new email service in the last 30 days and haven't confirmed its alignment
Your total aligned percentage (passing DKIM or SPF) is below 95%

Move to p=quarantine if:

All your known senders are passing alignment consistently
Your aligned percentage has been above 95% for at least two weeks of reports
You understand every source on your sender list

Move to p=reject if:

You've been at p=quarantine for at least a month with no legitimate mail going to spam
Your aligned percentage is consistently above 99%
You're confident you know every service that sends mail for your domain

For more detail on the quarantine vs. reject tradeoff, see p=reject vs p=quarantine: which policy is right for you.

If this feels like too much to track manually

It is. Reports arrive daily. Senders change. A new ESP you added three months ago might quietly start failing because they rotated their signing key. Tracking this by hand means downloading XML files, parsing them, and comparing them to last week's snapshot, which is exactly why most domains stay at p=none forever.

DMARCdrift ingests your reports automatically as they arrive, tracks your alignment over time, and alerts you when something changes: a new unknown sender, a drop in alignment on a sender that was passing, or a DNS change to your DMARC record. The goal is the same checklist as above, done continuously without the manual work.

FAQ

Check for unrecognized senders, verify that your known senders are passing SPF and DKIM alignment, watch for volume spikes on failing sources, and use the data to decide when you're ready to tighten your DMARC policy from p=none toward p=quarantine or p=reject.

Reports arrive daily from major receivers. Weekly review is enough for most low-volume domains; you're looking for trends, not individual messages. If you've recently added a new email service or changed your DNS, check within 48 hours to confirm alignment is working correctly.

A DMARC failure means a message failed both DKIM alignment and SPF alignment. What happens to that message depends on your policy: p=none delivers it anyway, p=quarantine routes it to spam, and p=reject tells the receiver to bounce it. A failure isn't always malicious; it's often a legitimate sender that wasn't configured correctly.