Find the modification before blaming the gateway
A security gateway can legitimately inspect or transform mail while complicating downstream DKIM verification. URL rewriting, attachment replacement and body warnings are possible examples, but the gateway's presence alone proves nothing about a failed signature. Establish which representation entered the gateway, which left it and where authentication was evaluated.
No gateway account or message stream was accessed for this article. Original evidence gate: Original and modified raw messages, signer placement and a before-and-after verification test. These items remain uncollected. The worked case is fictional. Any operational change must preserve the intended security controls and follow the owner's approved process.
Inventory the exact processing sequence
Draw a sequence from message acceptance through authentication, threat inspection, content modification, signing and onward delivery. A service may combine these functions, and several gateways may appear on one route. Record the version and enabled behavior only when supported by the actual configuration. Do not assume that a product always verifies before rewriting, or that its outgoing connector always signs.
RFC 7960 describes boundary filters that remove harmful content, mark suspected spam or alter URLs. It also explains why evaluating authentication after a filter's modifications can produce different results. These are architectural possibilities, not a verdict about a specific tenant. A message trace and preserved copies are necessary to connect the documented mechanism to an incident. RFC 7960 section 3.2.5
Determine what the failed signature covered
For each DKIM-Signature, preserve the signing domain d=, selector s=, canonicalization c=, header list h= and any l= body-length value. The body hash is computed over the selected canonicalized body input; the signature also covers specified header instances. “The gateway changed a header” is incomplete without knowing whether that instance was selected and whether canonicalization preserved the difference. RFC 6376 sections 3.4–3.5 and 5.4
Relaxed canonicalization tolerates particular whitespace and header-formatting changes. It does not treat arbitrary HTML edits, URL substitutions or attachment changes as equivalent content. Conversely, an added field outside the selected coverage need not invalidate an existing signature. Header duplication and oversigning can complicate that assessment, so compare the selected instances rather than only a list of unique field names. RFC 6376 sections 3.4 and 5.4
Compare raw messages without altering the evidence
Use unchanged raw-message files from approved capture points. Rendered screenshots can hide MIME boundaries, encoding changes and folded headers. Re-saving a message through an editor can itself change line endings or serialization, so keep originals and perform analysis on copies. Record capture time, route position and file hashes to connect each sample to the claimed step.
A later failed signature does not establish that the signature was valid before the gateway. RFC 6376 warns that a verifier cannot generally infer prior validity from an invalid signature. The proposed test therefore includes verification of the preserved input as well as the output, with the relevant key and verifier context retained. Otherwise, a preexisting signing error could be misattributed to the gateway. RFC 6376 section 4.2
Work through a fictional URL replacement
Suppose a fictional author-domain signature verifies on a raw input message and covers its entire body. A gateway then replaces a URL in an HTML MIME part with a threat-protection URL. The corresponding output contains different canonicalized body bytes, and a verification attempt reports body-hash mismatch. These assumptions form an illustrative test outcome; no such test ran here.
That comparison supports the narrow conclusion that the observed replacement affected this signature's covered body. It does not imply that every gateway action breaks every signature or that protection should be turned off. An additional signature from gateway.example can authenticate that domain's handling of the modified message, but it does not reconstruct the original author signature or automatically align with an unrelated author domain. RFC 6376 sections 3.4 and 5.1 RFC 9989 section 5.3
Keep ingress results and downstream verification distinct
An organization may rely on authentication performed at its trusted ingress before internal safety transformations. Preserve the evaluator identity and trust boundary behind that result. A downstream receiver evaluating modified bytes may correctly obtain a different DKIM result. Copying an Authentication-Results field into a message does not by itself make that field trustworthy outside the boundary that produced it. RFC 8601 sections 5 and 7
ARC can carry prior assessments through participating handlers, but chain validation and confidence in those handlers remain different questions. RFC 8617 does not make ARC a mechanism for restoring an old DKIM signature. Its published category is Experimental; the reviewed proposal to move ARC to Historic remains an active draft. Do not promise that enabling ARC makes every downstream receiver accept gateway-modified mail. RFC 8617 sections 5.2 and 9.3 IETF proposal status
Place legitimate signing after the intended changes
For outbound mail authored under a domain the organization controls, a supported design may place the authorized aligned signer after final legitimate content changes. Verify that later steps do not modify covered content again. A gateway cannot legitimately sign as an external author's domain merely because it relays that author's message; the relevant domain authorization and key custody must exist. RFC 6376 section 5.1
The review packet should state which control remains active, which processing order is proposed, and how before-and-after verification will be repeated. Do not use reduced body coverage or blanket authentication bypasses merely to produce a green indicator. A successful authorized test would support only its sampled routes and message forms. Original raw pairs, actual signer placement and a controlled verification result are still absent from this draft.