DKIM

DKIM adds a cryptographic signature to outgoing mail, so a receiving server can verify that the signed parts of the message haven't changed, and that the signature validates against the public key published by the signing domain. The private half of the key signs the message on the way out; the public half, published in DNS, is what lets anyone receiving it check that signature.

Not something you create yourself

Unlike most records on this site, you can't just make one up. A DKIM record only works because the service doing the signing holds the matching private key, so the public key has to come from that service itself, not from your own imagination or a generator you found. Copy it exactly as given, capitals included: the key is base64, where changing the case of a single letter changes the key. Any external service that needs to sign mail on behalf of your domain hands you its own selector and key to publish, Mailchimp is a common example, and so, less obviously, is your own spam filter, if it signs outgoing mail on the way through rather than merely scanning incoming mail.

Selector: which key, published where

The public key doesn't live at a domain's own apex. It's published as a TXT record at <selector>._domainkey.example.com, where the selector is a short name chosen by whichever service generated the key, not something you invent yourself. A domain sending mail through more than one service at once, its own mail server and a separate marketing platform, say, ends up with more than one selector, each with its own key, sitting side by side without conflicting, the two rows in the table above being exactly that.

Name Type Value
google._domainkey TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
mailchimp._domainkey TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Long keys, split across strings

A single string inside a TXT record has a length limit, and a DKIM public key is often long enough to exceed it. When that happens, the key gets split into several quoted segments within the same record, which a receiving server rejoins before reading it. Most panels handle this automatically the moment you paste a key in; if you're ever pasting one in manually and it comes back invalid, an accidentally broken split is one of the first things worth checking.

An empty p= means "revoked", not "missing"

RFC 6376 gives an empty p= a specific meaning: this exact selector's key has been deliberately revoked, not merely left unset. It's the difference between a record that never existed and one that existed, worked, and has now been explicitly retired, which is why rotating away from an old selector often means emptying its p= rather than deleting the record outright, the same "say so explicitly instead of leaving it ambiguous" pattern as -all on a non-sending domain's SPF record or a null MX on one that doesn't accept mail at all.

Closing off every selector at once, with an ordinary DNS wildcard

A domain, or more often a subdomain, that never signs mail with DKIM at all can say so for every selector in one go: a wildcard record, *._domainkey.example.com, with an empty key. This isn't a DKIM-specific provision, RFC 6376 doesn't mention wildcards at all, it's ordinary DNS wildcard behaviour (RFC 1034 ยง4.3.3, clarified further in RFC 4592) doing the work underneath an otherwise completely normal DKIM lookup. A DKIM verifier checking a made-up or unexpected selector does nothing more than an ordinary DNS TXT query, and DNS itself, not DKIM, is what quietly hands back the wildcard's empty-key answer when no selector-specific record exists. Whatever queries that selector gets the same explicit "revoked" answer as the named-selector case above, without a separate record for every selector nobody's using.

Rotating a key

Because a DKIM key is just a DNS record, rotating it, replacing an old key with a new one periodically, is good security practice, works by publishing the new key under a new selector alongside the old one, switching the mail server over to sign with that new selector, and only removing the old selector's record once nothing is still relying on it. The two selectors coexist safely in the meantime, there's no moment where a key has to be swapped out all at once.