DNS Fundamentals for Email
How DNS actually routes mail — before you touch a single policy.
Overview
DNS errors are silent until mail stops flowing. Understanding how DNS drives email routing — at the record level, not just conceptually — is the foundation every other email infrastructure skill builds on. Answer the five questions below with the precision a senior administrator would use when diagnosing a live routing problem.
Read before you answer
Every email delivery decision starts with DNS. When a sending mail server needs to deliver a message to user@example.com, it does not know the destination IP address — it queries DNS for the MX (Mail Exchanger) records for the domain example.com. MX records return one or more hostnames with associated priority values (lower number = higher priority). The sending server attempts delivery to the highest-priority MX host; if that fails, it tries the next in the list. The MX record points to a hostname, not an IP address, which means the sending server must then resolve that hostname to an A or AAAA record to get a usable address. This two-step resolution (domain → MX hostname → IP) is fundamental to how SMTP routing works and is the mechanism that lets organisations point inbound mail at a gateway like Proofpoint or Mimecast rather than their internal mail server.
TTL (Time to Live) controls how long DNS resolvers cache a record before querying authoritative nameservers again. For email records, TTL decisions have operational consequences. A high TTL (86400 seconds / 24 hours) reduces DNS query load and speeds up resolution for senders who have cached your MX records, but means that any change — a gateway migration, a failover event, a new MX record — will take up to that TTL value to propagate globally. A low TTL (300–900 seconds) allows faster propagation of changes but increases DNS query volume. The operational practice for planned migrations is to lower TTL to 300 seconds 24–48 hours before the change, make the change, then raise TTL back to the normal value after confirming stability. This ensures the old high-TTL cached records expire quickly while giving administrators control over rollback windows.
Beyond MX, email-specific DNS records include: SPF (TXT record defining which servers are authorised to send mail for the domain), DKIM (TXT record publishing the public key used to verify message signatures), DMARC (TXT record specifying policy for SPF/DKIM failures and a reporting address), and MTA-STS (a policy file accessed via HTTPS that specifies TLS requirements for inbound connections). PTR records (reverse DNS, mapping IP to hostname) are configured by the owner of the IP address range — typically the ISP or cloud provider — and are used by receiving servers to verify that a sending IP has a matching forward and reverse DNS entry. Missing or mismatched PTR records are a common cause of deliverability problems. A senior email administrator needs to understand all of these record types, where they are configured, and how they interact.