Routing a Post-Acquisition Domain Through a Central SMTP Gateway
Northwind Health has 6,200 mailboxes in Microsoft 365 and acquires a 900-user clinic group running Google Workspace. For 9 months, both tenants must coexist. The clinics keep their domain clinic.example, while Northwind uses northwind.example. A legacy scheduling system in the clinic sends 4,000 transactional messages per day via an on-premises SMTP relay at 10.20.4.15 that cannot do TLS 1.2. Northwind's security team requires all inbound mail to pass through its cloud secure email gateway (SEG), but the clinic's Google Workspace MX records currently point directly to Google. Internal calendar invites between the two domains must resolve; the acquired staff appear in the global address list only after a directory sync. The CIO wants no mail loops, no duplicate delivery, and a single outbound IP reputation. The clinic's IT lead worries that changing MX records will break the scheduling system's notifications.
1. What mail routing architecture would you propose for the coexistence period, and how would you prevent loops and duplicate delivery?
Read the worked answer
Use the SEG as the single inbound MX for both domains and as the outbound smarthost for both tenants, but keep mailboxes where they are. Concretely:
- Publish MX for northwind.example and clinic.example to the SEG.
- SEG delivers northwind mail to Microsoft 365 and clinic mail to Google Workspace via separate inbound connectors scoped by recipient domain.
- Both tenants send outbound to the SEG as a smart host, authenticated by IP or TLS certificate; the SEG applies one outbound IP reputation and DLP.
- For tenant-to-tenant mail, let it route through the SEG rather than creating direct cross-tenant connectors. Internal-looking mail will traverse the SEG twice if both sides send outbound through it, so use a dedicated inter-tenant connector on the SEG that delivers directly to the other tenant and does not re-enter the outbound path.
Loop prevention: scope each connector by recipient domain, add a custom header (for example X-Central-SEG) and drop any message that already carries it, and avoid dual delivery unless journaling requires it. Duplicate delivery usually comes from leaving the old MX active during propagation or from a tenant's outbound connector pointing to the other tenant instead of the SEG.
This meets the CIO's requirements: one inbound inspection point, one outbound reputation, and no direct tenant-to-tenant path that bypasses policy.
2. How would you handle the legacy SMTP relay and its lack of TLS 1.2 without violating the security requirement?
Read the worked answer
The clinic relay is an outbound transactional source, not inbound mail, so the 'all inbound through SEG' rule does not force it to terminate TLS 1.2. Still, do not simply open an anonymous relay. Options in order of preference:
- Put the relay behind the SEG as a scoped outbound connector: allowlist 10.20.4.15, require SMTP AUTH or IPsec, and accept opportunistic TLS on that one connector. This keeps the relay working while the SEG still applies outbound policy and reputation.
- If the relay must send to internal recipients, route it to an internal receive connector on the SEG that only accepts from that IP and only for the clinic domain.
- Treat TLS 1.0 as a documented, time-bound exception: log every session, restrict the connector to the relay IP and the scheduling vendor's recipient domains, and set a remediation date to replace or front the relay with a TLS 1.2-capable smart host.
If the relay sends external notifications containing patient data, the exception is not acceptable; require the vendor to upgrade or move notifications to an API. The judgement is to isolate the weak protocol to the smallest possible source and destination set rather than lowering tenant-wide TLS.
3. What signals would you monitor to declare the coexistence routing stable, and what would trigger rollback?
Read the worked answer
Monitor SEG connector queue length, duplicate message IDs, messages hitting the loop-drop rule, TLS failures on the relay connector, and mail-flow latency between tenants. Also track SPF and DMARC results on inter-tenant mail because the SEG rewrites the path.
Rollback triggers: a sustained increase in duplicate deliveries, any message loop that exceeds a threshold, scheduling notifications failing, or clinic users not receiving internal invites. Rollback should be DNS-only for inbound (restore Google MX) and connector disablement for outbound, not a full re-architecture. Document the exact order because MX TTL and cached connections mean rollback is not instant. Declare stable only after a full week with no unexplained queue growth and no user-reported calendar failures.