DMARC Aggregate Report Failures: Triage Framework

You set up DMARC monitoring. You are getting aggregate reports. The reports show failures. Now what?

Most DMARC guides focus on deployment. Far fewer address the harder question: how do you interpret what the reports are telling you, and which failures actually need action?

This guide gives you a repeatable framework for triaging DMARC aggregate report failures. The framework itself is what DMARCFlow automates - but understanding it means you can evaluate any DMARC monitoring tool against what it actually surfaces.

What DMARC aggregate reports actually tell you

A DMARC aggregate report is a periodic summary from receivers. It tells you which IPs are sending email claiming to be from your domain, whether they passed SPF and DKIM, and whether those authentication results aligned with your DMARC policy.

Each report entry covers a set of messages from one sending source over a 24-hour window. The key fields:

Source IP: which server sent the mail
SPF result: pass or fail
DKIM result: pass or fail
DMARC result: pass, fail, or none
Message count: how many messages this entry represents

The "failures" in reports are entries where the DMARC result is not "pass". Not all of those failures are actual problems.

The three failure categories

Most DMARC aggregate report failures fall into three buckets. Knowing which bucket a failure falls in determines what you do next.

Category 1: Forwarding breakage

This is the most common source of confusing failures. When someone forwards your email to another recipient, the forwarded copy often loses DKIM signatures and may break SPF alignment. The result: your DMARC check fails, even though the original message was legitimate.

Forwarding failures typically show up as:

Low volume relative to your normal sending

DKIM failing while SPF passes (or the reverse)

Recipient domains that differ from your normal patterns

Forwarding breakage is not a security problem. It is an artifact of how email forwarding works. The fix depends on whether the forwarding is intentional (your users forwarding work email to personal accounts) or automated (mailing lists, aliases, catch-all rules).

Category 2: SPF or DKIM misconfiguration

This is a real configuration error. A mail server you control or a third-party service you use is sending mail that fails SPF or DKIM.

Signs you are looking at a misconfiguration rather than forwarding:

The failing source IP belongs to a service you send mail through

The failure rate is consistent across days, not sporadic

The failures originate from your own infrastructure, not external forwarders

Common causes include:

Sending servers added or changed since your SPF record was last updated

Third-party services (CRMs, marketing tools, support platforms) that send on your behalf but are not in your SPF record

DKIM keys rotated without updating DNS

Subdomains that do not have their own DKIM records

Category 3: Spoofing attempts

This is the signal you are actually looking for. When a third party tries to send email claiming to be from your domain and gets caught by DMARC, it shows up as a failure.

Unlike forwarding and misconfiguration failures, spoofing attempts tend to:

Come from IP ranges you do not control and have no relationship with

Show up with irregular volume patterns

Often have DKIM failing when you have DKIM deployed (because the spoofer does not have your private key)

Some spoofing is noisy and obvious. Some is low-volume and targeted. The value of DMARC is not just catching the obvious spoofs - it is giving you visibility into whether anyone is even trying.

How to tell the categories apart in practice

The most useful single diagnostic: check whether the failing source IP is one you recognize.

If the IP belongs to a service you send mail through, it is either a misconfiguration (your records need updating) or expected forwarding behavior. If the IP is completely unfamiliar and not associated with any of your vendors or infrastructure, it is worth investigating further.

DMARCFlow automates this first-level classification by cross-referencing source IPs against known sending infrastructure and flagging unfamiliar IPs automatically. Rather than manually scanning each entry in a raw XML report, you see the classification already applied.

What to do for each failure type

For forwarding breakage

If the forwarding is intentional and important:

Evaluate whether the forwarding is worth the DMARC compliance cost

Consider whether a different communication workflow would reduce the dependency on forwarding

Some forwarding can be mitigated with SRS (Sender Rewriting Scheme), but SRS adds complexity and its own failure modes

If the forwarding is from a mailing list or automated system:

The mailing list operator needs to implement ARC (Authenticated Received Chain), which preserves authentication results through the forwarding chain

Many modern mailing lists support ARC; those that do not are increasingly the exception

If the forwarding is from an automated system you control:

Audit whether the forwarding is necessary

Look for SRS implementation options for your mail transfer agent

For SPF/DKIM misconfiguration

1. Identify the source: which IP or range is generating the failures
2. Determine whether it is infrastructure you control or a third-party service
3. For your own infrastructure: update your SPF record or fix the DKIM configuration
4. For third-party services: add them to your SPF record or set up DKIM signing for their use of your domain

The most common misconfiguration pattern: a service starts sending from a new IP range that is not in your SPF record. This is common with cloud email providers that add capacity dynamically. The fix is usually to use an include mechanism that covers all IPs the provider might use, not individual IP addresses.

For spoofing attempts

Low-volume spoofing that gets rejected is working as intended. Make sure the failures are actually being rejected (p=quarantine or p=reject in your policy, not just p=none).

If spoofing volume is high, that is worth noting. Sustained high-volume spoofing attempts against your domain may indicate your domain is being used in a phishing campaign or is a high-value target. High-volume spoofing is worth monitoring over time to see whether it changes. A sudden spike is often the most useful early warning a DMARC report can give you.

Reading failure volume in proportion

A single failure entry in an aggregate report is not automatically a problem. The question is whether the failure makes sense relative to your sending patterns.

A useful rule of thumb: if your total daily message volume is known and the failure count is a small fraction (under 5%), the failures are usually forwarding artifacts or normal third-party service behavior. If the failures come from sources you do not recognize and the volume is growing, that warrants investigation.

The threshold is not fixed. A 1% failure rate on 10,000 daily messages is 100 failures - enough to investigate if they all come from the same unknown IP. A 10% failure rate on 50 daily messages from a small domain might be entirely explained by a single forwarding user.

This proportional view is one of the first things to check in any DMARC monitoring tool. DMARCFlow shows failure rate over time as a chart, making it easy to spot when something changes rather than reviewing individual report entries.

When to escalate from p=none to p=quarantine or p=reject

Moving from p=none (monitoring only) to p=quarantine or p=reject is one of the most consequential decisions in DMARC deployment. Aggregate reports are supposed to give you the confidence to make that call.

Useful signals that you are ready to escalate:

Your own legitimate sending is fully DMARC-compliant (no failures from sources you control)

Third-party services that cannot be made compliant are either removed or documented

You have reviewed reports long enough to be confident that the failure patterns are understood

Premature escalation (before your legitimate sending is compliant) will cause mail delivery failures for your real email. That is worse than staying at p=none.

A practical approach: stay at p=none until two conditions are met. First, at least 30 days of reports show no failures from your own infrastructure. Second, third-party services that cannot be made compliant are either addressed or accepted as known gaps.

How DMARCFlow handles this triage automatically

The triage framework described here - classify failures into categories, check IP ownership, read failure volume in proportion - is exactly what DMARCFlow applies to your aggregate reports automatically.

When you connect your domain to DMARCFlow, it pulls your aggregate reports and processes them through this classification logic. What you see is not raw XML entries but a structured view:

Failures grouped by type (forwarding breakage vs. misconfiguration vs. spoofing)
Failure rate tracked over time with alerts for sudden changes
New sending sources flagged for review before they become problems
Per-domain and aggregate views for multi-domain environments

For teams managing multiple domains or high-volume sending, this automation is what makes DMARC monitoring actually sustainable. Manual report review works for one domain on a good week. It does not scale.

The specific workflow in this article - categorize, check sources, read volume, decide action - is the logic DMARCFlow implements. Understanding the framework helps you interpret what the tool surfaces and know what questions to ask of any DMARC monitoring setup.

FAQ

What does it mean when DMARC aggregate reports show failures from my own mail server?

It usually means your SPF or DKIM configuration is not covering that sending path. Check whether your mail server is using an IP range that is in your SPF record, and whether your DKIM signing is active and using the correct selector.

How do I tell if DMARC failures are from forwarding or a real configuration problem?

Forwarding failures tend to be sporadic (not every message from that source fails) and involve DKIM failing while SPF passes or vice versa. Configuration errors tend to be consistent (every message from that source fails) and affect both SPF and DKIM.

Should I be worried if my failure rate is below 1%?

Probably not, as long as the failures come from sources you recognize and understand. A consistently low failure rate from forwarding or known third-party services is normal. What matters more than the rate is whether the failures make sense.

Why do legitimate newsletter and mailing list failures show up in DMARC reports?

Mailing lists and newsletters often forward mail on behalf of subscribers, which can break SPF and DKIM alignment. The failures are real - the messages technically fail DMARC - but they are not spoofing. This is one of the most common sources of confusing report entries.

When should I move from p=none to p=quarantine based on aggregate report failures?

Move when you have confirmed that all of your legitimate sending sources pass DMARC consistently, and you have reviewed at least 30 days of reports. If you still see failures from your own infrastructure at the 30-day mark, fix those first.

Can I use DMARC reports to find configuration errors before they cause delivery problems?

Yes. An IP that is starting to fail DMARC for your legitimate mail will show up in reports before the failures become widespread enough to cause noticeable delivery problems. Regular report review catches configuration drift early.

Summary

DMARC aggregate reports tell you more than most admins realize. The challenge is not getting the reports - it is knowing what to do with the failures they contain.

The triage framework is straightforward:

Forwarding breakage is normal and expected in most environments

SPF/DKIM misconfigurations are real problems that need fixing

Spoofing attempts caught by DMARC are the policy working as intended

The decision to move from p=none to enforcement should be based on evidence from your reports, not a calendar date. Use the monitoring period to actually monitor.

Understanding this framework helps even if you use a tool - it means you know what the tool is doing when it classifies failures, and you can verify that the classification makes sense for your environment.

For teams managing this across multiple domains, the classification logic is also the main thing to verify when evaluating any DMARC monitoring tool. If the tool surfaces failures without classifying them, you are still doing the hard part manually.