Cloud Email Architecture and Deployment Models
Domain 1 tests how a cloud email service is laid out: where mail enters, how a namespace is shared with legacy systems, and which component is authoritative for a given recipient. Expect scenario questions that describe a topology and ask what happens to a message at each hop, or which record an administrator must change.
The building blocks
- Edge layer – the first SMTP hop. It may be the provider's inbound stack, a third-party secure gateway, or an on-premises transport/Edge server. Whoever holds the MX record makes the first routing decision.
- Mailbox layer – accepted domains, each typed as authoritative, internal relay, or relay; plus per-recipient routing objects such as remote mailboxes and target addresses.
- Directory authority – cloud-only, synchronised (password hash, pass-through, federation), or hybrid with writeback. Source of authority decides which console owns an attribute.
- Connectors – inbound connectors scoped by certificate or IP, outbound connectors to a smart host, and TLS enforcement settings on each.
Coexistence patterns
- Gateway-in-front: MX points at a hygiene appliance that forwards to the cloud; outbound exits through the same appliance for a consistent IP reputation.
- Direct-to-cloud: MX points at the provider, and on-premises users are reached through a connector scoped to their address space.
- Journaling or dual delivery: required while archiving and compliance systems still expect a copy of every message.
Worked example
A 2,000-seat Exchange organisation migrates a 500-user pilot to a cloud tenant while both share contoso.com. Keep MX at the existing gateway. Create remote mailbox objects for pilot users with target addresses so the gateway routes their inbound mail to the tenant. Add an outbound connector from the tenant back to the gateway, scoped by certificate, so pilot mail still leaves through the corporate edge. Reasoning: with a shared namespace the cloud cannot authoritatively claim the whole domain, so per-recipient routing preserves one address space, keeps SPF-aligned egress IPs, and avoids mail loops between the two systems.
Traps
- Assuming MX moves on day one of a migration; coexistence usually keeps MX elsewhere.
- Forgetting that a synced object's source of authority changes which tool you use to edit it.
- Confusing authoritative with internal relay accepted domains, which changes how unknown recipients are handled.
- Ignoring Autodiscover split-brain, where on-premises service connection points and DNS records point clients at different systems.