Email authentication

What is DKIM?

DKIM lets the sending domain cryptographically sign messages so receivers can verify they haven't been tampered with. It's the authentication mechanism that survives forwarding — and the one most likely to provide DMARC alignment for third-party senders.

Why DKIM matters in 2026

DKIM has shifted from “nice to have” to operationally required:

• Gmail (February 2024): All senders must authenticate with SPF or DKIM. Bulk senders must also pass DMARC alignment — and DKIM alignment is often the only viable path for third-party senders.
• Yahoo (February 2024): Sender requirements tightened significantly. Bulk senders are expected to authenticate with SPF and DKIM and publish DMARC.
• Microsoft Outlook (May 2025): Microsoft began rejecting non-compliant mail from high-volume senders to Outlook consumer mailboxes under its SPF, DKIM, and DMARC requirements.

DKIM is especially important because it survives email forwarding. SPF breaks when mail is forwarded (the forwarding server's IP isn't in the original sender's SPF record). DKIM, as long as the message body isn't modified, remains valid regardless of how many hops the message takes.

For third-party senders that can't provide SPF alignment, DKIM alignment is typically the only path to DMARC pass.

How DKIM works

DKIM uses public key cryptography. The sending server signs the message with a private key. The receiving server retrieves the public key from DNS and verifies the signature.

Signing (sender side)

The sending MTA computes two hashes:

• A body hash over the canonicalized message body (stored as bh= in the DKIM-Signature header)
• A header hash over selected headers plus the DKIM-Signature itself (stored as b=)

The b= value is the actual signature, computed using the signer's private key.

Verification (receiver side)

The receiver uses the d= (signing domain) and s= (selector) from the DKIM-Signature header to construct a DNS query: <selector>._domainkey.<domain>. It retrieves the public key and verifies the signature.

If the receiver's recomputed body hash doesn't match bh=, the result is “body hash did not verify” — meaning the message was modified after signing.

Canonicalization

Mail transfer can introduce benign changes (whitespace, line folding). DKIM handles this via canonicalization:

• simple: almost no modification tolerance
• relaxed: tolerates whitespace changes, header case folding, and line rewrapping

Most business senders use relaxed/relaxed for improved robustness. Canonicalization does not protect against real content changes (added footers, subject modifications, MIME restructuring).

Key DKIM-Signature fields

DKIM alignment under DMARC

DMARC checks whether the DKIM signing domain (d=) aligns with the visible From: domain.

• Relaxed alignment (default): organizational domains must match. d=mail.example.com aligns with From: user@example.com.
• Strict alignment (adkim=s): full domains must match exactly.

A DKIM signature can pass verification but fail DMARC alignment if d= is set to a vendor's domain rather than yours. This is the most common reason third-party mail passes DKIM but fails DMARC.

The fix: configure the sending platform to sign DKIM with your domain (custom DKIM). After setup, d= should be your domain or a subdomain of it.

→ See: DMARC alignment failure

Key management best practices

Algorithm and key size

• Use rsa-sha256 — RFC 8301 says rsa-sha1 must not be used.
• Use 2048-bit RSA keys as the baseline — this aligns with RFC 8301 guidance and NIST SP 800-131A recommendations for digital signatures.
• Ed25519 is defined in RFC 8463 but has limited platform support. Microsoft Exchange Online does not support Ed25519, and Google Workspace currently offers RSA key options.

Selector rotation

Selectors (s=) let you publish multiple keys and rotate safely:

1. Publish the new public key in DNS under a new selector.
2. Wait for DNS propagation.
3. Switch signing to the new selector.
4. Keep the old public key live for at least 7 days (up to 30) so in-transit mail can still be verified.
5. Retire the old key by setting p= to empty rather than deleting the record.
6. Avoid reusing selector names to prevent stale-cache validation failures.

Private key handling

Treat DKIM private keys like any signing credential: restrict access, secure transmission, use change control, and maintain a documented rotation process. M3AAWG guidance explicitly warns against sending private keys via unencrypted email.

DKIM setup in Microsoft 365 and Google Workspace

Microsoft 365

• If you only use the default *.onmicrosoft.com domain, outbound mail is automatically DKIM-signed by that domain.
• For custom domains, configure DKIM explicitly so mail can achieve DMARC DKIM alignment with your domain.
• Setup requires two CNAME records (selector1._domainkey and selector2._domainkey). Microsoft manages the private keys.
• Use Get-DkimSigningConfig to retrieve the correct DKIM CNAME targets for your tenant and domain.
• Key rotation uses Rotate-DkimSigningConfig and supports RSA 1024/2048. Ed25519 is not supported.

Google Workspace

• Generate a DKIM key in the Admin console, publish the public key as a TXT record (default selector: google), then enable DKIM signing.
• Google offers 2048-bit keys where supported (recommended) and 1024-bit where necessary.
• After adding a DKIM key, authentication can take up to 48 hours to start working.
• Do not assume platform-default signing gives DMARC-aligned DKIM for your custom domain. Enable custom DKIM explicitly for every domain you send from.

The key takeaway for both platforms: Enable custom DKIM for every sending domain you want DMARC-aligned DKIM for.

Common DKIM failures and how to fix them

Body hash did not verify

Something modified the message body after signing — commonly an outbound gateway, a security appliance rewriting links, or a mailing list processor modifying content. DKIM body hash did not verify

No key found / selector missing

The DNS record for the DKIM selector doesn't exist or hasn't propagated. This is common during setup and key rotation if the old selector is removed too quickly.

Signature verification failed

The signature doesn't match the public key, often due to a key mismatch, DNS record corruption, or header modifications in transit.

DNS TXT record truncation

2048-bit DKIM keys can exceed the 255-character DNS TXT string limit. The value should be split into multiple quoted strings within one TXT record.

CNAME/TXT conflicts

A CNAME cannot coexist with other record types at the same name. If both CNAME and TXT records exist at the same _domainkey host, resolver behavior varies and failures may become intermittent.