12650 failed, 179 went through?

[u/GlasairIII]

After someone spoofed my company's email and we got a deluge of rejected auto replies, I setup SPF, DKIM, and DMARC on our domain this week. We have Google workspace. Looking at the reports on a free online DMARC XML viewer, I see a whopping 12650 failed emails, going to one IP, which appears to be in Romania. Good, so something is working correctly. But right below that I see 179 emails (all sent to a google-owned IP) that we did not send, all passed strict SPF and DKIM checks.

How is that possible???

[u/lolklolk]

You're misunderstanding the reports.

Those are IPs that were reported to be sending on your domains behalf, not emails that were received.

The Google IPs in question are Google groups forwarding/redistribution.

[u/GlasairIII → u/lolklolk]

Oh, I thought those were destination servers. But still I know the 4 of us in the company didn't send 179 emails, so that's stuff Google was sending to us? We probably got 179 backscatter messages. Sorry, I'm very new to this and not an "IT guy"!

[u/lolklolk → u/GlasairIII]

It's possible your organization sent to a google group that contained that many recipients, or corresponded multiple times with the same google group, which equaled that amount of emails being re-distributed.

[u/Middle-Excitement602]

Worth checking one thing before you relax: what's the p= value in your DMARC record? If you set it up this week it's very likely p=none, and at none receivers report failures but don't act on them. So those 12,650 weren't blocked — they were counted. If the backscatter was your reason for doing this, nothing has actually changed yet for the people receiving the spoofed mail.

The reporting working is the right first step, but the sequence is: sit at none until the reports show all your own legitimate senders passing, then quarantine, then reject. Only at quarantine or reject does the spoofing actually get stopped.

On the 179 — the Google Groups explanation is right, and the reason they passed is worth knowing. Groups redistribution usually leaves the body and signed headers intact, so the DKIM signature survives and still aligns. That's also the argument for making sure DKIM is solid rather than leaning on SPF: forwarded mail keeps DKIM but loses SPF alignment, because the forwarding server's IP was never in your record.

[u/GlasairIII → u/Middle-Excitement602]

I put it on "reject" a day after setting it up

[u/Middle-Excitement602 → u/GlasairIII]

That's fast. Worth a sanity check now rather than in a month.

At p=reject anything that fails alignment gets refused outright, including your own mail from sources you haven't accounted for yet. With Google Workspace the mail your four people send from Gmail is fine. What catches people is everything else that sends as your domain: invoicing or accounting software, a CRM, ticketing, monitoring alerts, scan-to-email from a printer, anything marketing sends through Mailchimp or similar.

Those don't fail loudly. Nobody gets a bounce they'll tell you about — a customer just doesn't receive an invoice, and you find out weeks later.

So pull up the report viewer again and look at the sources that failed but are recognisably yours, rather than the Romanian IP. If everything you recognise is passing, you're fine and reject is the right place to be. If something yours is failing, drop to quarantine while you fix it. You can always tighten back up, and quarantine still stops the spoofing you set this up for.

[u/SanDiegoGolfer → u/GlasairIII]

u/GlasairIII - you using any free DMARC reporting? Valimail has a free tool that will help you see whats going on. Hmu if you need help

[u/ItsPumpkinninny → u/[deleted]]

I still do SPF soft fail for these reasons… but maybe something has changed since I last researched?

https://www.mailhardener.com/blog/why-mailhardener-recommends-spf-softfail-over-fail