DKIM
DKIM signs outgoing mail with a private key and publishes the matching public key in DNS, under a label called a selector. A receiving server fetches the key, checks the signature, and learns that the message was not altered on the way and really came from a sender your domain authorized. It survives forwarding, which is why it matters more than SPF alone.
At a glance
- Category
- Domain authentication
- Lives in
- A TXT record at <selector>._domainkey.<domain>
- Adds
- A DKIM-Signature header on every message
- Checked by
- The receiving mail server, on delivery
- Key length
- 2048 bits — RFC 8301 raised the floor from 1024
- Specified in
- RFC 6376
How it works
Your sending service holds a private key and adds a signature header to every message. The header names the domain, the selector and the list of headers the signature covers. A receiving server reads the selector, looks up that selector under the _domainkey label of the domain, and finds the public key in a TXT record. It then recomputes the hash over the signed headers and the body and compares the two. If they agree, the message arrived exactly as it was signed, and by a sender holding your key.
Why it matters
A signature that verifies is the strongest claim your domain can make about a message, and it is the claim receiving servers weigh most heavily. It survives a forwarding rule, because the signature travels inside the message rather than depending on which server connected. DMARC needs it too: a DMARC policy passes only when DKIM or SPF verifies and the verified domain lines up with the From address a reader actually sees.
Example
A domain publishes a TXT record at rasket._domainkey.example.com whose value begins with a version tag, a key type and the public key itself. Mail from example.com then carries a signature header naming the domain and the selector rasket. A receiving server fetches that record, verifies the signature and records a pass. Rotating the key means publishing a second record under a new selector, signing with it, and removing the old record only once nothing still in flight refers to it.
Common mistakes
- 01Pasting the record with the quotes or line breaks a DNS panel inserted, so the key no longer parses.
- 02Signing with a 1024-bit key because a panel defaulted to one, when RFC 8301 raised the floor to 2048.
- 03Rotating the key and deleting the old selector on the same day, so mail already in flight fails to verify.
In Rasket
Each domain gets its own 2048-bit key, published as one TXT record under the selector rasket._domainkey. Domains
Related terms
Frequently asked questions
Does DKIM stop someone spoofing my domain?
On its own, no. It proves that a signed message really was signed by your domain, but it says nothing about mail that carries no signature at all. DMARC is the part that tells receiving servers what to do with unsigned mail claiming to be from you.
How long should a DKIM key be?
Publish 2048 bits. RFC 8301 raised the floor from 1024, and every large mailbox provider verifies a 2048-bit key. Some DNS panels split the record across two strings, which is normal and resolves correctly.
Can one domain have more than one key?
Yes. Each key lives under its own selector, so a domain can sign with several services at once and rotate without a gap. A receiving server only looks up the selector named in the signature it is checking.
Does DKIM survive forwarding?
Usually. The signature covers the message rather than the connection, so a plain forward still verifies. A mailing list that rewrites the subject or appends a footer breaks the body hash, which is the problem ARC was designed to describe.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.