What Is DKIM?
Definition
DKIM (DomainKeys Identified Mail) is an email authentication method that adds a digital signature to every message you send. The receiving server checks that signature against a public key published in your DNS, which proves the message came from your domain and was not changed on the way.
DKIM proves who signed a message, not that the message is wanted. A spammer with their own domain can produce a perfectly valid signature, so a pass builds reputation for a domain rather than granting trust on its own.
Why DKIM Matters
Without a signature, your mail has no proof of origin once it leaves your server. Forwarding, a common B2B habit when a contact passes your email to a colleague, breaks SPF every time, and a signature is the only check that survives the extra hop.
Gmail now enforces this. Since February 2024, unauthenticated mail can be marked as spam or rejected with a 5.7.26 error, and bulk senders need all three checks in place.
Gmail rule above 5,000 messages a day
SPF + DKIM + DMARC, with the From domain aligned to SPF or DKIM
How DKIM Signing Works
Two keys do the work. Your sending server keeps a private key, and your DNS publishes the matching public key.
- Sign. Your server hashes the body and a chosen set of headers, then signs that hash with the private key.
- Attach. The signature travels in a
DKIM-Signatureheader, which names your domain and a selector. - Look up. The receiver joins the selector and domain into a DNS name and fetches the public key from there.
- Verify. It recomputes the hashes. If they match, the check passes. If one byte of a signed part changed, it fails.
Nothing is encrypted. Anyone can read a signed message; the signature only shows it was not altered.
How To Read a DKIM-Signature Header
Open any message you sent, show the original, and find the header. It looks like this:
Example DKIM-Signature header
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yourdomain.com; s=s2027; h=from:to:subject:date; bh=...; b=...
Why it works: every tag answers one question a receiver asks, so reading them in order tells you exactly what was signed and where the key lives.
| Tag | What it says | What to check |
|---|---|---|
| a= | Signing algorithm | Must be rsa-sha256 or ed25519-sha256, never rsa-sha1 |
| d= | Signing domain | Should be your domain, not your sending tool’s |
| s= | Selector | Tells you which DNS record holds the key |
| h= | Signed headers | From must be in the list |
| c= | Canonicalization | relaxed/relaxed survives small formatting changes |
| l= | Body length signed | Best left out entirely |
The l= tag deserves a warning. It tells receivers to verify only the first part of the body, so anything appended afterwards still passes. RFC 6376 lists this as a known misuse risk, and most senders have no reason to set it.
DKIM Key Length and Selectors
Use a 2048-Bit Key
RFC 8301 says signers “MUST use RSA keys of at least 1024 bits” and “SHOULD use RSA keys of at least 2048 bits”. It also retired SHA-1: “rsa-sha1 MUST NOT be used for signing or verifying”.
Google sets the same floor for mail to personal Gmail accounts, a key of 1024 bits or longer, and recommends 2048 bits where your DNS host supports it.
Split Long Keys Correctly
A 2048-bit public key is longer than the 255 characters one DNS text string can hold. It has to be stored as two or more quoted strings inside the same TXT record, which receivers join back together.
Some DNS panels split it for you and some do not. A key pasted as one long string, or broken across two separate records, is the most common reason a fresh setup fails on day one.
Rotate With a New Selector
Selectors let you keep several public keys live at once. To rotate, publish a new key under a new selector, switch signing to it, and remove the old record a week or two later so mail still in transit verifies.
DKIM vs SPF vs DMARC
The three are often lumped together, but each checks a different thing and fails in a different situation.
| DKIM | SPF | DMARC | |
|---|---|---|---|
| Checks | A signature on the message | The sending IP | That SPF or DKIM aligns with From |
| Domain checked | d= in the signature | Envelope sender (Return-Path) | The visible From domain |
| Survives forwarding | Usually | No | If DKIM survives |
| Breaks when | Signed content is edited | Mail is forwarded | Neither aligns |
That forwarding row is why signing matters most. When a message is forwarded, the new hop sends from an IP your SPF never listed, and only the signature can still carry your domain through.
DKIM Alignment and Cold Email Tools
A passing signature is not enough on its own. DMARC also asks whether the signing domain matches the domain in the From line, which is called alignment.
Many sending platforms sign with their own domain by default, such as a d= belonging to the platform. That signature verifies and still fails alignment, because it proves nothing about your domain.
Under RFC 7489, relaxed alignment accepts a subdomain, so d=mail.yourdomain.com aligns with mail from yourdomain.com. Strict alignment needs an exact match. Check the custom signing setting in every tool you send from, because the default is usually the one that fails.
This matters more since February 2024. Google now requires anyone sending more than 5,000 messages a day to Gmail to set up SPF, DKIM and DMARC, with From aligned to one of them, which is why authentication sits at the base of cold email deliverability.
Common DKIM Failures and Fixes
| Failure | Why it happens | Fix |
|---|---|---|
| No key found | Wrong selector, or record not yet published | Match s= to the DNS name exactly |
| Key syntax error | 2048-bit key pasted as one string | Split into quoted strings in one record |
| Body hash mismatch | A gateway or footer tool edited the body | Sign after the last system that edits mail |
| Passes but not aligned | Tool signs with its own domain | Turn on custom DKIM for your domain |
| Fails after list delivery | Mailing list changed subject or body | Expected; ARC helps receivers judge it |
Bottom Line
DKIM signs each message with a key only you hold, so receivers can confirm it came from your domain and arrived unchanged.
Use a 2048-bit RSA key, store it as split strings in one TXT record, and rotate it with a new selector. Most of all, make sure every tool you send from signs with your own domain. A pass from someone else’s domain does nothing for your reputation or your DMARC result.
FAQs
1- What does DKIM stand for?
DomainKeys Identified Mail. It is defined in RFC 6376 and combines two earlier systems, Yahoo’s DomainKeys and Cisco’s Identified Internet Mail.
2- Is DKIM required to send to Gmail?
Google requires all senders to use SPF or DKIM. Above 5,000 messages a day to Gmail accounts, it requires both, plus DMARC with From aligned to one of them.
3- What DKIM key length should I use?
2048 bits. RFC 8301 sets 1024 bits as the minimum and recommends 2048, and Google recommends 2048 where your DNS host supports it.
4- Can I have more than one DKIM record?
Yes. Each record sits under its own selector, so every tool you send from can have its own key, and a message can even carry more than one signature.
5- Why does DKIM pass but DMARC fail?
Because the message was signed with a domain that does not match your From domain. Set up custom DKIM in your sending tool so the d= value is your own domain or a subdomain of it.
6- How do I check if DKIM is working?
Send a message to a Gmail address, open it, and choose Show original. The header summary shows DKIM as PASS or FAIL along with the signing domain.
7- Does DKIM stop my email going to spam?
No. It proves the message is really from you, which lets your domain build a reputation. Whether mail reaches the inbox then depends on that reputation, complaints and engagement.