DKIM (DomainKeys Identified Mail) is an email authentication standard defined in RFC 6376. The sending server signs every email with a private key; the receiving server fetches the matching public key from DNS and verifies the signature. A valid signature proves the email came from the claimed domain and was not modified in transit — the foundation of modern email deliverability, alongside SPF and DMARC.
Since February 2024, Gmail and Yahoo require DKIM for anyone sending more than 5,000 emails per day. Without it, your marketing emails go to spam — or bounce entirely. This page covers what DKIM is, how it works, and how to set it up correctly the first time.
What is DKIM?
DKIM is one of three pillars of modern email authentication (alongside SPF and DMARC). It works with public-key cryptography: the sending domain owns a private key that it uses to sign outbound emails; the corresponding public key is published in DNS as a TXT record. Any receiving inbox can look up the public key and verify the signature independently.
A DKIM signature is added as a header to the email, invisible to end users. It typically looks like this:
- v=1 — DKIM version
- a=rsa-sha256 — signing algorithm
- d=example.com — the signing domain
- s=selector1 — the selector, so receivers know which public key to fetch
- bh=… — body hash
- b=… — the actual signature
Email was designed in 1982 with zero authentication. Anyone could set the From address to ceo@yourcompany.com and mail servers would deliver it. DKIM (2007) closed that gap by making sending domains prove ownership of every message using cryptography.
Why DKIM matters for deliverability
DKIM is the single most important lever for inbox placement. Get it right and your open rates lift; get it wrong and campaigns die in spam. Four reasons every email sender cares:
- Gmail and Yahoo require it. Since Feb 2024, both providers reject or spam unauthenticated mail from bulk senders (5K+/day). Enterprise inboxes (Microsoft 365, Zoho) apply similar rules.
- DMARC depends on it. DMARC alignment needs either SPF or DKIM to pass. DKIM is the more reliable of the two because it survives email forwarding.
- Anti-spoofing protection. DKIM makes it much harder for bad actors to impersonate your domain in phishing attacks.
- Reputation building. Consistent DKIM signing across all your streams (marketing, transactional, sales) builds a stronger domain reputation with mailbox providers.
How DKIM actually works
Every DKIM email goes through six steps — three at the sender, three at the receiver.
1. Compose email
2. Server hashes headers + body with private key
3. Adds DKIM-Signature: header and sends
# RECEIVER side
4. Reads d= (domain) and s= (selector) from header
5. Fetches TXT record at selector._domainkey.example.com
6. Verifies signature → PASS or FAIL
Example DNS TXT record
selector1._domainkey.example.com
# Type: TXT
# Value
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN…
…AwEAAQ==
DKIM vs SPF vs DMARC — how the three fit
| Protocol | What it verifies | Where it lives | Survives forwarding? |
|---|---|---|---|
| DKIM | Signature over headers + body | TXT at selector._domainkey | Yes |
| SPF | Sending server IP is authorised | TXT at root domain | No (breaks on forward) |
| DMARC | Alignment between DKIM/SPF and From: | TXT at _dmarc.domain | Follows DKIM/SPF |
| BIMI | Brand logo display (needs DMARC p=quarantine+) | TXT at default._bimi | Yes |
Real DKIM setup examples
Four common setups you will run into, and the pattern each one uses.
1. Google Workspace
Host: google._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIB…
2. Microsoft 365
Uses two CNAME records pointing at Microsoft-hosted keys, so Microsoft can rotate them without you touching DNS.
selector2._domainkey.example.com CNAME selector2-example-com._domainkey.example.onmicrosoft.com
3. SendGrid (marketing / transactional)
SendGrid signs with a unique selector per subuser. You publish three CNAME records — two for DKIM (s1/s2) and one for return-path alignment.
4. Mailchimp / HubSpot
Both give you a CNAME record to publish. Verification usually completes within an hour, and DKIM signing starts on the next send.
DKIM vs SPF — which should you set up first?
Set up both. Modern deliverability requires SPF, DKIM, and DMARC. But if you can only do one first, DKIM is the higher-value move because it survives forwarding and is required for reliable DMARC alignment.
Use DKIM when
- You want signatures that survive email forwarding
- You send from multiple platforms (marketing + transactional + sales)
- You plan to enable a strict DMARC policy
- You send bulk email to Gmail, Yahoo, or Microsoft
- You want to enable BIMI logos in Gmail
Use SPF when
- You need a fast baseline authentication (5-minute setup)
- Sending from a single, known IP or provider
- You want to prevent basic spoofing
- You need lightweight backup authentication for DMARC
- Your sending platform does not support DKIM yet (rare)
7 DKIM best practices
- Use 2048-bit keys. 1024-bit is technically valid but crackable with enough compute. Every major provider now defaults to 2048.
- Rotate keys annually. Rotation limits the blast radius if a private key is ever exposed. Use different selectors (s1/s2) so you can swap without downtime.
- Sign every sending stream. Marketing, transactional, sales tools, ticketing systems — every one needs its own DKIM setup or messages fail alignment.
- Publish only what you use. Remove old selectors from DNS when you leave a provider. Stale keys become attack surface.
- Monitor DKIM with DMARC reports. Aggregate reports (rua) will show which sending sources are passing and failing DKIM.
- Do not modify signed messages downstream. Content filters, appended footers, or list servers can break the body hash and cause DKIM to fail.
- Test before you launch. Send to a mail-tester.com address or check headers in Gmail (Show original → dkim=pass).
Many teams set up DKIM on their primary email server, then start sending marketing through a new ESP without adding that ESP’s DKIM record. The ESP’s emails go out unsigned, DMARC starts failing, and inbox placement collapses. Every sending platform needs its own DKIM.
Common DKIM mistakes to avoid
- Copying the DKIM value with line breaks — DNS providers often mangle multi-line TXT values. Paste as a single string.
- Using weak 1024-bit keys — deprecated by most modern authentication guidance.
- Signing with the wrong domain (d=) — must align with the From: header for DMARC to pass.
- Not enabling signing after DNS publish — the record can be live and the platform still not signing until you flip the switch.
- Leaving old ESPs’ selectors in DNS forever — growing attack surface with no benefit.
How theStacc helps with email authentication
theStacc does not send your email or manage your DNS — DKIM setup stays with you and your ESP. What it does cover is the other half of the funnel those emails point at: planning, writing, and publishing blog content to your site, so the links in your campaigns land on pages worth opening. Fix authentication first, then give the traffic somewhere to go.
Frequently asked questions
DKIM is a way for your email server to sign every message with a hidden signature that receiving inboxes can check. If the signature matches, the receiver knows the email really came from your domain and was not tampered with.
Yes. SPF only checks the sending server IP. DKIM signs the actual email content, so it survives forwarding. Google and Yahoo now require both DKIM and SPF (plus DMARC) for bulk senders.
Generate a key pair in your email service (Google Workspace, Microsoft 365, SendGrid, Mailchimp, etc.), publish the public key as a TXT record at selector._domainkey.yourdomain.com, then enable signing. Most providers give the exact record to paste into DNS.
A selector is a short label that identifies which DKIM public key to use. It appears in the DNS record as selector._domainkey.yourdomain.com. Using different selectors lets you rotate keys or run multiple sending services.
If DKIM verification fails, receivers rely on your DMARC policy. A p=none policy still delivers; p=quarantine sends to spam; p=reject blocks the message outright. Failed DKIM usually points to a broken key, missing selector, or content modified by an intermediate server.
Related glossary terms
Sources
