Every time you send email to [email protected], the machinery defined in this fourteen-page RFC kicks into gear. Craig Partridge's RFC 974 introduced the MX (Mail Exchanger) record — the indirection layer that decoupled email delivery from the host that "owns" a domain name.

The problem in 1986. The DNS had just been deployed (RFCs 1034/1035 were not yet a year old). Before MX records, an SMTP sender resolving [email protected] would look up the A record for bbn.com and try to open a TCP connection to port 25 on that host. This was awful for several reasons:

• Many organizations wanted mail delivered to a dedicated relay, not whatever host happened to bear the domain name.
• Hosts behind UUCP, BITNET, CSNET, or other non-IP transports had no A record at all but still wanted Internet mail.
• Redundancy required hacks — there was no clean way to say "try server B if server A is down."

The design. RFC 974 defines a new DNS record type: MX, carrying a 16-bit preference and a hostname. To deliver mail to foo.example, a sender queries for MX records, sorts them by preference (lowest number wins), and tries them in order. Equal-preference records are tried in any order — the seed of today's load balancing across mail farms. The lower-is-better convention is counterintuitive and still trips up admins forty years later.

The clever bits. Several rules in this RFC are still load-bearing:

• Loop prevention. A sending host must find itself in the MX list and discard its own entry and any entry with equal-or-higher preference. Without this, two misconfigured relays would bounce a message between themselves forever.
• Implicit MX. If no MX records exist, fall back to the A record. This was a transition concession for the pre-MX world. RFC 5321 kept it; modern operators consider it a footgun and explicitly publish MX records (or "null MX" per RFC 7505) for every mail domain.
• CNAME handling. MX targets must not be CNAMEs. This rule, restated countless times since, is still violated weekly by someone setting up Google Workspace.
• Wildcards and gateways. The RFC describes how a UUCP gateway could publish MX 10 relay.uucp-gateway.example for an entire suffix — the mechanism that quietly bridged the non-IP mail world onto the Internet during the late 1980s.

Why it still matters. RFC 974 was obsoleted by RFC 2821 and then RFC 5321, but the on-the-wire behavior is unchanged. Every spam filter, every dig MX gmail.com, every "mail loops back to myself" error message you have ever seen traces back to this document. The pattern it pioneered — service-specific DNS records with priority and weight — was later generalized as SRV (RFC 2782) and is now how SIP, XMPP, Minecraft servers, and Kubernetes headless services are discovered.

A historical footnote. Partridge was 24 when he wrote this. The same year he also co-authored RFC 950 (subnetting). The implicit-MX rule he included as a politeness to the existing installed base ended up being the longest-lived piece — a reminder that "temporary" compatibility shims tend to outlive their authors' careers.