What to Look For in DMARC Reports

The hard part is not setup. It is interpretation.

You have DMARC running in monitor mode. Your DNS record says v=DMARC1; p=none; rua=mailto:your-reports@example.com. You are receiving aggregate reports. And then you open one and see a wall of XML or JSON that means nothing to you.

That is where most email administrators get stuck. They did the hard work of setting up SPF, DKIM, and DMARC. But the reports sitting in their inbox are not actionable on their own. This guide fixes that.

By the end you will know the four signals that matter in every DMARC report, how to tell normal from concerning, and when to move from p=none toward enforcement. And if you are managing this manually, you will understand exactly why most administrators who skip this step end up delaying their DMARC enforcement by months.

What DMARC aggregate reports actually contain

Before diving in, a quick orientation. Aggregate reports arrive daily (sometimes weekly) from participating mail receivers. Each report covers a 24-hour window and lists every message that attempted to deliver to a receiver that enforces DMARC.

The key fields in each record are:

Source IP: the IP address that tried to send mail on your behalf
Count: how many messages from that IP
SPF result: pass or fail
DKIM result: pass or fail
Alignment: did the From domain align with the SPF or DKIM domain (aligned means the message is legitimate; not aligned means something needs investigating)
Disposition: none, quarantine, or reject (p=none means you see this but receivers do not act on it)

If you are reading reports manually, the first thing you need is a parser or aggregator. Raw XML reports are not designed for human reading. But the four signals below are what you are looking for once you have a readable view. Tools like DMARCFlow pull all your aggregate reports into a single dashboard and surface these signals automatically, so you do not have to parse XML to find them.

Signal 1: Unauthorized sending sources

The most important thing to check in any DMARC report is which IP addresses are sending mail on your domain.

If you see an IP passing SPF or DKIM that you do not recognize, that is worth five minutes of investigation. It might be a legitimate third-party service you forgot about (a CRM, a marketing platform, a legacy mail server). Or it might be something else.

How to investigate: take the source IP and do a reverse DNS lookup. Check whether the hostname it resolves to matches your organization. Search the IP in Spamhaus or similar blocklists. Ask your team whether they recognize it.

If the IP is unknown, passing SPF because your record includes it via an include mechanism, but no one in your organization set that up, that is a gap in your inventory. You need to either add it to your SPF record deliberately or confirm it should not be sending as your domain.

Without a monitoring tool, discovering new sending sources requires reading every report carefully. With one, new IPs appear as alerts rather than buried in data.

Signal 2: Alignment failures

Alignment is separate from authentication. A message can pass SPF and still fail DMARC if the From domain does not align with the sending domain.

The most common case: your SPF record covers mail.example.com, but the From address shows @example.com. The sending domain and the From domain do not match, so alignment fails. The message is authenticated but not aligned.

In your DMARC reports, look for sources where SPF result = pass or DKIM result = pass, but alignment = fail. A small number of alignment failures is normal, especially with third-party services that do not use your exact From domain. But if more than roughly 5-10% of your volume is failing alignment, something in your setup is wrong.

Common causes:

A mailing list or forwarding service that rewrites the From address

A legacy system that sends from a subdomain not covered by your SPF record

A CRM or automation tool that sends from its own infrastructure but uses your From domain

Fixing alignment failures usually means either updating your SPF record to cover the sending infrastructure, or ensuring your DKIM selector is signing the From domain.

Signal 3: Authentication pass rates

If your DMARC reports show that most mail is passing SPF and DKIM, your setup is healthy. If pass rates are consistently low, something is misconfigured.

A pass rate below 80-85% for either SPF or DKIM warrants investigation. Common causes include:

SPF: multiple sending sources with different IPs, some of which are not in your SPF record. This often happens when teams add new tools without updating DNS.
DKIM: the DKIM selector is not signing all sending sources, or a key rotation broke the signing for one service.

Low pass rates are not always a security problem. But they are a configuration problem. Fixing them makes your DMARC setup cleaner and gives you a more reliable baseline before you move to enforcement.

Signal 4: Geographic and ISP patterns

Some DMARC aggregate reports include the ISP or geographic origin of sending mail. If your legitimate mail comes from known datacenters in the US and Europe, and you suddenly see volume from servers in regions you do not use, that is a signal.

This is one of the less-discussed signals in DMARC reporting, but it matters for phishing detection. If a phishing campaign is using your domain, the sending infrastructure will often differ from your legitimate sending patterns. Unexplained geographic anomalies in your reports are worth flagging.

Not all receivers include geographic data in their aggregate reports. If yours do not, this signal is not available to you. Focus on the first three.

Reading your first real report: an example

Imagine a small company, example.com. They have one primary mail provider (Google Workspace) and one marketing platform (Mailchimp). Their DMARC record is v=DMARC1; p=none; rua=mailto:reports@example.com.

In their first aggregate report they see:

94% of mail from Google Workspace IPs, SPF pass, DKIM pass, alignment pass
5% of mail from Mailchimp IPs, SPF fail, DKIM pass, alignment pass
1% of mail from an IP in Eastern Europe, SPF pass, DKIM fail, alignment fail

The Mailchimp failures are a known issue: Mailchimp often sends from IPs that are not in the customer's SPF record, but DKIM alignment passes because Mailchimp signs the From domain. The fix is to accept these failures as a known limitation or to use a DMARC-compliant sending option if Mailchimp offers one.

The Eastern Europe IP with alignment failures is the real concern. That 1% could be a third-party system you forgot about, or it could be someone sending as your domain from infrastructure you do not control. Investigate before moving to enforcement.

This is exactly the scenario where a monitoring tool changes the outcome. Without one, that 1% from Eastern Europe gets buried in a sea of XML. With a dashboard that flags new sending sources and alignment failures automatically, it surfaces immediately.

When to move from p=none to p=quarantine

The standard advice is to run p=none for at least 30 days to build a baseline. But the real trigger is confidence in your data.

Move to p=quarantine when:

You have identified every legitimate sending source
Your pass rates for SPF and DKIM are above 90%
Alignment failures are below 5% and have been explained
You have investigated and resolved any unknown sending sources

If you move to quarantine too early, legitimate mail gets flagged. If you wait too long without reviewing reports, you stay exposed. The goal is to move when you have enough data to be confident, not on a fixed calendar.

When to move from p=quarantine to p=reject

Reject is the strongest DMARC policy. Mail that fails DMARC is deleted at the receiver.

Move to p=reject when:

p=quarantine has been running for 30-60 days without significant legitimate mail being quarantined
You have high confidence in your sending infrastructure
You have resolved all alignment failures from legitimate sources

Some organizations skip quarantine and go straight to reject if they have a very simple, well-understood sending setup. For most, the graduated approach is safer. DMARCFlow's dashboards make it straightforward to check whether any legitimate mail is being affected before you make the jump.

---

FAQ

How often do DMARC aggregate reports arrive?
Most receivers send them daily, some weekly. The timing is set by the receiver, not by you. If you are not receiving reports, check that your rua target is correct and that your receiving server accepts the volume.

What if my report shows 100% alignment pass rate?
That is a good sign, assuming you have verified all the sending sources. It means everything sending as your domain is passing authentication and alignment. You may be ready to move toward enforcement faster than you thought.

Can DMARC reports tell me if someone is impersonating my domain?
Not directly. DMARC tells you who is sending mail that passes your authentication. If a phisher sends from infrastructure that does not pass SPF or DKIM for your domain, you will see the failures in your report. If a phisher somehow passes authentication (rare, and requires either a compromised sending system or a subdomain misconfiguration), you may not see it in aggregate reports at all.

Should I set p=none forever?
No. p=none is a monitoring mode, not a long-term policy. Once you have a clear picture of your sending infrastructure and have resolved obvious problems, move to p=quarantine. Staying in monitor mode indefinitely leaves you exposed to spoofing that DMARC would otherwise block.

Do I need to set up SPF, DKIM, and DMARC for every subdomain?
Yes, in most cases. DMARC validation applies per-domain. If sub.example.com sends mail but does not have its own SPF record or DKIM signature, messages from that subdomain will fail alignment. You can use a wildcard SPF record to cover subdomains, but DKIM typically requires per-subdomain configuration.