A footer can turn a correctly signed outbound message into a DKIM failure. The repair starts with the processing sequence: identify which system signed the message, which system inserted the footer, and which signature the receiver evaluated. Publishing another DNS key cannot make a signature cover text added after it was created.
Prove which bytes changed
Save a controlled message immediately after signing and another after the gateway, using raw message export rather than copied text from a mail client. Preserve the original files. Record each signature's d, s, c, h and any l tag. A message may have multiple signatures with different coverage and outcomes.
DKIM computes a hash of the canonicalized body. Under ordinary full-body coverage, a new footer adds substantive content and changes that hash. Relaxed body canonicalization removes certain whitespace differences; it does not remove a disclaimer, HTML block or new MIME part. A body-hash mismatch concerns the compared body-hash inputs and values: the body representation, c/l settings and bh value. A damaged or incorrectly generated bh, or a signer/verifier implementation error, can also explain a mismatch. The comparison in RFC 6376 section 6.1.3 does not by itself prove that a gateway changed the body. A general signature failure may instead involve a signed header, key lookup or signature syntax. RFC 6376 §3.4, RFC 6376 §3.7 and RFC 6376 §6.1 describe those separate checks.
Compare the samples at the boundary where the footer is applied. Inspect both text/plain and text/html parts, MIME boundaries and transfer encoding. An apparently identical visible footer can be serialized differently. If the gateway also changes Subject, inspect whether Subject is listed in h: repairing the body alone will not restore a signature over a changed header.
Test the ordering rather than guessing
Illustrative scenario: an application creates an invoice, the outbound server signs it, and a gateway then appends a legal notice. The receiver reports a body-hash mismatch for the application's signature. In a controlled alternative, the gateway appends the notice first and an authorized signer signs the final serialized message. A passing result on that second path supports the ordering diagnosis. These are proposed test observations, not results from a real tenant.
Use the same message variants through both paths, including HTML, plain text and an attachment. Record receiver authentication results from a trusted boundary, the signature domain and the visible From domain. DKIM pass alone is insufficient for DMARC if the passing signature does not align with the author domain. An unrelated gateway signature can verify correctly without providing that aligned path.
Choose an owned signing boundary
The usual durable design is to perform required content changes before the final authorized signing operation. That may mean moving the signer later, moving footer insertion earlier, or configuring the gateway to sign the final message using a domain the organization controls. Confirm supported behavior and key ownership before selecting a design. Do not assume every gateway supports custom-domain signing.
If an existing signature is broken, adding a new valid signature does not repair the earlier one. Evaluate the new signature on its own merits and verify alignment separately. Do not enable the body-length l tag just to make footers disappear from the hash calculation: it leaves an unsigned suffix and creates the security trade-off described in RFC 6376 §8.2.
Finish with a regression check
Keep a route diagram showing the last body-changing component and the signer immediately after it. Re-test when disclaimer rules, antivirus rewriting or outbound routing change. Success means the required footer is present, the intended signature verifies, its domain meets the intended alignment policy, and critical messages still arrive through the expected route. Keep a rollback plan for the configuration change without treating removal of a required legal notice as an automatic remedy.
Use a regression acceptance record
For each synthetic plain-text, HTML and attachment variant, record: footer present; last body-changing hop; final signer d/s; selected c/h/l; trusted receiver result; Author Domain and alignment; and the business-route outcome. If the footer is missing, the notice requirement is not met even when DKIM passes. If the footer is present but only an unrelated gateway domain passes, the intended DKIM-alignment requirement is not met. These are acceptance criteria, not completed checks.