All thirty domains I checked enforce DMARC. Seventeen of them sit on an SPF record that fails soft.

Two years ago the interesting question about DMARC was whether anyone had turned it on.

That question is finished. I pulled the DNS records for thirty product companies this week, and every single one publishes both SPF and DMARC. Not one is parked at p=none, the observation-only setting where records go to sit forever.

So I went looking for the next problem instead, and it was one layer down.

What the enforcement layer looks like now

Twenty-two domains publish p=reject. Eight publish p=quarantine. All thirty run at pct=100, which means none of them are still ramping a rollout: the policy applies to every message.

That is a healthier picture than I expected. It is also the whole of the good news.

Seventeen of thirty end their SPF in a shrug

The final mechanism in an SPF record tells a receiver what to do with a sender that is not on the list.

-all is a hard fail. Not on the list, reject it. ~all is a soft fail. Not on the list, be suspicious, deliver anyway. ?all is neutral. Draw no conclusion.

Here is the split across the sample:

Fifty-seven percent of these domains sit behind an enforcing DMARC policy while their SPF record politely declines to enforce anything.

Why that combination is not a contradiction

It is a reasonable position, and I want to be fair about it before criticising it.

DMARC passes when either SPF or DKIM passes with domain alignment. A company that signs everything with DKIM does not depend on SPF for the DMARC verdict. Softfail then costs nothing on the happy path.

The cost appears on the unhappy path. Key rotations break DKIM. New vendors send before anyone signs their mail. A subdomain gets delegated and the signature stops matching.

In that moment SPF is the only evidence left, and ~all tells the receiver that the absence of the sender from the list means very little.

The two records worth looking at twice

One domain publishes ?all. Neutral is the weakest qualifier in the specification. It asks the receiver to conclude nothing, which is functionally similar to publishing no SPF policy at all while appearing to have one.

One domain publishes no all mechanism at all. RFC 7208 treats a record with no final mechanism as neutral by default, so the effect is the same as ?all, arrived at by omission rather than choice. That domain belongs to a company whose product is marketing email.

I am not naming either, because both are one-line fixes and neither is causing visible harm today. The point is that both records were almost certainly written years ago by someone who has since left, and nobody has looked at them since.

What I expected to find and did not

I went in expecting the ten lookup limit to be the story.

SPF evaluation is allowed at most ten DNS lookups. Every include:, a: and mx costs one, and includes nest, so a record with four vendors can quietly cost twelve. Over the limit, evaluation returns permerror, and most receivers treat that as no SPF at all.

Zero of thirty exceeded it. Either these companies have consolidated their senders, or someone measured. Either way it is a solved problem at this tier, and I would not assume the same holds one tier down.

How to check your own in four minutes

Three commands, no tools, no signup.

dig +short TXT example.com
dig +short TXT _dmarc.example.com

In the first output, find the line beginning v=spf1 and read its last mechanism. In the second, find p= and read the policy.

Then count your lookups. Every include:, a:, mx, ptr, exists: and redirect= in your record costs one, and each include: recursively costs whatever the included record costs. If the total approaches ten, you are one vendor away from a permanent error.

What I would change, and in what order

If you are at p=none: that is the only genuinely urgent item on this list, and nobody in this sample still is. Move to quarantine with a low percentage and read the reports.

If you are at reject with ~all: leave it alone until you are confident every legitimate sender is enumerated. Then move to -all. Doing it in the other order costs you real mail.

If you publish ?all or no all: fix it this week. It is the one case where the record creates an impression of protection without providing any.

The limit of this study

Thirty domains, all software companies, all large enough to have someone whose job includes DNS. That is the easiest possible sample, and it still contained two records that nobody has read in years.

I would not extrapolate the DMARC adoption number to smaller businesses. I would extrapolate the second finding: the record gets written once, during a migration, by whoever is holding the ticket, and then it stays.

Questions people ask about this