What to Do with DMARC Monitoring Data: A Practical Guide for Email Admins

You have DMARC configured. Your domain is publishing a policy. You are getting reports.

And then the question arrives: what do you actually do with this data?

This is the gap most DMARC guides skip. They explain what DMARC is. They walk through DNS records. They do not tell you what to do when the report lands in your inbox and shows a block of failures you were not expecting.

This guide does that. It covers how to read a DMARC aggregate report, how to categorize the failures you see, and how to decide what needs action versus what is harmless.

The short version: parse the reports automatically, categorize the failures, and act on the ones that matter. That is exactly what DMARCFlow handles. The rest of this guide explains how the categorization works so you understand what the tool is doing and can verify it is doing the right thing.

Understanding DMARC Reports: Aggregate vs. Forensic

Before the decisions, the data types.

DMARC produces two kinds of reports:

Aggregate reports (rua) are XML files sent daily or weekly by receiving mail servers. They summarize authentication results across your domain without exposing individual email content. One aggregate report can contain thousands of rows showing which IPs sent mail, what authentication results they got, and how many messages passed or failed.

Forensic reports (ruf) are real-time failure notifications. They fire every time an individual email fails DMARC and are sent to an address you specify. They contain the full RFC 822 headers of the failed message.

Most administrators should rely on aggregate reports. Forensic reports generate high volume and can quickly become unusable noise. If you are not actively investigating a specific incident, aggregate reports give you the signal you need without the noise.

The reports land in your inbox as compressed XML attachments. Parsing them by hand is painful. DMARCFlow parses them automatically and presents the data as a dashboard.

The Four Most Common Reasons for DMARC Failures

When you look at an aggregate report and see failures, the most likely causes fall into four buckets.

1. Forwarding

When someone forwards your email to another provider, the forwarded copy often fails SPF because the forwarding server is now the sender, not your original mail server. DKIM may also break if the forwarding process modifies headers in a way that invalidates the signature. This is the single most common source of benign DMARC failures.

If you see consistent failure patterns from known forwarding destinations (Gmail, Outlook, Yahoo), forwarding is almost certainly the cause. These failures are not spoofing. They do not represent a threat to your domain.

2. Third-Party Senders and Marketing Tools

Marketing automation platforms, CRM systems, support tools, and any SaaS that sends email on your behalf can trigger DMARC failures if they send from your domain but authenticate in ways that do not align with your DMARC policy.

Examples:

A marketing platform that sends from newsletters@yourdomain.com but uses its own IPs for delivery
A legacy CRM that rewrites the From header on outbound emails
Shared sending infrastructure that cannot sign with your DKIM key

Before you worry about a spoofing attack, audit every service that sends email from your domain.

3. Internal Misconfiguration

Sometimes the failures are genuine problems you can fix. Common examples:

A mail server was added or migrated without updating the SPF record
DKIM signing was disabled during a software upgrade and not restored
A subdomain was set up to send email but was never added to your SPF record or DKIM selector

These show up as consistent, reproducible failures from your own infrastructure. They are detectable and fixable.

4. Spoofing and External Abuse

This is the failure pattern that actually matters for security. A third party is sending email that claims to be from your domain and is failing authentication. This is the scenario DMARC was designed to catch.

Indicators that a failure represents genuine spoofing rather than benign causes:

Failures from IP ranges you do not recognize and cannot attribute to any known service
High-volume failure bursts with no matching legitimate traffic
Failures from geographic regions where you have no business presence
No Forensic reports from your configured ruf address when the volume is large enough to expect them (some spoofing sources suppress delivery, meaning no forensic report fires)

Decision Framework: Is This Failure a Problem or Not?

Use this quick filter:

Check the source IP first. Does it belong to any service you use? Check your SPF record against the IP. If the IP is in your SPF list and aligned with your domain, the failure has a legitimate cause you need to investigate.

Check the failure volume and pattern. One-off failures from a single IP over a short window are usually forwarding. Sustained failures from an IP not in your SPF record are more likely abuse.

Check the From-header domain. If the failures show mismatches between the envelope sender and the visible From header, that points to forwarding or a third-party tool. If the From header is being spoofed by an external source, the sending IP will not be yours and the volume may spike suddenly.

Check whether legitimate mail is also failing. If your legitimate sends are landing in spam or failing DMARC alongside the suspicious failures, you have a configuration problem that needs fixing before you can safely move to p=quarantine or p=reject.

What to Do at Each DMARC Policy Level

Your DMARC policy level determines what actions you can take and what risks you face.

p=none: Read the Reports and Build a Baseline

At p=none, mail is not being blocked. This phase exists entirely to collect data and identify problems before enforcement.

Your job at this stage:

Parse every aggregate report and build a list of all sending sources
Identify every IP that is not in your SPF record but is sending legitimate mail from your domain (these are third-party services you need to authorize or align)
Confirm that the only unaligned sending activity is forwarding and known SaaS tools
Set a reminder to re-examine the data quarterly or after any infrastructure change

Most organizations should stay at p=none for at least 30 to 60 days before moving to enforcement. Rushing to p=quarantine before you understand your sending baseline is how legitimate mail gets blocked.

p=quarantine: Start Selective Enforcement

At p=quarantine, failing mail is sent to spam rather than rejected outright. This is a safer enforcement step that catches obvious spoofing without the blast radius of a full reject policy.

Your job at this stage:

Monitor aggregate reports weekly for any new failure sources
Watch for a spike in quarantine-tagged failures from legitimate forwarding that you may need to address with ARC
Move to p=reject only when the failure patterns are stable and attributable

p=reject: Full Enforcement

At p=reject, any mail that fails DMARC is blocked entirely. This is the goal state for most domains, but it requires confidence that you have identified all legitimate sending sources.

Your job at this stage:

Continue monitoring aggregate reports monthly
Set up alerts for sudden spikes in failure volume, which may indicate an infrastructure change or an active spoofing campaign against your domain
Reject policy means you need to catch legitimate failures fast, because they will now generate user complaints instead of quiet spam-folder placement

How DMARCFlow Automates DMARC Monitoring and Alerting

The reason most administrators stall at p=none is not ignorance. It is the cost of parsing XML reports manually. DMARCFlow removes that cost.

DMARCFlow connects to your rua address, pulls aggregate reports automatically, and presents the data as a dashboard rather than a compressed XML attachment. Every sending IP is matched against your SPF record and labeled as known, unknown, or forwarding. Failure sources are categorized by type, so you see forwarding noise separate from genuine spoofing without having to read the raw data.

For the administrator who said monitoring felt like watching something they could not act on: the tool does the parsing. You make the decisions.

DMARCFlow also handles alerting. You set thresholds for what failure volume warrants a notification. You get alerted about real problems, not every Gmail forwarder that triggers a benign failure. Mobile apps for iOS and Android let you check status and failure alerts from anywhere, without logging into a web dashboard.

Starting at 1 EUR per month, with EU data hosting and no minimum commitment.

FAQ

How often do I get DMARC aggregate reports?

Most receiving servers send aggregate reports daily. Some send weekly. The timing is set by the receiver, not by you.

Can I get DMARC reports in a human-readable format without a tool?

You can, but it requires opening and parsing XML files manually. For domains with any meaningful mail volume, this quickly becomes impractical. DMARCFlow handles this automatically.

My DMARC failures are all from Gmail. What does that mean?

Gmail is a common destination for forwarded mail. When your email is forwarded to a Gmail user, Gmail receives it from the forwarding server's IP, not yours. That server may not have DKIM signatures that align with your domain. This is almost always forwarding-related, not a spoofing problem.

I see failures from IP addresses I do not recognize. Is my domain being spoofed?

Possibly. Check whether the failures are high-volume and whether they correspond to any legitimate mail you are sending. If you are seeing failures from IPs outside your SPF record with no matching legitimate traffic, that points to spoofing. If you also see failures from your own known forwarding destinations, check the forwarding case first.

Should I move from p=none to p=quarantine or p=reject as fast as possible?

No. Move when you have a stable understanding of your sending baseline and have authorized all legitimate third-party senders. Rushing enforcement is how organizations accidentally block their own legitimate mail.

What is the difference between rua and ruf reports?

rua (Reporting URI for Aggregate) delivers summary XML reports on a schedule set by the receiver. ruf (Reporting URI for Forensic) delivers real-time individual failure notifications for each message that fails DMARC. Forensic reports can be noisy and are optional.

---

The data DMARC monitoring provides is only as useful as your ability to act on it. Understanding what the failures mean, categorizing them correctly, and knowing when to escalate are skills that take practice. DMARCFlow removes the parsing overhead so you can focus on the decisions that matter. Start monitoring at 1 EUR per month.