Cloud Email Platform Architecture and Configuration
Cloud Email Platform Architecture and Configuration
This domain tests mail-flow design in a cloud email service: how messages enter, which domains the tenant accepts, how connectors and rules route them, and where hybrid coexistence breaks. You must distinguish authoritative, internal relay, and external relay domains.
Core rules
- MX records determine the inbound path. A gateway in front of the cloud platform must be documented in connectors; otherwise mail can loop or fail TLS.
- Accepted domains have a type. An authoritative domain rejects unknown recipients; an internal relay domain forwards unknown recipients to another system; an external relay domain relays to external recipients.
- Inbound and outbound connectors define routing and TLS. Certificate names and SANs must match the target hostname; opportunistic TLS can fall back to plaintext if not enforced.
- Transport rules evaluate conditions and exceptions in priority order. Use them for disclaimers, routing, moderation, and header manipulation, but test for loops and unintended matches.
Worked example
Contoso's MX points to a third-party hygiene gateway, which relays to the cloud tenant. The tenant's accepted domain is authoritative. A message to an unknown alias is rejected by the cloud platform after the gateway accepts it. Fix: make the domain internal relay only if another system hosts the alias, or create the recipient; do not simply add an allow rule.
Traps
- Assuming the cloud platform is always the MX and ignoring gateway connectors.
- Marking a domain authoritative when a legacy system still hosts some mailboxes.
- Forgetting that transport-rule exceptions are evaluated after conditions.
- Enforcing TLS without validating the remote certificate chain.