We Checked the DMARC Policies of 100 SaaS Companies. A Third Still Leave the Door Open.

You publish a DMARC record once, mail keeps flowing, and you assume the job is done. A published record doesn’t mean anyone is actually blocked from spoofing your domain. That depends entirely on the DMARC policy inside it, and almost nobody goes back to check.

We picked 100 well-known, mostly mid-to-large SaaS, developer-tool, and cybersecurity companies, names most technical readers would recognise, and ran a public DNS lookup against each _dmarc record to see how many were actually enforcing protection, not just publishing something. Anyone can run the same check with one command, dig +short TXT _dmarc.example.com. No scanning, no accounts, no special access. DMARC records are meant to be public, published so any mail server can read them before deciding whether to trust a message. The results were less reassuring than we expected.

What the DMARC policy tag actually controls

A DMARC record is a single DNS TXT entry at _dmarc.yourdomain.com. Its most important piece is the p= tag, the policy, which tells receiving mail servers what to do with a message that fails SPF and DKIM checks while claiming to be from your domain.

There are three options. p=none means monitor only, and spoofed mail still lands in the inbox exactly as if nothing were wrong. p=quarantine is a half-measure: it routes spoofed mail to spam instead of the inbox, which helps, but does nothing for the person who checks their spam folder anyway. p=reject blocks it outright before it’s delivered. Only reject actually stops a spoofed email from reaching someone’s mailbox at all.

This is defined in RFC 9989, the current DMARC specification (DMARCbis, which we’ve covered before). It builds on the authentication mechanics of SPF and DKIM, which we’ve also written about in more detail.

The headline numbers

Every one of the 100 domains had a DMARC record published. That’s the encouraging part, and it’s likely a reflection of the sample: companies that sell software to technical buyers tend to have decent baseline hygiene.

But publishing a record isn’t the same as enforcing one:

68 use p=reject at the root domain
24 use p=quarantine
8 use p=none

Add the last two together and 32 of the 100 companies we checked don’t fully block spoofed email at their root domain. The 8 on p=none deliver it straight to the inbox as if nothing were wrong. The 24 on p=quarantine at least push it to spam, but that’s a half-measure, not a block, and it relies on the recipient never checking their spam folder for a convincing invoice or password-reset email.

A separate finding: three of the 100 records had no rua= tag at all, the address DMARC uses to send aggregate reports on pass/fail activity. That doesn’t weaken enforcement, the stated policy still applies, but it means no one at that company ever sees who’s sending mail as their domain, legitimately or otherwise. A policy with no reporting address is running with no feedback loop.

The subdomain blind spot

Here’s the part most people miss, including some of the companies with a strong root policy.

DMARC has a second policy tag, sp=, which governs subdomains separately from the root domain. A company can have p=reject on example.com while mail.example.com, promo.example.com, or any other subdomain inherits a completely different, weaker policy, or no protection at all if sp=none is set explicitly.

Of the 68 domains enforcing p=reject at the root, 7 leave their subdomains meaningfully weaker, either dropping to sp=quarantine or, in a handful of cases, sp=none. In practice, that means the domain everyone associates with the brand is locked down, while a subdomain nobody thinks about is wide open. An attacker looking for a way in isn’t going to spoof example.com. They’ll spoof billing.example.com or mail.example.com, banking on the fact that nobody checked whether the subdomain policy matched the root.

This is exactly the kind of gap that’s invisible unless you’re specifically checking for it. The root domain “looks protected” in any quick manual check. The subdomain policy is a separate line in the same record that’s easy to miss.

RFC 9989 also adds np=, a third policy tag covering subdomains that don’t exist at all, closing the gap sp= leaves for made-up addresses like invoices.example.com. We’ve covered it in more depth in our DMARCbis breakdown; we didn’t parse for it in this dataset, but it’s worth checking alongside sp= on your own domain.

Does having a DMARC record mean I’m protected from spoofing?

No, and this is the single most common misreading of DMARC. A record proves you’ve configured something, not that it’s enforcing anything. Full protection requires three things at once: p=reject at the root, a matching sp=reject (or np=) at the subdomain level, and an rua= address someone is actually reading. Miss any one of the three and the “protection” is partial at best.

A quick self-audit

If you manage a domain’s email, or a client’s, these take about two minutes each:

Look up your own _dmarc record and check the p= value. Anything short of reject is monitoring, not protection.
Check sp= separately. It’s easy to set the root policy and forget subdomains inherit their own rule.
Check for a leftover pct= tag. Under RFC 9989, compliant receivers ignore it entirely and apply your stated policy at 100% regardless of the value, so a pct=50 left over from an old rollout isn’t doing what the person who set it probably thinks it’s doing. Remove it rather than trying to tune it.
Make sure rua= points somewhere someone actually reads.

None of this requires new infrastructure. It’s a five-minute DNS lookup against a record you already control.

kant.au checks the DMARC policy, subdomain policy, and reporting configuration for every domain you monitor, and flags exactly the gaps above: a root policy that doesn’t match the subdomain policy, a record missing rua=, or a leftover pct= tag doing nothing under RFC 9989. Want to see where your own domain lands? Check your email authentication setup for free, or start a 14-day trial to monitor it continuously.

RFC 9989, DMARCbis core protocol
RFC 7208, Sender Policy Framework (SPF)
RFC 6376, DomainKeys Identified Mail (DKIM)