DKIM relaxed vs simple canonicalization: what whitespace changes can survive and what still breaks the body hash

Define the exact state transition

RFC 6376 defines simple and relaxed canonicalization separately for headers and body. Relaxed form tolerates specified whitespace and header-field normalization; it is not a mechanism for ignoring arbitrary content inserted after signing.

DKIM canonicalization defines which formatting differences are normalized before the signature hash is checked. “Relaxed” is not permission for intermediaries to rewrite the message freely. Relaxed header canonicalization normalizes defined whitespace and field-name case behavior; relaxed body canonicalization normalizes certain whitespace and trailing empty-line differences. If a gateway appends a footer, rewrites a URL, changes MIME content, or alters bytes outside those normalization rules, the body hash can still fail. The `c=` tag in DKIM-Signature tells you which header/body modes the signer selected, so start diagnosis there instead of assuming every DKIM failure is a key or DNS problem.

Where automation can flatten two different states

The c= value can contain two modes, such as relaxed/relaxed, because header and body canonicalization are selected independently. Assuming one global mode can lead an operator to test the wrong mutation.

Choosing simple canonicalization because it sounds stricter can make signatures more fragile across legitimate transport transformations, while choosing relaxed cannot protect against substantive content modification. The right choice depends on the signing platform and expected path, not on a belief that one mode boosts reputation. Another source of confusion is testing only the received body visually. Two bodies can look identical in a mail client while MIME encoding, line endings, or whitespace bytes differ. Conversely, a visible whitespace change might be normalized by relaxed canonicalization. Debug from the raw source and the signing parameters, not from rendered appearance.

A deterministic test case

Capture the received raw source and the DKIM-Signature, note c=, h= and bh=, then compare a message before and after the suspected gateway. Focus on actual body bytes and MIME boundaries rather than the rendered view in a mail client.

To reproduce a failure, preserve the original message before the modifying gateway if possible and the final raw message after delivery. Read the DKIM `c=`, `h=`, `bh=`, selector, and domain tags. Compare whether the signed headers changed and whether the body transformation is one relaxed canonicalization permits. If the body hash already fails, DNS key lookup is not the first suspect. Send a control message that bypasses the suspected footer or rewrite step; if the control verifies and the modified path fails, the content-changing hop becomes the narrow target for repair.

The smallest change that restores correctness

Place signing after systems that must rewrite the message, or configure downstream systems not to alter signed content. Change canonicalization only when you understand the exact transformation and its security trade-off.

The clean repair is usually to sign after the final content-changing step, stop the intermediary from modifying signed content, or configure the mail path so the signer and gateway agree on responsibilities. Do not weaken authentication by stripping DKIM just because a footer breaks it. After changing the route, send several message shapes—plain text, HTML, attachments if used—and verify the same selector succeeds. Document which canonicalization is configured and which gateways are allowed to modify content. That operational map is much more useful than a blanket rule that every sender should switch to relaxed or simple.

Example from a multi-mailbox workflow

Collapsing extra spaces may survive relaxed body canonicalization, while appending “This email was scanned” changes body content and normally changes the body hash. Both can look visually trivial to a human.

When a signature fails only on one route, compare the MIME path before changing canonicalization. Marketing systems may re-encode quoted-printable content, security gateways may wrap URLs, and corporate relays may append legal footers. Those are content transformations, not merely whitespace normalization. If you control the path, place DKIM signing after the last expected transformation or configure that intermediary not to rewrite the signed message. If you do not control it, use the before/after raw source to prove which hop changes bytes and involve the owner of that hop. Keep a test message with a stable body and headers as a regression fixture. After future gateway updates, resend the fixture and verify `dkim=pass`. This turns canonicalization from an abstract setting into a concrete compatibility contract for your actual mail route.

Audit fields for later debugging

Save paired raw messages, the signer selector, canonicalization modes, and the component that changed the MIME body. A visual screenshot cannot prove why DKIM verification failed.

Failure modes that need a different branch

Do not use canonicalization changes to mask a chaotic mail path. The durable design is a clear finalization boundary followed by an aligned DKIM signature that downstream relays preserve.

Field checklist

• Capture the raw evidence for DKIM relaxed simple canonicalization footer body hash before editing DNS, queue state, or mailbox metadata.
• Confirm the cited mechanism using dkim-rfc, google-dkim-troubleshoot rather than a generic deliverability score.
• Keep a known-good control case so the failing layer can be compared without changing several variables at once.
• Apply the narrow repair described for DKIM relaxed vs simple canonicalization: what whitespace changes can survive and what still breaks the body hash and preserve a rollback or retry path.
• Repeat the original failing test after the change; do not substitute a different checker as proof of recovery.
• Store timestamp, affected identity, raw result, action taken, and the post-change result in the operator log.