What is DKIM, and how does a DKIM signature work?

DKIM is the email authentication method that survives the journey. Where SPF checks the server a message came from, DKIM signs the message itself, so the proof travels with it through relays and most forwarding. This guide explains what a signature contains, how receivers verify it, how keys and selectors work, and what breaks it. It's also the hub for our DKIM guides.

What is DKIM?

DKIM stands for DomainKeys Identified Mail. It's defined in RFC 6376, a Standards Track document from September 2011. The RFC says DKIM "permits a person, role, or organization to claim some responsibility for a message by associating a domain name with the message."

It works with a key pair:

• Your mail platform holds a private key and uses it to sign each outgoing message.
• The matching public key is published in DNS under your domain.
• The receiver reads the signature, fetches the public key and checks that the two match.

Three things DKIM is not:

• Not encryption. The message stays readable. DKIM proves origin and integrity only.
• Not a From check. The signing domain can be any domain. Tying it to the visible From address is DMARC's job.
• Not a reason to reject on its own. RFC 6376 section 6.3 says receivers "SHOULD NOT" decide acceptability based only on a missing or unverifiable signature, because "such rejection would cause severe interoperability problems."

How does DKIM signing work?

When your server sends a message, it:

1. Picks the headers to sign and lists them in h=. The From: header "MUST be signed" (RFC 6376 section 5.4).
2. Canonicalizes the headers and body: it normalizes them by the chosen rules so small, harmless changes in transit don't break the signature.
3. Hashes the body and puts the result in bh=.
4. Hashes the signed headers, including the new DKIM-Signature header itself with an empty b=, and signs that hash with the private key.
5. Writes the signature into b= and adds the DKIM-Signature header to the top of the message.

A signature looks like this (shortened):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s202610;
  h=from:to:subject:date:message-id; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB...

How does a receiver verify a DKIM signature?

1. Read the DKIM-Signature header and check the required tags.
2. Fetch the public key with a DNS TXT query for <s>._domainkey.<d>, for example s202610._domainkey.example.com.
3. Recompute the body hash with the same canonicalization and compare it with bh=. A mismatch is the familiar "body hash did not verify" error.
4. Verify b= against the signed headers using the public key.
5. Record the result, for example dkim=pass header.d=example.com in Authentication-Results.

A message can carry several signatures, from the sender, an email service and a mailing list. A broken signature doesn't make a message worse than an unsigned one: RFC 6376 says a verifier "SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all."

What is DKIM canonicalization?

Mail gets lightly rewritten in transit: headers re-wrapped, trailing spaces trimmed. Canonicalization decides how much of that a signature tolerates. RFC 6376 section 3.4 defines two algorithms each for headers and body, written as c=header/body.

The RFC says relaxed "tolerates common modifications such as whitespace replacement and header field line rewrapping." If c= is missing, simple/simple applies. Neither mode survives real content changes, such as a footer added by a mailing list or a disclaimer from a gateway.

What are DKIM selectors and DNS keys?

A selector names one key among several for the same domain. RFC 6376 section 3.1 introduces them "to support multiple concurrent public keys per signing domain." That's what lets each sending service have its own key, and lets you replace a key without downtime.

The key lives at <selector>._domainkey.<domain>:

s202610._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Providers differ in how they publish keys. Microsoft 365 uses two CNAME records, selector1 and selector2, that point to keys Microsoft hosts and rotates. Google Workspace has you publish one TXT record, by default at google._domainkey (Google). Our DKIM records by provider pages list the records for common services, and how to find a DKIM selector shows how to read one from a message.

How long should a DKIM key be?

RFC 8301 updated DKIM's crypto rules in 2018:

Use 2048-bit RSA. The catch is DNS: a 2048-bit public key is too long for one 255-character TXT string, so it's stored as several strings that receivers join back together. Most DNS hosts handle this; if yours truncates the key, the signature fails.

What about Ed25519?

RFC 8463 adds the Ed25519-SHA256 algorithm, which "has much shorter keys than RSA for similar levels of security." Its key record uses k=ed25519, and the base64 public key is only 44 characters, so it fits in one TXT string. The RFC says verifiers MUST implement it, but large mailbox providers don't document whether they do, and Microsoft 365 documents only RSA keys (1024 or 2048 bits) for its DKIM signing. RFC 8463 section 6 gives the safe path: sign with both algorithms, each under its own selector.

How does DKIM relate to DMARC?

DMARC (RFC 9989) passes a message when SPF or DKIM passes for a domain that aligns with the From domain. For DKIM, the domain that counts is d=. RFC 9989 explains why alignment is needed: "a message can bear a valid signature from any domain, even one used by a bad actor."

So a pass isn't always a useful pass. If your newsletter tool signs with d=vendor-mail.net, DKIM passes, but DMARC for example.com gets nothing from it. Turn on custom-domain signing in each service so d= is your domain or a subdomain of it.

DKIM matters more for DMARC than SPF does, because it generally survives forwarding. RFC 9989 section 7.4 says forwarded mail "will most likely fail SPF checks" while "DKIM signatures will generally remain valid", and says domains publishing p=reject "MUST apply valid DKIM signatures to their messages." For the full picture, see what DMARC is and SPF vs DKIM vs DMARC.

What breaks DKIM?

The first row is the most common. Our guide to DKIM "body hash did not verify" covers each failure in detail.

How often should you rotate DKIM keys?

M3AAWG's key rotation guidance says "DKIM keys should be rotated at least every six months"; its April 2018 revision relaxed the earlier quarterly cycle. Selectors make it painless, as RFC 6376 section 3.1 describes: publish the new key under a new selector, switch signing to it, and keep the old public key published while mail signed with it may still be in transit. Then revoke the old one.

Microsoft 365 rotates between its two selectors when you trigger it, and Microsoft Learn documents the steps. The full procedure for other platforms is in DKIM key rotation.

How do I set up DKIM?

1. List every service that sends as your domain, as you would for SPF.
2. Turn on custom-domain signing in each one. Most services generate the key and show you a TXT or CNAME record to publish. Our DKIM setup guide for Microsoft 365 and Google Workspace covers the two big platforms step by step.
3. Run your own mail server? Create a 2048-bit key pair with the DKIM Key Generator, which makes the key in your browser, and configure your server to sign with it.
4. Publish the record at your DNS host, then check it with the DKIM Checker.
5. Send a test message to an outside mailbox and confirm dkim=pass with your domain in header.d, using the Email Header Analyzer.
6. Publish DMARC so receivers act on the result.

Our DKIM guides

Next steps

1. Check your selectors and key strength with the DKIM Checker.
2. Confirm every sending service signs with your domain in d=, not the vendor's.
3. Replace any 1024-bit key with a 2048-bit one at the next rotation, and put rotation on the calendar.
4. Once DKIM passes everywhere, move your DMARC policy toward enforcement; check it with the DMARC Checker.

DKIM protects your domain in other people's inboxes. For the mail arriving at yours, an inbound filter such as iBlockSpam checks each sender's authentication alongside spam and phishing signals; see how it works.

If apps or devices send mail through iBlockSpam, its outbound relay DKIM-signs those messages, with 500 relay messages per domain per month included.

Browse our other SPF, DKIM and DMARC guides.