Why Your DMARC Report Shows Bulk Failures But Some Messages Still Pass Through

You set up DMARC. You are now looking at your first aggregate report. You see 12,650 failures. You also see 179 messages that passed. You did not send 179 messages to Google. So what is going on?

The first thing to understand is what DMARC aggregate reports actually contain. They do not show you every email a destination server received. They show you every source that was observed sending mail as your domain in the From header. That is a meaningful difference, and understanding it changes how you read the entire report.

What the source column actually tells you

Each row in your DMARC aggregate report represents a source IP that sent mail using your domain. The report tells you how many times that IP was observed, whether it passed SPF, whether it passed DKIM, whether it aligned with your domain, and what policy the receiving server applied.

When you see a cluster of thousands of failures from a single IP in Romania, that is almost certainly spoofing. Someone ran a mass email campaign impersonating your domain from one server. The failures are the good news: your DMARC policy is catching them.

When you see a smaller number of passes from an IP you do not recognize, the question to ask is not "how did these get through" but "who is this IP and did they have the right to send as my domain."

Why 179 messages passed to Google even though you did not send them

One common scenario that confuses people: you see messages that passed DMARC, going to Google IPs, that you did not send. The most likely explanation is Google Groups redistribution.

When someone sends an email to a Google Group, Groups redistributes that message to all group members. Groups preserves the original headers and body, including the original DKIM signature, as long as Groups does not modify the message. Since the DKIM signature is intact and the From domain matches your domain, the DKIM alignment check passes. The message shows as a DMARC pass.

This is not your mail getting through despite spoofing. It is Google Groups legitimately redistributing mail that was already authenticated. The sender is real. The volume reflects redistributions, not individual messages you composed.

This pattern is also exactly what DMARCFlow is built to surface automatically. Rather than manually scanning a report for Google IPs and trying to remember whether your team uses Groups, DMARCFlow labels the source, shows the pass/fail breakdown, and flags whether the pattern looks like redistribution or something you need to investigate.

What p=none actually means right now

If your current policy is p=none, those 12,650 failures were not blocked. They were counted and reported. The receiving servers processed them according to their own policies. Setting p=none is monitoring mode. You are collecting data, not yet enforcing.

This is why p=none is the right starting point. The failures tell you what is happening. They do not stop anything on their own.

The silent failure problem before moving to p=reject

One warning that appears repeatedly in DMARC discussions: moving from p=none to p=reject too quickly breaks legitimate mail without you knowing.

Here is what happens. Your company has legitimate services that send email as your domain: an invoicing platform, a CRM, a help desk system, a network printer with scan-to-email, a monitoring tool that sends alerts. Most of these do not use DKIM. Some do not use proper SPF. When you set p=reject, messages from these services get refused. Nobody gets a bounce notification in most cases. A customer simply does not receive an invoice, and you find out three weeks later when they call to ask where it is.

The 12,650 failures in your report are external spoofing. Those are the ones you want blocked. But the internal services you forgot about will also fail, and they will fail silently unless you have aggregate reports set up to catch them.

The practical way to avoid this: keep p=none long enough to see every source that sends as your domain. Any source that appears with failures needs to be resolved before you tighten the policy. DMARCFlow automates this monitoring and alerts you when a new source appears in your reports, so you catch the forgotten printer or the new ESP integration before it becomes a broken invoice.

The diagnostic checklist before moving to p=reject

Before you tighten your policy, work through this checklist using your DMARC aggregate report.

Step 1: Separate external spoofing from everything else

Look at the source IPs. Large clusters from foreign IPs with high failure counts and no passes are spoofing. Ignore them for policy decisions. They are working correctly.

Step 2: Identify your known legitimate senders

Your Google Workspace servers should appear in the report as high-volume pass sources. Your third-party email service provider should appear as well. Any ESP worth using will have documented the IPs they send from, and they should be in your SPF record.

Step 3: Find the sources you forgot about

Look for mid-volume sources with failures. These are often the forgotten legitimate services: printers, internal tools, legacy systems. If the IP belongs to your network range or a vendor you recognize, investigate before blocking it.

Step 4: Check alignment separately from authentication

A source can pass SPF and still fail DMARC if the aligned domain does not match your From domain. This happens with some marketing automation tools and legacy CRMs. It is a configuration issue, not spoofing.

Step 5: Set p=quarantine first

Move to quarantine before reject. Quarantine routes failing mail to spam folder instead of refusing it outright. If legitimate mail is being blocked, you will hear about it quickly. If it is spoofing, the spoofed recipients will not receive the mail, which is what you want.

How DMARCFlow handles this

Reading aggregate reports manually means downloading XML files, finding a parser, and then working through rows of source IPs trying to separate the signal from the noise. For organizations with a handful of senders, this is manageable. For organizations with multiple ESPs, internal tools, and remote workers, it becomes a real task.

DMARCFlow parses your aggregate reports automatically and categorizes sources by pass/fail and alignment status. It flags new IPs appearing in your reports, identifies which failures are likely spoofing versus legitimate misconfiguration, and tracks your legitimate senders over time. When the Romanian IP cluster appears in your report, DMARCFlow labels it as high-volume foreign failures with no passes, which is the spoofing pattern. When the Google Groups redistribution appears, it shows as passes to Google infrastructure, clearly labeled.

The diagnostic checklist above is what DMARCFlow automates. Instead of manually reviewing every source in every report, you get a categorized view of all your senders, with new or suspicious sources flagged for review.

FAQ

I see failures from IPs in countries where I do not do business. Is this spoofing?

Almost certainly. Legitimate email sources usually come from your country or your vendors' countries. Large failure clusters from foreign IPs, especially when concentrated on a single IP, are almost always spoofing attempts. Your DMARC policy is handling them correctly.

My DMARC policy is p=none. Are those failures being blocked?

No. p=none means failures are reported but not acted on. The receiving server applies its own policy. The failures you see in your aggregate report are informational. They tell you what would happen if you set a strict policy.

I moved to p=reject and now a customer says they never received an invoice. What happened?

Your aggregate report will show a failure for the source IP associated with that sending platform. Check whether the source is a known ESP or internal system. If it is, the sending system needs either DKIM signing or its IP added to your SPF record. Move back to p=quarantine while you resolve it.

How do I find all the services that send as my domain?

Start with your aggregate report. Any legitimate sending source will appear as either a pass or a failure, depending on how it is configured. Cross-reference the IPs with your known infrastructure. For organizations using Google Workspace, all outbound mail passes through Google servers. Anything appearing from another IP needs investigation.

Should I block the Romanian IP in my firewall?

You can, but it will not help much. Spoofers cycle through IPs quickly. The better approach is ensuring your DMARC policy is set to quarantine or reject. That stops spoofing at the destination server, regardless of which IP they use.

Does DMARCFlow show me new sources automatically?

Yes. DMARCFlow monitors each aggregate report and alerts you when a source IP appears that was not present in previous reports. This is the practical way to catch the forgotten services that will break when you move to a strict policy, and to detect new spoofing infrastructure as it appears.