DKIM is a word you hear very commonly these days when in the context of Email security. Let us try and understand what it means, and how it is beneficial to us.
DomainKeys Identified Mail a.k.a DKIM is a technical standard for email authentication wherein a digitally encrypted signature is added to the email header which is then verified by the receiving email server by using a public key fetched via DNS lookups. It is a protocol that has become essential to combating phishing and email spoofing. Together with SPF, it allows you to associate a domain with your email to validate your email message.
Since February 2024, Google and Yahoo have enforced sender-authentication requirements for bulk senders. Any domain sending more than 5,000 emails a day to Gmail must have DomainKeys Identified Mail and SPF properly configured, alongside a DMARC record.
Without these protocols in place, legitimate mail is much more likely to land in spam or be rejected outright. In 2026, DKIM will be mandatory for any sender who relies on email to reach customers.
A Brief History of DKIM
DKIM was created in the year 2004 by the merger of two different yet similar mechanisms, “Identified Internet Mail” from Cisco and “enhanced DomainKeys” from Yahoo.
This merged specification evolved into a new authentication technique that is defined by the RFC 6376. The “Identified Internet Mail” was about an email authentication method based on the signature, and DomainKeys was all about checking the identity of the sender using DNS and verifying the email integrity.
How Does DKIM Work?
How this works is that sending party adds a unique DKIM signature header to the email (example for such a header can be seen below). Such a header includes two important cryptographic hashes, assigned to tags (the header uses a notation like tag=value delimited by semicolons) like “b” and “bh”.
DKIM-Signature: v=1; a=rsa-sha256; d=mydomain.com; s=s2; c=relaxed/relaxed; i=ian@mydomain.com; t=1579522642; h=subject:from:reply-to:to:date:message-id:list-unsubscribe:content-type: mime-version; bh=R39S4ybFvxWVEnU5LL/Gid3+5s/mxVQNMfzh2CjrCME=; b=nDfDnXmMpjMmp9bOnehWsVkzr/j9W6MEerRgBHXXXcS4ArYorzRGc8PLB/M7W/PpoqkPGqCUvIC yCFDar/plrW7AKyN8egpF3I8PJP3US/9DAr50w3AyH14Cm8+ryb01l97JD45QMaIyJhPdfAFpvlMD S8XX3fZbQtu5sHMK93QjHTlAP6+A80EiK09jZNN3gLJAobC1tmJxJSYUy7Xu98FRF0a+9Rut9pSC/ fV0eTyiPDu0ar4cNgPg3kquxthRh6mHMdaz8sGyaaz0QQxlq2Rv1QNCcFajLKF4P/9w3xX5f1LOWL MRHX1JMUZXYRY+5BX1QCra0QEZZvvlSf0TOg==
In simple words, the sending server signs the message using a private key that only it holds. The receiving server then looks up the matching public key, which the domain owner has published in DNS.
The receiver uses that public key to verify the signature. If the verification succeeds, the receiver knows the message genuinely came from the claimed domain and was not altered in transit.
Understanding DKIM Tags
The mandatory DKIM tags that need to be present in your email header for it to be signed correctly are listed below:
- v: This indicates the version of the signature.
- a: This indicates the algorithm that was used to generate the signature.
- s: This indicates the selector record name used with the domain to locate the public key in DNS.
- h: This is a list of headers that will be used in the signing algorithm to create the hash found in the b= tag. The order specified in the value is important for the generation of the hash.
- b: This is the hash result of the headers listed in the h= tag. This hash is the DKIM signature and is encoded in Base64.
- bh: This is the computed hash of the message body. The value of this is evaluated by the hash algorithm.
- d: This is the sending domain.
When the receiving email server sees this email, the first thing it does is to look up the public key of the sending domain and use that to decrypt both the hashes above. The result is then compared to fresh hashes created against the received mail content. If the two values match, then it passes the DKIM test and proves that the mail has not been modified from its original source.
Key length matters as well. In 2026, a 2048-bit key is the recommended standard, replacing the older 1024-bit keys that are now considered weak and easier to break.
How Can We Test DKIM Records?
There are a few online tools wherein you can test your DKIM records, but before we do that we need to understand what is being fetched here. In the example given above, “mydomain.com” needs to have a subdomain of the form “s2._domainkey,” which stores the value of the DKIM key directly as a “TXT” record or indirectly as “CNAME”.
- Mxtoolbox: https://mxtoolbox.com/dkim.aspx
- Dmarcian: https://dmarcian.com/dkim-inspector/
- Mail tester: https://www.mail-tester.com/spf-dkim-check
- Dmarcanalyzer: https://www.dmarcanalyzer.com/dkim/dkim-check/
After publishing or rotating a DKIM key, always retest the record before sending at volume. A small DNS propagation delay or a mistyped selector can cause every email in a campaign to fail authentication.
DKIM, SPF and DMARC: How They Work Together
DomainKeys Identified Mail does not work alone. It is one piece of a three-part authentication stack that inbox providers now expect every sender to have in place.
SPF authorizes which sending servers are allowed to send mail on behalf of a domain. DKIM signs the message and protects its integrity, proving the content was not altered in transit. DMARC sits on top of both.
It tells receiving servers what to do when SPF or DKIM checks fail, whether to quarantine the message, reject it outright, or let it through, and it provides reporting so domain owners can see who is sending mail using their name.
Heading into 2026, major inbox providers, including Gmail, Yahoo, and Outlook, expect all three protocols to be configured together. A domain with only DKIM and no DMARC policy is still exposed to spoofing, and a domain with SPF but no DKIM loses protection against message tampering. The three protocols are designed to complement one another, not to be used in isolation.
Common DKIM Mistakes (and How to Fix Them)
A handful of recurring mistakes account for most DKIM failures.
A missing or mistyped TXT or CNAME record is the most common issue. Double-check the exact value against what your email provider supplied, since a single missing character breaks the entire signature.
Using the wrong selector causes the receiving server to look in the wrong place for the public key. Confirm the selector in your DNS record exactly matches the selector your mail server signs with.
A key that has not yet propagated through DNS will cause temporary failures. Wait for propagation to complete, then re-test before sending any real campaign.
Third-party senders, such as a marketing platform or CRM, sometimes send on your behalf without their DKIM signature configured. Confirm every tool sending email from your domain has been properly added to your authentication setup.
Keys that are never rotated become a long-term security risk. Treat DKIM keys like passwords and rotate them periodically rather than leaving the same key in place indefinitely.
Conclusion
We have seen how DKIM plays a vital role in Email authentication. It provides the incoming email server with a mechanism to check if the original message was altered.
DomainKeys Identified Mail works best as part of a complete authentication stack. Pairing it with SPF and DMARC, and adding BIMI in 2026 to display your verified brand logo directly in the inbox, gives recipients the strongest possible signal that a message is genuine. SpiceSend includes built-in authentication setup, so your domain is signed correctly from day one without needing to manage DNS records manually.
Frequently Asked Questions
What is DKIM and how does it work?
DomainKeys Identified Mail is an email authentication standard that adds a digital signature to outgoing messages. The sending server signs the message with a private key, and the receiving server retrieves the matching public key from the sender’s DNS records to verify the signature. If the signature checks out, the receiving server confirms the message genuinely came from the claimed domain and was not altered during transit.
What is the difference between DKIM, SPF and DMARC?
SPF authorizes which mail servers are permitted to send on behalf of a domain. DKIM adds a cryptographic signature that verifies message integrity and sender identity. DMARC builds on both by instructing receiving servers how to handle messages that fail SPF or DKIM checks, and it provides reporting visibility. Together, the three protocols form the full authentication stack that major inbox providers now expect.
How do I check if my DKIM record is set up correctly?
Use a dedicated DKIM lookup tool such as MxToolbox, dmarcian’s DKIM Inspector, Mail-Tester, or DmarcAnalyzer. Enter your domain and selector, and the tool will confirm whether a valid public key is published and correctly formatted in your DNS. Always re-test after publishing a new key or rotating an existing one, since a small typo or propagation delay can cause every email to fail authentication.
Is DKIM required for email delivery in 2026?
Yes. Since February 2024, Google and Yahoo have required bulk senders to authenticate with both SPF and DKIM alongside a DMARC record, and Microsoft introduced similar requirements for Outlook, Hotmail, and Live accounts in 2025. In 2026, any domain sending email at meaningful volume without proper DomainKeys Identified Mail configuration faces a significantly higher risk of messages landing in spam or being rejected outright.
