How do you read a DKIM check result (selector, p=, k=, t=)?

Why a DKIM result starts with a selector, not just a domain

Unlike an SPF or DMARC check, which reads a record at a fixed, predictable location for any domain, a DKIM check needs two inputs: the domain and a selector. RFC 6376 §3.1 describes DKIM’s key namespace as subdivided “using ‘selectors’” specifically because a domain can publish more than one key at once — one per sending service, or rotated over time — each under its own label, resolving to a DNS name like selector._domainkey.example.com. There is no DNS record that lists a domain’s active selectors; the value has to come from whoever configured mail sending, typically visible in that provider’s admin panel or, for a message you already have, in the s= tag of its DKIM-Signature header. AdminKit’s DKIM check fetches exactly that TXT record once you supply both values, and validates its syntax.

Reading the p= tag: the public key itself

A valid DKIM record’s most important field is p=, which holds the base64-encoded public key a receiver uses to verify a message’s signature. A result showing a well-formed p= value with a plausible length means the record is published and structurally correct — not that any specific message actually verifies against it, since that depends on the matching private key being used correctly by your mail server, which a DNS lookup can never see directly.

An empty p= value is a special case worth recognizing on sight: RFC 6376 §3.6.1 states that an empty value means the key has been deliberately revoked, not that it’s missing or broken. This is the standard way to retire a selector — the record stays published so a query doesn’t simply return nothing, but any mail still signed under that old key will now fail verification, which is the intended effect. Seeing an empty p= on a selector you recognize as retired is expected; seeing it on a selector you believe is still actively signing mail means that provider’s key was revoked without your sending stopping, which is worth investigating immediately.

Reading k= and t=: algorithm and status flags

k= names the signing algorithm the key uses — almost universally rsa in current deployments — and exists so a receiver knows how to interpret the p= value correctly rather than assuming a single fixed algorithm forever. t=y, when present, marks the selector as being in “testing” mode, a state some mail providers set automatically during initial DKIM rollout; some receivers are more lenient about signature failures on a testing-flagged selector. A production selector that’s been live and verified for a while shouldn’t still carry t=y — leaving it set past initial setup provides no benefit and can mask ongoing verification problems a receiver would otherwise flag more strictly.

What “no result” actually means

A DKIM check returning no record at all for a given domain and selector combination has two likely explanations, and telling them apart matters: either that selector was never published at all (a typo in the selector name, or a provider that uses a different one than you guessed), or you’re querying the wrong domain — a signing service that sends on behalf of your domain sometimes publishes its selector under a third-party domain rather than yours, depending on how the sending relationship is configured. Confirm the exact selector and signing domain from your mail provider’s own setup documentation or a real message’s DKIM-Signature header rather than guessing at common selector names.

What the check doesn’t tell you

AdminKit’s DKIM check validates the published key record’s syntax; it does not and cannot confirm that any specific outgoing message is actually signed correctly, since that requires the message’s own headers, which the check never sees. RFC 6376 treats publishing a key record (§3) and a receiver verifying a signed message (§6) as genuinely separate steps — a syntactically perfect published record and a mail server that signs incorrectly, or not at all, are two different failure modes that look identical from a DNS lookup alone. If a published record checks out but mail still isn’t verifying for recipients, see DKIM selector and record mistakes that break signing for the most common causes beyond the record itself, and inspect a real sent message’s headers for a dkim=pass result as the final confirmation.

Checking your own setup

Run AdminKit’s DKIM check with your domain and the exact selector your mail provider assigned. For how DKIM fits together with SPF and DMARC as a complete mail authentication setup, see SPF, DKIM and DMARC explained.