What to Do When DMARC Aggregate Reports Show Failures

The report is in front of you. Now what.

You set up DMARC monitoring. You are receiving XML files or a digest. You open it and see rows of IP addresses, SPF results, DKIM results, and something called DMARC alignment. Some rows are green. Some are red. Some say pass in one column and fail in another.

You do not know if you are looking at a problem or noise.

This is the most common reaction to DMARC aggregate reports. The data is there. The meaning is not obvious. This guide fixes that.

By the end you will have a clear decision tree for any DMARC failure row. You will know which failures to ignore, which to investigate, and which to act on immediately. If the manual review feels like too much overhead, that is where DMARCFlow fits: it handles the grouping and alerting so you apply judgment to the failures that matter instead of building the list manually.

---

What a DMARC aggregate report actually tells you

A DMARC aggregate report is a summary of email delivery attempts from all receivers that enforce your DMARC policy. It arrives via your /rua endpoint and covers a reporting period - typically 24 hours.

The report tells you, for each sending source:

The IP address that sent the mail
Whether SPF authentication passed or failed for that IP
Whether DKIM authentication passed or failed for that IP
Whether the From domain aligned with the sending domain (DMARC alignment)
The result: pass or fail
The sending domain and your aligned domain

This matters because DMARC authentication requires both individual protocol passes (SPF, DKIM) AND domain alignment. An email can pass SPF but still fail DMARC if the From domain does not align with the sending domain.

---

How to read the rows and columns

The columns in a DMARC aggregate report map to specific concepts.

source_type tells you what kind of server sent the mail. Most commonly this is "ip" for a direct mail server.

source_ip is the IP address of the server that delivered the message to the receiver. This is the column you use to identify who is sending as your domain.

count is how many messages from that IP arrived during the reporting period.

SPF_result and DKIM_result tell you whether individual authentication checks passed or failed.

alignment (either relaxed or strict) tells you whether the From domain matched the sending domain.

disposition tells you what the receiver did with the message: none (delivered), quarantine, or reject.

The key column is the combination of results. An email that passes SPF and DKIM individually can still fail DMARC if the From domain and the sending domain are not aligned. This is the most common source of confusion in DMARC reports.

---

The three failure patterns you will see most often

Pattern 1: Your own IP is failing SPF or DKIM

This is a real problem. If your mail server is sending as your domain and SPF or DKIM is failing, something is misconfigured.

Common causes:

Your mail server's public IP changed and the SPF record no longer includes it

Your DKIM selector is wrong or the private key was rotated without updating DNS

You are sending through a third-party mail provider and the DKIM key was not set up correctly for your domain

Action: Fix your SPF and DKIM configuration before worrying about anything else. If your own servers cannot authenticate, you cannot trust the report to distinguish real spoofing from your own mistakes.

Pattern 2: Failures from IPs you do not recognize

This could be spoofing attempts or forwarding artifacts. The difference matters.

If the From domain in the failure row matches your domain exactly and the IP is not yours, that is a spoofing attempt. Someone is sending email that claims to be from your domain but is not authorized by your SPF or DKIM records.

If the From domain is different from your aligned domain (for example, the From says user@example.com but the aligned domain is example.com), the failure may be a forwarding issue rather than spoofing. The message authenticated correctly for the original sender but failed alignment when forwarded.

Action: For spoofing attempts, check your DMARC policy. If you are at p=none, now is the time to move to p=quarantine and eventually p=reject. For forwarding failures, you may be able to ignore them or work with the forwarder to fix their DKIM signing.

Pattern 3: High-volume failures from a single IP you do not recognize

This is the pattern that deserves the fastest response. A sudden spike in failures from an unknown IP could mean someone is actively spoofing your domain at scale.

Action: If the volume is high and the IP is not yours, treat this as a potential spoofing attack. Your DMARC policy at p=reject will stop these messages from reaching recipients. If you are at p=none, you have no protection regardless of what the report shows.

---

A decision tree for every DMARC failure row

Use this logic for each unique source IP in your report:

1. Is the source IP yours? Check your SPF record and your known mail server IPs.
- Yes: go to step 2
- No: go to step 3

2. Your own IP is failing. Is the failure consistent across multiple reporting periods?
- Yes: your SPF or DKIM is misconfigured. Fix your authentication first.
- No: single-period anomaly. Monitor for recurrence.

3. The source IP is not yours. Is the From domain in the failure row your exact domain?
- Yes: this is likely a spoofing attempt. Evaluate your DMARC policy and consider moving to p=quarantine or p=reject.
- No: the From domain differs from your domain. This is likely forwarding-related. Check if you have known forwarding relationships.

4. Is the volume unusually high for this source?
- Yes: prioritize investigation. This could be an active spoofing campaign.
- No: log and monitor. Continue tracking over subsequent reporting periods.

The challenge is that applying this decision tree across hundreds of rows in a raw XML report is tedious. A monitoring tool like DMARCFlow groups the IPs for you and flags the ones that are new or high-volume, so you spend time on the decision tree instead of on data entry.

---

What to do about each failure type

For your own misconfigured mail streams

Fix SPF first. Your SPF record must include every IP address that sends mail for your domain. Any IP that is not in the record will cause SPF failures.

Then fix DKIM. Make sure your DKIM selector is correctly published in DNS and that the private key on your mail server matches. If you recently rotated keys, verify the new public key is in DNS before the old key expires.

If you use a third-party mail provider (Google Workspace, Microsoft 365, Mailchimp, SendGrid), verify that DKIM is configured for your domain specifically. Many providers set up DKIM for their own domains by default. You need DKIM signing for your actual From domain.

For forwarding-related failures

Forwarded mail often fails DMARC because the forwarding server sends the message on behalf of the original From domain but is not authorized by SPF (its IP is not in your SPF record) and cannot DKIM-sign with your domain.

This is a known problem with no perfect solution. Some options:

Encourage correspondents to use DKIM signing on their end

If you control the forwarder, configure it to add a Sender header or use ARC

If the forwarding failures are low volume and from known sources, they are usually safe to ignore

For spoofing attempts

If your DMARC policy is p=none, you have visibility but no protection. The report shows you the spoofing attempts but does nothing to stop them.

Moving to p=quarantine reduces the risk: legitimate receivers will route suspicious mail to spam rather than the inbox. Moving to p=reject stops most spoofed mail from being delivered at all, though you may see some backscatter as a side effect.

Before moving to p=reject, verify that all legitimate sending sources are authenticated. A p=reject policy on a misconfigured domain will cause legitimate mail to bounce.

---

How monitoring tools make this easier

Reading raw DMARC reports manually is time-consuming and error-prone. A single report can contain hundreds of source IPs. Manually checking each one against your SPF record and investigating the ones that are not yours does not scale.

DMARC monitoring tools parse the XML reports and present them as a dashboard. They group failures by source, flag new IPs, track trends over time, and alert you when something unusual appears.

DMARCFlow handles the aggregation and alerting problem specifically. Instead of opening XML files and scrolling through rows of IPs, you receive alerts when new failure sources appear and you see at a glance which failures are new, which are persistent, and which match known forwarding patterns. The grouping and flagging is automatic; your judgment handles the decision tree.

This matters because one of the biggest failure modes in DMARC deployments is simply not looking at the reports. Organizations set up p=none, assume everything is fine, and miss real spoofing problems because the reports are too noisy or too time-consuming to review manually. DMARCFlow removes the noise so the signal is visible.

---

Common mistakes to avoid

Ignoring p=none failures

Many admins interpret p=none as "nothing to see here." This is wrong. p=none means you are in monitoring mode, not that your domain is not being attacked. If your reports show consistent spoofing attempts at p=none, you have the same exposure as someone with no DMARC at all - you just have more data about it.

Treating forwarding failures as attacks

When your legitimate forwarded mail fails DMARC, it looks alarming in the report. It is not an attack. It is a side effect of how DMARC works. Forwarding rewrites the envelope and the From header in ways that break alignment. If you see failures from IPs associated with known forwarding services (Gmail, Yahoo, Outlook.com), those are almost always forwarding artifacts, not spoofing.

Overreacting to single-period spikes

One bad reporting period does not mean you are under attack. Check whether the spike corresponds to a known mail migration, a new sending source you forgot to add to SPF, or a campaign sent through a new provider. If the spike disappears the next day and does not recur, it was probably a configuration issue that corrected itself.

Moving to p=reject without auditing your sending sources first

p=reject is the right long-term destination for most domains. But deploying it without knowing what IPs send mail for your domain will cause legitimate mail to bounce. Use p=none for at least 2-4 reporting periods. Use p=quarantine for another 2-4 periods. Only move to p=reject when you have reviewed the reports and confirmed that every legitimate sending source is authenticated.

---

FAQ

Why does my DMARC report show failures even though I did not send any suspicious email?

The most common reason is forwarding. When a message is forwarded, the forwarding server delivers it to the final recipient but the From header still shows the original sender. From the receiver's perspective, an email arrived from a server that is not authorized to send for that From domain - even though the message is legitimate. This shows up as a DMARC failure in your report.

Should I be worried if DMARC reports show SPF or DKIM failures for my own mail server IP?

Yes. If your own mail server IP is failing SPF or DKIM, something is misconfigured. Check your SPF record to make sure your server's IP is included. Check your DKIM selector and verify the DNS record points to the correct public key. Fix your own authentication before worrying about external failures.

How often do DMARC aggregate reports arrive?

Most major email receivers (Google, Microsoft, Yahoo, FastMail) send DMARC aggregate reports daily. Some send more frequently for high-volume domains. The /rua endpoint you configure is where all reporters send their data. If you are not receiving reports, check that your /rua endpoint is accessible and that DNS is resolving correctly.

What is the difference between a DMARC failure and a DMARC misalignment?

A DMARC failure means the message failed SPF, DKIM, or both. A DMARC misalignment means the message passed SPF or DKIM but the From domain does not align with the domain used for authentication. A message can pass SPF and fail DMARC if the From header domain is different from the domain that SPF authenticated.

My DMARC policy is p=reject but I am still receiving aggregate reports showing failures. Is something wrong?

If you are at p=reject and still seeing failures, it means some receivers are not enforcing your policy or are quarantining instead of rejecting. Not all receivers enforce p=reject in the same way. Some may still send you failure reports for mail they quarantined rather than rejected. This is normal. As long as the disposition column shows reject for your own domain, your policy is working.

How do I know if the failures in my report are real spoofing or just forwarding?

Check the source IP first. If it is not yours, check the From domain in the failure row. If the From domain matches your domain exactly, it is likely a spoofing attempt. If the From domain is different from your domain, it is probably forwarding. You can also check the volume: spoofing campaigns tend to have high volumes from a single IP, while forwarding failures are usually spread across multiple IPs with lower volumes each.

---

What to do next

Start by downloading your last 30 days of DMARC reports. Even if you have been ignoring them, the data is there. Review each unique source IP and apply the decision tree above.

If you find that your own IPs are failing, fix SPF and DKIM first. If you find spoofing attempts from IPs you do not recognize, consider moving your DMARC policy to p=quarantine. If you are already at p=quarantine and the spoofing continues, move to p=reject.

If the manual review process sounds like more work than you have time for, DMARCFlow automates the grouping, trending, and alerting so you get to the decision faster. That is the practical difference between having DMARC data and using it.