Enterprise Mail Routing Architecture
Smart hosts, connectors, and routing every domain through one backbone.
Overview
Mail routing architecture is where design decisions become operational reality. Getting it wrong means mail bounces, policies are bypassed, or subsidiaries route outside the gateway entirely. Answer the five questions below with the precision of an architect who will also be the one on call when it breaks.
Read before you answer
Enterprise mail routing architecture is the set of decisions that determine how messages flow between internal systems, outbound through security gateways, and inbound from the internet. The central pattern in large organisations is a hub-and-spoke model: a centralised gateway (Proofpoint, Mimecast, or similar) handles all inbound and outbound traffic for every domain the organisation owns, while internal mail servers (Exchange, Google Workspace) handle mailbox hosting and internal routing. This architecture centralises policy enforcement — all DLP rules, spam filtering, and email authentication signing happen at the gateway, not on individual subsidiary systems — and simplifies operational management because there is one place to look when something goes wrong.
A smart host (also called a relay host or outbound connector) is the mechanism that implements this centralisation for outbound mail. Instead of allowing internal mail servers to deliver directly to external recipients via MX lookup, administrators configure the internal server to route all outbound mail to the gateway via SMTP. The gateway then performs policy checks, applies DKIM signing, and delivers to the recipient. In Microsoft Exchange and Exchange Online, this is configured as a Send Connector (on-premises) or an Outbound Connector in Exchange Online, specifying the gateway FQDN as the smart host. For inbound mail, the gateway is placed in front of the internal server via MX records: the MX record points to the gateway, which filters and then routes clean messages to the internal server via a configured inbound connector or routing rule. The internal server must be configured to accept relay connections from the gateway's IP addresses and should not be publicly reachable on port 25 — this is enforced via firewall rules to prevent gateway bypass.
Connector configuration details matter operationally. Key parameters include: TLS enforcement (whether TLS is required or optional for the SMTP connection), certificate validation (whether the connecting server's TLS certificate must match a specific domain or be issued by a trusted CA), IP restrictions (which source IPs are permitted to relay), and accepted domains (which recipient domains this connector will accept mail for). In complex organisations with multiple subsidiaries, each subsidiary domain must be listed as an accepted domain in the gateway's routing configuration. Misconfigured accepted domains are a common source of NDRs (non-delivery reports) when new domains are added without updating gateway routing. Routing rules or transport rules at the gateway level can further modify message routing based on sender, recipient, content classification, or policy match — enabling different delivery paths for different domain groups or content types.