Mail Loop After a Shared-Domain Migration
Fabrikam (fabrikam.example) runs Exchange Online for 8,000 users. Inbound mail flows through a third-party secure email gateway (SEG), then to Exchange Online; outbound goes directly from Exchange Online. MX records point to the SEG. A recent acquisition added 1,200 mailboxes in a separate tenant; a shared address space domain was moved to the primary tenant, but an SMTP connector still routes that domain's mail to the acquired company's on-premises Exchange 2016. Since the cutover, users report NDRs '5.4.6 or 5.3.5 loop detected' and delayed mail. The SEG's IPs are in the SPF record; the acquired company's on-premises server is not. Autoforwarding to external addresses is enabled for VIPs. Microsoft 365 Defender shows a spike in 'tenant-to-tenant' inbound messages. The acquired company's IT says its server is only for archive retrieval.
1. Diagnose the loop. What routing contradiction exists, and what evidence would you collect to confirm it?
Read the worked answer
The loop is a routing contradiction, not an authentication failure. The domain is authoritative in the primary Exchange Online tenant, but an SMTP connector still scopes that domain to the acquired company's on-premises Exchange 2016. Mail reaches the SEG, is delivered to Exchange Online, and Exchange Online's connector hands it to on-premises. The on-prem server either has the domain as accepted but lacks the recipient, or forwards unresolved mail back toward the SEG/Exchange Online, producing 5.4.6/5.3.5 loop NDRs. The tenant-to-tenant spike suggests messages are also being re-injected between tenants.
Evidence: message trace with every connector hop and enhanced status code; connector scope (recipient domains); accepted domains in both tenants; on-prem send connectors and forwarders; and the SEG's inbound/outbound logs for the affected domain. Confirm whether the on-prem server is authoritative for the domain or merely relaying.
Fix: scope the connector to the specific archive mailboxes or remove it entirely. Do not route an entire authoritative domain to a non-authoritative server. If archive retrieval is required, use journaling or export rather than live SMTP.
2. Design the target mail routing for this domain and list the changes needed to get there safely.
Read the worked answer
Target state: MX -> SEG -> Exchange Online inbound only; Exchange Online outbound either direct or via the SEG, but one deterministic path. The acquired domain should be authoritative in the primary tenant only.
Changes:
- Remove the domain from the acquired tenant's accepted domains and from the connector's scope in the primary tenant.
- Keep the SEG as the sole inbound path; ensure the SEG outbound connector targets Exchange Online and is restricted to inbound delivery, not open relay.
- If outbound goes direct, publish SPF including the SEG and Exchange Online. Do not add the on-premises server unless it actually sends mail.
- Configure DKIM signing for the domain in Exchange Online so alignment does not depend on the on-prem path.
- For archive retrieval, use a separate mailbox import/export or journaling solution, not live mail routing.
- Validate with message trace and external seed accounts before removing the old connector, and keep a rollback plan.
3. VIP external autoforwarding is enabled and tenant-to-tenant re-injection is occurring. How should both be addressed?
Read the worked answer
External autoforwarding for VIPs is both a data-exfiltration path and a loop amplifier. Replace the blanket allowance with a remote-domain policy that blocks external auto-forward by default, permits only approved partner domains, and requires documented exceptions. Audit existing inbox rules for external forwarding, especially on VIPs. For tenant-to-tenant mail, disable automatic re-injection unless there is a documented business need; cross-tenant collaboration should use shared channels or guest access rather than SMTP forwarding.
The reasoning is that both settings create alternate delivery paths outside the intended SEG-to-Exchange Online flow. Each alternate path can re-enter the system and produce loops, and each weakens message-trace visibility. After changing the policy, re-test with a VIP mailbox and confirm that blocked forwards generate a visible NDR rather than silent loss.