A security gateway can appear as the source seen by a reporting receiver because it relayed the message. Its appearance does not establish that it created the message, owns the sending application or caused an authentication failure. Investigate the route and the point at which message content changed before making a DNS or gateway-policy change.
Establish the gateway role
References: RFC 9990 §3.1.1.8, RFC 9990 §3.1.1.10.
Draw the intended route from application to final receiving system. Distinguish outbound relay, inbound gateway and forwarding intermediary. Record which organization controls each hop and which hop the reporting receiver actually saw. A familiar gateway hostname is only an infrastructure clue until the route is corroborated.
Preserve source IP, reporter, interval, count, author domain, envelope identity, DKIM domains and reported alignment results. Compare these with authorized gateway logs and trusted receiver evidence. Restrict access to raw messages because they may contain personal or confidential content.
Locate the signing boundary
References: RFC 6376 §3.4, RFC 6376 §3.7.
RFC 6376 defines how DKIM covers selected headers and canonicalized body content. A gateway that changes covered material after signing can invalidate the signature. Not every change necessarily does: the signed fields, canonicalization and exact transformation matter.
Obtain safe representative messages from immediately before and after the suspected transformation when authorized. Preserve their original bytes and compare verification results, selected headers and canonicalized body input. Do not compare screenshots or re-saved text as though they preserve the signed message exactly. Establish whether signing occurred before or after footer insertion, subject rewriting or other processing.
Evaluate SPF separately
References: RFC 7208 §4.1, RFC 9989 §4.4, RFC 9989 §5.3.5.
A downstream receiver evaluates the connecting source against the relevant SPF identity. A relay can therefore change the SPF situation even when DKIM survives. Raw SPF success does not satisfy DMARC if that authenticated identity is unrelated to the author domain under the applicable alignment rule.
DMARC can pass through either a passing aligned SPF or DKIM path. Avoid treating a failed signature as proof of overall DMARC failure without checking the other mechanism. Likewise, do not treat the gateway's own unrelated signature as automatically aligned for the original author.
Work through a controlled comparison
Hypothetical scenario, not an executed test in this review: an application signs for example.com, then an outbound gateway appends a disclaimer. Suppose the receiving test mailbox shows a body-hash failure for that signature. SPF passes for an unrelated service envelope domain. With no other aligned passing mechanism, this example fails DMARC.
The investigation would need to compare retained before-and-after samples and confirm that the covered body changed at the gateway. A proposed repair is to place authorized aligned signing after the intended transformation, using a supported design. That is a candidate solution, not a claim that every gateway offers the feature or that moving a signer is always safe.
Verify the chosen repair
Have the responsible owners approve the design and security implications. Test the actual route with representative content, including templates that trigger rewriting. Confirm aligned authentication at an external receiver and verify the business workflow. Keep security scanning effective; do not disable controls indiscriminately to make a test pass.
Close the incident with the verified route, exact transformation, signing placement, retained test evidence and rollback criteria. If the before-and-after evidence is unavailable, keep the suspected cause tentative and acquire a controlled reproduction. A gateway label alone cannot justify a root-cause conclusion or a broad SPF authorization.