DKIM — DomainKeys Identified Mail — is a way for a domain to take responsibility for the email it sends. The sending server attaches a cryptographic signature to each message, and the receiving server checks that signature against a public key published in the sender’s DNS. If the signature verifies, the receiver knows two things with confidence: the message really was authorised by that domain, and the signed parts of it were not altered anywhere along the way.
Alongside SPF and DMARC, DKIM is one of the three standards receivers use to decide whether mail is genuine. Google and Yahoo both require it for bulk senders, and mail without it is treated with growing suspicion. It is defined in RFC 6376.
The two halves of a DKIM key
DKIM is built on public-key cryptography, which always comes in pairs:
- The private key lives on the mail server (or at your email provider). It is used to create signatures and must stay secret.
- The public key is published in DNS, in a TXT record, where anyone can read it. It can only verify signatures — it cannot create them.
The public key lives at a name built from a selector:
selector._domainkey.example.com. The selector lets one domain publish several keys
at once — different services, or an old and a new key during
rotation. A typical record looks like this:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...
The p= tag carries the base64-encoded public key; k= names the
algorithm (RSA, or Ed25519 for newer setups); v=DKIM1 declares the version.
What happens when a message is signed
When your server sends a message, it adds a DKIM-Signature header. Inside that
header are the pieces a receiver needs to repeat the calculation:
d=— the signing domain (this is the domain being vouched for);s=— the selector, which tells the receiver where in DNS to find the key;h=— the list of headers that were included in the signature;bh=— a hash of the message body at the moment of signing;b=— the signature itself.
The receiver builds the DNS name from s= and d=, fetches the public
key, recomputes the body hash and the header hash, and checks them against
bh= and b=. If everything matches, the result is
dkim=pass. If anything was changed — a re-written subject line, an appended
footer, a corrupted DNS record — verification fails.
What DKIM protects against — and what it does not
DKIM proves origin and integrity. It stops someone forging mail that claims to be signed by your domain, and it detects tampering in transit. It survives forwarding better than SPF does, because the signature travels inside the message rather than depending on which server delivered it.
It is not encryption: a DKIM-signed message is still readable by anyone who handles it. It also does not, on its own, stop someone signing mail with their own domain while displaying your name in the From line. That gap — checking that the signing domain actually matches the visible From address — is DMARC’s job, which is why the three standards work as a set. Our guide to DKIM vs SPF vs DMARC walks through how they fit together.
Setting DKIM up
How you enable DKIM depends on who sends your mail:
- Hosted providers (Google Workspace, Microsoft 365, and most marketing or transactional platforms) hold the private key for you. You switch signing on in their admin console, and they tell you exactly which TXT or CNAME records to publish at your DNS host.
- Self-hosted servers (Postfix with OpenDKIM or rspamd, Exim, and similar) need you to generate the key pair yourself. Our record generator creates one in your browser and gives you the record to publish; the private key goes into your signing software.
Either way, the checklist is the same: publish the record, wait for DNS to propagate, send a
test message to a mailbox you control, and confirm the header says dkim=pass.
You can verify the published record at any time with our DKIM checker — it
fetches the record, decodes the key, and measures its strength.
Key strength matters
A DKIM signature is only as trustworthy as the key behind it. The current recommendation (RFC 8301) is 2048-bit RSA or stronger. Many older setups still publish 1024-bit keys: they verify, but they are weaker than recommended, and receivers may discount them. If your check comes back with a warning about key length, read our key length guide and plan a rotation — it is a straightforward job when done in the right order.
Common questions
Does DKIM slow mail down?
Not noticeably. Signing adds a few milliseconds per message, and verification is a single DNS lookup plus one signature check — trivial for modern servers.
Do I need DKIM if I already have SPF?
Yes. SPF breaks when mail is forwarded and says nothing about message integrity. Receivers — and DMARC — want both signals. Bulk-sender rules at the large mailbox providers now require both.
How do I find out whether my domain signs mail?
If you know the selector, use the DKIM checker. If you do not, our
selector finder sweeps the names providers commonly use — or
send yourself an email and read the s= tag in the
DKIM-Signature header.