Summary

  • MX records turned the domain in a mail address into a stable identity rather than an instruction to contact the machine with that name. DNS could point senders to one or more different exchangers without renaming users.
  • The common rule stayed thin. A sender queried MX data, tried lower numeric preferences first, treated equal values as peers, removed routes that would loop through itself and made retry decisions locally. An exchanger's own MX records did not create a hidden chain of responsibility.
  • This indirection created operational power, not sovereign truth. Whoever controls authoritative DNS can redirect incoming mail; caches make changes asynchronous; several exchanger names can share one failure; MX provides neither authentication nor confidentiality.

When the address still looked like a machine

RFC 974 opened with an assumption that had once been useful. If a message was addressed to a mailbox at LOKI.BBN.COM, a mailer could usually open an SMTP connection to LOKI.BBN.COM and pass the message along. The right-hand side of the address appeared to name both the public destination and the host implementing it.

The assumption was never universal. Some UUCP and CSNET hosts were not directly attached to the Internet. Mailers carried special configuration rules; one common exception forwarded CSNET mail to CSNET-RELAY.ARPA. SMTP, standardised in RFC 821 in 1982, already knew relaying, gateways and source routes. MX did not invent store-and-forward mail or rescue an otherwise direct-only network.

What changed was the cost of exceptions. A route held in each sender's configuration was hard to update consistently. The owner of the destination could not change one public fact and expect independent mailers to learn it. As domain names became the stable form of address, the network needed a standard answer to a question that an address alone no longer settled: which host currently accepts mail for this domain?

Two record types become one ordered statement

The early domain system in RFC 882 and RFC 883 stored typed resource records. Mail routing first used two types: MD for a mail destination and MF for a mail forwarder. The distinction encoded a simple hierarchy—try the destination, use the forwarder when necessary—but it did not generalise cleanly to several alternatives.

RFC 973 replaced both with MX. One Mail Exchanger record joined a domain to two values: an unsigned 16-bit preference and the hostname of an exchanger. Lower numbers were tried before higher ones. Several records could carry the same preference and therefore the same priority.

The change was more than tidying the DNS type table. MD and MF named roles. MX published an ordered set of possible receivers. A direct host could be one exchanger among others; a relay could be preferred, secondary or equal. The receiving domain described the current delivery surface without asking every remote sender to install a site-specific exception.

RFC 1035 later preserved the compact wire and master-file form: a preference followed by an exchange domain name. The record did not contain a full route, a service contract or a health report. It contained just enough common data for senders to act.

The name survives the machine

Craig Partridge's RFC 974 stated the conceptual break plainly: a domain name is usually, but not always, a host. Under domains, the mailer could not simply contact the name in the mailbox. It first had to ask the domain system where messages for that name should go. The answer might be an entirely different host, or a choice among several.

That indirection gave an organisation a durable mail identity. Users could keep addresses at one domain while the operator moved mailboxes, replaced hardware, contracted a filtering gateway, added a backup exchanger or shifted delivery to another facility. Senders did not need to know the internal story. They needed a current MX answer and reachable addresses for its targets.

This did not make identity metaphysical. Control of the domain and its zone became a practical control surface over incoming mail. A malicious or mistaken MX change could redirect delivery. But the design did separate two things that should not have the same lifetime: the public name by which correspondents know a recipient, and the machinery that happens to serve it today.

A route published once, executed everywhere

RFC 974 strongly urged a mailer to query MX records every time it attempted delivery. The reason was operational, not ceremonial. If a primary host failed, the destination administrator could change DNS and reroute messages already waiting in remote queues. Each sender would learn the new instruction on its next lookup, subject to cached data.

The sender then interpreted the list locally. It had to try the lowest numeric preference. It was encouraged to continue through higher values until an exchanger accepted the message or the usable list was exhausted. When several exchangers shared the lowest value, all of them should be tried before the message was declared undeliverable.

Modern SMTP in RFC 5321 keeps the same basic settlement while tightening behaviour. A client must be able to try and retry relevant addresses. If equal-preference destinations offer no other reason for a choice, the sender randomises among them, spreading load rather than turning DNS order into an accidental permanent favourite.

Preference is often misread as a performance score. It is not latency, geographic distance, server load or institutional rank. Ten is preferred to twenty because the domain published that order. A high-preference backup can be physically closer and technically faster; it is still later in the administrative delivery sequence.

This is local execution in a strong sense. The common layer publishes a small ordered set. No central mail router chooses each packet's path. Thousands of independently operated sending MTAs apply the rule, schedule retries and decide when temporary failure becomes a bounce.

The rule that stops a helpful relay from becoming a loop

Ordered alternatives create a new failure: two mailers can keep handing a message to one another. RFC 974 therefore made the sender locate itself in the MX set. If the local host appeared as an exchanger, it discarded its own record and every record with an equal or higher numeric preference. It could pass the message only toward an exchanger preferred ahead of itself.

Consider a domain with a primary at preference 10 and a backup at 20. When the backup holds mail for the domain, it may try the primary at 10. It must not follow another route at 20 or 30 that could send responsibility sideways or back. The preference list is thus not merely failover order. Relative position defines who may hand mail to whom.

RFC 974 also closed a subtler loophole. The MX query is made for the original destination. A sender does not query the MX records of an exchanger target and treat those as a further relay chain. If one host is an MX for a relay, that does not silently make it responsible for every domain the relay serves.

This non-transitivity protects consent. Accepting mail for one named destination is an explicit operational responsibility. It cannot be inherited through an arbitrary chain of DNS relationships.

Caches make change affordable—and incomplete

The Domain Name System scaled through caching. That meant a changed MX set would not reach every sender simultaneously. RFC 974 acknowledged that stale records could produce temporary loops or false delivery failure while resolver caches expired.

One theoretical cure was to make every mailer ask an authoritative server every time and refuse cached answers. The RFC rejected it as impractical: eliminating caching would make mail excessively expensive. Instead, it required operational care. Administrators should coordinate before adding a host as an exchanger. Mailers should accept complete answers and repeat a truncated datagram query over a reliable virtual circuit.

The tradeoff remains instructive. A cache is not merely stale bureaucracy standing between policy and reality. It is part of the scalability mechanism. The operator controls a TTL and transition plan, not a simultaneous global switch. Safe changes therefore overlap old and new service long enough for distributed knowledge to converge.

That is a more honest model than pretending publication is instantaneous command. DNS records become effective through many resolvers and running mailers, at different moments, according to bounded local state.

When silence meant “try the address anyway”

The 1986 design carried a compatibility rule. If a query returned no MX records, the mailer treated the domain as if it had an MX of preference zero pointing to itself. Modern RFC 5321 calls this an implicit MX. The sender then resolves the domain's A or AAAA records and attempts SMTP there.

The fallback helped domains enter the new system without publishing MX immediately. But it made absence ambiguous. No MX could mean an old but working configuration, an oversight, or a domain that never intended to accept mail. Senders could not infer “no service” from silence. They queued and retried against web or other addresses that had no SMTP listener.

RFC 5321 also draws a boundary around explicit data. If MX records exist but none are usable, the sender must report an error; it may not ignore the published set and fall back to the domain's address. An MX target must resolve to address records, and a target that resolves through CNAME lies outside the modern standard. Explicit routing information carries obligations that absence does not.

A dot that finally meant no mail

In 2015, RFC 7505 filled the missing state with null MX. A domain that accepts no email publishes one MX at preference zero whose exchange is the DNS root label, written as a dot. It must publish no other MX record.

The dot is not a dead server. It is an explicit statement that no mail exchanger exists. A sender can fail immediately rather than falling back to A or AAAA, queueing a message and retrying for what RFC 7505 described as typically a week. The result saves sender resources and returns a useful error while the person who sent the message can still correct the address.

Null MX arrived twenty-nine years after RFC 974, so it cannot be written into the original design. It is valuable precisely as a later correction. Compatibility had made non-participation indistinguishable from missing configuration. A new explicit state restored the operator's ability to say “this domain does not provide that service.”

The record also has limits. A domain used in mail return addresses should not casually advertise null MX, because receivers may reject messages whose delivery failures could never return. Null MX is not SMTP's null reverse-path and does not make forged or unreachable identities legitimate.

Indirection without innocence

MX produced a powerful asymmetry. A user could keep the same address while an administrator changed the entire receiving stack. That portability reduced dependence on one machine, but it also concentrated a consequential decision in DNS control. Whoever can alter the authoritative zone can point incoming correspondence toward a new operator.

Several MX names do not automatically repair that risk. They may share a provider, network, facility, administrative account or filtering policy. A backup exchanger may accept mail during an outage but also acquire access to message metadata or content. DNSSEC can protect the integrity of the published record; it does not certify the legal identity of the recipient or the internal conduct of the exchanger.

Nor does MX complete delivery. A successful SMTP transfer shows that an exchanger accepted responsibility at one protocol boundary. It does not prove that the final mailbox stored the message, that a user saw it or that confidentiality survived every relay.

The record's legitimacy is narrower and stronger. It says where a domain currently asks Internet mailers to transfer responsibility, in what order, and when no service exists. That is enough to let independent systems coordinate. It is not enough to make the zone operator sovereign over identity or truth.

The smallest useful mail map

The MX settlement joined three different lifetimes. The address could remain durable. Delivery infrastructure could be replaced. Routing knowledge could expire from caches on a controlled schedule. Keeping them separate made change possible without making every correspondent participate in the migration.

The common layer stayed compact: destination domain, exchanger names, preference, TTL and a few loop and fallback rules. Everything else—queue discipline, retry cadence, transport security, internal mailbox placement and business relationship—remained with operators running their own systems.

That is why the mail address outlived its server. Not because DNS discovered one permanent home for it, but because the architecture made the home an explicit, replaceable mapping. Identity survived machinery when publication described just enough reality for local code to act—and no more.

Sources and evidence limits

The SMTP and early domain-address context comes from RFC 821, RFC 882 and RFC 883. The MD/MF-to-MX change is documented in RFC 973. The January 1986 routing algorithm, cache tradeoff, loop rule and non-transitive responsibility are in RFC 974.

The record format is preserved in RFC 1035, with host requirements and corrections in RFC 1123. The mature SMTP lookup, implicit-MX and equal-preference behaviour comes from RFC 5321. The explicit no-service state is RFC 7505.

These sources describe different protocol eras. Later rules are used to show maturation and correction, not attributed to the 1986 mailers. Operational consequences beyond the specifications are presented as bounded inferences, not measured claims about every deployment.