What to Do with DMARC Monitoring Failures: A Practical Decision Guide

You set up DMARC with a policy of p=none, which means monitoring only. You receive your first aggregate report and find failures. Some look like spoofing. Others look like legitimate email you did not realize was being sent from your domain. You are not sure what to do with either type.

This is the most common point email admins get stuck with DMARC. The standard advice is "set it and forget it at p=none," but nobody explains the follow-up. This guide covers what to do with the failures you find.

The challenge is that decoding aggregate reports manually does not scale. A domain with moderate email volume can receive thousands of RUA records per day. Tools like DMARCFlow exist specifically to classify these failures automatically, so you act on signal instead of drowning in XML. But before you delegate the work, you need to understand what the failures actually mean.

What an Aggregate Report Actually Shows

A DMARC aggregate report arrives as an XML file at your configured RUA endpoint. It summarizes authentication results over a reporting period, typically daily. Each record in the report represents one sending source.

The fields you need to understand first:

• Source IP: the mail server IP that sent the message
• SPF result: whether the source IP passed SPF checks
• DKIM result: whether the message signature verified
• Alignment: whether the From domain aligns with SPF and DKIM domains
• Count: how many messages matched this combination

A DMARC pass requires both authentication (SPF or DKIM) and alignment. A failure in either axis causes the overall DMARC result to fail. The failure alone does not tell you whether the source is legitimate.

The Four Types of DMARC Failures You Will See

When you look at aggregate report failures in practice, most fall into four categories.

1. Legitimate Misconfigured Sender

A service or vendor is sending email on your behalf but has not been added to your SPF record. The From domain is yours, alignment is correct, but SPF fails because the sending IP is not authorized.

This is the most common failure type for organizations that use third-party email services. The fix is usually straightforward: add the service's SPF include to your DNS record.

2. Forwarding Chain Artifact

A recipient configured email forwarding on their end. The forwarded message originated from a legitimate source but is now arriving through a forwarding server that is not in your SPF record. Alignment fails because the forwarding server's IP does not match your domain.

These failures are usually identifiable by their pattern: low volume, consistent source IPs, and a mix of SPF pass and alignment fail. They are annoying but not malicious.

3. Forwarded Mail with Broken Authentication

Some forwarding services re-sign messages with their own DKIM key. Others do not. When re-signing does not happen, the forwarded message arrives with your From domain but authentication done by the forwarder, not by you. DMARC alignment fails.

Many mailing list packages do not preserve original DKIM signatures and instead apply their own, which often breaks alignment for the original sender's domain. The result looks like spoofing but is a forwarding infrastructure issue.

4. Actual Spoofing Attempt

A malicious actor is sending email with your From domain from an IP address that has no relationship to your infrastructure. SPF fails, DKIM fails, alignment fails. The source IP is unknown, often located in a different country, and the volume pattern is typically bursty.

These are the failures you act on, not ignore. The question is what action to take.

How to Classify a Failure in Five Questions

Before deciding a failure is spoofing, run it through these five questions.

1. Is the source IP in my SPF record?

If yes, the sender is authorized. The failure is likely a misconfiguration or forwarding artifact. If no, proceed to question 2.

2. Is the source IP associated with an ESP I use?

Some ESPs use IPs that are not immediately obvious. Check your ESP's documentation for the full list of sending IPs. If it matches, add the appropriate include to SPF.

3. Does the sending domain align with my domain?

If the From domain is yours but alignment failed, this is often forwarding or a subdomain issue. If the From domain is not yours, this is cross-domain spoofing and is almost always malicious.

4. Is the failure volume consistent with one forwarded message or a campaign?

One to five messages from a source over a day is typically forwarding. Hundreds or thousands of messages from a new source over minutes is typically spoofing.

5. Is the source IP known good or known bad reputation?

Tools like abuseat.org, Spamhaus, and SORBs can tell you whether a sending IP has a negative reputation. An IP with no reputation at all is neutral. An IP on a blocklist with your domain in its From header is worth investigating.

What to Do with Each Failure Type

Legitimate misconfigured sender: Add the service's SPF include to your DNS record. If the service supports DKIM, publish the DKIM key as well. Then wait for the next report cycle and confirm the failures stop.

Forwarding chain artifact: You have limited options. You cannot control how forwarding services handle authentication. If forwarding is business-critical, consider whether a different delivery path is available, such as a direct delivery option instead of forwarding.

Forwarded mail with broken authentication: If the forwarding is a vendor's internal process, ask them whether they can re-sign messages. If it is a mailing list, consider whether ARC (Authenticated Received Chain) support is available, which preserves authentication results through intermediaries.

Actual spoofing attempt: Document the source IP, ASN, and sending pattern. If the spoofing is coming from a specific ISP, contact their abuse team. If your domain is frequently spoofed, move to p=reject as soon as your legitimate sending sources are fully documented in SPF and DKIM.

When to Move from p=none to p=reject

p=none tells receiving mail servers to take no action on failing messages. It is strictly a monitoring mode. It does not protect your domain.

The move to p=reject is safe when you are confident that every legitimate sending source for your domain is covered by SPF, DKIM, or both. The signs that you are ready:

• Your aggregate reports show zero unexpected failures over a 30-day period
• Every failure you see has a documented and understood root cause
• Your ESPs and internal mail systems are fully authenticated
• You have a process for adding new sending sources before they appear in your reports as failures

p=none has done its job when you no longer need it. If you have been at p=none for more than 90 days and you are still seeing new unexplained failures, something in your infrastructure has changed without your knowledge.

How DMARCFlow Fits Into This Process

DMARCFlow processes aggregate reports and categorizes failures automatically, so you receive structured alerts organized by type instead of an XML file to decode.

When DMARCFlow processes your RUA data, it classifies each failure and generates alerts that map directly to the four categories above:

• spoof_detected: a source outside your infrastructure is sending with your From domain
• esp_misconfigured: a legitimate ESP is sending but authentication is not passing
• policy_ready_upgrade: your aggregate data suggests p=reject is safe to enable
• lookalike_domain_found: a domain that impersonates yours has been identified

These alerts can be routed to Slack, Jira, Microsoft Teams, or any webhook endpoint. The classification is done before you see the data, so your first question when an alert arrives is not "what does this mean?" but "what do I do about it?"

Manual review of aggregate reports works when you have one domain and low email volume. For anything more complex, the monitoring step only has value if someone is actually looking at the results and making decisions.

The Decision Framework

When you see a DMARC failure in your aggregate report, run this sequence:

• Is the source IP in my SPF record? If no, it is either spoofing or a service you forgot to authorize.
• Is the source aligned with my domain? If no and the From domain is yours, it is almost always forwarding or a mailing list.
• Is the volume consistent with one person's email or a bulk campaign? Bulk patterns are spoofing until proven otherwise.
• Do I have a tool that classifies this automatically, or am I decoding XML manually? If the latter, consider whether your monitoring process is giving you enough signal to act.

Monitoring without a response plan is just collecting data. The value of p=none is not the report itself. It is what you do with the information inside it.

FAQ

How often do aggregate reports arrive?

Most receivers send aggregate reports daily. Some send them more frequently for high-volume domains. The timing is set by the receiver, not by you.

Can I get forensic reports instead of aggregate reports?

Yes, by configuring an RUF endpoint in your DMARC record. Forensic reports contain individual message details instead of summaries. They are more sensitive and require a secure endpoint. Most organizations start with aggregate only.

What is the difference between p=none and p=quarantine?

p=none takes no action. p=quarantine tells receivers to treat failing messages as suspicious, usually by routing them to spam. p=reject treats failing messages as invalid and refuses delivery.

I see failures from my own IP addresses. What does that mean?

Your own IP addresses might not be in your SPF record, or your mail server might be sending through a different IP than you documented. Check your SPF record against the actual sending IPs in your server logs.

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

At minimum 30 days with no unexpected failures. Many organizations stay at p=none for 60 to 90 days to capture a full picture of their sending patterns, including seasonal or campaign-based sending.

Does DMARCFlow work with all ESPs?

DMARCFlow processes standard DMARC aggregate and forensic reports regardless of which ESP you use. If your ESP sends DMARC-compliant reports to your RUA endpoint, DMARCFlow can process them.