5.3.5 Email routing concepts

Key Ideas in Email Routing

Email routing is about how MTAs (Mail Transfer Agents) decide where to send a message next, and how to get it there. In the Email Services section, you’ve seen components like SMTP, Postfix, and spam filtering; here we focus on the decision‑making and flow of messages between servers.

This chapter will use generic examples and some Postfix terms, but the configuration details of specific MTAs (like Postfix) belong in their own chapters.

Basic Message Flow and Roles

At a high level, an email may pass through several roles:

• MUA (Mail User Agent)
  The client (e.g., Thunderbird, Outlook, webmail) used by the user; it hands off mail to an MSA.
• MSA (Mail Submission Agent)
  Typically port 587 with authentication; accepts mail from users of a domain and enforces submission policies.
• MTA (Mail Transfer Agent)
  Routes email between servers (port 25). Examples: Postfix, Exim, Sendmail, qmail.
• MDA (Mail Delivery Agent)
  Delivers mail into user mailboxes (Maildir, mbox, LMTP to Dovecot, etc.).

Routing concepts are mainly about what MTAs and MSAs do with a message: which next hop to choose, and how.

Addressing and Domains in Routing Decisions

Envelope vs. Header Addresses

Routing is based on the SMTP envelope, not the message headers:

• Envelope sender: MAIL FROM:<sender@example.com>
• Envelope recipient(s): RCPT TO:<user@domain.tld>

Headers like From: or To: can be different and are mostly for display; routing logic cares about the envelope.

Local vs. Remote Domains

An MTA must distinguish between:

• Local domains
  Domains for which this server is authoritative and should deliver mail locally (hand to MDA).
• Relay domains
  Domains that this server should accept mail for and then forward elsewhere.
• Remote domains
  Domains that are not handled locally or as relays; the MTA must look up MX or A records and send mail over the Internet.

Routing rules typically begin with:

1. Is the recipient domain local?
2. If not, is it a relay domain?
3. Otherwise, treat as remote and resolve via DNS.

---

DNS and MX in Email Routing

MX Records and Priority

For a domain like example.com, DNS may contain:

• MX 10 mail1.example.com.
• MX 20 mail2.example.com.

Key points:

• MTAs look up MX records for the recipient domain.
• Lower MX preference values have higher priority.
• If multiple MX records have the same priority, MTAs usually randomize among them (for load distribution).
• If no MX exists, MTAs fall back to an A or AAAA record for the domain itself.

Backup MX and Store‑and‑Forward

A backup MX is a secondary server with a higher preference value (numerically larger) that:

• Accepts mail when the primary MX is down or unreachable.
• Stores messages in its queue.
• Periodically attempts delivery to the primary.
• Eventually bounces mail if it can’t deliver after a configured time.

Routing considerations:

• Backup MX must be configured to relay only for the protected domain(s).
• Spammers often abuse misconfigured backup MXs; ensure strict relay rules and spam filtering.

---

Inbound vs Outbound Routing

Inbound Routing (Mail Coming *Into* Your Domain)

Typical inbound path:

1. Remote MTA looks up MX for yourdomain.tld.
2. Sends mail to your MX (may hit load balancer, anti‑spam/AV gateway, etc.).
3. Your MX decides:
• If domain is local: hand to MDA (e.g., LMTP to Dovecot).
• If domain is a relay target: forward to an internal mail server.

Important concepts:

• Front‑end vs back‑end MTAs
• Front‑end (edge, gateway): exposed to the Internet; handles anti‑spam/AV, DMARC/DKIM checks, greylisting, etc.
• Back‑end: internal, holds mailboxes, often not externally reachable.
• Internal routing
  Within your network, routing is often based on:
• Domain or subdomain (e.g., user@dept.example.com → specific internal server)
• User mapping (aliases, virtual domains, LDAP lookups)

Outbound Routing (Mail Going *Out* of Your Domain)

Outbound path:

1. Users submit mail via MSA (auth on port 587 or 465).
2. The MSA applies policies (authentication, authorization, rewriting).
3. Outbound MTA chooses how to route:
• Directly to recipient MX over the Internet.
• Via a smarthost / relay (common in corporate or cloud environments).

Considerations:

• Smarthosts used for:
• Centralized logging and policy enforcement.
• IP reputation management and rate limiting.
• Compliance (e.g., journaling, legal hold).
• Split routing (different paths depending on destination):
• Internal domains: route via an internal hub.
• External domains: route via a cloud email gateway or ISP smarthost.

---

Relaying and Open Relay Prevention

What Is Relaying?

Relaying = accepting mail where sender and recipient domains are not local and forwarding it on.

Example:

• Your server at mail.company.com receives mail from user@random.net to user@another.com.
• If you accept and forward this, you are relaying.

Legitimate scenarios:

• Authenticated users sending mail to others on the Internet.
• Partner systems allowed to send via your relay.
• Internal servers (e.g., printers, apps) sending notifications.

Open Relay

An open relay is an MTA that:

• Accepts mail from anyone to anyone, without authentication or constraints.

Consequences:

• Will be used for spam.
• IPs/domains will quickly land on blacklists.
• Deliverability to major providers will be severely impacted.

Routing‑related protections:

• Only relay:
• From authenticated users, or
• From trusted IP ranges (e.g., internal networks), or
• For explicitly allowed recipient domains (backup MX, partner domains).

---

Internal vs External Routing Topologies

Single Server

For small setups:

• One host acts as MX, MSA, MTA, MDA.
• Simple routing rules:
• Local domains → local delivery.
• Everything else → direct Internet delivery.

Edge/Hub Model

Common in medium/large organizations:

• Edge MTAs:
• Public MX records.
• Perform filtering, throttling, TLS termination.
• Route accepted messages for example.com to internal hubs.
• Hub/Relay MTAs:
• Not public; receive mail from edge and internal systems.
• Route to mailbox servers or out to the Internet (for outbound).

Routing examples:

• Edge → Hub:
  RCPT TO:user@example.com → hub.example.com (fixed internal next hop).
• Hub → Internet:
  RCPT TO:user@external.com → resolved via MX, or via outbound relay/smarthost.

Hybrid and Cloud Gateways

Organizations using hosted filtering / cloud email gateways (e.g. proofing or SaaS gateways):

• MX records point to the cloud service, not directly to on‑prem server.
• Cloud service routes:
• Inbound mail to on‑prem or cloud mailboxes.
• Outbound mail from on‑prem servers to the Internet.

Routing impacts:

• Ensure only mail for your domains is relayed from cloud to your servers.
• On‑prem MTAs may be configured to send all external mail only through the cloud relay.

---

Routing Based on Recipient and Sender

Recipient‑Based Routing

MTAs can select next hops based on:

• Domain:
• @example.com → internal mail cluster
• @example.org → partner gateway
• Subdomain:
• @sales.example.com → sales mail server
• @support.example.com → ticket system
• Address‑level routing:
• billing@example.com → finance system
• devops@example.com → ticketing platform

These may use:

• Alias maps
• Virtual domain maps
• LDAP or SQL lookup tables

Sender‑Based Routing

Less common but useful:

• Different outbound route depending on sender:
• *@marketing.example.com → email marketing provider (ESP) relay.
• *@alerts.example.com → monitoring‑specific relay.
• Executive accounts → high‑reputation outbound IP pool.

Use cases:

• Compliance (certain units must use specific gateways).
• Reputation management (bulk vs transactional email separate).
• Geographic routing (route by business unit’s location).

---

Policy Routing and Security‑Driven Decisions

Routing is not only about “where,” but also “whether”:

• Policy checks can cause:
• Immediate rejection.
• Temporary deferral (4xx) to slow suspicious senders.
• Acceptance then quarantine rather than routing to final mailbox.

Examples:

• SPF/DMARC failure → reject or route to a quarantine system.
• High spam score → deliver to spam folder via a different internal path.
• Attachment type → route through sandboxing/AV gateway.

In complex environments, routing decisions may involve:

• Sender reputation.
• Authentication (SPF, DKIM).
• Sender/recipient pair policies.
• Time of day / load conditions (rate limiting, greylisting).

---

Alias, Forwarding, and Distribution Lists

These mechanisms influence routing within a domain:

• Aliases:
• support@example.com → alice@example.com, bob@example.com
• Forwarding:
• User mailbox that forwards to another address (local or external).
• Distribution lists / mailing lists:
• One address expands to many recipients, possibly across domains.

Routing implications:

• One incoming RCPT TO: can turn into many individual deliveries.
• MTAs must:
• Rewrite or preserve headers correctly.
• Avoid mail loops (forwards bouncing between systems).
• Handle bounce routing correctly (Return‑Path, envelope sender).

---

Special Routes: Smarthosts and Transport Maps

Smarthosts

A smarthost is an intermediary relay that all or some mail is sent through, regardless of the destination domain.

Uses:

• Use ISP’s SMTP relay when you cannot send directly on port 25.
• Central organization relay cluster in large enterprises.
• Outbound filtering / DLP / logging.

Typical logic:

• “For all domains, send via relay.isp.net.”
• Or: “For all external domains, send via outbound.company.com; internal domains deliver directly.”

Targeted Transports

Transport rules allow fine‑grained routing for specific destinations:

• @partner.com → smtp:partner-gateway.local:25
• @internal.example.com → lmtp:mailbox-cluster.local:24

This enables:

• Partner‑specific next hops (VPN, dedicated links).
• On‑prem vs cloud mailbox routing.
• Special ports or protocols (LMTP vs SMTP).

---

Loop Prevention and Bounce Handling

Loop Prevention

Misconfigured routing can create loops:

• Server A forwards mail for user@example.com to server B.
• Server B, thinking example.com is not local, relays back to A.

Mechanisms to avoid loops:

• Correct configuration of local and relay domains.
• Hop count checks using:
• Received: header count
• Built‑in loop detection (e.g., same host appears repeatedly in Received: chain).
• Time‑to‑live in queues: messages are eventually bounced instead of looping forever.

Bounces and Non‑Delivery Reports (NDRs)

When routing fails permanently:

• MTA must generate a bounce to the envelope sender or drop silently (for certain spam).

Common routing‑related causes:

• No valid MX or A record for recipient domain.
• Destination server repeatedly returns 5xx errors.
• Local configuration: unknown user/domain, refused relay.

Good practice:

• Include a meaningful diagnostic in NDRs.
• Avoid backscatter: don’t generate NDRs for spam with forged senders; reject at SMTP time instead.

---

High Availability and Load Distribution in Routing

Routing is central to HA strategies:

• Multiple MX records:
• Distribute inbound load.
• Provide redundancy if one MX fails.
• DNS‑level load balancing:
• Multiple A/AAAA records for the same hostname.
• Application‑level distribution:
• MTAs configured with multiple next hops and round‑robin/failover behavior.

Routing policies typically specify:

• Primary paths and fallback paths.
• Behavior when a next hop is:
• Down (TCP failure).
• Temporarily refusing mail (4xx).
• Overloaded (rate limiting).

---

Putting It Together: Common Routing Patterns

Small Business Scenario

• Single VPS: acts as MX, MSA, and MTA.
• Direct MX for example.com to this VPS.
• Routing:
• example.com → local delivery.
• All other domains → direct outbound via MX lookup (no smarthost).

Corporate with Cloud Gateway

• MX → cloud filtering service.
• Cloud routes:
• @corp.example → on‑prem mail servers via VPN.
• @subsidiary.example → Microsoft 365 tenant.
• Outbound:
• On‑prem → cloud gateway (smarthost) → Internet.
• Some apps → internal smarthost for logging first → cloud.

ISP/Hosting Provider

• Front‑end MX pool → per‑customer back‑end clusters.
• Routing logic uses:
• Virtual domain maps: domain → cluster.
• Recipient lookups in databases.
• Outbound uses:
• Multiple IP pools with sender‑based routing (transactional vs bulk).

These patterns are all implementations of the same routing concepts: local vs remote domains, DNS lookups, explicit transport rules, and policy‑driven decisions.

By understanding these routing concepts—domains, MX records, local vs relay vs remote handling, smarthosts, policy‑based decisions, and loop prevention—you can design and troubleshoot complex email flows regardless of the specific MTA you use. Configuration details for Postfix, Dovecot, and others build directly on these fundamentals.