A secure email gateway and DMARC solve overlapping operational problems but are not interchangeable. A gateway may inspect, route, quarantine or modify messages. DMARC evaluates aligned authentication and provides domain policy information to receivers. The important question is how your complete route behaves, including transformations after a signature is created.
Draw the actual message path
Record submission, signing, gateway processing and final receipt in order. Identify which components you control and which identities each is authorized to sign. A diagram that says only gateway enabled cannot establish whether a downstream receiver gets an intact aligned signature. Obtain original and final raw messages from an authorized test route, retaining message identifiers and times.
DKIM covers selected headers and a canonicalized body. A body rewrite can invalidate an existing signature even if the changed link is part of a legitimate security feature. RFC 6376 defines the signature and verification behavior. DKIM specification. Preserve the signed header list, canonicalization choices and any body-length parameter when explaining a specific failure.
Place verification and signing deliberately
An inbound gateway can verify a message before modification, but that internal result is not automatically trustworthy to every downstream recipient. Define how the next system recognizes trusted results and what it does with untrusted header assertions. RFC 8601. A later verifier checking modified bytes may reach a different result for a legitimate reason.
For an outbound route you administer, signing after approved transformations can avoid breaking the final signature. The signer must be authorized for its domain, and alignment still needs evaluation. Adding a valid signature from an unrelated gateway domain does not necessarily produce an aligned DMARC result. Do not remove security inspection simply to preserve a signature without reviewing the wider control design.
Trace a hypothetical rewrite
Suppose an authorized brand.test signer signs a message body containing a URL. A gateway then changes that covered URL without adding an authorized aligned signature afterward. If the canonicalized signed bytes change, the earlier signature will not validate against the changed body. A transformation that leaves the relevant canonicalized signed bytes unchanged need not break the signature. Inspect canonicalization, selected headers and any l= limit instead of assuming every rewrite has the same effect.
If a separate authorized signer signs the final transformed message, that new signature may verify even while the old signature fails. It does not repair the old signature or prove the new signer had business authority. Evaluate the new d= domain’s alignment and the trusted final receiver result. These are protocol-based hypothetical outcomes, not raw message specimens, generated keys, dkimpy output or an executed gateway experiment.
Translate the result into a route test
In production, reproduce the relevant authorized transformation using controlled recipients and the vendor's supported configuration. Capture the final receiver's trusted results rather than inferring success from the gateway console. Compare the same content revision across the route, and note other changes such as subject prefixes or disclaimers. A passing new signature does not prove that earlier authentication survived.
Test failure handling as well. If a signing step is unavailable, determine whether mail queues, fails or leaves without the expected signature. Keep recovery instructions tied to the actual service. Avoid an emergency bypass that turns a contained authentication problem into unrestricted relay or uninspected delivery.
The acceptance record should name the tested route, transformation, signer placement, final identities and receiver result. Maintain separate checks for malware filtering, phishing detection and domain authentication. Passing one test is useful evidence for that capability, not a certificate that the entire message or gateway is safe.
Source and execution boundary
RFC 9989 Sections 4.4, 5.3.5 and 5.4 distinguish authentication, alignment and handling; a pass does not endorse message content. The operational decisions here are scoped recommendations and explicitly hypothetical examples, not new tests of a customer, provider or historical fixture. Any real change requires its own authorized scope, retained evidence and accountable decision.