Table of Contents
Why Email Routing Matters
Email routing decides how a message travels from a sender to a recipient and which servers handle it along the way. As a server administrator you must understand how routing choices affect deliverability, reliability, security, and compliance. This chapter focuses on how messages are directed across domains and servers, not on the detailed configuration of individual mail transfer agents, which belongs in their specific chapters.
Email routing is mostly about three questions. First, where should mail for a domain be delivered. Second, which server is allowed to send mail for that domain. Third, how to move mail between internal systems and external networks in a controlled way.
The Path of an Email
When someone sends a message to user@example.com, the sending system must find out which server accepts mail for example.com. It does not guess. It performs a DNS query and follows specific rules that come from the SMTP standards.
At a high level, the path involves a mail user agent that the person interacts with, such as a webmail interface or a local mail client, and one or more mail transfer agents that move the message between servers. There may also be submission agents and relays in the path, each with a role in enforcing policy, security, or routing rules.
A message may pass through several servers before it reaches the final delivery agent that writes it into a mailbox or passes it to another subsystem. At every step, routing decisions are made based on the recipient address, local configuration, DNS information, and sometimes content policies.
DNS and MX Records
DNS is fundamental to email routing. For each domain that receives mail, DNS can publish Mail Exchanger records that tell the world which hostnames accept incoming email.
A domain can have multiple MX records, each with a priority value called preference. The SMTP standard uses these preference values to define an ordered list of target hosts. Lower numbers have higher priority. The sending server will try the host with the lowest preference value first.
If a domain has no MX records, SMTP falls back to using the A or AAAA record of the domain itself, but this is not recommended for production systems.
For reliable and standards compliant email routing, always publish correct MX records for your mail receiving domains and do not rely on A or AAAA fallback.
Because MX records point to hostnames rather than IP addresses, you can change the IPs behind those hostnames without changing the MX values. This separation is useful for maintenance, failover, and load balancing.
Priority, Failover, and Load Distribution
Multiple MX records allow controlled failover and distribution of incoming traffic. Each MX record has a preference value and points to a host. When a sending MTA connects, it follows a defined order.
First, the sender collects all MX records for the domain and sorts them by preference, lowest preference value first. Second, it attempts to connect to one of the hosts with the lowest value. If that connection fails or the host reports a temporary error, the sender moves on to the next host. This process continues until a successful delivery or until all options have been tried.
If several MX records share the same preference value, the sender is supposed to choose randomly among them or rotate through them. This gives you simple load distribution. You can put two MX hosts at preference 10 to share normal traffic, and a third at preference 20 as a backup that is used only if the primary layer is unavailable.
You can design multi tier mail topologies with this mechanism. For example, MX hosts with the lowest preference can be anti spam gateways or filtering appliances. These then relay accepted mail to internal servers that are not visible as MX targets.
Direct Delivery vs Smarthost and Relay
Email routing inside your infrastructure must choose between direct delivery and relayed delivery. Direct delivery means that your outbound server connects to recipient MX hosts on the internet itself. Relay based delivery means that local systems hand off all or some outbound mail to another server, often called a smarthost or relay host.
Smarthosts simplify administration and security. A managed relay can perform outbound spam filtering, outbound DKIM signing, rate limiting, and IP reputation management. Your internal servers do not need to be reachable from the internet and may not need public IP addresses. They route all external mail through the smarthost instead.
Routing decisions for relaying are often based on recipient domains. For example, your internal Groupware server may relay all non local domains to a smarthost controlled by the provider, while delivering local domains directly. This separation lets you keep internal mail traffic on your private network while still being able to talk to external recipients through a controlled gateway.
Internal vs External Routing
In many organizations, email routing is split between internal and external views. Internally, your mail system may handle many domains and aliases that never appear directly on the public internet. Externally, only a subset of domains is routed through internet facing MX hosts.
Internal routing often uses transport maps and virtual alias maps. These configuration structures let you say that mail for user@corp.example goes to one internal host, while mail for user@example.com is routed differently. Internally, routing may resolve to user accounts, mailboxes, or functional addresses across multiple systems such as ticketing or CRM platforms.
External routing must respect DNS records and internet mail standards. Mail for external domains uses DNS MX lookups. Mail for your own public domains is normally routed directly to your own hosts, bypassing external MX resolution. The separation between internal and external routing is enforced by policies on edge MTAs that know which domains are local and which are remote.
MX vs SPF and Other DNS Controls
MX records tell the world where to send mail for your domain. Other DNS records influence how receiving systems treat mail that claims to be from your domain. These record types do not route mail, but they affect acceptance and trust.
SPF records list which servers or IP ranges are allowed to send mail using your domain in the envelope sender. DMARC records describe policy for handling mail that fails alignment checks between SPF and DKIM. DKIM records publish public keys used to verify that a message was signed by an authorized system.
Routing interacts with these records. If you route outbound mail for your domain through a third party relay, that relay's IPs must be included in your SPF policy and have the correct DKIM keys. Otherwise recipients may reject or flag your messages. When designing outbound routing, always check that DNS based sender policies match the real sending path.
Route Selection and Transport Maps
Inside a mail server, routing logic can become quite detailed. Administrators use transport maps and routing tables to define how messages should leave the system depending on the recipient address or domain.
A transport map associates patterns such as a full domain, a subdomain, or even specific addresses with a delivery transport and target host. Here, delivery transport means a defined method such as direct SMTP based on MX lookup, or forced relay through a particular host. This lets you override normal MX resolution for specific domains.
For instance, you may send @partner.example through a dedicated relay over a VPN instead of over the public internet. A transport map entry for partner.example can force all such messages to use a particular internal route. You might also use this mechanism to route sensitive internal domains through encrypted tunnels or to send particular traffic through compliance archiving systems.
Relaying Policies and Open Relay Risks
Relaying is necessary for legitimate email routing, but it is also a common source of abuse. An open relay is a server that will accept mail from anyone and forward it to any destination. Spammers actively search for open relays to hide the real source of their messages.
Proper routing configuration must include relay access controls. A well configured server only relays for authenticated users or trusted networks. It refuses to relay arbitrary traffic from unknown clients. You define which client IP ranges or authenticated identities are allowed to submit messages for external destinations. Messages for your own local domains may be accepted from the internet, but that is not considered relaying because delivery ends on your system.
Misconfigured relaying policies can result in your server being blacklisted on spam block lists. This affects outbound deliverability and may require a long cleanup process. When you design routing, always consider who is allowed to send to whom through each path.
Never operate an SMTP server that relays mail from the internet to arbitrary external domains without authentication or explicit access control, or it will become an open relay and will almost certainly be abused.
Multi Domain and Multi Tenant Routing
Many servers host email for multiple domains at once. This multi domain or multi tenant setup relies on routing logic that understands which domains are local and how to separate them. DNS for each domain points MX records to your server, but inside the server you may route each domain to different virtual mailbox structures or even different backend systems.
You may use domain based routing to direct messages for one customer to a cluster in one data center and messages for another customer to a different cluster. The front end MX servers accept mail for all hosted domains and act as a routing layer toward the correct internal destination, using configuration maps to relate each domain to a backend.
Internal routing must keep tenant data separated. For example, a catch all rule for one domain should not affect another. When you manage routing in this context, you think in terms of domains and namespaces, not only individual accounts.
Role of Gateways, Filters, and Archives
In many environments, a message does not travel directly from public MX to final mailbox. Instead, it passes through specialized gateways and filters. These systems might perform spam filtering, virus scanning, compliance checking, encryption, or archiving. Routing must be arranged so that these components see the messages in the correct sequence.
Edge gateways often appear as MX hosts and then relay accepted messages to internal mail servers. Sometimes, outbound mail is also routed through these devices so they can enforce outbound policies and maintain archival copies. In such designs, the internal servers may never communicate directly with the internet.
Forwarding chains can be more complex, for example when external compliance archives require that a copy of every message is routed to a separate archive address. This is implemented through BCC style routing rules that send a copy of the message to an additional destination while still delivering the original to its intended recipient.
Address Rewriting and Forwarding
Routing is not always based on the original address written by the sender. Many organizations use aliasing and forwarding rules that rewrite addresses on the fly. This may involve mapping public addresses to internal usernames or redirecting mail for a role address such as support@example.com to a ticketing system.
Aliasing means that several external addresses route to the same mailbox or internal account. Forwarding means that mail for one address is sent on to other addresses, possibly in different domains. For instance, a user may forward all mail from a corporate address to a personal account. When you design forwarding, you must be careful not to create routing loops. A loop occurs if forwarding rules cause a message to bounce back and forth between systems.
Routing logic must also respect headers and envelope details when rewriting. Some systems preserve the original recipient in special headers to help downstream software know how a message was addressed before it was routed internally.
Special Cases and Routing Pitfalls
There are several routing related edge cases to be aware of. One common problem is misdirected internal routing when a domain is both hosted locally and used externally, such as example.local inside your network and example.com publicly. If internal clients send mail to user@example.com but your resolver has a split horizon DNS that overrides public records, routing may take an unexpected path.
Another pitfall is partial migration. During a move from one provider to another, MX records might point to the new provider while some mailboxes still exist on the old one. During the transition, you can use routing rules and targeted forwarding between providers. The key is to carefully define which server has authority for which subset of addresses at each moment, and to phase changes while monitoring for unexpected bounces or loops.
Finally, routing can interact poorly with aggressive spam filtering if intermediate hops modify messages, such as rewriting subjects or adding disclaimers. If downstream systems treat such modifications as suspicious, your routing design may unintentionally reduce deliverability. In critical paths, test how intermediate gateways affect message content and authentication details like DKIM signatures before broad deployment.
Conceptual Summary
Email routing brings together DNS based address location, internal policy decisions, and transport mechanisms. MX records tell the world where mail for your domain should go. Internal routing tables and transport maps decide how it moves inside your infrastructure and when to use direct delivery, relays, and gateways. Authentication and authorization policies prevent abuse of your routing paths.
A clear understanding of these concepts prepares you to configure and troubleshoot real world deployments with software such as Postfix or Exim, and to interpret errors and logs when messages do not arrive where they should.