A hybrid deployment can send two messages from the same domain through different external paths. One may leave Exchange Online directly, while another traverses an on-premises server or a gateway. The domain name alone does not identify the system that signed the final message.
Map transport before choosing the DKIM control
Microsoft’s hybrid transport documentation distinguishes direct cloud outbound delivery from centralized mail transport through the on-premises organization. Read the actual connector configuration and transport route, not just the intended architecture diagram. Include cloud mailboxes, on-premises mailboxes and applications submitting through a local relay.
For each path, record the first submission system, any content-changing service, the final public egress system, the envelope domain and expected DKIM signer. Identify where disclaimers, signatures, encryption wrappers or content conversion occur. A signature added before a later transformation may not survive that transformation.
Microsoft explicitly prohibits message-modifying servers, services or devices between on-premises Exchange and Microsoft 365. Its transport guidance also excludes generic SMTP intermediary hosts on that hybrid link, because required transport information can be lost. A firewall that passes SMTP without modification is a different case. The gateway analysis in this guide concerns supported placement on the external delivery path; it does not authorize inserting a modifying gateway into the protected hybrid connection. Resolve an unsupported topology before attempting authentication repairs.
Configure the system that actually handles the route
For mail signed by Microsoft 365, use its domain-specific DKIM configuration and both tenant-generated selector CNAMEs. Confirm signing is enabled after public DNS discovery. Do not assume that enabling Exchange Online DKIM automatically gives an unrelated on-premises or third-party egress server a signing key or applies a signature to messages that bypass the cloud signer.
For an on-premises or gateway signer, establish the actual supported signing component, its documentation, key custody and public-record model. This guide does not assert that every Exchange Server installation has a native DKIM-signing feature. Publish only values generated or explicitly required by the deployed component. A connector authenticated with TLS is not equivalent to a DKIM signature that external receivers can validate.
SPF must authorize the actual external sending infrastructure at the evaluated envelope domain. If some messages leave directly from a local public IP and others from Microsoft 365, represent the legitimate routes in one appropriate policy rather than adding a second SPF record. Review the lookup budget and remove retired routes only after verifying that they no longer send.
Inspect final-hop authentication
Send controlled examples from a cloud mailbox, an on-premises mailbox and an application relay, where those paths exist. Use an external recipient and inspect its trusted Authentication-Results. Record every signature, not just the first d= value. Compare aligned passing SPF and DKIM identities with the visible From domain under the published DMARC alignment modes.
A signed message can still fail if a downstream service changes covered content. Conversely, a valid signature for a gateway-owned domain may not align with the organization’s From domain. These are different failures and require different remedies.
Use a route-by-route acceptance table
Illustrative plan only; no hybrid tenant execution is claimed:
- Origin: Cloud mailbox; Planned route: Cloud to internet; Required evidence: Cloud signing state and final recipient headers.
- Origin: Cloud mailbox; Planned route: Cloud to on-premises to internet; Required evidence: Signature integrity after local transformations.
- Origin: On-premises mailbox; Planned route: Local relay or cloud path; Required evidence: Actual final egress and aligned authentication.
- Origin: Business application; Planned route: Approved local connector path; Required evidence: Application event, relay acceptance and external result.
For a controlled failure example, suppose cloud DKIM initially passes with d=example.com but a later gateway alters the signed body. The final DKIM verification can fail even though the cloud configuration is correct. If the final envelope domain is unrelated and SPF passes only there, that SPF result does not rescue DMARC alignment. Place signing after supported content changes or use another documented compatible route, then retest.
Make route changes safe
Before changing centralized transport, retain connector settings, DNS values and known-good samples. Pilot an authorized recipient population, watch queues and failures, and keep a rollback route. Do not change MX records merely to troubleshoot outbound signing unless the approved design actually requires it.
Retest after hybrid wizard changes, mailbox migration, outbound connector changes, gateway upgrades, new disclaimers, local IP changes and key rotation. The completion record should name the final signing component and evidence for each route. A single green tenant setting is insufficient for a hybrid estate.
Give each route its own owner and rollback
A proposed route record should name the application or mailbox origin, connector owner, last content-changing component, final signer, external recipient evidence and rollback approver. Stop the change if a required hybrid link has an unsupported intermediary. A rollback must restore a supported known-good route, not merely a route that happened to deliver once.