Email routing is driven almost entirely by DNS. Before a message can be sent anywhere, the sending MTA needs to answer one question: which host is responsible for accepting mail for this domain?

MX records¶

An MX (Mail Exchanger) record maps a domain to the hostname(s) that accept mail for it, each with a numeric priority (lower number = more preferred):

example.com.    MX    10   mx1.example.com.
example.com.    MX    20   mx2.example.com.

A sending MTA queries DNS for example.com's MX records, gets back both, and tries mx1 first (priority 10). If that fails or times out, it falls back to mx2 (priority 20). Multiple equal-priority records are used for load balancing (the client picks one at random or round-robins).

If a domain has no MX record at all, RFC 5321 says the MTA falls back to the domain's A/AAAA record directly — this is the "implicit MX" rule, and it's a common source of confusion for small setups that never bothered adding an explicit MX record and rely on this fallback.

PTR records (reverse DNS)¶

While MX records tell a sender where to send mail, PTR records (reverse DNS) are what a receiver checks about the sender: they map an IP address back to a hostname. A huge number of receiving mail servers will reject or heavily penalize mail from an IP with no PTR record, or where the PTR hostname doesn't plausibly match the sending server's HELO/EHLO name. This is one of the most common reasons a self-hosted mail server on a residential/dynamic IP or a generic cloud VM gets its outbound mail silently dropped — and it's why so many of the notes distilled into this guide end up routing outbound mail through a smart host (Gmail, Mailgun) rather than sending directly: a home connection or a fresh VM IP essentially never has usable reverse DNS, no matter how correctly Postfix itself is configured.

Relaying vs. final delivery¶

Two fundamentally different things an MTA can do with an accepted message:

• Final delivery — the MTA is authoritative for the recipient domain (it's listed in mydestination or virtual_mailbox_domains in Postfix terms) and hands the message to a local mailbox.
• Relaying — the MTA is not authoritative for the recipient domain, but forwards the message on toward its actual destination anyway.

Relaying is necessary and normal (every hop of every message not delivered in a single leap is a relay), but unrestricted relaying — accepting mail from anyone, for any destination, and forwarding it — is what makes a server an open relay, and open relays get bounce-flooded, blacklisted, and abused for spam within hours of being discovered. Nearly every Postfix smtpd_recipient_restrictions configuration exists specifically to define which combinations of sender/network/authentication are allowed to relay through the server, and to reject everything else with reject_unauth_destination.

Smart hosts / relay hosts¶

A smart host (Postfix calls this a relayhost) is a single designated MTA that all outbound mail is unconditionally routed through, rather than each message being routed by looking up the destination's own MX record. This is the pattern behind every "relay through Gmail/Mailgun" setup in this guide: instead of your server trying to establish its own sending reputation (fighting the PTR-record problem above, warming up an IP's reputation, etc.), it authenticates to a provider that already has that reputation and hands off delivery entirely.

Split-horizon / internal vs. external views¶

Not covered in depth in the personal notes here, but worth knowing: larger or more careful setups sometimes run split-horizon DNS, where internal clients resolve a domain's MX/A records to an internal mail server while external senders resolve the same name to a different, internet-facing one. This is a DNS-server concern, not a Postfix one, but it explains why "local network mail server" setups (see the Postfix administration/relay docs) sometimes need explicit /etc/hosts entries or internal-only DNS zones rather than relying on public DNS for intra-LAN mail routing.