Learn / What is DKIM

What is DKIM?

DKIM (DomainKeys Identified Mail) uses cryptographic signing to prove that an email was created by someone authorized by the domain owner and has not been modified in transit.

How DKIM works

DKIM operates in three steps: signing, transmission, and verification.

Step 1: Signing (at your mail server)

When your mail server sends an email, it:

  1. Takes the email's headers and body
  2. Generates a cryptographic hash of selected headers and the body (using a hash algorithm like SHA-256)
  3. Encrypts that hash with your private DKIM key
  4. Adds the encrypted hash as a new header to the email: the DKIM-Signature header

Step 2: Transmission

The signed email travels through the internet to the receiver's mail server. If a spammer or attacker modifies the email in transit (changing the body, rewriting headers, etc.), the signature becomes invalid.

Step 3: Verification (at the receiving mail server)

The receiver's mail server:

  1. Reads the DKIM-Signature header to find the selector and domain
  2. Performs a DNS query for the public key: selector._domainkey.example.com
  3. Decrypts the signature using that public key
  4. Computes a fresh hash of the email headers and body
  5. Compares the decrypted hash with the fresh hash—if they match, the email passed DKIM

If even one byte of the email changed, the hashes won't match, and DKIM verification fails.

Selectors: managing multiple keys

A selector is a label for a specific DKIM key. You can publish multiple keys (e.g., s1, s2, default) under different selectors, allowing you to rotate keys or use separate keys for different mail servers without downtime.

The public key is always published at: {selector}._domainkey.{domain} 

# Example selector: s20250601
s20250601._domainkey.example.com

This lets you publish a new key under a new selector (e.g., s20250602) before retiring the old one. During rotation, both keys are valid; afterward, you can remove the old selector.

The public key record

The DKIM public key is stored in a TXT record in DNS. It contains the key itself, the hash algorithm, and the key type: 

s20250601._domainkey.example.com
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD...

The fields:

  • v=DKIM1 — version (always 1)
  • k=rsa — key type (RSA is standard; Ed25519 is emerging)
  • p=MIGfMA0G... — the public key itself (base64-encoded)
  • h=sha256 — hash algorithm (defaults to SHA-256)
  • t=y — optional; testing mode (receiver should not reject failed signatures)

DKIM alignment

For DMARC, DKIM alignment checks whether the domain in the DKIM-Signature header matches the From header domain (in strict mode) or shares the same organizational domain (in relaxed mode).

For example:

  • From: alice@example.com and DKIM domain is example.com → aligned (both modes)
  • From: alice@example.com and DKIM domain is mail.example.com → aligned in relaxed mode (same organizational domain), not aligned in strict mode
  • From: alice@example.com and DKIM domain is other.com → not aligned (either mode)

Key rotation best practices

DKIM keys should be rotated periodically (annually or when you suspect compromise). The process is simple:

  1. Generate a new key pair

    Create a new public/private key with a new selector (e.g., s202506).

  2. Publish the new public key in DNS

    Add a TXT record at s202506._domainkey.example.com with the new public key.

  3. Update your mail server to use the new key

    Configure your mail infrastructure (Office 365, Google Workspace, SendGrid, etc.) to sign with the new private key.

  4. Wait for propagation

    Give DNS a few hours to propagate globally.

  5. Remove the old key

    After a grace period (1–2 weeks), delete the old selector's TXT record from DNS.

Tip

During rotation, both the old and new keys are valid. This prevents a window where legitimate email fails verification.

What DKIM does and doesn't prove

DKIM proves:

  • The email was created by someone with access to your private key (your mail infrastructure)
  • The email was not modified in transit
  • The domain in the DKIM signature is yours (because you published the public key in DNS)

DKIM does not prove:

  • The email's sender is legitimate (only that they have your private key)
  • The user in the From header is real (the From header is not signed; only specific headers are)
  • The email wasn't sent by a compromised or rogue authorized server

A spammer with access to your mail server can still send signed phishing mail. That's where DMARC comes in—by enforcing alignment and a policy, you tie DKIM to the user-facing From header.

Example DKIM records

Google Workspace / Gsuite

When you enable DKIM in Google Workspace, they generate a key and give you a record like: 

google._domainkey.example.com
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...

Microsoft 365

Microsoft 365 generates DKIM keys automatically. You publish them at: 

selector1._domainkey.example.com
selector2._domainkey.example.com

Microsoft creates multiple selectors for redundancy.

Custom mail server (e.g., self-hosted Postfix)

If you run your own mail server, you generate and manage the keys: 

# Generate a 2048-bit RSA key:
openssl genrsa -out dkim.private.key 2048
# Extract the public key and format it for DNS:
openssl rsa -in dkim.private.key -pubout -outform DER | openssl base64 -A

Then publish the public key in DNS and configure your mail server (e.g., Postfix, Sendmail, Exim) to sign with the private key.

Common DKIM issues

Long public keys in DNS (TXT record length limits)

DKIM public keys can be large (2048-bit RSA keys are ~300 bytes base64-encoded). DNS TXT records are limited to 255 characters per string, but you can split the key across multiple strings: 

selector._domainkey.example.com
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3... "...rest of key..."

Most DNS providers handle this automatically.

Key mismatch between mail server and DNS

If your mail server is signing with a private key but the corresponding public key isn't published (or is outdated), receivers can't verify the signature. Always double-check that the public key in DNS matches the private key in your mail server config.

Selector mismatch

If your mail server is configured to use selector default but the public key is published under selector s1, verification fails. Ensure the selector is consistent.

Going further

DKIM is nearly bulletproof for preventing email modification and proving domain authorization. Combined with SPF, it's the foundation of a strong authentication posture. The next layer—DMARC—ties them together and enforces a policy.

Learn about DMARC, which builds on both SPF and DKIM to enforce alignment and deliver powerful reporting on your email authentication posture.