Your DMARC record might contain something that no longer exists

Steven Browning — Sat, 19 Sep 2026 22:07:42 +0000

Most of us set up SPF, DKIM and DMARC once, watch the reports for a week or two, and then leave them alone. That's usually the right call. They aren't systems that need constant attention.

This year is worth an exception, though — and not quite for the reason you'd expect. The spec changed in May, and one of those changes means that tidying up your DMARC record can quietly make it stricter than you intended.

Here's what moved, and what I'd look at.

What actually changed

On 19 May 2026, DMARC moved onto the IETF Standards Track as RFC 9989, replacing RFC 7489 and RFC 9091. Reporting moved out into two companion documents: RFC 9990 for aggregate reports, RFC 9991 for per-message failure reports.

For the ten years before that, DMARC carried the status Informational — a description of something the industry had already built, rather than a standard anyone was obliged to follow. A lot of records out there were written against that older spec and haven't been touched since. Some of them contain a tag that no longer exists.

The `pct` tag is gone, and deleting it isn't free

If you rolled DMARC out gradually, you probably used pct:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com

It was a reassuring idea: apply the policy to a quarter of failing messages, watch what breaks, then raise the number. In practice receivers interpreted it inconsistently enough that RFC 9989 removes it altogether — there's an appendix titled "Removal of the 'pct' Tag."

This is the part I'd slow down for. If you delete pct=25 from that record, you don't land back where you started. Receivers that don't recognise the tag already treat the policy as applying to everything, and removing it just makes that explicit. You've gone from quarantining a quarter of failing mail to quarantining all of it.

That may be exactly what you want. It's nicer to be the person who decided it than the person who finds out from the helpdesk.

The replacement is a t tag, for testing. t=y asks receivers to handle mail one step below your published policy — p=reject behaves as quarantine, p=quarantine behaves as none — while you carry on collecting reports. It's a cleaner mechanism than sampling, though it does mean the gradual percentage ramp isn't available any more.

Stricter isn't automatically the goal

There's an assumption running through a lot of DMARC advice that p=reject is the finish line and everything else is a waypoint. RFC 9989 is more careful than that. Section 7.4 puts it directly:

domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of p=reject

The reasoning is practical rather than theoretical. Mailing lists and forwarders relay and rewrite messages in ways that break the original authentication, so rejecting on failure can bounce your own users' perfectly legitimate mail — and list software often responds to those bounces by unsubscribing them.

If your domain is purely transactional, p=reject is a sound destination. If real people send mail from it, quarantine may be as far as you want to go.

Three smaller changes worth knowing about

Organizational domain discovery no longer uses the Public Suffix List. RFC 9989 replaces it with a series of DNS queries the spec calls the DNS Tree Walk. Worth knowing by name — it's what you'll be searching for the day something behaves oddly on a multi-level domain.

np covers non-existent subdomains. Carried over from RFC 9091, it lets you publish a separate policy for subdomains that don't exist at all, which is handy, because those are a favourite for spoofing. Without it they inherit sp, or failing that p.

sp only applies where you'd expect it to. It's ignored on records published below the organizational domain or public suffix level. If you've ever set it on a subdomain and wondered why nothing happened, that's the reason.

SPF: a short record can still be doing a lot of work

An SPF record can look completely manageable and still sit close to a hard limit, because every include: pulls in whatever that provider has published — and their includes count too.

RFC 7208 puts the ceiling at ten DNS-querying terms per evaluation, and going over it produces a permerror. That's a hard failure, not a soft one, and it isn't something you'll notice unless you're reading your reports. Three or four mainstream providers is enough to get uncomfortably close.

There's also a recommended limit of two "void" lookups — queries that come back empty, or for a name that doesn't exist. Which is a good reason to clear out includes for services you stopped using two migrations ago.

Check how your SPF record ends

This one takes ten seconds, and it's the first thing I'd look at:

v=spf1 include:_spf.google.com all

That record passes every sender on the internet.

A mechanism with no qualifier defaults to +, so a bare all means +all — pass. It's one missing character, the record looks perfectly tidy, and nothing anywhere warns you. ~all is softfail and -all is fail; one of those is almost certainly what was intended.

While you're in there: if you added a second v=spf1 record when you onboarded a new provider, the two don't combine. More than one SPF record at the same name is a permerror, and the fix is to merge the mechanisms into a single record.

DKIM: "not found" often means "not found by this checker"

If a checking tool tells you DKIM is missing, it's worth a second look before you go and re-key anything.

DKIM keys live at names called selectors, and there's no standard lookup that lists them. So a checker has to guess: it tries a handful of common selectors and reports what comes back. If yours isn't on its list, you get an empty result and a record that is perfectly healthy.

A real signed message settles it in seconds. Find the DKIM-Signature header on a message you sent externally — s= is the selector, d= is the signing domain. That domain often isn't the one in the From field, particularly when a marketing platform signs on your behalf, and that's expected rather than a problem.

Two things worth filing away. Finding a key doesn't prove your messages are actually being signed correctly — it only proves the key is published. And a record with an empty p= value means the key has been revoked, not that it's missing. The record is there; the key just isn't usable any more.

If you only do three things

Look at a real message header from your own domain, on something that went to an external recipient. It'll hand you your DKIM selector and signing domain straight away.
Read the end of your SPF record, and count the includes while you're there.
Read a week of DMARC aggregate reports before you tighten anything. They're the only thing that tells you who is genuinely sending as you, and there's nearly always one legitimate sender nobody remembered.

I built a free checker for this, mostly because I got tired of tools reporting "DKIM: missing" when they simply didn't know my selector: stashgrid.site/emailcheck. It reads the public SPF, DKIM, DMARC, MTA-STS, TLS-RPT and DNSSEC records for a domain and explains each result in plain English. It runs in the browser, there's no sign-up, and nothing is stored. Treat it as a starting point rather than an audit — the fuller picture comes from your reports and your own message headers.

One last thing, worth saying plainly: these records stop people sending mail as your domain. They don't filter what arrives in your inbox, and they can't stop someone registering a domain that merely looks like yours and sending from that instead. Different problem, different tools.

Sources: RFC 9989 (DMARC), RFC 7208 (SPF), RFC 6376 (DKIM).

DEV Community: Steven Browning