RFC 1035 – Domain Names: Implementation and Specification

Internet Standard DNS & Mail Routing Published November 1987 Core Infrastructure

ELI5: When you send a letter, you need to know which post office handles the recipient’s address. DNS is the phone book that answers that question for email. You look up the domain name and DNS tells you which mail servers accept mail for it (MX records), what their IP addresses are (A/AAAA records), and what policies apply (TXT records for SPF, DKIM, DMARC). Without DNS, there’s no way to deliver email.

Why This RFC Exists

RFC 1035, published in 1987 alongside RFC 1034, defines the implementation details of the Domain Name System. While DNS is a general-purpose infrastructure, it is absolutely critical to email. Every email delivery begins with a DNS lookup — the sending server must discover which servers accept mail for the recipient's domain.

RFC 1035 defines the record types, query formats, and response structures that make this possible. For email, four record types matter most: MX (mail exchange routing), A (IPv4 addresses), AAAA (IPv6 addresses, defined later in RFC 3596), and TXT (text records used for SPF, DKIM keys, DMARC policies, and more).

Without RFC 1035, there would be no standard way to map a domain name to the servers that handle its mail. Every authentication and routing mechanism in modern email depends on it.

How It Works

When a sending MTA needs to deliver a message to user@example.com, it follows a specific DNS lookup sequence:

Query MX records for example.com. The response contains one or more mail exchangers, each with a priority value (lower = preferred).
Sort by priority. If multiple MX records share the same priority, the sender randomizes among them for load balancing.
Resolve the MX hostname to an IP address using A (IPv4) or AAAA (IPv6) queries.
Connect to the mail server at the resolved IP address on port 25 and begin the SMTP session.
If the preferred MX is unreachable, try the next-lowest priority, and so on.
If no MX records exist, fall back to the A/AAAA record for the domain itself (per RFC 5321).

Key Technical Details

MX Records — Mail Routing

The MX record is the cornerstone of email routing. It maps a domain to the hostname(s) of its mail servers, with a preference value that determines the order in which they're tried:

example.com. IN MX 10 mx1.example.com. example.com. IN MX 20 mx2.example.com. example.com. IN MX 30 mx-backup.example.com.

The MX target must be a hostname, never an IP address. The sending MTA then resolves that hostname to an IP via A/AAAA queries. An MX record pointing to a CNAME is technically prohibited by the spec, though some resolvers tolerate it.

A and AAAA Records — IP Resolution

Once the MX hostname is known, A records provide IPv4 addresses and AAAA records provide IPv6 addresses:

mx1.example.com. IN A 198.51.100.25 mx1.example.com. IN AAAA 2001:db8::25

If an MX hostname resolves to both A and AAAA records, the sending MTA chooses based on its own configuration and connectivity. Most modern MTAs prefer IPv6 when available, falling back to IPv4.

TXT Records — Email Authentication

TXT records were originally a generic mechanism for attaching text data to a domain name. Email authentication has adopted them extensively:

# SPF — which servers may send mail for this domain example.com. IN TXT "v=spf1 include:mailertogo.com ~all" # DKIM public key — used to verify message signatures selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGf..." # DMARC policy — what to do with mail that fails authentication _dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

TXT records are limited to 255 bytes per string, but a single record can contain multiple strings that are concatenated. SPF records that exceed 255 bytes must be split this way.

Null MX — RFC 7505

A domain that does not accept email can publish a Null MX record — an MX with a priority of 0 pointing to "." (the root). This tells sending servers not to attempt delivery, avoiding delays and bounces:

no-reply.example.com. IN MX 0 .

TTL and Caching

Every DNS record has a TTL (time-to-live) that controls how long resolvers cache the result. For MX records, typical TTLs range from 300 to 3600 seconds. Lower TTLs allow faster failover but increase DNS query volume. During migrations, reduce TTL well in advance so cached records expire before the change takes effect.

DNS Lookup Example

A complete DNS lookup sequence for delivering to user@example.com:

# Step 1: Query MX records $ dig example.com MX +short 10 mx1.example.com. 20 mx2.example.com. # Step 2: Resolve the preferred MX hostname $ dig mx1.example.com A +short 198.51.100.25 $ dig mx1.example.com AAAA +short 2001:db8::25 # Step 3: Check SPF for the sending domain $ dig example.com TXT +short "v=spf1 include:mailertogo.com ~all" # Step 4: Check DMARC policy $ dig _dmarc.example.com TXT +short "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Common Mistakes

Pointing an MX record at an IP address. MX records must point to a hostname, not an IP. MX 10 198.51.100.25 is invalid and will cause delivery failures.
Pointing an MX record at a CNAME. The MX target must resolve directly to A/AAAA records. An MX pointing to a CNAME is prohibited by the spec and causes unpredictable behavior across different resolvers.
Missing reverse DNS (PTR) for mail server IPs. While not defined by RFC 1035, most receiving servers check that your mail server's IP address has a PTR record that resolves back to the same IP. Missing or mismatched PTR records trigger spam filters.
Forgetting to update DNS after migrating mail providers. If you switch email services but leave old MX records in place, mail goes to the old provider. Always verify MX records after migration.
Setting TTLs too high before a migration. If your MX records have a 24-hour TTL and you change providers, some servers will continue delivering to the old destination for up to 24 hours. Lower TTL to 300 seconds at least 48 hours before the switch.
Exceeding the 10-lookup limit for SPF. SPF evaluation follows include: and redirect= directives, each generating additional DNS queries. More than 10 lookups causes a permanent SPF error. Keep your SPF record flat.
No MX record and no A record. If a domain has neither MX records nor an A/AAAA fallback, mail to that domain is undeliverable. Publish explicit MX records or at minimum an A record.

Deliverability Impact

MX records are the first thing checked. If your MX records are missing, misconfigured, or pointing to unreachable servers, no mail reaches you. This is the most fundamental deliverability requirement.
SPF, DKIM, and DMARC all live in DNS. Every email authentication check starts with a TXT record lookup. If your DNS is slow, unreliable, or misconfigured, authentication fails and your messages get flagged or rejected.
Reverse DNS affects sender reputation. Mail servers with properly configured forward and reverse DNS are trusted more by receiving servers. Mismatched or missing PTR records are a strong spam signal.
DNS propagation delays affect migrations. When changing email providers, DNS caching means the transition is never instant. Plan for a period where both old and new systems must accept mail.
IPv6 requires matching AAAA and PTR records. If you send from IPv6 addresses, you need AAAA records for your sending hostnames and PTR records for the IPv6 addresses. Incomplete IPv6 DNS setup causes delivery failures to providers that prefer IPv6.