What is DKIM and Why It Matters in 2026
DKIM (DomainKeys Identified Mail) is an email authentication standard defined in RFC 6376 that lets a sending domain cryptographically sign outgoing messages. The receiver pulls the matching public key from DNS, recomputes the signature, and confirms the message was authorised by the domain owner and was not altered in transit. Without DKIM, a spoofer can forge your From: address, hurt your sender reputation, and quietly reroute replies to look-alike domains — a problem most teams only notice after deliverability collapses.
In 2026, DKIM is no longer optional. Gmail and Yahoo's bulk-sender rules — enforced from February 2024 and tightened through 2025 — require any domain sending more than 5,000 messages per day to publish valid SPF, DKIM, and DMARC. Microsoft 365 announced equivalent enforcement for high-volume senders. Failing DKIM no longer just lowers your inbox rate; it triggers hard rejects, dmarc=fail reports, and in many cases removal from the recipient's allow-list. Validating DKIM weekly is the cheapest deliverability insurance you can buy.
How DKIM Works — Public/Private Key Cryptography
DKIM is built on standard asymmetric cryptography. When you set up DKIM your mail platform generates an RSA key pair: a private key it keeps on the sending server and a public key you publish in DNS. Every outbound message is hashed (body + selected headers), the hash is encrypted with the private key, and the result is attached as a DKIM-Signature header. The receiver fetches your public key from DNS, decrypts the signature, recomputes the hash from the message it received, and compares the two. If they match, DKIM passes; if they do not, the signature is broken and the message is treated as suspicious.
The DKIM-Signature header carries the metadata receivers need to verify: v= (version), a= (algorithm, normally rsa-sha256), d= (signing domain), s= (selector), c= (canonicalisation, normally relaxed/relaxed), h= (signed headers), bh= (body hash) and b= (the signature). Together these tell the receiver exactly which DNS record to fetch and which bytes were covered.
Example DKIM-Signature header:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=google;
h=from:to:subject:date:message-id;
bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
b=KX5vRn3...truncated...What is a DKIM Selector?
A DKIM selector is a short label that lets a single domain publish multiple DKIM keys at the same time. Receivers find the public key by combining the selector and the signing domain into a DNS name in the form selector._domainkey.domain.com. For example, Google Workspace uses google._domainkey.example.com, while a Mailgun-signed message looks for k1._domainkey.example.com. Selectors are critical because they let you rotate keys, run different sending platforms in parallel (transactional, marketing, sales), and stage new keys before retiring old ones — all without ever having two records collide. There is no wildcard or fallback at _domainkey.domain.com itself; the selector is mandatory.
Example DNS record format:
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."5 Common DKIM Errors and How to Fix Them
DNS lookup returns nothing
The receiver queried selector._domainkey.yourdomain.com and got NXDOMAIN. This is the most common DKIM failure. Causes: the TXT record was never published, it was published under the wrong selector, or it was added at the apex (yourdomain.com) instead of at the selector subdomain. Fix it by re-publishing the exact name your provider gave you (e.g. google._domainkey) as a TXT record and verifying it propagated with dig TXT selector._domainkey.yourdomain.com or by re-running this checker. Allow up to 48 hours for global propagation.
Public key invalid
DNS returns a record but the p= value is malformed, truncated, or rejected by the receiver. The most frequent cause is a 2048-bit key that was split across multiple TXT strings and reassembled incorrectly — many DNS UIs add stray quotes, spaces, or line breaks. Fix it by copying the public key exactly as your mail platform exported it, pasting it as a single TXT value (most providers auto-split at the 255-byte boundary), and confirming the record contains v=DKIM1; k=rsa; p=BASE64KEY with no whitespace inside the base64 block.
Body hash mismatch
DKIM signed bh=ABC but the receiver computed bh=XYZ from the body it received, so verification fails. This means something modified the message after signing. Common culprits: a downstream gateway (anti-virus, DLP, mailing list) rewrites links or adds a footer, an SMTP relay re-encodes line endings, or a forwarder strips attachments. Fix it by signing with relaxed/relaxed canonicalisation (tolerates whitespace changes), removing the rewriting middleware, or — for mailing lists — implementing ARC so the original DKIM is preserved across hops.
Signature verification failed
The body hash matched but the cryptographic signature did not verify against the public key. Causes: the signing server used a private key that no longer matches the published public key (common after a key rotation where DNS was updated but the mail server cache was not), the public key in DNS was edited and corrupted, or the signing algorithm in a= does not match the key type. Fix it by re-exporting the public key from the sending platform, republishing it verbatim, and restarting the mail service so it reloads its private key.
Selector not found / wrong
Your mail server is signing with selector s1 but DNS only publishes s2, or you migrated providers and the old selector was retired. Fix it by checking the s= tag in the DKIM-Signature header of a real outbound email (most clients let you view full headers), confirming a TXT record exists at exactly that selector, and removing any stale selectors that no longer have a matching private key — old selectors with empty p= values cause hard fails.
Step-by-Step DKIM Setup
- 1
Choose a key length (1024 vs 2048 bit)
Always pick 2048-bit RSA in 2026. 1024-bit keys are still accepted by most receivers but Gmail, Yahoo, and Microsoft now actively flag them as weak in DMARC reports, and security teams routinely fail audits that find 1024-bit DKIM in production. The only reason to drop to 1024 is a legacy DNS provider that cannot store a TXT record over 255 bytes — and even those almost all support multi-string TXT splitting today. 2048-bit keys add roughly two milliseconds to signing time, which is negligible for any production mail server.
- 2
Generate the key pair
Most platforms generate keys for you — Google Workspace, Microsoft 365, Mailgun, SendGrid, Postmark, and Amazon SES all expose a one-click DKIM setup page that produces both halves and shows you the public key to publish. If you are running your own server (Postfix + OpenDKIM, Exim, or Haraka), use opendkim-genkey -b 2048 -d yourdomain.com -s s1 which writes s1.private (keep secret) and s1.txt (publish). Never reuse a key across domains or platforms.
- 3
Add the public key as a TXT record
Create a TXT record at selector._domainkey.yourdomain.com — for example s1._domainkey.example.com — with the value v=DKIM1; k=rsa; p=MIIBIjANBgkq... pasted from the .txt file your generator produced. Many DNS providers will auto-split the value into 255-byte chunks; that is fine, receivers reassemble them. Set TTL to 3600 seconds while testing and raise it to 86400 once the record is stable. Do not include the surrounding quotes from the generator output as part of the value.
- 4
Configure your email service to sign with the private key
On hosted platforms this is automatic once you publish the DNS record and click Verify. On self-hosted servers, point your milter (OpenDKIM, Rspamd) at the .private file, set the selector to match the DNS record, and restart the mail process. Send a test message to a Gmail address and view its raw source — you should see Authentication-Results: dkim=pass header.d=yourdomain.com. If you see dkim=none, the server is not signing yet; if dkim=fail, the keys do not match.
- 5
Test with a free DKIM checker
Use this DKIM Checker to confirm DNS publication, then send a real test message to mail-tester.com or a Gmail account you control and inspect the headers. Expected: Authentication-Results shows dkim=pass and the selector matches your published record. Re-test after every key rotation, every new sending platform, and at minimum once per quarter. Add the check to your monitoring tool so a silent DKIM failure cannot take down deliverability for weeks.
Common DKIM Selectors by Provider
Different email platforms each pick their own selector convention. Knowing the convention makes troubleshooting much faster — if you receive a message from Google Workspace and DKIM is broken, you already know to look up google._domainkey before scanning fifty alternatives. Below are the selectors used by the major providers in 2026:
Google Workspace — google._domainkey.yourdomain.comMailgun — k1._domainkey.yourdomain.com (sometimes mta._domainkey)SendGrid — s1._domainkey.yourdomain.com and s2._domainkey.yourdomain.com (CNAME-based)Mailchimp — k1._domainkey.yourdomain.com and k2._domainkey.yourdomain.comMicrosoft 365 — selector1._domainkey.yourdomain.com and selector2._domainkey.yourdomain.comPostmark — pm._domainkey.yourdomain.com (or 20XXXXXXX.pm._domainkey)Amazon SES — Custom random selectors like abc123._domainkey.yourdomain.com (CNAME-based)Mandrill (by Mailchimp) — mandrill._domainkey.yourdomain.comConstant Contact — ctct1._domainkey.yourdomain.com and ctct2._domainkey.yourdomain.comConvertKit — ck._domainkey.yourdomain.comMailjet — mailjet._domainkey.yourdomain.comBrevo (formerly Sendinblue) — mail._domainkey.yourdomain.com
Nova Uptime's DKIM Checker auto-scans all of the above selectors plus 38 more in parallel, so you do not need to know in advance which one your provider uses.
Gmail and Yahoo 2026 Requirements
Since February 2024, Gmail and Yahoo enforce stricter authentication on any domain sending more than 5,000 messages per day to their users. The rules: every message must be signed with a valid DKIM record (2048-bit recommended), SPF must align with the From: domain, and a DMARC policy must be published — at minimum p=none — with a reachable rua= reporting address. Through 2025 and into 2026, both providers have lowered the volume threshold and started rejecting messages outright (5.7.26) instead of routing them to spam. Microsoft 365 began equivalent enforcement in May 2025. The practical effect: a single broken DKIM record now causes hard bounces, not just inbox placement issues, and recovery takes days because DMARC reports lag by 24 hours. Continuous monitoring is no longer optional.