What it is
DKIM adds a digital signature to every outgoing message using a private key held by your mail provider. The matching public key is published in your DNS. A receiver fetches that public key, verifies the signature, and now knows two things: the message genuinely came from your domain, and nothing in the signed portion has been changed since.
Selectors
A domain can have many DKIM keys, so each one is filed under a label called a selector. Google Workspace typically uses google, so the key lives at google._domainkey.yourdomain.com. The selector is included in the signature header of every message, which is how a receiver knows which key to fetch.
This matters at scale. If a domain sends through two providers it needs two keys under two selectors. A mailbox pool provisioned in a hurry can end up with none at all, and the only symptom is worse placement.
Why it beats SPF for forwarded mail
When a message is forwarded, the forwarding server becomes the sender, so SPF breaks — the new sending IP is not on your list. DKIM does not care. The signature travels with the message and still verifies, as long as the signed content was not modified. This is why DKIM is the more reliable of the two signals.
The record and the key
A DKIM record lives at selector._domainkey.yourdomain.com as a TXT record, or as a CNAME pointing at one the provider hosts. The TXT form looks like v=DKIM1; k=rsa; p=MIIBIjANBg… — version, key type, and the public key in base64. A 2048-bit key is around 400 characters, longer than the 255-character DNS chunk limit, so it is stored as two quoted strings that the resolver joins; most DNS panels do this automatically and a few do not, which is the single most common reason a freshly published key fails to verify.
Google Workspace gives you a TXT record under the google selector and requires you to click Start authentication after it resolves. Microsoft 365 gives you two CNAMEs, selector1._domainkey and selector2._domainkey, pointing at records Microsoft hosts, and requires DKIM signing to be enabled per domain in the Defender portal. In both cases the record existing is not the same as signing being on — the DKIM checker confirms the key resolves, and only a real sent message confirms it is being used.
Rotation and multiple selectors
Keys should be rotated, and selectors are what make that possible without downtime. Publish the new key under a new selector, switch the provider to sign with it, and leave the old selector's record in place for at least a week so mail already in transit still verifies. Then remove the old record. Microsoft rotates between its two selectors on its own; Workspace keeps one and you rotate by generating a new key in the admin console.
A domain can have as many selectors as it needs. A sending tool that signs with its own key, a transactional service, and the mailbox provider can each have one on the same domain. What matters for DMARC is that at least one signature verifies with a d= that matches the From domain — the alignment page covers why a signature can verify and still not count.
Why a good key still fails
The message changed after signing. DKIM hashes the body and a set of headers. A gateway that appends a legal footer, a tool that rewrites links after the signature is applied, or a mailing list that adds a subject tag all break the hash. The signature is valid; the message no longer matches it. Look for a body-hash mismatch in the Authentication-Results header — the header analyzer reads it out.
Wrong canonicalisation. The c= tag sets how strictly whitespace is compared. relaxed/relaxed survives the minor reformatting that mail servers do; simple breaks on a trailing space. Providers default to relaxed; if you are running your own signer, so should you.
The CNAME points at the wrong tenant. On Microsoft 365 the CNAME targets include your tenant name. A record copied from another domain's setup verifies against the wrong key and fails every time. Compare the target the checker resolves with the one in the admin portal.
The key is 1024-bit. Still verifies, but Google treats it as weak and it counts against you. Regenerate at 2048 and rotate.
Check yours
These run free in your browser. Nothing you type reaches a server.
Common questions
What key length should I use?
2048-bit. 1024 is still accepted but is being phased out and some receivers now treat it as weak. The main practical annoyance with 2048 is that the record is too long for a single DNS TXT string and has to be split into chunks.
Do I need a DKIM key for every sending domain?
Every domain you send from needs DKIM published for it. Whether that is a distinct key or a provider key published across domains depends on the provider — Google Workspace generates per-domain keys automatically.
Should I rotate DKIM keys?
Periodically, yes — annually is a reasonable rhythm. Publish the new key under a new selector, let both run briefly, then switch signing over and retire the old selector.
Can a domain have more than one DKIM key at the same time?
Yes, and most do. Each key sits under its own selector, so the mailbox provider, a sending tool and a transactional service can all sign mail from the same domain with different keys. Receivers verify whichever selector the message names. The only limit is housekeeping: unused selectors should be removed so a leaked old key cannot be used to sign as you.
Why does DKIM pass but DMARC still fail?
The signature verified, but the d= domain in it does not match the From domain your recipient sees. A tool signing with its own domain passes DKIM for that domain and fails alignment for yours. Fix it by having the tool sign with a key on your domain — most sending platforms support this under a custom DKIM or sending-domain setting — or by ensuring SPF aligns instead.
Related concepts
If this is the thing going wrong
The pages explain it. If you would rather it was simply fixed, that is the work I do.