DKIM — DomainKeys Identified Mail

How DKIM works — the signing and verification flow

DKIM operates as a three-actor protocol: the sending mail server, your DNS, and the receiving mail server. The signing happens once at send time; verification happens at every hop that chooses to verify. The signature rides in a single header (DKIM-Signature) attached to the message and survives every routing decision until the message arrives at its destination.

The cryptographic guarantee is meaningful: a valid DKIM signature proves the message came from the signing domain (only the holder of the private key could have generated the signature) and that the signed bytes haven't changed. What DKIM doesn't prove is anything about the visible From: header — that's why DMARC exists, to tie DKIM authentication results back to the visible sender domain through alignment.

The DKIM-Signature header — tag by tag

The DKIM signature is a single header with a structured tag list. Every tag has a purpose; understanding what each one does is the difference between debugging a DKIM failure in 10 minutes vs 10 hours. Below is a real signature, followed by what each tag means and what to check when something fails.

The DKIM DNS record — what receivers actually look up

The public key is published as a DNS TXT record at selector._domainkey.example.com. Receivers extract the selector and signing domain from the DKIM-Signature header, perform the DNS lookup, then verify the signature with the published key. The record format:

Algorithm choice — RSA-2048 vs Ed25519

The current cryptographic landscape for DKIM is straightforward: RSA-2048 with SHA-256 is the universal default, with Ed25519 as the forward-looking alternative for receivers that support it. RSA-1024 is deprecated as of 2024 (Google, Yahoo, Microsoft reject it). RSA-4096 introduces DNS UDP truncation problems and provides no meaningful security gain over 2048 for email authentication. The decision matrix:

Receiver verification support matrix (2026)

The biggest gap in most DKIM documentation is concrete data on which receivers verify which algorithms. Below is the empirical support matrix as of May 2026, based on test sends to each receiver and inspection of Authentication-Results headers. Treat as moving — these change with little notice.

Canonicalization — relaxed vs simple

Canonicalization is how DKIM normalizes the message before hashing. Mail servers routinely make minor adjustments to messages in transit — header folding, whitespace normalization, line ending conversion — that don't change content meaning but change byte content. Canonicalization tells the receiver how to handle these changes when computing the verification hash.

The c= tag specifies two canonicalization modes: one for headers, one for the body, separated by /. Production deployments should use relaxed/relaxed. Use simple/simple only if you have a specific compliance reason — it's a documented source of unnecessary failures.

Safe DKIM key rotation

The single biggest operational risk in DKIM isn't choosing the wrong algorithm — it's botching key rotation. Done wrong, rotation creates a window where messages signed with the new key fail verification because resolvers still cache the old public key, or messages signed with the old key fail because the DNS record was replaced too early. Done right, rotation is invisible to receivers and adds zero authentication failures.

The pattern below is the safe rotation sequence. Notice that the new key is signed with for the entire DNS propagation window before retiring the old key — the old key stays valid until propagation is confirmed.

ESP DKIM signing patterns — who aligns with your domain and who doesn't

A critical operational distinction often missed: not all ESPs sign DKIM with your domain. Some sign with their own domain (d=sendgrid.net), which produces dkim=pass but fails DMARC alignment because sendgrid.net ≠ yourdomain.com. The setup pattern matters more than whether DKIM is "configured" at all.

CNAME vs TXT — Microsoft 365's distinct pattern

Microsoft 365's DKIM setup pattern differs from most other ESPs and is responsible for a large share of "DKIM looks configured but isn't working" tickets. Microsoft publishes the actual public key at a Microsoft-controlled DNS location and asks you to publish CNAMEs that point to it. The advantage is that Microsoft can rotate keys without your DNS update; the disadvantage is that admins frequently configure TXT records directly when CNAMEs were expected.

Common DKIM failure modes in production

The error message is the diagnosis. Below are the seven most common DKIM failure patterns, with the symptom you'll see in Authentication-Results headers and the operational root cause to investigate.

DKIM in Cloud Server for Email's managed infrastructure

For clients on managed PowerMTA + MailWizz infrastructure, DKIM is configured during the day 1-3 onboarding sequence as part of the broader authentication setup (SPF + DKIM + DMARC + MTA-STS + TLS-RPT). The patterns we use across most accounts:

• RSA-2048 default with date-based selectors. A new client typically gets selectors named s2026q2, s2026q3, etc., aligned to the rotation calendar. The selectors are tied to PowerMTA's domain configuration so signing happens automatically per VirtualMTA without per-message setup.
• Per-stream selectors for multi-stream architectures. Clients with separated transactional, marketing, and prospecting streams get separate selectors per stream (tx2026q2, mk2026q2, pr2026q2). This lets each stream rotate independently and shows up as separate rows in DMARC aggregate reports — invaluable for diagnosing per-stream reputation issues.
• Quarterly rotation calendared, executed as a coordinated change with the client's DNS administrator. The 7-step rotation sequence above is the documented playbook.
• relaxed/relaxed canonicalization. The default in PowerMTA's DKIM signing module. Clients have requested simple/simple in only one historical case (compliance requirement); we documented the operational implications and reverted within a quarter when the resulting failure rate proved unacceptable.
• No l= tag. The body length limit is a documented security risk — attackers can append content beyond the signed range. Our PowerMTA configuration explicitly omits l= so the entire body is always signed.
• DMARC aggregate report monitoring for DKIM alignment failures specifically. ESP integrations on customer accounts (when a client's MailWizz also sends through SendGrid for some segments) are common sources of DKIM-pass-but-not-aligned signals — we alert on these and coordinate the ESP's domain-auth setup.

For Microsoft 365 customers using our infrastructure for the marketing layer alongside their corporate Microsoft 365 mail, we maintain documentation specifically on the CNAME-vs-TXT distinction since it's a recurring source of confusion. The CSE-managed sending domain uses TXT records; the Microsoft 365 corporate domain uses CNAMEs. Both can coexist, just on different subdomains.

Auditing your DKIM — practical workflow

Related concepts

• SPF — IP-based authentication; complements DKIM. Most production DMARC pass-through relies on DKIM because SPF breaks during forwarding.
• DMARC — the policy layer that uses DKIM (and SPF) authentication results plus alignment to decide what receivers should do with failing mail.
• ARC — Authenticated Received Chain (RFC 8617); preserves original auth results across forwarding hops where DKIM/SPF would otherwise break. (Coming soon)
• BIMI — brand logo display, requires DMARC enforcement, which requires functional DKIM and SPF. (Coming soon)
• Sender Reputation — DKIM authentication is one input to overall sender reputation at major receivers, especially for receivers that weight "stable, aligned authentication" as a positive signal.

Frequently asked questions

What's the difference between DKIM and SPF?

SPF authenticates the sending IP — it answers "is this connecting server authorized to send for this domain?" DKIM authenticates the message content itself — it answers "was this message authorized by the signing domain, and has the content been tampered with?" Critically, DKIM signatures survive forwarding because they sign the message body, not the envelope. SPF almost always breaks during forwarding because the forwarder's IP isn't in your authorized list. This is why DMARC pass-through in the real world relies more on DKIM than on SPF — and why DKIM is the more important of the two for forwarding-heavy environments.

Should I use RSA-2048 or Ed25519 for DKIM keys?

RSA-2048 in 2026, with optional Ed25519 dual signing for forward compatibility. Ed25519 (defined in RFC 8463) produces shorter keys, faster signatures, and equivalent or better security, but Microsoft 365 and Yahoo do not reliably verify Ed25519 signatures as of May 2026 — going Ed25519-only causes DKIM failures at major receivers. The recommended pattern is dual signing: publish both an RSA-2048 selector and an Ed25519 selector, sign every message with both. Receivers that support Ed25519 use it; receivers that don't fall back to the RSA signature. RSA-1024 has been rejected by Google, Microsoft, and Yahoo since 2024 — never deploy new infrastructure with 1024-bit keys.

What does "body hash did not verify" mean?

It means the receiving server's hash of the message body does not match the hash recorded in the DKIM-Signature header. The message body changed between signing and verification. Common causes: email gateways inserting disclaimers/footers post-signing, forwarders modifying content, TLS termination at intermediate hops re-encoding characters, Microsoft 365 normalizing non-ASCII characters (smart quotes → straight quotes) before verification, or anti-virus systems modifying the body. The error is almost always due to content modification in transit, not a key configuration problem. Diagnostic step: compare the raw body as sent vs as received byte-for-byte.

How often should DKIM keys be rotated?

Industry standard is quarterly rotation (every 90-180 days), recommended by Google. Studies across large sending operations show 6-9% reduction in transient DKIM failures with rotation cadences in the 120-180 day range vs semiannual or annual rotations. Use date-based selector naming (s202601, s202602) to make audits trivial and rotation a routine operation. The actual security risk from a leaked private key grows linearly with time — quarterly rotation caps the exposure window. The bigger risk is doing rotation incorrectly: DNS propagation must complete before retiring the old key, otherwise messages signed with the new key fail verification because resolvers still cache the old public key.

What is a DKIM selector and how do I choose one?

The selector is the identifier that points receivers to a specific public key in DNS, allowing multiple keys per domain. The DNS lookup is selector._domainkey.example.com. Choose date-based names tied to rotation cycle: s202601 for Q1 2026, s202602 for Q2, etc. Avoid generic names like 'default', 'key1', or 'mail' — they make rotation tracking impossible and conflict with ESP-default selectors. For multi-stream architectures, use stream-prefixed selectors: tx202601 for transactional, mk202601 for marketing, sup202601 for support. This lets you rotate one stream's key without disrupting others, and per-stream selectors can be observed independently in DMARC aggregate reports.

Can a forwarded message preserve DKIM?

Yes, if the forwarding server doesn't modify the signed portions. Simple forwarding (the message is reused unaltered) preserves DKIM and is one of the main reasons DKIM is preferred over SPF for DMARC pass-through. Forwarding that adds footers, modifies headers in the signature's h= list, or re-encodes characters breaks DKIM. The signed headers (From, Subject, Date, Message-ID) and the signed body must arrive byte-identical to verify. ARC (Authenticated Received Chain, RFC 8617) is the protocol designed to let forwarders preserve original authentication results across hops where SPF and DKIM would otherwise break. Major providers (Gmail, Microsoft) increasingly check ARC chains as a signal.

What does relaxed vs simple canonicalization mean?

Canonicalization is how DKIM normalizes headers and body before hashing. Two modes per dimension. Simple/simple: no modifications allowed — any whitespace change between signing and verification breaks the signature. Relaxed/relaxed: tolerates whitespace normalization, line ending changes, header folding adjustments. Production deployments should use relaxed/relaxed (the default in most signers) because mail systems routinely make minor whitespace adjustments that don't affect content meaning but would break simple canonicalization. The c= tag in the DKIM-Signature header takes the form c=header_canon/body_canon, e.g., c=relaxed/relaxed. Use simple/simple only if you have specific compliance reasons — it's a documented source of unnecessary DKIM failures.

Why do my Microsoft 365 DKIM records use CNAME instead of TXT?

Microsoft 365 publishes DKIM keys via CNAME records that point to Microsoft-managed DNS records. When you enable DKIM in Microsoft 365 admin center, you add CNAME records like selector1._domainkey.example.com pointing to selector1-example-com._domainkey.your-tenant.onmicrosoft.com. The actual public key lives at the Microsoft-controlled target. This pattern lets Microsoft rotate keys without requiring your DNS update on every cycle — you publish CNAMEs once, Microsoft handles the rotation upstream. The most common Microsoft 365 DKIM failure is configuring TXT records directly when CNAMEs were expected, or vice versa. The setup is correct only when CNAMEs resolve to populated TXT records at the Microsoft target.