DIAGNOSTIC PLAYBOOK
DKIM canonicalization: which whitespace changes survive?
DKIM canonicalization defines how headers and body content are normalized before hashing. Relaxed processing tolerates certain whitespace differences, but it does not authorize arbitrary HTML rewrites or inserted content.
HealthCheck Email editorial team · · Examples are illustrative
How to investigate
- Read the c tag to identify header and body canonicalization, including defaults if absent.
- Compare raw messages before and after the suspected gateway, preserving line endings.
- Locate a concrete byte transformation and test whether it falls within the selected normalization rules.
What this looks like
ILLUSTRATIVE EXAMPLE
A gateway rewraps a header in a way relaxed header canonicalization tolerates, but also inserts a footer that changes the signed body. Only the first change may survive.
A mistake to avoid
Switching to relaxed mode is not a universal repair. A material content change still invalidates the relevant signature.
Keep the result in context
A DKIM investigation needs a real signed message and the public key for its selector and signing domain. DNS alone cannot prove that a service is signing outgoing mail. Preserve the raw source when comparing messages so your own copy process does not change the bytes being checked.
Take the next step
Use the related check to gather evidence, then compare it with the affected message or service. Keep the result and time with your notes so a later change can be distinguished from the original problem.
Sources and further reading
The protocol references below explain the underlying behavior. Your sending or DNS provider supplies the account-specific settings for its service.