DEV Community

Cover image for Every DKIM checker is guessing — including mine
Jose Pollman
Jose Pollman

Posted on • Originally published at notspoofed.com

Every DKIM checker is guessing — including mine

#devops #security #dns #tutorial

Almost every DNS record you care about can be looked up. Ask for the SPF record, you get it. Ask for _dmarc, it's there.

DKIM doesn't work that way, and almost nobody building tooling around it says so out loud.

You cannot list selectors. At all.

A DKIM public key lives at:

<selector>._domainkey.<domain>
Enter fullscreen mode Exit fullscreen mode

The selector is an arbitrary label chosen by whoever set up signing. Google Workspace uses google. Microsoft 365 uses selector1 and selector2. Mailchimp uses k1. Amazon SES generates three random tokens per identity.

There is no DNS query that returns "every name under _domainkey". ANY doesn't do it. Zone transfers are refused by every sane nameserver. To read a DKIM key, you must already know its name.

Which means every DKIM checker in existence — mine included — is guessing from a list.

So when a tool tells you "no DKIM found", the honest translation is:

We tried our list of forty or fifty common selectors and none of them matched.

That is a genuinely different statement from "you have no DKIM", and the gap between the two is where people waste afternoons.

Amazon SES makes it concrete. Its selectors are random tokens. No guess list will ever find them. A domain signing perfectly through SES will read as "no DKIM" on every guessing tool, forever. If your checker doesn't tell you that, it's misleading you by omission.

The opposite failure: selectors that were never there

Now the direction that's actually dangerous, because it produces confident output instead of a shrug.

Some domains publish a wildcard DNS record, which answers every name under the domain. On such a domain:

dig +short TXT totally-made-up-selector._domainkey.example.com
Enter fullscreen mode Exit fullscreen mode

...returns something. Not because that selector exists. Because the wildcard matches everything.

A checker whose test is "did I get an answer?" will report a dozen imaginary selectors on these domains, and it will look authoritative doing it.

The obvious defence is to require the answer to actually parse as DKIM — specifically to carry a p= tag, which RFC 6376 makes mandatory.

That's necessary, and it isn't sufficient. Here's the one that got me:

*._domainkey.example.com.  TXT  "v=DKIM1; p="
Enter fullscreen mode Exit fullscreen mode

That's a structurally valid DKIM record with an empty key. It passes the p= test. So every guessed selector comes back looking like a revoked key — and now your tool is telling someone they have thirty revoked DKIM selectors, which is both alarming and entirely fictional.

The only defence I've found that holds: query a deliberately nonsensical selector first, then discard any result identical to what the wildcard returned. Establish the baseline lie, then subtract it.

If a checker has ever told you that you have dozens of revoked selectors, this is what happened. Ignore it.

Finding yours for certain

Two methods, neither of which involves guessing.

Read a message you sent. Most reliable, and needs access to nothing. Send yourself a message, view the raw source (⋮ → Show original in Gmail), and find:

Enter fullscreen mode Exit fullscreen mode

s= is your selector. d= is the signing domain — check that d= matches your visible From: domain, because if it doesn't, DKIM is passing and not aligning, and DMARC fails anyway.

Do this once per sending system. Each has its own selector and they all have to work.

Or check the provider's console. Every platform exposes this under "authentication", "verified domains" or "DKIM" — which is also where you switch signing on if it turns out it was never enabled.

Reading the record once you have the name 

dig +short TXT selector1._domainkey.example.com
Enter fullscreen mode Exit fullscreen mode 
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"
Enter fullscreen mode Exit fullscreen mode

Four things worth noticing:

  • p= with nothing after it means revoked. If anything is still signing with that selector, that mail is failing DKIM right now.
  • A missing v= tag is fine. RFC 6376 only recommends it. Plenty of production records start straight at k=rsa and validate perfectly.
  • Key length. 1024-bit RSA is still accepted everywhere but is no longer considered strong. 2048 is the norm. Rotate through your provider, not by hand-editing DNS.
  • A CNAME instead of a TXT is normal. Most platforms have you delegate the selector to them so they can rotate keys without touching your zone. Follow it and you should land on a valid key.

Worth stealing: the revoke-everything wildcard

The wildcard pattern that breaks checkers is genuinely useful if you own a domain that sends no mail:

*._domainkey.example.com.  TXT  "v=DKIM1; p="
Enter fullscreen mode Exit fullscreen mode

That declares every selector on the domain revoked. Combined with v=spf1 -all and p=reject, it's an unambiguous statement that this domain sends nothing and any signature claiming otherwise is forged.

And it doesn't paint you into a corner: DNS wildcards only apply where no exact match exists, so publishing a real selector later takes precedence automatically. One working key coexists happily with a revoke-everything wildcard.

Most parked and brand-protection domains have SPF and DMARC locked down and leave DKIM wide open. This closes it.

I maintain notspoofed — a free, no-signup SPF/DKIM/DMARC checker. It guesses fifty selectors like everything else, but it says so, it verifies each hit is a real parseable signing key rather than a wildcard echo, and it runs the nonsense-selector baseline described above so it won't invent thirty revoked keys for you. I built that last part because I got it wrong first. Source is on GitHub under MIT.

If you've seen a checker confidently report selectors that don't exist, I'd like to know which — that failure mode is more common than it should be.

Top comments (0)