DKIM setup explained: selector, key and signature

How the signature is made

As it sends a message, your mail system computes a hash over the body and selected header fields such as From, Subject and Date. It signs that hash with a private key and adds the result as a DKIM-Signature header. You publish the matching public key in DNS. The receiver fetches it, does the maths and either gets the same result or does not.

A shortened signature looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
  h=from:to:subject:date:message-id; bh=2jUSOH9N...; b=AuUoFEfD...

Two tags matter most. d= names the domain that signs. s= is the selector, a name of your choice for the key. Together they tell the receiver where in DNS to find the public key.

The DNS record

For the example above the receiver looks for a TXT record at selector1._domainkey.example.com:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

A 2048-bit key is longer than the 255 characters a single string in a TXT record can hold. So it is split into several strings, and the receiver puts them back together. Most DNS panels handle that for you. Some quietly cut the value off instead, and then the key no longer matches.

On the big platforms you do not generate the key yourself:

• Microsoft 365 creates the keys. You publish two CNAME records (selector1._domainkey and selector2._domainkey) and then enable signing for your domain in the Defender portal. Until you do, Microsoft only signs with your onmicrosoft.com domain.
• In Google Workspace the Admin console generates the key. You publish it at google._domainkey and then start authentication there explicitly.

Newsletter services, CRMs and ticketing systems each bring their own selectors. Every service that sends in your name should sign with your domain, not with its own.

Key length and algorithm

2048-bit RSA keys are today's standard. 1024 bits still count but are the bare minimum, and RFC 8301 forbids receivers to accept anything shorter as valid. Use rsa-sha256 as the algorithm. The old rsa-sha1 has not been allowed since RFC 8301. Ed25519 (RFC 8463) is more modern but not yet verified everywhere, so if you use it, sign with RSA as well.

No key should stay in use forever. Rotate keys regularly, say once a year: publish a new selector, switch signing over, and remove the old one only after a few days. That way, messages still in transit are not left without a key to verify against.

Why signatures break

The signature protects the message as it was when sent. If the body or a signed header changes in transit, it no longer verifies. With the usual settings, only changes to whitespace are tolerated. The usual culprits are gateways that add a disclaimer, a marketing line or an "external sender" banner after signing. Mailing lists that prefix the subject line do the same.

The fix is nearly always a question of order. Anything that changes the content has to happen before signing.

Leave out the l= tag as well. It limits the signature to the first bytes of the body, and an attacker may append whatever they like after that. From must always be among the signed headers (h=). If it is missing there, the signature is invalid under RFC 6376.

DKIM and DMARC

A valid signature shows that some domain signed. For DMARC, the domain in d= must also match the visible sender address. If your newsletter service signs with d=newsletter-service.example, the signature is valid and still does nothing for your domain.

Checking DKIM

A test message to ZwoMailCheck shows selector, domain, key length and algorithm of the signature your real mail carries. You also see whether it arrives intact and counts for DMARC.