What is DKIM?

DKIM (RFC 6376) adds a cryptographic signature over selected headers and the body of every outgoing message. Your sending service holds the private key; the matching public key is published as a TXT record at <selector>._domainkey.<domain>, where the receiver fetches it to verify.

What the receiver checks

The DKIM-Signature header carries the signing domain (d=), the selector (s=), the list of signed headers (h=) and the signature itself. The receiver fetches <s>._domainkey.<d>, verifies the signature over the canonicalised headers and body, and returns pass or fail.

A pass proves two things: the message was authorised by the holder of that key, and the signed parts were not modified in transit. It does not prove anything about the visible From header — that is what DMARC alignment adds, by requiring d= to line up with the From domain.

Why selectors cannot be enumerated

There is no way to list the selectors on a domain: DNS gives no directory, and a selector is any label the signer chose. not found is therefore never proof of absence — it only means the names we tried are not in use.

The scan at the bottom of this page works around that by detecting your sending services from the MX records and SPF includes first, then querying only the selectors those services actually use. If it recognises no signing service, it says so rather than reporting a hard failure.

Two states worse than missing

A record with an empty p= is a revoked key (RFC 6376 §3.6.1): the record exists, so the domain claims to sign, and every signature carrying that selector fails verification. A t=y flag puts the key in test mode, which tells receivers to treat a signature as non-binding.

A short RSA key is a third: below roughly 1024 bits, receivers increasingly refuse to verify at all. 2048-bit RSA is the practical default; ed25519 keys are short by design and are not judged on length.

Why DKIM matters more than SPF

DKIM survives forwarding. A forwarding service rewrites the envelope, which destroys the SPF pass, but leaves the signed headers and body intact — so an aligned DKIM signature is the only thing that keeps a forwarded message passing DMARC. A domain that authenticates on SPF alone is green on every dashboard and breaks the moment somebody forwards a message.

Frequently asked questions

Can I set up DKIM myself?

Partly. The key pair is generated in your sending service's dashboard, because the private key has to live there. You publish the TXT record it gives you, and the service starts signing once it sees the record resolve.

One service signs and another does not. Is that a problem?

Yes, for the one that does not. Each sending service signs with its own d=/s= pair, so an unsigned stream depends on SPF alone for DMARC — and loses even that as soon as a message is forwarded.