Skip to content
SenderProbe
Authentication check

Check the key a DKIM selector publishes

A DKIM signature is only as good as the key a receiver can fetch to verify it. SenderProbe probes the common selector names, reads the key material each one publishes, and reports its type, its length and the flags that quietly disable it.

Free to run No mail is sent to your domain

Where a DKIM key lives in DNS

A DKIM public key is a TXT record at a name built from three parts: the selector, the fixed label _domainkey, and the domain that signs. The signing host puts the same selector in the s= tag of the DKIM-Signature header, which is how a receiver knows where to look.

The record itself carries the version, the key algorithm and the key in base64. A receiver fetches it, verifies the signature over the headers and body the signature covers, and reports a pass or a fail.

A DKIM key record. The owner name is the selector, then the literal label _domainkey, then the domain.
selector1._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

What a DKIM selector is, and how to find yours

A selector is a label that lets one domain publish several keys at once — one per sending platform, and a second one during a key rotation. Nothing about the name is meaningful to a receiver; it is simply the pointer the signature carries.

If you do not know which selector your mail is signed with, the definitive answer is in a message you have already sent: open its raw headers and read the s= tag of the DKIM-Signature. SenderProbe probes the fixed selector names the large platforms and ESPs use and reports every one that publishes a key. Platforms that mint a random selector per key cannot be discovered that way, which is why the header is the reliable source.

Key type, DKIM key length and what receivers accept

RFC 8301 sets the floor: verifiers must reject signatures with keys shorter than 1024 bits, and 2048-bit RSA is the sensible default for a new key. Ed25519 keys, defined in RFC 8463, are far shorter on the wire and are safe to publish alongside an RSA key rather than instead of one, because a receiver that does not implement them will fall back to the signature it understands.

A 2048-bit RSA key does not fit in a single 255-byte string, so it is published as two or more quoted strings that resolvers concatenate. That is normal, and not a reason to shorten the key.

Flags that quietly switch a key off

Two tags will make a correctly signed message fail to authenticate while the record looks fine at a glance. An empty p= is a revocation: it says the key is withdrawn, and receivers must treat any signature made with it as invalid. A t=y flag puts the selector in test mode, telling receivers to record the result but not to act on a failure — useful for one afternoon during a rollout, harmful when it is still there a year later.

Both problems in one record: t=y leaves the selector in test mode, and an empty p= revokes the key entirely.
"v=DKIM1; k=rsa; t=y; p="

Why DKIM fails although the key is published

Verification covers the headers named in the h= tag and the body as the canonicalisation allows. Anything that alters those in transit breaks the signature: a mailing list that appends a footer or rewrites the subject, a gateway that reformats the body, or a signature made with relaxed header canonicalisation but a simple body canonicalisation that no longer matches.

The other common cause is arithmetic rather than modification — the signing host uses a selector that was never published, or was published on a different domain. That is what the DKIM record checker settles: the key is either there and usable, or it is not.

Run this check on your own domain. A workspace takes a minute to create and runs every one of the eleven checks against the domain you name.

Check my domain

Common questions

What is a DKIM selector?
A selector is the label that identifies which key signed a message. The public key is published at the selector, the literal label _domainkey and the domain, and the signing host names the same selector in the s= tag of the DKIM-Signature header. Selectors let one domain publish several keys at once and rotate them without an interruption.
How do I find which DKIM selector my domain uses?
Open the raw headers of a message you have already sent and read the s= tag of the DKIM-Signature header; that is the selector, and it is authoritative. SenderProbe also probes the fixed selector names used by the major platforms and reports each one that publishes a key, which finds most setups but not platforms that generate a random selector.
Is a 1024-bit DKIM key still acceptable?
It still verifies. RFC 8301 requires verifiers to reject anything below 1024 bits, so a 1024-bit key sits exactly on the floor rather than comfortably above it, and 2048-bit RSA is the sensible choice for any key you generate now. Rotate by publishing a new selector, signing with it, then withdrawing the old one.
Why does DKIM fail even though the key is published?
Because the message changed after it was signed, or it was signed with a different selector than the one you checked. Mailing lists that append footers or rewrite subjects are the usual culprit, as are gateways that reformat the body. Check the s= and d= tags in the failing message's DKIM-Signature against the record that actually exists.

Keep reading

Related checks, definitions and guides.