A message that verifies before forwarding and fails afterward calls for a comparison of the signed bytes and signature context. Do not assume that every added header breaks DKIM or that relaxed canonicalization permits arbitrary editing. The signature identifies the protected header fields, canonicalization and body hash. Reconstruct those choices before deciding which transformation matters.
Preserve comparable artifacts
References: RFC 6376 §3.5, RFC 6376 §3.7.
Retain the raw original and final message without opening and resaving through a client that may normalize line endings or re-encode MIME. Record the signer domain, selector, algorithm, signed-header list, canonicalization and any body-length limit. Keep the verifier output and DNS key observation with the timestamp. A visually identical message can have different encoded bytes.
Find the signer in the processing chain. A footer added before the final signature is part of the signed content; the same footer appended after signing may invalidate the body hash. Inventory list software, gateways, disclaimer engines, antivirus rewriters and archival paths as possible transformation points. Only evidence from the actual route can identify which one acted.
Understand what canonicalization allows
References: RFC 6376 §3.4, RFC 6376 §5.4, RFC 6376 §8.2.
RFC 6376, section 3.4, defines simple and relaxed canonicalization. Relaxed body processing normalizes specified whitespace and trailing empty lines. It does not make an added paragraph or changed amount disappear. Header canonicalization has its own rules and should not be replaced by body rules.
A Subject prefix affects a signature that covers the relevant Subject field. Merely adding an unrelated unsigned header is a different case. Duplicate signed fields and header selection require the verifier's rules, not a casual visual diff. Where a signature includes a body-length limit, understand the uncovered-content risk; do not introduce that option as a convenient way to make arbitrary footers safe.
Run a real body hash comparison
References: RFC 6376 §3.4.4.
The local fixture applies relaxed body canonicalization to three synthetic bodies. It computes SHA-256 and base64 for the original, a whitespace-only variation and a footer-appended version. The original and whitespace cases match; the footer case differs. The generated original and modified .eml files preserve the illustrative body bytes for inspection.
This is an observed hash transformation, not a DKIM signature verification. No private signing key, DNS key lookup, header signature or trusted receiving service is involved. The expected effect on a full signature remains conditional on the actual signature covering the changed bytes. The retained evidence below records historical local signing and before-and-after verification; production-route evidence remains uncollected.
Fix ordering before weakening coverage
References: RFC 9989 §4.4.1, RFC 9989 §5.3.5.
Where possible, apply required transformations before the legitimate domain's final signing step. For an intermediary that cannot sign for the original author, preserving the original signed content may retain an aligned pass. A replacement signature from the intermediary authenticates its own domain and is not automatically aligned with the original From address. RFC 9989 supplies that separate comparison.
Retest the same transformation with the full verifier and representative MIME content. Include attachments, multipart alternatives and non-ASCII messages if they are in scope. Preserve negative controls so a test cannot succeed simply because the signature disappeared. Closure should say which transformation changed, which signature now validates and whether that signature provides aligned authentication at the final receiver.
Retained laboratory evidence
References: RFC 6376 §6.
In the 7 November 2026 capture, a temporary 2048-bit RSA key signed the original bytes with dkimpy before forwarding. The key's public DNS record is retained and the private key is deleted after execution. dkimpy verifies the original and preserved-forwarding messages and rejects the footer-appended body. The list case applies attribution and footer changes before creating its list-domain signature, which verifies. These are genuine complete DKIM signature tests, not supplied boolean results. The relaxed-body helper also now handles empty input as zero octets.
The retained runner and 7 November 2026 capture were inspected; no network experiment was rerun for this review. The original experiment used loopback only and sent no Internet mail. Its receiver creates Authentication-Results from its own checks, giving those fields known laboratory provenance. Authentication outcome and disposition remain separate: all six SMTP samples receive 250 under an explicit capture policy, including failing samples. The trust boundary is this controlled laboratory, not a production mailbox provider. The DNS adapter supplies retained fixture answers rather than querying public DNS, and the DMARC evaluator uses strict domain equality only. Full organizational-domain discovery, production policy parsing and live deployment outcomes remain untested.