Quick DKIM reference
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every email you send. Receiving servers fetch your public key from DNS and verify that the message was authored by your domain and not altered in transit. Without it, your mail looks unsigned and gets filtered.
| What it is | A public key published in DNS plus a digital signature added to each outbound message header. |
| Where it lives | A TXT record at selector._domainkey.yourdomain.com. Multiple selectors are allowed and encouraged. |
| Algorithm | RSA-SHA256 (default), or Ed25519 (newer, smaller keys). |
| Required by | Gmail, Yahoo, Microsoft, all major ISPs. Mandatory for bulk senders since February 2024. |
| Defined in | RFC 6376, with updates in RFC 8301 (algorithm), RFC 8463 (Ed25519). |
| Tools | Free DKIM Generator, Free DKIM Checker. |
What is a DKIM record?
A DKIM record is a public RSA (or Ed25519) key that you publish at a specific DNS location: selector._domainkey.yourdomain.com. Your mail server holds the matching private key in secret. Every outbound message gets a DKIM-Signature header that contains a cryptographic signature of selected message headers and body, computed with the private key. Recipients fetch your public key from DNS, run the verification, and learn two facts: the message really came from a server that holds your private key, and the signed parts were not modified between sending and delivery.
DKIM is one of the three pillars of modern email authentication, alongside SPF and DMARC. Where SPF authorizes which IP addresses can send, DKIM authenticates the content itself, which is why DKIM survives email forwarding (a forwarder may change the envelope, but the signature stays valid as long as the signed headers and body are untouched).
If you send more than 5,000 messages per day to Gmail or Yahoo addresses, DKIM is mandatory. Even below that threshold, unsigned mail is increasingly throttled or routed to spam. See Google and Yahoo bulk sender rules for the full checklist.
How DKIM works, step by step
The full signing and verification round trip:
- You generate a key pair. A private key, kept on your mail server, and a public key, published at
selector._domainkey.yourdomain.comas a TXT record. - Outbound: your mail server signs each message. It selects which headers to include in the signature (usually From, To, Subject, Date, Message-ID), canonicalizes them, hashes the body, and computes a cryptographic signature using the private key. The result is added as a
DKIM-Signatureheader. - The message travels through SMTP relays and arrives at the recipient mail server.
- The receiver reads the DKIM-Signature header. The header points to the selector and the signing domain (
d=yourdomain.com,s=selector). - The receiver fetches the public key by querying
selector._domainkey.yourdomain.comin DNS. - The receiver recomputes the signature over the same headers and body using the public key. If it matches, DKIM passes. If not (key rotated, body modified, header lost), DKIM fails.
- The result is added to the
Authentication-Resultsheader withdkim=passordkim=fail, and DMARC (if you have one) uses it for alignment.
DKIM record syntax: anatomy of a TXT record
A DKIM TXT record looks like this:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7/lwI...wIDAQABThe mandatory fields are the version (v) and the public key (p). Everything else is optional but commonly set by ESPs.
DKIM tag reference
| Tag | Meaning | Example |
|---|---|---|
v= | Version. Always DKIM1. | v=DKIM1 |
k= | Key type. rsa (default) or ed25519. | k=rsa |
p= | Public key, Base64-encoded. The longest part of the record. | p=MIGfMA0G...wIDAQAB |
t= | Flags. y (testing, signature failures should be tolerant), s (strict, no subdomain delegation). | t=s |
s= | Service type. * (all) or email. | s=email |
h= | Acceptable hash algorithms (rare in public keys). | h=sha256 |
n= | Notes (free text, ignored by verifiers). | n=Generated by Postfix |
The signature in the message header (DKIM-Signature) uses a different set of tags: v (version), a (algorithm), d (signing domain), s (selector), h (signed headers), bh (body hash), b (signature), c (canonicalization), l (body length), t (timestamp), x (expiration). You rarely edit those manually; your mail server generates them.
DKIM setup by provider
Each ESP publishes one or more selectors. You add CNAME records (most common) or TXT records that point at the ESP’s published public keys. Examples below use example.com as the signing domain.
Google Workspace
Selector: google. Record location: google._domainkey.example.com. Generate the key from the Admin Console under Apps, Google Workspace, Gmail, Authenticate email, then publish the TXT record Google gives you.
Microsoft 365
Selectors: selector1 and selector2 (Microsoft rotates between them). Records published as CNAMEs at selector1._domainkey.example.com and selector2._domainkey.example.com, pointing to Microsoft’s DKIM key endpoints. Enable in the Defender admin center under Email and collaboration, Policies, DKIM.
SendGrid
Selectors: s1 and s2. Records published as CNAMEs pointing to s1.domainkey.u.wl.sendgrid.net. SendGrid generates both during sender authentication setup.
Mailchimp
Selector: k1. Record published as CNAME at k1._domainkey.example.com pointing to dkim.mcsv.net.
Mailgun
Selector: mta (configurable). Record published as TXT at mta._domainkey.example.com with the public key Mailgun generates per sending domain.
Amazon SES
Three CNAME records under random selector names like abc123._domainkey.example.com, pointing to abc123.dkim.amazonses.com. SES uses Easy DKIM by default, which auto-generates and rotates the keys.
Postmark
Selector: pm. Record published as TXT at pm._domainkey.example.com.
Brevo (ex-Sendinblue)
Selector: mail. Record published as TXT at mail._domainkey.example.com.
Selectors and key rotation
A selector is just a label that lets you publish multiple DKIM keys on the same domain. s1._domainkey.example.com and s2._domainkey.example.com are independent, and your mail server picks which one to sign with by name. If you send through several ESPs from the same domain, this is the mechanism you use to give each ESP its own key. See our multi-ESP DKIM guide for the full setup pattern.
You should rotate DKIM keys at least once per year. Most ESPs do this automatically using two selectors: while one signs outbound mail, the other is being rotated. Once the new key is published and propagated, signing switches over and the old key can be retired.
If you operate your own mail server (Postfix with OpenDKIM, Exim, Halon), keep the private key file restricted to the signing user (chmod 0600), and avoid storing it in your repository. A leaked private key lets an attacker sign mail as your domain, which DMARC will validate as authentic.
How DKIM fits into DMARC
DMARC requires that the signing domain (the d= tag in the DKIM signature) align with the visible From header domain. Strict alignment requires an exact match; relaxed alignment (the default) allows a parent or subdomain match.
If you send from news@example.com but your ESP signs with d=esp.com, DKIM passes but DMARC alignment fails. Fix: configure DKIM signing with your own domain (most ESPs offer this under names like “branded sending domain,” “custom domain,” or “domain authentication”).
For the full authentication stack, see our Email Delivery Infrastructure guide.
Common DKIM mistakes (and how to avoid them)
- Signing with the ESP’s domain instead of yours. If
d=esp.cominstead ofd=example.com, DKIM passes but DMARC alignment fails. Always enable branded or authenticated sending domains in your ESP. - Forgetting to rotate keys. Old keys sitting in DNS for years are a security risk. Rotate yearly, minimum.
- Publishing a malformed public key. Copy-paste from the ESP console often introduces line breaks. The TXT record must contain a single continuous Base64 string (DNS handles the 255-character split automatically).
- Mixing 1024-bit and 2048-bit keys carelessly. 1024-bit DKIM keys are legacy and vulnerable. RFC 8301 recommends 2048-bit. Some DNS providers truncate longer records, breaking the key. Test after publishing.
- Multiple TXT records at the same selector. Two TXT records at
s1._domainkey.example.comproduce undefined behavior. Use one record per selector. - Body modifications by intermediate servers. Mailing lists or footer-injecting gateways can alter the body and break DKIM. The fix is ARC (Authenticated Received Chain, RFC 8617) on the receiving side.
- Signing too few headers. A signature over From, Subject, and Date only is fragile. Best practice is to also sign To, Cc, Reply-To, Message-ID, Content-Type, and List-Unsubscribe.
- Forgetting subdomains. If you sign mail from
news.example.com, you need a DKIM key atselector._domainkey.news.example.com, not just on the apex. - Testing mode left on (
t=y). Thet=yflag tells verifiers to treat failures leniently. Useful during rollout, but remove it once you are confident DKIM is signing correctly. - Mistaking SPF pass for DKIM pass. They are independent checks. A passing SPF says nothing about DKIM, and vice versa. Both must pass and align for DMARC to validate.
How to test your DKIM record
- Use the free SMTPedia DKIM Checker at smtpedia.com/free-dkim-record-checker. It validates the public key, confirms the selector exists, and inspects tag syntax.
- Send a test email to a Gmail or Outlook account you control. View the full headers and confirm an
Authentication-Resultsline containingdkim=passwith the correctd=value. - Query DNS directly:
You should seedig TXT selector._domainkey.example.com +shortv=DKIM1; k=rsa; p=.... - Watch DMARC aggregate reports for real-world DKIM pass and fail rates by signing source.
DKIM FAQ
Can I publish multiple DKIM keys on the same domain?
Yes, that is the whole point of selectors. Each ESP gets its own selector (e.g. google._domainkey, s1._domainkey, mta._domainkey). They coexist without conflict because each is a distinct DNS name.
What key length should I use for DKIM?
2048 bits is the current standard (RFC 8301). 1024 bits is deprecated and considered weak. If your DNS provider rejects 2048-bit records as too long, check whether they support multi-string TXT records (most do).
Does DKIM survive forwarding?
Usually yes, because DKIM signs the message content, not the envelope. A simple forwarder that does not modify headers or body will preserve the signature. Mailing lists that rewrite the subject line or inject a footer will break DKIM, which is why ARC (RFC 8617) exists.
How often should I rotate DKIM keys?
At least once a year, ideally every 6 months. Use two selectors so you can rotate without downtime: publish the new key, wait for DNS propagation, switch signing to the new selector, then retire the old key.
Why does DKIM pass but DMARC still fail?
DMARC requires DKIM alignment: the signing domain (d= tag) must match the visible From domain. If your ESP signs with its own domain instead of yours, DKIM passes but does not align. Enable branded or custom domain signing in your ESP settings.
My DKIM record is too long. What do I do?
A single DNS string is limited to 255 characters, but a TXT record can contain multiple concatenated strings totaling up to 65,535 characters. Most DNS providers (Cloudflare, Route 53, GoDaddy) handle the split automatically when you paste the full key. If yours does not, you must split the Base64 string manually into chunks under 255 characters.
Final words
DKIM is the cryptographic backbone of modern email authentication. Where SPF says “this IP is allowed,” DKIM says “this message is genuine.” Together with DMARC, they make domain impersonation effectively impossible.
Three habits keep DKIM healthy: rotate keys yearly, sign with your own domain (never your ESP’s), and verify signatures in production by reading your DMARC reports.
Once DKIM is solid, finalize the trio with a DMARC policy. Three records, one weekend of work, a lifetime of inbox placement.
Clean your list before you send.
SMTPing catches what regex misses: disposable addresses, role-based emails, catch-all domains, syntax errors, dead mailboxes and known traps. 13 validation types, 25 free checks daily, no card required.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
