An outbound security gateway or corporate signature service can inspect and modify mail after the application has already signed it. A stable DKIM design places the final authorized signing step after required content changes and verifies the whole route. The important question is which component emits the final message, not which product first displays an enabled DKIM setting.
Draw the actual processing order
Map submission, content inspection, disclaimer or signature insertion, MIME serialization, DKIM signing and external delivery. Include alternate routes used by applications and emergency failover. Do not assume employee mailbox mail and application mail take the same path.
For each component, record whether it changes the body, selected headers, envelope identity or only routing metadata. A corporate email signature block is body content; it is unrelated to the cryptographic DKIM-Signature header despite the shared word “signature.” URL rewriting, attachment handling and HTML rebuilding can also affect covered content.
RFC 6376 §5.3 and RFC 6376 §5.5 require the signer to operate on the intended transmitted representation and modifying re-signers to make changes before re-signing. The design should make that sequencing visible and testable.
Choose the domain and key owner
A gateway may add a valid signature under its own domain. That does not automatically satisfy DKIM alignment for your Author Domain under RFC 9989 §4.4.1. If the required design uses custom-domain signing, verify the product's documented capability, generated DNS values and custody of the private key. Do not invent selector names or copy another tenant's configuration.
Decide who can change signing configuration, rotate keys and alter the final content pipeline. Protect private keys from export into incident notes or test bundles. Publishing a public key is only one part of setup; real outgoing messages must carry a matching signature created after final processing.
Test the pipeline with two controls
Illustrative design A signs first and then appends a corporate contact block. The original full-body signature can fail. Design B inserts the block, completes MIME serialization and then signs with an authorized aligned domain. The intended signature can survive if later processing leaves covered data intact. These are test expectations, not a claim about a named vendor.
Send plain text, HTML, non-ASCII content and an attachment through the intended route. Include application-generated messages and a supported failover route where relevant. Capture the message after the last processor and at a trusted external receiver. Associate each result with d and s rather than accepting an undifferentiated pass label.
Keep security controls in the design
Moving signing later should not silently move inspection outside the protected workflow or bypass required scanning. If the final signer cannot run after a mandatory rewriting service, evaluate supported integrations or a different authorized signing boundary. Avoid using l to exclude later content merely to produce a pass count; RFC 6376 §8.2 explains unsigned-content risks.
A downstream new signature can coexist with an earlier failed one. Confirm which signature provides the intended alignment and how the receiving service reports it. Do not delete evidence of the earlier failure from test records.
Operate the boundary as a change-controlled service
Retain the route diagram, responsible owners, key-retention plan and format test suite. Re-test after gateway upgrades, branding-template changes, routing changes and failover activation. Success requires the intended content, a valid aligned authentication path and correct delivery, with human approval still separate from the technical result.
Record the next decision
For a hypothetical message, record processor order, expected content changes, each d/s pair, receiver verdict and alignment. If the gateway signs only as an unrelated vendor domain, mark aligned DKIM unresolved even if its signature passes. If moving the signer would bypass inspection, stop that design change and seek a supported integration. These are planning criteria, not executed route tests.