Mail routing and the domain system
RFC 974

Document Type RFC - Historic (January 1986; No errata)
Obsoleted by RFC 2821
Obsoletes RFC 772, RFC 780, RFC 788
Last updated 2013-03-02
Stream Legacy stream
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 974 (Historic)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                    Craig Partridge
Request for Comments: 974                 CSNET CIC BBN Laboratories Inc
                                                            January 1986


Status of this Memo

   This RFC presents a description of how mail systems on the Internet
   are expected to route messages based on information from the domain
   system described in RFCs 882, 883 and 973.  Distribution of this memo
   is unlimited.


   The purpose of this memo is to explain how mailers are to decide how
   to route a message addressed to a given Internet domain name.  This
   involves a discussion of how mailers interpret MX RRs, which are used
   for message routing.  Note that this memo makes no statement about
   how mailers are to deal with MB and MG RRs, which are used for
   interpreting mailbox names.

   Under RFC-882 and RFC-883 certain assumptions about mail addresses
   have been changed.  Up to now, one could usually assume that if a
   message was addressed to a mailbox, for example, at LOKI.BBN.COM,
   that one could just open an SMTP connection to LOKI.BBN.COM and pass
   the message along.  This system broke down in certain situations,
   such as for certain UUCP and CSNET hosts which were not directly
   attached to the Internet, but these hosts could be handled as special
   cases in configuration files (for example, most mailers were set up
   to automatically forward mail addressed to a CSNET host to

   Under domains, one cannot simply open a connection to LOKI.BBN.COM,
   but must instead ask the domain system where messages to LOKI.BBN.COM
   are to be delivered. And the domain system may direct a mailer to
   deliver messages to an entirely different host, such as SH.CS.NET.
   Or, in a more complicated case, the mailer may learn that it has a
   choice of routes to LOKI.BBN.COM.  This memo is essentially a set of
   guidelines on how mailers should behave in this more complex world.

   Readers are expected to be familiar with RFCs 882, 883, and the
   updates to them (e.g., RFC-973).

Partridge                                                       [Page 1]

RFC 974                                                     January 1986
Mail Routing and the Domain System

What the Domain Servers Know

   The domain servers store information as a series of resource records
   (RRs), each of which contains a particular piece of information about
   a given domain name (which is usually, but not always, a host).  The
   simplest way to think of a RR is as a typed pair of datum, a domain
   name matched with relevant data, and stored with some additional type
   information to help systems determine when the RR is relevant.  For
   the purposes of message routing, the system stores RRs known as MX
   RRs. Each MX matches a domain name with two pieces of data, a
   preference value (an unsigned 16-bit integer), and the name of a
   host.  The preference number is used to indicate in what order the
   mailer should attempt deliver to the MX hosts, with the lowest
   numbered MX being the one to try first.  Multiple MXs with the same
   preference are permitted and have the same priority.

   In addition to mail information, the servers store certain other
   types of RR's which mailers may encounter or choose to use.  These
   are: the canonical name (CNAME) RR, which simply states that the
   domain name queried for is actually an alias for another domain name,
   which is the proper, or canonical, name; and the Well Known Service
   (WKS) RR, which stores information about network services (such as
   SMTP) a given domain name supports.

General Routing Guidelines

   Before delving into a detailed discussion of how mailers are expected
   to do mail routing, it would seem to make sense to give a brief
   overview of how this memo is approaching the problems that routing

   The first major principle is derived from the definition of the
   preference field in MX records, and is intended to prevent mail
   looping.  If the mailer is on a host which is listed as an MX for the
   destination host, the mailer may only deliver to an MX which has a
   lower preference count than its own host.

   It is also possible to cause mail looping because routing information
   is out of date or incomplete.  Out of date information is only a
   problem when domain tables are changed.  The changes will not be
   known to all affected hosts until their resolver caches time out.
   There is no way to ensure that this will not happen short of
   requiring mailers and their resolvers to always send their queries to
   an authoritative server, and never use data stored in a cache.  This
   is an impractical solution, since eliminating resolver caching would
   make mailing inordinately expensive.  What is more, the out-of-date
   RR problem should not happen if, when a domain table is changed,
Show full document text