What is DKIM? How Email Signatures Prove Your Messages Are Genuine

Reading time: 11 minutes
Last updated: March 2026
Written for: IT professionals, security analysts, engineers, students, and anyone who wants to understand how email authentication actually works under the hood

Imagine you receive a letter in the post. The envelope has a wax seal on the back. You recognise the seal as belonging to someone you trust. You know two things before you even open the letter: it genuinely came from that person, and nobody has tampered with it since it was sent.

DKIM does exactly this for email. It is a cryptographic seal that travels with every message, allowing receiving mail servers to verify that the email genuinely came from the claimed domain and that nothing inside it was changed in transit.

Where SPF asks "did this email come from an authorised server?", DKIM asks something deeper: "can we prove this message is authentic and untampered?" Those are two different questions, and both matter.

What is DKIM?

DKIM stands for DomainKeys Identified Mail. It is an email authentication standard that uses public key cryptography to attach a verifiable digital signature to outgoing emails.

When you send an email, your mail server signs it using a private cryptographic key that only your organisation holds. The signature is embedded invisibly in the email's headers. When the email arrives at its destination, the receiving server retrieves your public key from DNS and uses it to verify that the signature is genuine.

If the signature is valid, the email passed DKIM. It means two things: the email was sent by a server that holds your private key, and nothing in the message was altered between sending and receiving.

If the signature is invalid or missing, the email fails DKIM. Something is wrong, either it was not sent by you, or it was tampered with along the way.

DKIM was first published as RFC 4871 in 2007, building on earlier work from DomainKeys (Yahoo) and Identified Internet Mail (Cisco). It has since become one of the three core email authentication protocols alongside SPF and DMARC.

Why DKIM Exists: The Problem it Solves

SPF, which we covered in the previous blog, verifies whether an email came from an authorised sending server. That is useful, but it leaves a significant gap: SPF says nothing about whether the email was tampered with after it left that server.

Think about what can happen to an email in transit. Messages pass through multiple servers, sometimes dozens, between sender and recipient. Any one of those servers could in theory:

• Modify the content of the email
• Change a payment account number in an invoice
• Alter a link in the body to point somewhere malicious
• Re-send a previously legitimate email with modified content

SPF cannot detect any of this because SPF only checks the sending server at the moment of dispatch. Once the email leaves, SPF has done its job. DKIM's job begins after that.

DKIM also solves a problem that SPF cannot touch at all: email forwarding. When an email is forwarded, the forwarding server re-sends it from its own IP address, which breaks the SPF check because that IP is not on the original sender's approved list. DKIM's cryptographic signature travels intact through forwarding, which is why it handles this scenario where SPF fails.

There is also a subtler problem DKIM addresses. Without it, an attacker who intercepts legitimate email traffic could modify messages and re-send them. The recipient would have no way of knowing the message had been altered. DKIM makes this kind of tampering detectable.

How DKIM Works: The Wax Seal Explained

The wax seal analogy holds up well here, so let us use it properly.

In the old days, when a noble sent a letter, they would fold it, drip hot wax on the fold, and press their signet ring into the wax before it hardened. The recipient could see two things: the unique pattern of the seal proved who sent it, and if the wax was broken or missing, someone had opened the letter in transit.

DKIM works on the same principle, but with mathematics instead of wax.

Your private key is the signet ring. It is unique to your organisation and kept secret. Only your mail server has it. When you send an email, your server uses this key to generate a unique cryptographic signature based on the content of the message. Change even a single character of the email and the signature changes completely.

Your public key is the pattern on the seal. Anyone can see it. It is published in your DNS records. Receiving servers use it to verify that your signature is genuine.

The DKIM signature in the email header is the wax seal itself. It travels with the email. The receiving server checks it against your public key. If it matches, the seal is intact and the email is authentic. If it does not match, the seal is broken and something is wrong.

The mathematical relationship between the public and private key is what makes this work. Data signed with a private key can only be verified with the corresponding public key. You cannot fake a valid signature without the private key. And you cannot reverse-engineer the private key from the public key.

How DKIM Works: Step by Step

Step 1: You generate a DKIM key pair

You generate two mathematically linked keys: a private key and a public key. Your mail provider (Google Workspace, Microsoft 365, or your own mail server) typically handles this for you through a setup wizard. The private key is stored securely on your mail server. You never share it.

Step 2: You publish your public key in DNS

The public key is published as a TXT record in your domain's DNS, under a specific subdomain called a selector. A selector is just a label that identifies which key is being used. For example:

1google._domainkey.yourcompany.com

The google part is the selector. _domainkey is a standard identifier that tells DNS this is a DKIM record. yourcompany.com is your domain.

The full DNS record looks something like this:

1google._domainkey.yourcompany.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb..."

The long string after p= is your public key. It looks like gibberish but it is a mathematically meaningful string that receiving servers use to verify your signatures.

Step 3: Your mail server signs every outgoing email

Every time an email leaves your mail server, the server uses your private key to generate a digital signature. The signature is calculated from specific parts of the email, typically the message body and selected headers like From, To, Subject and Date.

This signature is added to the email as a DKIM-Signature header. It looks something like this:

1DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
2  d=yourcompany.com; s=google;
3  h=from:to:subject:date:message-id;
4  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
5  b=ABC123...very long string...XYZ789

Breaking this down:

• d=yourcompany.com is the signing domain
• s=google is the selector, telling the receiving server where to find the public key
• h= lists the headers that were included in the signature
• bh= is a hash of the message body
• b= is the actual signature

Step 4: The receiving server verifies the signature

When the email arrives, the receiving server reads the DKIM-Signature header and:

1. Extracts the selector (s=google) and domain (d=yourcompany.com)
2. Looks up the public key at google._domainkey.yourcompany.com in DNS
3. Uses the public key to verify the signature against the email content
4. If the verification succeeds, DKIM passes. If it fails, DKIM fails.

The entire process happens automatically, in milliseconds, completely invisible to both sender and recipient.

What DKIM Actually Signs

This is an important detail that most explanations skip.

DKIM does not sign the entire email. It signs a selected set of headers and the message body. The headers included in the signature are listed in the h= field of the DKIM-Signature header.

Why does this matter? Because some headers, particularly those added by mail servers during transit (routing information, delivery timestamps), legitimately change as the email travels. Signing those would cause DKIM to fail on every forwarded or relayed email. So DKIM is designed to sign the parts that should not change: the content, the sender, the recipient, the subject.

The body hash (bh=) is a separate digest of the message body. If even a single character of the body changes after signing, the body hash will not match and DKIM will fail.

There are two canonicalization modes that control how strictly the signature handles minor formatting changes that mail servers sometimes make:

relaxed: Minor whitespace changes, header field name casing, and line folding are tolerated. This is the most commonly used mode and is what most deployments use.

simple: No changes whatsoever are permitted. Any modification, even insignificant whitespace, will break the signature. This mode is rarely used in practice because too many mail servers make minor formatting adjustments that are not meaningful but would break a strict signature.

What DKIM Selectors Are and Why They Matter

The selector is a label that tells receiving servers which public key to use for verification. You can have multiple DKIM keys active at the same time, each with a different selector.

This is more useful than it might sound at first.

Multiple sending services: If you use both Google Workspace and SendGrid to send email from your domain, you can have separate DKIM keys for each, identified by different selectors. This lets each service sign its own emails independently.

Key rotation: When you need to replace an old DKIM key with a new one (which is good security practice), you can publish the new key under a new selector and start signing with it before removing the old one. This prevents a gap in email authentication during the transition.

Identifying the source: If a DKIM signature fails on an email, the selector tells you which key was supposed to sign it, which helps narrow down where the problem is.

Revocation: If a private key is compromised, you simply remove the corresponding public key from DNS. Any email signed with that key will immediately fail DKIM verification. It is a clean revocation mechanism.

Reading a DKIM Result in Email Headers

You can see DKIM results in the authentication headers of any email you receive. In Gmail, click the three-dot menu and select "Show original".

A passing result looks like this:

1Authentication-Results: mx.google.com;
2   dkim=pass header.i=@example.com header.s=google header.b=ABCdef12

A failing result looks like this:

1Authentication-Results: mx.google.com;
2   dkim=fail (bad signature) header.i=@example.com

Or if there is no DKIM signature at all:

1Authentication-Results: mx.google.com;
2   dkim=none

The header.i= field shows the signing identity, which is the domain that signed the email. The header.s= field shows the selector used. The header.b= field shows the first few characters of the signature itself, useful for matching up with the full DKIM-Signature header.

Getting comfortable reading these results is a useful skill. When an email lands in your suspicious folder and you want to understand why, the authentication headers tell the whole story.

What DKIM Protects Against

Email tampering in transit
This is DKIM's primary purpose. If anyone modifies the email body or signed headers after the message was sent, the signature becomes invalid. The receiving server will know something has been changed. An attacker who intercepts an invoice email and changes the bank account number, for example, will break the DKIM signature in the process.

Replay attacks with modified content
An attacker who captures a legitimate signed email and tries to re-send it with modified content will break the signature. The body hash will not match.

Impersonation from servers lacking your private key
An attacker cannot generate a valid DKIM signature for your domain without your private key. Even if they send from a server that passes SPF for their own domain, they cannot fake your DKIM signature. This adds a second, independent layer of verification.

Phishing through compromised relay servers
If an attacker gains access to a legitimate relay or mail server but not to your private signing key, any email they send through that server for your domain will lack a valid DKIM signature (or will have no DKIM at all), making it detectable.

Where DKIM Falls Short

DKIM is powerful but it is not complete on its own. Understanding what it does not do is just as important.

DKIM does not verify the visible From address
This is the same blind spot that SPF has, approached from a different angle. DKIM verifies that the email was signed by the domain in the d= field of the DKIM-Signature header. But it does not verify that this domain matches the visible From address your recipient sees.

An attacker can sign an email with valid DKIM for their own domain, attacker.com, while displaying ceo@yourcompany.com in the From header. DKIM would pass for attacker.com. Your recipient would see your CEO's address. The alignment check between DKIM and the visible From address is what DMARC handles.

DKIM does not stop phishing from legitimately signed domains
If an attacker sets up their own domain with valid DKIM, every email they send will pass DKIM for their domain. DKIM says nothing about whether the domain itself is trustworthy, only that the email genuinely came from it.

DKIM does not inspect email content for threats
A perfectly signed email can still contain a malicious link. DKIM proves authenticity and integrity of the message. It says nothing about whether the content is safe. A signed invoice with a malicious payment link is still a threat.

DKIM does not prevent account compromise
If an attacker gains access to a legitimate email account within your domain, they send from a server that holds your private key. DKIM passes. There is nothing for DKIM to flag because the email genuinely was signed by your server.

Common DKIM Mistakes

Not enabling DKIM for your custom domain
Microsoft 365 and Google Workspace set up DKIM automatically for their own subdomains but not for your custom domain. Many organisations assume DKIM is configured when it is not. Always verify this explicitly for your actual domain.

Never rotating DKIM keys
Most security standards recommend rotating cryptographic keys periodically. A DKIM key that has been in use for years is a higher-value target if it ever gets compromised. Rotating annually is a reasonable practice. Use the selector system to rotate without disruption.

Deleting old DNS records before updating
If you remove an old DKIM DNS record before all emails signed with that key have been delivered or before you have confirmed your new key is working, you will break DKIM for emails in transit. Always publish the new key first, transition to signing with it, then remove the old one.

Using too short a key length
The older 1024-bit RSA keys are now considered weak by modern standards. Use 2048-bit keys at minimum. Most mail providers default to 2048-bit but it is worth confirming.

Not testing after setup
Always verify your DKIM configuration after setting it up. Tools like MXToolbox, mail-tester.com, or Google's Email Markup Tester will confirm whether your emails are being signed correctly and whether the DNS record is reachable.

How to Check Your DKIM Configuration

Step 1: Find your selector
Your email provider's documentation will tell you your selector. For Google Workspace it is typically google. For Microsoft 365 it varies and is usually found in the Microsoft 365 admin centre under Defender, then Email and Collaboration settings.

Step 2: Look up your DKIM DNS record
Use MXToolbox at mxtoolbox.com/dkim.aspx. Enter your domain and selector. If a valid DKIM record is returned with a public key, DKIM is configured. If you get "DKIM record not found", it is not set up.

You can also use the command line:

1dig TXT google._domainkey.yourdomain.com

Replace google with your actual selector.

Step 3: Send a test email and check the headers
Send an email to a Gmail address and check the authentication headers using "Show original". You should see dkim=pass in the Authentication-Results header. If you see dkim=none or dkim=fail, there is a problem with your configuration.

DKIM and SPF Together: Why You Need Both

SPF and DKIM solve different problems and they complement each other directly.

SPF verifies the sending server. It answers: did this email come from an IP address we authorised? But SPF breaks when email is forwarded, because the forwarding server sends from its own IP.

DKIM verifies message authenticity. It answers: was this email genuinely signed by the claimed domain and has it been altered? DKIM travels intact through forwarding, making it more robust in that scenario.

But DKIM alone still does not verify the visible From address. And SPF alone still does not detect tampering.

The two protocols plug each other's gaps in meaningful ways. Organisations that run both have significantly stronger email authentication than those running either one alone.

Even together, though, SPF and DKIM leave one important gap open: neither of them enforces alignment between their authentication results and the visible From address your recipients see. That is the job of DMARC, which builds on top of both.

Interview Questions on DKIM

Q: What is DKIM and what problem does it solve?
DKIM is an email authentication standard that uses public key cryptography to attach a digital signature to outgoing emails. It solves two problems: verifying that an email was genuinely sent by the claimed domain, and verifying that the email was not modified in transit after leaving the sender's server.

Q: How does DKIM signing work technically?
The sending mail server uses a private key to generate a cryptographic signature based on the email body and selected headers. The signature is added as a DKIM-Signature header. The receiving server retrieves the corresponding public key from DNS using the selector and domain in the header, then uses it to verify the signature. If verification succeeds, the email is authentic and unmodified.

Q: What is a DKIM selector and why is it useful?
A selector is a label that identifies which DKIM key was used to sign an email. It appears in the DKIM-Signature header as s= and points to a specific DNS subdomain where the public key is published. Selectors allow you to use multiple keys simultaneously (for example one per sending service), rotate keys without disruption, and revoke compromised keys by simply removing the DNS record.

Q: Why does DKIM survive email forwarding when SPF does not?
SPF checks whether the sending server's IP is on the original domain's approved list. When email is forwarded, the forwarding server's IP is not on that list, so SPF fails. DKIM's cryptographic signature is embedded in the email headers and travels with the message unchanged through forwarding. As long as the signed content is not modified, DKIM verification will still succeed at the final destination.

Q: What is the difference between relaxed and simple canonicalization in DKIM?
Canonicalization controls how strictly DKIM handles minor formatting changes that mail servers sometimes introduce in transit. Relaxed mode tolerates minor whitespace changes and header capitalisation differences. Simple mode tolerates no changes whatsoever. Relaxed is used in almost all real-world deployments because many servers make trivial formatting adjustments that would break a strict signature.

Q: Can DKIM alone stop phishing?
No. DKIM verifies that an email was signed by a particular domain and has not been tampered with. It does not verify that the signing domain matches the visible From address the recipient sees. It also says nothing about whether the content of the email is safe, or whether the signing domain itself is legitimate or newly registered for malicious purposes. DKIM must work alongside SPF and DMARC, plus additional content inspection controls, to provide meaningful phishing protection.

Q: What happens if a DKIM private key is compromised?
You remove the corresponding public key TXT record from DNS. Any future email signed with the compromised private key will immediately fail DKIM verification because receivers can no longer find a matching public key. You then generate a new key pair, publish the new public key under a new selector, and configure your mail server to sign with the new private key.

Q: What is the body hash in a DKIM signature?
The body hash (bh=) is a cryptographic hash of the message body, calculated before signing. It is included in the data that the private key signs. If the email body is changed after signing, the body hash calculated by the receiving server will not match the one in the signature, causing DKIM to fail. This is what makes DKIM tamper-evident.

Frequently Asked Questions

Do I need DKIM if I already have SPF?

Yes, and for two specific reasons. First, DKIM detects email tampering in transit, which SPF cannot do. Second, DKIM survives email forwarding where SPF breaks. The two protocols are complementary, not redundant. Running both is the correct approach.

My email provider says DKIM is enabled. Do I still need to do anything?

Possibly. Most providers configure DKIM for their own sending infrastructure, but you typically need to add the DKIM DNS record to your own domain's DNS. This is a step you do yourself, in your DNS management panel. Without that DNS record, receiving servers cannot verify your signatures. Your provider's setup guide will walk you through this.

How do I know if DKIM is actually working?

Send a test email to a Gmail address and view the original message headers. Look for dkim=pass in the Authentication-Results header. If you see dkim=none, the email was not signed. If you see dkim=fail, there is a signing or DNS configuration problem. MXToolbox's DKIM lookup tool is also a fast way to verify that your DNS record is published correctly.

How often should I rotate DKIM keys?

There is no universal standard, but rotating annually is a widely accepted practice. Some organisations rotate every six months for higher-security environments. The key thing is to have a rotation process rather than leaving the same key in place indefinitely. Use the selector system to rotate without disrupting email delivery.

Can I have multiple DKIM keys for the same domain?

Yes, and this is normal. If you send email through multiple services (your primary mail server, a marketing platform, a support tool), each one can have its own DKIM key identified by a different selector. Multiple keys can be active simultaneously without any conflict.

What key length should I use for DKIM?

2048-bit RSA keys are the current standard. 1024-bit keys are considered weak and should be replaced. Some providers now support 4096-bit keys for higher security, though these are slightly slower to process and some older mail servers may not handle them correctly. 2048-bit is the right choice for most organisations.

Does DKIM work with mailing lists?

This is a known problem area. Many mailing list software packages modify email subjects or bodies (adding list prefixes or footers), which breaks the DKIM signature because the signed content has changed. Some mailing list tools strip DKIM signatures entirely. The email community has explored solutions including ARC (Authenticated Received Chain), which is designed to preserve authentication information through legitimate email modification scenarios. For most organisations this is not a day-to-day concern but it is worth knowing about.

Summary

DKIM is the wax seal of email. It provides cryptographic proof that an email was genuinely sent by the claimed domain and that nothing inside it was changed in transit. It does something SPF cannot: it travels intact through email forwarding, and it detects tampering at the content level.

Setting up DKIM properly means generating a key pair, publishing the public key in DNS under the right selector, and confirming that your mail server is signing outgoing emails. Once it is in place, the process is entirely automatic.

But like SPF, DKIM alone is not the complete picture. DKIM verifies the signing domain. It does not verify that the signing domain matches the visible From address your recipients see. That alignment check is what DMARC provides, sitting above both SPF and DKIM to enforce policy and close the final gap.

SPF is layer one. DKIM is layer two. DMARC is what ties them together and enforces the rules.

DKIM proves your message is genuine. But neither SPF nor DKIM enforces alignment with the From address your recipients see. That is what DMARC adds: What is DMARC? Why 66% of Companies Still Don't Have It Configured

Related reading:

• Email Authentication Explained: SPF, DKIM, DMARC and Why All Three Matter
• What is SPF? The Sender Policy Framework Explained in Plain English
• What is DMARC? Why 66% of Companies Still Don't Have It Configured