This RFC has been superseded by RFC 5321. New implementations should reference the current standard.
What it defines
RFC 974 introduced the use of DNS MX records for email routing, replacing the earlier approach of using HOSTS.TXT tables. It defined how sending MTAs should query DNS to find the mail servers responsible for a domain.
Where you see it in practice
The MX record lookup that every email verification tool and MTA performs to route mail has its origins in RFC 974. The MX record system defined here remains the core of email routing DNS today.
Evolution chain
See the full email RFC directory for the complete catalog of internet mail standards.
Mail routing and MX records
RFC 974 was published in January 1986 and defined how mail servers should use DNS MX (Mail Exchange) records to determine where to deliver mail for a given domain. Before MX records, mail was routed based on the A record of the domain, which meant every domain had to run a mail server on the same host as its web server (if any). MX records let a domain point mail delivery to a different host or set of hosts, ranked by priority, without affecting other services on the domain.
MX priority and fallback
MX records have a numeric preference value; lower numbers mean higher priority. When a sending MTA looks up MX records for example.com and finds three records with priorities 10, 20, and 30, it tries the priority-10 host first, falls back to priority-20 if the first is unreachable, and so on. Equal-priority records are load-balanced by trying them in random order. This design provides both load balancing and failover with a single DNS mechanism, and remains the backbone of internet mail routing in 2026.
Superseded by RFC 5321
RFC 974 was obsoleted by RFC 5321 in 2008; the MX record semantics are now specified in section 5 of that document. However, the essential rules remain the same: MX priorities are ranked ascending, lower is preferred, ties are load-balanced randomly. Understanding MX record behavior is essential for anyone debugging mail delivery issues; a misconfigured MX (pointing to an unresolvable host, missing entirely, or pointing to the wrong server) is one of the most common causes of hard-bouncing incoming mail.
RFC 974 (January 1986), authored by Craig Partridge, defined MX record processing: how SMTP senders use DNS MX records to find the mail server for a recipient domain. Introduced the priority-based fallback model (lower number = higher priority, try in order) still universal in 2026. Obsoleted by RFC 2821 (2001), then folded into RFC 5321 (2008). Reference RFC 5321 for current MX handling; RFC 974 is the foundational document that established the mechanism. Also introduced implicit MX fallback (if no MX record exists, fall back to A record).
RFC 974 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Define MX record processing for SMTP mail routing |
| Author | Craig Partridge |
| Key concept | Priority-based MX list; try lower numbers first, fall back to higher |
| Fallback | Implicit MX to A record if no MX exists |
| Published | January 1986 |
| Superseded by | RFC 2821 (2001), then RFC 5321 (2008) |
MX record processing mechanism
Priority semantics
| Priority value | Meaning |
|---|---|
| Lower number | Higher priority; try first |
| Equal numbers | Load-balanced; sender picks randomly or round-robin |
| Any 16-bit value | Legal range 0 to 65535 |
| Common convention | 10 for primary, 20 for secondary, 30+ for tertiary |
Common MX configuration mistakes
example.com. IN MX 10 mail.example.com. where mail.example.com is itself a CNAME. Fix: point MX directly at a hostname with A/AAAA records.MX 100 primary and MX 10 backup, thinking higher priority number means primary. Reversed; lower is higher priority. Standard convention: primary at 10, secondaries at 20, fallbacks at 30+. Deploying reversed sends all mail to the backup as long as it responds.MX 10 mail.example.com. when mail.example.com has no A/AAAA record leaves senders unable to deliver. They will retry for days then bounce. Verify every MX target resolves; use DNS monitoring to catch drift.Related standards and further reading
- RFC 5321 SMTP Guide: current MX processing
- RFC 7505 Null MX Guide: signaling no mail acceptance
Frequently asked questions
Should I reference RFC 974 or RFC 5321 for MX processing?
RFC 5321. It folded RFC 974 into the base SMTP standard in 2008. RFC 974 is the historical foundation and remains valid for context; new work should target RFC 5321. Both describe the same mechanism; RFC 5321 has integrated errata and clarifications.
What is the difference between explicit MX and implicit MX fallback?
Explicit MX: example.com. IN MX 10 mail.example.com. tells senders to deliver to mail.example.com. Implicit MX: no MX record exists, so senders fall back to the A record of example.com per RFC 5321. Both work; explicit is clearer and more common. Implicit fallback catches domains that host both web and mail on the same server without dedicated MX configuration.
Can two MX records have the same priority?
Yes. Equal priorities indicate load balancing; senders pick randomly (or round-robin) among them. Common pattern: two servers behind priority 10 for HA, one server at priority 20 for failover. Different priorities are always tried in order (10 before 20); equal priorities are balanced.
Why does RFC 2181 prohibit MX pointing to CNAME?
Complexity and ambiguity. Chasing a CNAME to find the A record can add latency and creates ambiguity about what the target of the MX really is. RFC 2181 requires MX (and NS, other special records) to point directly to hostnames with A/AAAA records. Modern DNS validators warn about MX→CNAME configurations; many receivers reject them entirely.
What is the maximum number of MX records I can publish?
Technically limited by DNS packet size (a few dozen). Practically, 2-3 MX records at distinct priorities is typical. More than 5 is unusual and suggests over-engineering. Load balancing is usually better handled at the A record level (multiple IPs behind one MX hostname) than at the MX level.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
