How can spoofing bypass weak authentication setups?

You've set up DMARC. You're checking the reports. Everything looks fine. But spoofed emails from your domain are still landing in inboxes. How is that possible?

The short answer is that authentication only works if it's actually enforced. And there are three common gaps where attackers slip right through.

DMARC at p=none does nothing to stop spoofing

When your DMARC policy is set to p=none, you're telling receiving mail servers "monitor this, but don't do anything about failures." So when a spoofed email arrives claiming to be from your domain and it fails authentication checks, the receiving server sees that failure, logs it in a DMARC report, and then delivers the email anyway.

The attacker doesn't need to beat your authentication. They just need to send while your policy is too polite to act. p=none is genuinely useful as a temporary monitoring phase while you gather data, but it was never meant to stay there forever. (Many senders set it up, forget to move to p=quarantine or p=reject, and wonder why spoofing continues.)

Loose SPF records hand attackers a free pass

SPF works by listing which IP addresses are allowed to send email on your behalf. But if that list is too generous, it backfires. Common examples include using +all or ~all with no restrictions, including third-party services you no longer use, or adding broad IP ranges that cover infrastructure you don't actually control.

So if an attacker sends from an IP that happens to be covered by one of those loose includes, your own SPF record vouches for them. The email passes SPF. It looks legitimate. And it probably gets delivered.

Unprotected subdomains are a side door

Let's say your main domain (yourcompany.com) has a solid DMARC policy at p=reject. An attacker can't spoof yourcompany.com easily anymore. So instead they spoof mail.yourcompany.com or updates.yourcompany.com.

Unless you've explicitly set sp=reject in your DMARC record (which applies the policy to subdomains too), those subdomains are wide open. Many organizations lock down the root domain and leave subdomains unprotected without realizing it.

What to actually do about it

If you're still on p=none, make a plan to move to p=quarantine first, then p=reject. Read your DMARC reports to understand what's legitimately sending on your behalf before you tighten the policy. When you're ready to make that move, check that your DMARC record includes sp=reject or sp=quarantine to cover your subdomains too.

For SPF, audit your record. Remove services you no longer use. Replace +all or ~all with -all once you're confident your legitimate senders are covered. Every unnecessary include is a potential gap.

You can check your current DMARC setup with our free DMARC Parser to see exactly what your record says and whether it's actually enforcing anything. If you're not sure what you're looking at, our SOS hotline is free and we'll walk through it with you.