Infrastructure

DNSDomain Name System

Definition

DNS (the Domain Name System) is the internet’s distributed directory: it translates human-readable names like example.com into the IP addresses machines actually connect to. Defined in RFC 1034 and RFC 1035, it is also where almost every email control lives: your MX, SPF, DKIM, and DMARC records are all DNS entries.

  • Translates domain names into IP addresses through a hierarchy of name servers
  • Holds every email authentication record: MX, SPF, DKIM, and DMARC
  • Answers are cached for a TTL (time to live), so changes are not instant
  • A single wrong or missing record can silently break mail delivery
At a glance
Stands for Domain Name System
Defined in RFC 1034 & RFC 1035 (1987)
Port UDP/TCP 53
Email records MX, TXT, A, AAAA, PTR
Caching Per-record TTL in seconds
Structure Hierarchical, from the root down

How a DNS lookup works

DNS is a hierarchy. At the top sit the root servers, below them the top-level domain (TLD) servers for .com, .org, and the rest, and below those the authoritative name servers that actually hold your domain’s records. When a program needs the IP for mail.example.com, a recursive resolver (usually run by your ISP or a service like 8.8.8.8) walks that chain on its behalf and returns the answer.

To keep the system fast, every answer carries a TTL, a time-to-live in seconds that tells resolvers how long they may cache it before asking again. That cache is why a DNS change is never instant: a record with a one-hour TTL can keep serving the old value for up to an hour after you edit it. Most lookups travel over UDP port 53, falling back to TCP for large responses.

The record types email depends on

A DNS zone is a list of resource records, each a hostname, a TTL, a type, and a value. Email leans on a specific handful:

  • MX: which mail servers accept mail for the domain, and in what order. See MX record.
  • A / AAAA: map a mail-server hostname to an IPv4 or IPv6 address so other servers can connect.
  • TXT: holds your SPF policy and your DMARC record; DKIM keys live in a TXT record too.
  • PTR: the reverse record that maps a sending IP back to a hostname. See PTR record.

A standard record reads left to right: hostname, TTL, class, type, value.

Common email-related records in a DNS zone file 
example.com.          3600  IN  MX    10 mail.example.com.
mail.example.com.     3600  IN  A     203.0.113.10
example.com.          3600  IN  TXT   "v=spf1 ip4:203.0.113.10 -all"
_dmarc.example.com.   3600  IN  TXT   "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Why DNS is the foundation of deliverability

Receiving mail servers read your DNS before they ever look at your message. They resolve your MX to know where to deliver, check your SPF and DMARC TXT records to authenticate you, and run a reverse DNS lookup on your sending IP to confirm it has a matching PTR record. Since February 2024, Google and Yahoo require every sending IP to have valid, matching forward and reverse DNS before they will accept bulk mail.

Because so much hinges on these records, a quiet DNS mistake is one of the most common causes of mail landing in spam: a TXT record with a typo, an SPF entry that forgets your new sending service, or a missing PTR. None of them throw an obvious error; the mail just quietly stops reaching the inbox. Our DNS records for email guide walks through getting each one right.

How a DNS lookup resolves a name

A program needs the IP for mail.example.com
It asks a recursive resolver, which checks its cache first
Cached and fresh: answer now Not cached: keep walking
The resolver queries the root, then the .com servers, then the domain’s authoritative name server
The authoritative server returns the record plus a TTL
The resolver caches it for the TTL and hands back the IP

The DNS records email cares about

MX TXT A / AAAA PTR
What it does Names mail servers Holds SPF / DMARC Hostname to IP IP to hostname
Lives in Forward zone Forward zone Forward zone Reverse zone
Email role Routing Authentication Connecting Reverse DNS / FCrDNS

By the numbers

Port 53
The UDP and TCP port DNS queries travel over, with UDP preferred for normal lookups.
1987
The year RFC 1034 and RFC 1035 defined the DNS still in use today.
Feb 2024
Since this date Gmail and Yahoo require valid forward and reverse DNS on every sending IP.

Common mistakes

Forgetting that DNS changes are not instant
Resolvers cache every record for its TTL. If you edit a record with a long TTL, the old value can keep serving for hours. Lower the TTL before a planned change, then raise it again afterward.
A typo in an SPF or DMARC TXT record
These records are plain text with no validator built in. One missing quote, an extra space, or a wrong mechanism can silently fail authentication. Verify with our SPF checker and DMARC checker.
No PTR record on the sending IP
Receivers run a reverse DNS lookup on your IP. If there is no PTR, or it does not match a forward record, major providers now reject or spam-folder the mail. Confirm it with our reverse DNS checker.

Frequently asked questions

What does DNS have to do with email?
Almost everything. Your MX records tell other servers where to deliver mail, your TXT records hold SPF and DMARC, DKIM keys live in DNS, and your sending IP needs a matching PTR record for reverse DNS. If any of these is wrong or missing, mail can fail authentication or be rejected outright.
Why did my DNS change not take effect immediately?
Because of caching. Every record has a TTL (time to live) that tells resolvers how long to keep the old answer. Until that timer expires, resolvers around the world may keep serving the previous value, so changes can take minutes to hours to fully propagate.
What is a DNS resolver?
A recursive resolver is the server that does the lookup work for you. It walks the DNS hierarchy from the root down to your domain’s authoritative name servers, caches the result, and returns the answer. Public examples include Google’s 8.8.8.8 and Cloudflare’s 1.1.1.1.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← Back to glossary