Changing an outbound gateway can alter a signed message even when its visible purpose is simply routing mail. Footers, link rewriting, MIME conversion and header edits may invalidate an existing DKIM signature. Locate the exact modification and signing boundaries before changing DNS or blaming the receiving provider.
Draw the message-processing order
Document the application output, first signer, gateway transformations, final signer and receiver. Capture an authorized raw message immediately before and after the gateway where possible. Preserve CRLF line endings and exact bytes; copying a displayed message into a text editor can create changes that never occurred in transit.
DKIM signs selected headers and a canonicalized body. Inspect the signature's d, s, h, c and any body-length restriction. Relaxed canonicalization tolerates specific formatting differences, not arbitrary content changes. A footer added after full-body signing normally changes the body hash. RFC 6376, sections 3.4, 5 and 6.
Compare the signing boundaries on paper
Assume From alerts@example.test, a valid original signature with d=example.test and selector first, relaxed body canonicalization, and no l= body-length limit. No real key or signed message is supplied.
- Before gateway transformation: signature validity is a premise, not an observed cryptographic result.
- After appending a nonempty text footer that changes the canonicalized full body: the original body hash no longer matches, so that original signature would fail under the stated assumptions.
- After final authorized signing of the transformed bytes with d=example.test and selector final: a correctly generated and independently verified new signature could provide an aligned DKIM path. Actual new-signature validity remains untested. The old signature is not repaired; keeping or removing it is a separate processing choice.
No key generation, signing, verification or gateway execution occurred for this written comparison. In production capture the actual before/after bytes and key data, then measure rather than assume each outcome.
Interpret the result narrowly
An observed failed old signature after a footer would establish that this transformation breaks that signature. It does not establish that every gateway modification breaks every signature. An unsigned header can change without affecting the signed header set. Canonicalization can also preserve validity across some whitespace changes. Test the actual gateway features, MIME structures and signature settings instead of extrapolating from a single text message.
The written example assumes the same signing and From domain, but does not execute full DMARC discovery or a receiving provider's policy. DMARC requires a passing aligned authentication path, and an unrelated gateway signing domain does not automatically supply that alignment. RFC 9989. A new valid signature must still be evaluated in relation to the intended author identity.
Choose the production signing boundary
Where supported, place final authorized signing after legitimate transformations that would otherwise alter signed content. Configure the new signer with a valid domain and selector under the organization's approved authority. Publish and verify its public key before directing production traffic through it. Preserve necessary old selectors for queued or delayed messages under a deliberate retirement plan.
Do not solve the footer problem by promising that relaxed canonicalization accepts any rewrite. Do not reduce signed-body coverage as a routine workaround; that changes what the signature protects. If an upstream signature must survive, adjust transformations or routing and verify the exact bytes rather than assuming final re-signing repairs the earlier signature.
Validate the gateway cutover
Test plain text, HTML, attachments and representative business templates through the actual authorized route. Compare raw headers, authentication results from a trusted receiver and message rendering. Include bounce handling and queue behavior. A local signature pass establishes cryptographic validity under supplied key data, not inbox placement, user trust or delivery of every template.
Rollback criteria should identify which legitimate flows or authentication paths failed and how to restore the old processing order. Retain the evidence before changing settings again. Close only after both the new route and the planned recovery path are understood.