Mail authentication in 2026: SPF and DMARC across zones

On 27 August 2026 we queried DNS records for 600 domains (150 per zone) and kept only those with an MX record — that is, those that accept mail at all. For those we checked for SPF and DMARC, and what those records actually instruct.

On SPF, .ru runs level with .com — 85% against 85%. On DMARC it trails clearly: 36% against 56%.

What this measurement does not include. DKIM cannot be checked from outside: the signature is published at selector._domainkey.domain, and no registry of selectors exists — only the sender knows them. So the third pillar of mail authentication is absent here, and that is a limit of the method, not a finding.

Sampling caveat: these are domains somebody brought to our tools, not a random slice of a zone. Comparing zones is sound — they were collected identically.

Having SPF says nothing about what happens to a forged message. That is decided by the final qualifier:

Strict mode is four times rarer in .ru than in .com. And 26 of 80 records carry no qualifier at all — by the standard that means a neutral result: the check formally completes but decides nothing.

Adding up: of 94 Russian domains that accept mail, SPF actually forbids something on six. The rest either ask for "mark as suspicious" or ask for nothing.

It is worth not overstating this: ~all is not an error. It is a deliberate compromise for as long as not every legitimate sender is listed. The problem is that "as long as" rarely ends: the record gets set during a mail migration and is never revisited.

DMARC ties SPF and DKIM to the address in the From field and says what to do on a mismatch. The policy is set by the p parameter:

The effects multiply. Of all domains accepting mail, those fully protected by a p=reject policy come to 27 of 109 in .com (about 25%) and 9 of 94 in .ru (about 10%). A two-and-a-half-fold gap.

p=none is the correct first step: it turns on reporting without touching delivery, and it is how you find out who sends in your name at all. But it is a step, not a destination. Nearly half of Russian domains with DMARC are still standing on it.

A consistent motif emerges across Russian domains: the record gets published but never brought to the point where it decides anything. SPF is present on 85% — as in .com; it is strict on 8% — four times rarer. DMARC is present on a third, and nearly half of those only observe.

We saw the same motif in other measurements: HSTS is sent but without includeSubDomains; robots.txt is written, but only one site in ten closes it to AI crawlers. The setting is made once at launch and never revisited.

The order of work, if this describes you:

1. Start with DMARC at p=none and a reporting address. Delivery will not change, but within two or three weeks you will see the full list of everyone sending in your name — forgotten newsletters and internal systems included.
2. Fix SPF against those reports. Not the other way round: tightening SPF blind is a reliable way to lose the mail from an accounting system nobody remembered.
3. Move SPF to -all once the reports are clean. Mind the ten-DNS-lookup limit: nested include statements consume it, and exceeding it invalidates the whole record.
4. Raise DMARC to quarantine, then reject. Leave at least a couple of weeks between steps.

To see what your domain has configured, use the mail record checker.