DKIM signs each outgoing message and publishes the matching public key in DNS at selector._domainkey.yourdomain. A receiver reads the selector from the message's DKIM-Signature header, fetches that key and verifies the signature, proving the domain authorised the message and that it was not altered in transit.

How to read your result

Selector. The name the key is published under, shown as selector._domainkey. Each sending system usually has its own.
Key label. The algorithm and key length. RSA keys under 1024 bits are weak and some receivers ignore them; 2048 is the sensible default.
Record. The raw TXT value, including the public key in p=. An empty p= means the key has been revoked deliberately.
Common-selector probe. If you left the selector blank, the checker guessed at the selectors well-known providers use. Finding nothing this way does not prove DKIM is missing — it proves your provider is not one of the guesses.

Why you need the header to be certain

DKIM has no discovery mechanism. There is no way to ask a domain which selectors it uses, because the selector is chosen by the sender and only ever announced inside the message itself. The authoritative answer is in a real email: open the raw source and read the s= tag in the DKIM-Signature header.

This is why a blank-selector probe is a convenience rather than an audit. It can confirm that a key exists; it cannot prove that one does not.

The five most common failures

The selector is not published

The provider generated a key pair and you never added the DNS record, or added it at the wrong name. The signature then references a key that does not resolve, and verification fails — which is worse than not signing at all, because the message carries a broken claim.

An empty p= tag

p= with nothing after it is a revocation. It is a legitimate thing to publish when retiring a key, but if the provider is still signing with that selector, every message fails. Revoke only after you have stopped using the key.

A key that is too short

1024-bit RSA still verifies almost everywhere, but it is below what current guidance recommends and some receivers discount it. If your provider offers 2048, use it. The usual reason people do not is the next failure.

The 255-character split

A single TXT string cannot exceed 255 characters, and a 2048-bit key does. The record must be published as multiple quoted strings that the resolver concatenates. Some DNS panels do this for you, some require you to split it manually, and a few silently truncate — which produces a key that looks present and never verifies.

Rotated at the provider, not in DNS

Key rotation is good practice and a common source of sudden failures: the sending platform switches to a new selector on a schedule, and DNS is never updated. Nothing changes on your side until authentication quietly stops passing.

A worked example

A 2048-bit RSA key published at s1._domainkey.example.com:

v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

v=DKIM1 — version; must be first.
k=rsa — key type. Ed25519 exists and is smaller, but support is not universal.
t=s — optional; forbids subdomain use of this key. Omit it unless you mean it.
p= — the public key itself, base64. This is the part that gets split.

Why DKIM matters more than SPF

SPF checks the connecting IP, so it breaks whenever mail is forwarded: the forwarding server is not in your record and never will be. DKIM signs the message, so the signature travels with it and still verifies after a forward. For DMARC, that difference is decisive — DKIM is the mechanism that keeps alignment intact through mailing lists and redirects.

If you can only get one of the two right, get DKIM right.

Related checks

DMARC checker — the policy that makes a DKIM result consequential.
SPF checker — the IP-based half of authentication.
TXT lookup — inspect the raw record at any selector name.
Full domain check — SPF, DKIM, DMARC and MX in one pass.

Check a DKIM key