DKIM (DomainKeys Identified Mail) is an email authentication standard, defined in RFC 6376, that attaches a cryptographic signature to every message your domain sends. The receiving mail server looks up your public key in DNS, recomputes the signature over the message body and selected headers, and confirms two things: the mail really came from your domain, and nobody altered it in transit. If you send email from your own domain, DKIM is no longer a nice-to-have. Google and Yahoo have required it from bulk senders since February 2024, and Microsoft began rejecting non-compliant high-volume mail to Outlook.com, Hotmail.com and Live.com on 5 May 2025 (Microsoft Defender for Office 365 blog).
How DKIM actually works
DKIM is a public-key signature scheme wrapped around SMTP. The flow has four steps:
- You generate a key pair. The private key stays on your sending mail server or with your email provider. The public key is published in DNS.
-
Your server signs outbound mail. It hashes the message body plus a chosen list of headers (From, Subject, Date and others), signs that hash with the private key, and inserts the result as a
DKIM-Signature:header. -
The receiver fetches your public key. It reads the domain (
d=) and selector (s=) from the signature header and queries<selector>._domainkey.<domain>for a TXT record. - The receiver verifies. It recomputes the hash and checks it against the signature. A match means the signed parts of the message are authentic and unmodified.
Crucially, DKIM survives forwarding in a way SPF does not. SPF validates the connecting IP address, so it breaks the moment a mailing list or forwarder relays your message. A DKIM signature travels with the message itself, which is why DKIM alignment is usually the more durable half of a DMARC policy.
Anatomy of a DKIM record
A published DKIM record is a DNS TXT record at a selector-specific hostname. Here is a trimmed example for the selector s1 on example.com, published at s1._domainkey.example.com:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
The tags you will meet most often:
| Tag | Where it appears | Meaning |
|---|---|---|
v= |
DNS record | Version, always DKIM1
|
k= |
DNS record | Key type: rsa (default) or ed25519
|
p= |
DNS record | The Base64 public key. An empty p= revokes the key |
t=y |
DNS record | Testing mode. Receivers should not penalise failures |
d= |
Signature header | The signing domain, the one DMARC aligns against |
s= |
Signature header | Selector, so one domain can hold many keys |
h= |
Signature header | The list of headers covered by the signature |
bh= |
Signature header | Hash of the canonicalised body |
x= |
Signature header | Signature expiry, as a Unix timestamp |
One detail trips up almost everyone: a 2048-bit RSA public key is longer than the 255-byte limit for a single DNS character string, so it must be published as multiple quoted strings that the resolver concatenates. Some DNS panels do this silently, others do not, and a mis-chunked key fails verification without any visible error.
How to set up DKIM in five steps
- Generate a 2048-bit RSA key pair, or let your provider generate it. Google Workspace, Microsoft 365, Zoho, Mailgun, SendGrid, Postmark and Amazon SES all issue keys from their admin consoles.
-
Pick a descriptive selector. Use one per sending source, for example
google1,mg-2026a,zoho._domainkey. Never reuse a selector across two systems. -
Publish the TXT record at
<selector>._domainkey.<yourdomain>. Wait for propagation, which usually takes minutes but can take up to the TTL of the parent zone. - Enable signing in the sending platform. Publishing the key without turning on signing is the single most common half-finished DKIM deployment.
-
Verify. Query the record from a terminal with
dig TXT s1._domainkey.example.com +short, then send a test message to a mailbox you control and read theAuthentication-Results:header. You want to seedkim=pass.
Repeat this for every system that sends as your domain: your mail host, your marketing platform, your invoicing tool, your helpdesk. Each one needs its own selector and its own key.
DKIM vs SPF vs DMARC
The three standards are complementary, not alternatives. DKIM proves integrity, SPF authorises the sending path, and DMARC ties either result back to the visible From address and tells receivers what to do on failure.
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Defined in | RFC 7208 | RFC 6376 | RFC 7489 |
| What it validates | Sending IP address | Message signature | Alignment of SPF or DKIM with the From domain |
| Survives forwarding | No | Yes | Depends on DKIM surviving |
| Crypto involved | None | Public-key signature | None |
| DNS records needed | One TXT per domain | One TXT per selector | One TXT at _dmarc
|
| Typical failure cause | Exceeding 10 DNS lookups | Missing or mis-chunked key | Neither mechanism aligned |
| Reporting built in | No | No | Yes, aggregate and forensic |
DKIM remains the least deployed of the three. A February 2026 scan of 5.5 million domains put SPF at 56.0%, DMARC at 30.4% and DKIM at 22.7% (DMARCguard research). The authors note DKIM is likely undercounted, because a scanner can only probe common selectors and cannot discover custom ones.
Key length, rotation, and the replay problem
Use 2048-bit RSA. RFC 8301 deprecated signing keys below 1024 bits, and NIST SP 800-57 treats 2048 bits as the current floor for RSA. 1024-bit keys still verify at most receivers but are on borrowed time. Going to 4096 bits buys little and makes DNS publishing harder.
Rotate on a schedule. RFC 6376 recommends periodic rotation without naming an interval; M3AAWG's best common practices and most operators land on every 6 to 12 months, or quarterly in regulated environments. Rotation is safe if you do it in the right order: publish the new selector, sign with the new key while the old record is still live, confirm passes in your DMARC aggregate reports, then remove the old record.
Understand DKIM replay. In April 2025 a phishing campaign abused a legitimately signed Google message, re-sending it verbatim to new victims so it arrived with a valid dkim=pass from google.com (Red Sift analysis). Nothing about the signature was forged. The attack works because a DKIM signature says nothing about who sent the message or to whom. Two practical mitigations: oversign the headers that matter by listing them in the h= tag more times than they appear, which blocks an attacker from appending a second To: or Subject: header, and set a short signature expiry with the x= tag to shrink the replay window.
Common DKIM failures and what causes them
| Symptom | Likely cause | Fix |
|---|---|---|
dkim=none in headers |
Signing not enabled at the sender | Turn on DKIM in the platform, not just DNS |
dkim=permerror |
Record missing, or p= mis-chunked |
Re-publish as split quoted strings |
dkim=fail on forwarded mail only |
A list or gateway rewrote the body or a signed header | Ask the forwarder to use ARC, or rely on SPF alignment for that path |
| Passes for one system, fails for another | A sending source has no selector of its own | Add a dedicated key per source |
DMARC fails despite dkim=pass
|
The d= domain does not align with the From domain |
Sign with your own domain, not the provider's |
Frequently asked questions
Does DKIM encrypt my email?
No. DKIM signs, it does not encrypt. Anyone who intercepts the message can still read it. Transport encryption is TLS, and content encryption is S/MIME or PGP.
Can I have more than one DKIM record?
Yes, and you usually should. Each selector is a separate record, so one domain can carry a key for every sending platform you use.
Does DKIM alone stop spoofing?
No. A valid signature proves a message was signed by some domain, but receivers only act on that if a DMARC policy tells them to. DKIM plus DMARC at p=quarantine or p=reject is what actually blocks spoofed mail.
What happens when I delete a DKIM key?
Any message still in flight that was signed with it will fail verification. To revoke deliberately, publish the record with an empty p= rather than deleting it outright, so receivers see an explicit revocation.
Is Ed25519 ready to use?
Ed25519 signing is standardised in RFC 8463 and produces far shorter DNS records, but verifier support is still uneven. Dual-sign with RSA-2048 alongside it rather than switching outright.
Related guides
- How to Set Up DMARC, Step by Step
- SPF Record Checker: How to Test, Read, and Fix Your SPF Record
- DNS Security Configuration: SPF, DMARC, DNSSEC and CAA Explained
Check your DKIM in 60 seconds
Most broken DKIM setups look fine from the admin console and only reveal themselves in the headers of delivered mail. FortifyNet's free scan reads your live DNS and reports on SPF, DKIM and DMARC together, alongside your SSL/TLS configuration, security headers and dark-web exposure. No signup required. Run a free scan of your domain and see what receivers actually see.
Originally published at fortifynet.com/blog/what-is-dkim. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.
Top comments (0)