Why Your DMARC Aggregate Report Shows Thousands of Failures But Only a Handful of Messages Were Actually Rejected

You opened your DMARC aggregate report. It says 12,650 failures in the last 24 hours. You sent 20 emails. You panic.

Then you check your mail logs. Everything delivered normally. No bounces, no complaints, no evidence of any problem. What is going on?

The numbers in a DMARC aggregate report are not lying. But they are measuring something most people do not expect. This is also where a DMARC monitoring tool like DMARCFlow earns its keep: parsing those numbers into a breakdown that immediately shows you which source IPs are responsible, whether those IPs belong to forwarding services or something that needs attention, and whether the failures actually affected your mail delivery.

What DMARC Aggregate Reports Actually Count

A DMARC aggregate report counts the number of times a receiving mail server processed a message that failed DMARC validation. It does not count individual messages sent.

One email, forwarded through a mailing list to 500 recipients, generates 500 separate report entries if DMARC alignment fails at each hop. One email sent to a distribution list that fans out internally can generate dozens of individual report rows from a single user action.

The formula looks like this:

One original message multiplied by every receiving MTA that applies DMARC policy equals your failure count.

If you send a newsletter to a mailing list that has 3,000 subscribers, and that list server forwards it onward to all of them, your DMARC report may show 3,000 failures even though your original message went out perfectly and the mailing list server simply could not pass DMARC alignment on your behalf.

This is why the "12650 failed, 179 went through" pattern in the Reddit thread above is so common. The 179 are the messages that passed both authentication and alignment checks at the destination server. The 12650 are individual receive events where a server somewhere in the chain received a message that failed DMARC, logged it, and moved on.

Why Forwarded Mail Is the Main Cause of High Failure Counts with Low Impact

Auto-forwarding is the most common source of inflated DMARC failure numbers that do not represent actual mail delivery problems.

When you set up an auto-forwarder in Gmail, Outlook, or any other email service to pipe messages to another account, your original sending domain DMARC alignment breaks at the first hop. The forwarding server is not authorized to send on behalf of your domain. It is relaying the message, not sending it. DMARC sees the mismatch and logs a failure.

This is by design. DMARC was built to stop forged mail, not to accommodate forwarding chains. But the result is that a single forwarded message can generate failure entries from multiple servers in the chain, making it look like a coordinated attack when it is just a vacation auto-responder.

Mailing list servers are the other major culprit. Services like Mailman, Google Groups, and internal mailing list software typically rewrite the sender address and forward from their own servers. They cannot pass DMARC alignment for the original domain because they are not that domain. Each list member mail server that receives a message from the list generates its own DMARC failure entry, even though the original sender is legitimate.

Auto-responders and delivery status notifications compound this. When your mail reaches a server that generates a read receipt or an out-of-office bounce, those auto-generated messages often fail DMARC because they come from the recipient domain, not yours. Another failure entry, another non-problem.

How to Read Your Aggregate Report to Tell Spoofing from Forwarding

The fields that matter most in a DMARC aggregate report are:

• source_ip: the IP address of the server that sent the message to the receiving MTA. This tells you who was actually sending the mail, not who it was from.
• dkim_align and spf_align: whether the message passed DKIM and SPF alignment. A "fail" here means the message failed the alignment check, not necessarily that it was forged.
• disposition: what the receiving MTA did with the message. "none" means the message was accepted despite the DMARC failure. "quarantine" and "reject" mean the MTA took action.

The critical distinction is this: a high volume of failures from a single source_ip that is a known forwarding service, mailing list server, or auto-responder is a forwarding problem, not a spoofing problem. A high volume of failures from hundreds of different source IPs that have no relationship to your normal mail flow is a stronger signal of actual domain spoofing.

Look at the alignment results first. If dkim_align and spf_align both show "fail," the receiving MTA could not verify that the message came from an authorized sender. But that does not mean it was malicious. It means it could not verify the alignment. The disposition field tells you whether anything actually happened to the message.

Look for patterns in the source IPs. If 90 percent of your failures come from a handful of known hosting providers or email service platforms, you are looking at forwarding-related failures, not an attack.

Without a tool, you are manually reviewing XML or JSON entries, cross-referencing source IPs against your known sending infrastructure, and building this picture yourself every time a report comes in. DMARCFlow automates this breakdown: it parses the source_ip, alignment result, and disposition fields from every report entry and surfaces a summary that immediately shows you the concentration of failures, which IPs are responsible, and whether the pattern looks like forwarding activity or something that needs immediate attention.

When High Failure Counts Actually Mean a Real Problem

Some patterns in your DMARC aggregate report do indicate real trouble.

If you see failures from source IPs that have no connection to your normal email infrastructure and the sending domains in the failures do not match any legitimate mailing lists or forwarding services you use, that is worth investigating. It means someone is trying to send mail that appears to come from your domain, and the receiving servers are correctly catching it.

The volume matters less than the pattern. A spike in failures from a single forwarding service during a busy email period is normal. A gradual increase in failures from hundreds of unique IPs that do not correlate with any known forwarding behavior is a signal that someone is probing your domain.

If your domain is large enough to be a worthwhile target, you will see this eventually. Phishers prefer to spoof domains that their targets trust, and if your domain has any brand recognition, it is a candidate.

Use the source IP analysis in your aggregate report to build a picture of your normal mail flow. Anything that falls outside that picture is worth a closer look.

An Interpretation Checklist for Your Next DMARC Review

Before you assume your domain is under attack, work through these five questions:

1. What percentage of my failures come from a single source IP or a small number of known forwarding services? If most failures trace back to one or two IPs, it is probably a forwarding or mailing list issue.
2. What does the disposition field say? If most entries show disposition "none," the receiving servers accepted the mail despite the DMARC failure. Nothing was rejected.
3. Are the aligned DKIM and SPF results both failing, or is one passing? A message that passes either SPF alignment or DKIM alignment has some legitimate connection to your domain, even if the full DMARC check failed.
4. Do the source IPs correspond to any legitimate services I use? Check your known sending platforms, marketing email providers, internal mail servers, and any forwarding rules you have configured.
5. Is there a temporal pattern? Failures that spike during business hours and drop on weekends likely correlate with internal mail server activity or legitimate auto-forwarding rules that fire during working hours.

What the "179 went through" number actually means: those are messages that passed both DMARC authentication and alignment checks at the receiving server. The MTA verified the message came from an authorized sender and that the domain in the From header matched. Those 179 messages were accepted and delivered normally. The 12,650 failures are the other receive events, almost all of which came from forwarding chains or mailing list servers that broke alignment but did not prevent the legitimate mail from arriving.

FAQ

Does a high DMARC failure count mean my domain is being spoofed?

Not necessarily. High DMARC failure counts usually mean your domain is being used in forwarding chains or by mailing list servers that cannot pass DMARC alignment. Actual spoofing shows up as failures from source IPs that have no relationship to your normal email sending infrastructure.

I sent 10 emails but my report shows 500 failures. Where do these numbers come from?

DMARC aggregate reports count the number of receive events where a message failed DMARC, not the number of messages you sent. If any of your emails were forwarded through a mailing list, auto-forwarder, or distribution group, each individual delivery attempt generates its own report entry. One forwarded email can generate hundreds of failure entries.

Are forwarded emails actually being rejected by the destination server?

Usually not. When a message fails DMARC, the receiving server applies the policy specified in your DMARC record. If your policy is p=none, the server accepts the mail anyway and just logs the failure. The message still gets delivered. High failure counts with p=none are almost always informational, not a sign of mail loss.

How do mailing list servers affect my DMARC aggregate report?

Mailing list servers rewrite the sender address and forward from their own infrastructure. This breaks DMARC alignment because the mailing list server is not authorized to send on behalf of your domain. Every recipient server that receives a message from the mailing list generates its own DMARC failure entry, even though the original message was legitimate. A mailing list with 2,000 members can turn one sent message into 2,000 failure entries in your aggregate report.

Should I switch to p=reject if I see high DMARC failure counts in my reports?

Only after you have investigated the cause. If the failures come from forwarding services or mailing lists, switching to p=reject will break legitimate mail flow. If your investigation shows no forwarding or mailing list sources for the failures and they instead come from unrelated source IPs with no legitimate connection to your domain, then a p=reject policy is the right move to stop spoofing.

What is the difference between SPF alignment and DKIM alignment in a DMARC report?

SPF alignment checks whether the domain in the RFC5321.MailFrom address (the return path) matches the domain in the RFC5322.From header. DKIM alignment checks whether the domain in the DKIM signature matches the domain in the RFC5322.From header. A message must pass at least one of these alignment checks to satisfy DMARC. If both fail, the message fails DMARC entirely.

How can I tell from my aggregate report whether forwarding is the cause of my failures?

Look for a concentration of failures from a small number of source IPs, especially IPs belonging to known email service providers, forwarding services, or mailing list platforms. Check whether those IPs correspond to any services you use that forward mail on behalf of your users. If the source IPs all trace back to known forwarding infrastructure and the aligned results are both failing, forwarding is almost certainly the cause.