How to Act on DMARC Aggregate Reports

When you first set up DMARC and switch it to p=none, you start receiving aggregate reports. They arrive daily. They are XML files, sometimes compressed. You open one and see rows of data you half-recognize: source IP, SPF result, DKIM result, DMARC disposition. Some rows show pass. Many show fail. Your first instinct is to ignore the whole thing.

That instinct is wrong. But the instinct is understandable, because aggregate reports do not come with instructions.

This guide is the instructions.

What DMARC Aggregate Reports Actually Tell You

An aggregate report covers a 24-hour window. Each row in the report represents one sending source that delivered mail on behalf of your domain during that window. Here is what each column means:

Source IP: the mail server that sent the message
SPF result: whether the sending server is authorized by your SPF record (pass or fail)
DKIM result: whether the message was signed with a valid DKIM key for your domain (pass or fail)
DMARC result: whether alignment passed (the From domain matches the SPF or DKIM domain) - pass or fail
Disposition: what the receiving server did with the message - none, quarantine, or reject

The most common confusion: a row can show SPF pass and DKIM pass but still show DMARC fail. That happens because SPF and DKIM are authentication checks. DMARC is an alignment check. Your mail server can be authorized (SPF pass) and your message can be signed correctly (DKIM pass), but if the From domain does not align with the sending infrastructure, DMARC fails.

Here is a real example of what a failure row might look like:

 Source IP: 203.0.113.45 SPF: pass DKIM: fail DMARC: fail Disposition: none Count: 12

That row tells you: a server at 203.0.113.45 sent 12 messages claiming to be from your domain. SPF passed because that server is probably in your SPF record. DKIM failed because the messages were not signed with your DKIM key. DMARC failed because DKIM failed and there was no alignment.

Now you need to decide: is this a problem?

The Four Failure Categories in Every DMARC Report

Before you panic, know that most failure rows fall into one of four categories. Getting them right matters, because the action for each is different.

Category 1: Legitimate alignment failures

Your legitimate sending sources are passing SPF or DKIM authentication but failing alignment. Common causes: forwarding, mailing list footers that rewrite headers, shared hosting providers that send on your behalf without DKIM signing. These are not threats. These need operational fixes.

Category 2: Operational misconfigurations

Your own infrastructure is misconfigured. Wrong DKIM selector. SPF record that does not include a sending service you added last month. A CRM platform that started sending marketing email but was never added to SPF. These failures are your own systems failing to authenticate correctly. Fix the configuration.

Category 3: Internal spoofing

Someone inside your organization is sending email that claims to be from your domain but is not passing authentication. This could be a compromised account used by an attacker. It could be a bulk mailer configured wrong. Internal spoofing is a real security signal and should be investigated.

Category 4: External spoofing

Someone outside your organization is sending email that claims to be from your domain. This is the threat DMARC was built to address. If you see this at scale, you have an impersonation problem.

A Step-by-Step Triage Workflow

Work through each failure row in this order:

Step 1: Is the source IP known and authorized?

Start a list of your known sending sources: your mail relay, your CRM, your marketing platform, your IT helpdesk system, any SaaS that sends on your behalf. If the source IP is on that list, go to Step 2. If it is not on the list, go to Step 4.

Step 2: Is SPF, DKIM, or both failing?

SPF fail only: the server is in your SPF record but the message was not sent from an authorized path. Could be forwarding or a configuration change you missed.
DKIM fail only: the message routing changed and the DKIM signature is no longer valid. Check your DKIM selector configuration.
Both fail: the sending source is not following your authentication setup at all. Investigate immediately.

Step 3: Are failures concentrated in one source IP or spread across many?

A single source IP responsible for 90% of failures suggests a specific misconfiguration at one provider. Failures spread across hundreds of source IPs suggest a broader routing or forwarding issue.

Step 4: Classify and act

Misconfiguration: fix the SPF include, the DKIM selector, or the sending service setup
Forwarding: document it, consider ARC (Authenticated Received Chain) if you have not already
Unknown source: investigate the IP, check reputation databases, check whether the volume is significant
Spoofing: if external and high volume, consider moving to quarantine policy to force receivers to tag rather than accept

When to Move from p=none to Quarantine

The most common question practitioners ask: when can I safely move from p=none to quarantine or reject?

Here are the criteria that matter:

You have at least 30 days of aggregate report data
Fewer than 5% of sources show unknown failures
All known legitimate sources are passing or have documented benign failure reasons
Your IT team has capacity to investigate quarantine reports as they arrive

The last point is the most overlooked. Moving to quarantine does not make problems disappear. It moves them from passive monitoring to active alerts. If no one is watching those alerts, you have created work without reducing risk.

When to Ignore DMARC Failures

Some failures are noise. Do not spend time on these:

Forwarded mail from known contacts where the forwarder does not support ARC
Auto-forwarding rules that are documented and accepted within your organization
Mailing lists that use header mangling (if theysupport ARC, receivers handle this correctly)
Third-party services that pass authentication but not alignment, where you have decided the alignment gap is acceptable given the service dependency

The test is simple: if the failure has a known cause, a documented reason, and no security implication, it is a configured-ignored item, not a monitoring item.

How DMARCFlow Makes Triage Practical

If you are reading aggregate reports manually, you are doing the hardest version of this workflow. The moment you finish classifying a week's worth of failures, Monday arrives and you are starting from zero again. DMARCFlow solves this by collecting reports from all major receivers - Google, Microsoft, Fastmail, and others - into a single normalized view. You see failure volume by source, ranked by risk, with your previous triage decisions preserved.

The practical benefit is continuity: new failures from unknown sources surface immediately, benign sources you have already classified stay classified, and your p=none monitoring actually reduces work weekover week instead of resetting.

Triage Checklist

Use this list every time you review aggregate reports:

[ ] Pull the latest aggregate report from your DMARC hosting provider
[ ] Identify every unique source IP in the report
[ ] Match each source IP against your known sending infrastructure
[ ] For unknown sources: look up the IP in a reputation database
[ ] Classify each failure row as: misconfiguration, forwarding, internal spoofing, or external spoofing
[ ] Fix any misconfigurations found
[ ] Document known benign failures so they are not re-investigated next week
[ ] Escalate any high-volume unknown or external spoofing sources
[ ] Update your known-sources list after any infrastructure change

FAQ

Why does DMARC fail when SPF and DKIM both pass?

DMARC requires alignment, not just authentication. A message can pass SPF (the sending server is authorized) and pass DKIM (the message is signed) but still fail DMARC if the From domain does not align with the domain used in SPF or DKIM. This separation is intentional. It means a sender can be authorized but still fail DMARC if they are sending on behalf of your domain without your infrastructure.

What is the most common cause of DMARC failures that are not spoofing?

Forwarding. When a message is forwarded, the forwarder's server becomes the new sending infrastructure. That server is not in your SPF record and does not sign with your DKIM key. The forwarded message fails both checks, and DMARC fails. This is one of the most common failure patterns in p=none reports and is almost never a security problem.

How long should I stay at p=none before moving to quarantine?

At minimum 30 days. In practice, stay at p=none until you have reviewed at least four weeks of aggregate reports, classified every significant failure source, and fixed your own misconfigurations. If you still see unknown sources appearing after four weeks of active triage, extend the monitoring period before moving to enforcement.