DNS/1/MX/5321について、ここに記述してください。

https://www.ietf.org/rfc/rfc5321.txt


5.  Address Resolution and Mail Handling

5.1.  Locating the Target Host
{{{
   Once an SMTP client lexically identifies a domain to which mail will
   be delivered for processing (as described in Sections 2.3.5 and 3.6),
   a DNS lookup MUST be performed to resolve the domain name (RFC 1035
   [2]).  The names are expected to be fully-qualified domain names
   (FQDNs): mechanisms for inferring FQDNs from partial names or local
   aliases are outside of this specification.  Due to a history of
   problems, SMTP servers used for initial submission of messages SHOULD
   NOT make such inferences (Message Submission Servers [18] have
   somewhat more flexibility) and intermediate (relay) SMTP servers MUST
   NOT make them.

   The lookup first attempts to locate an MX record associated with the
   name.  If a CNAME record is found, the resulting name is processed as
   if it were the initial name.  If a non-existent domain error is
   returned, this situation MUST be reported as an error.  If a
   temporary error is returned, the message MUST be queued and retried
   later (see Section 4.5.4.1).  If an empty list of MXs is returned,
   the address is treated as if it was associated with an implicit MX
   RR, with a preference of 0, pointing to that host.  If MX records are
   present, but none of them are usable, or the implicit MX is unusable,
   this situation MUST be reported as an error.

   If one or more MX RRs are found for a given name, SMTP systems MUST
   NOT utilize any address RRs associated with that name unless they are
   located using the MX RRs; the "implicit MX" rule above applies only
   if there are no MX records present.  If MX records are present, but
   none of them are usable, this situation MUST be reported as an error.

   When a domain name associated with an MX RR is looked up and the
   associated data field obtained, the data field of that response MUST
   contain a domain name.  That domain name, when queried, MUST return
   at least one address record (e.g., A or AAAA RR) that gives the IP
   address of the SMTP server to which the message should be directed.
   Any other response, specifically including a value that will return a
   CNAME record when queried, lies outside the scope of this Standard.
   The prohibition on labels in the data that resolve to CNAMEs is
   discussed in more detail in RFC 2181, Section 10.3 [38].


   When the lookup succeeds, the mapping can result in a list of
   alternative delivery addresses rather than a single address, because
   of multiple MX records, multihoming, or both.  To provide reliable
   mail transmission, the SMTP client MUST be able to try (and retry)
   each of the relevant addresses in this list in order, until a
   delivery attempt succeeds.  However, there MAY also be a configurable
   limit on the number of alternate addresses that can be tried.  In any
   case, the SMTP client SHOULD try at least two addresses.

   Two types of information are used to rank the host addresses:
   multiple MX records, and multihomed hosts.

   MX records contain a preference indication that MUST be used in
   sorting if more than one such record appears (see below).  Lower
   numbers are more preferred than higher ones.  If there are multiple
   destinations with the same preference and there is no clear reason to
   favor one (e.g., by recognition of an easily reached address), then
   the sender-SMTP MUST randomize them to spread the load across
   multiple mail exchangers for a specific organization.

   The destination host (perhaps taken from the preferred MX record) may
   be multihomed, in which case the domain name resolver will return a
   list of alternative IP addresses.  It is the responsibility of the
   domain name resolver interface to have ordered this list by
   decreasing preference if necessary, and the SMTP sender MUST try them
   in the order presented.

   Although the capability to try multiple alternative addresses is
   required, specific installations may want to limit or disable the use
   of alternative addresses.  The question of whether a sender should
   attempt retries using the different addresses of a multihomed host
   has been controversial.  The main argument for using the multiple
   addresses is that it maximizes the probability of timely delivery,
   and indeed sometimes the probability of any delivery; the counter-
   argument is that it may result in unnecessary resource use.  Note
   that resource use is also strongly determined by the sending strategy
   discussed in Section 4.5.4.1.

   If an SMTP server receives a message with a destination for which it
   is a designated Mail eXchanger, it MAY relay the message (potentially
   after having rewritten the MAIL FROM and/or RCPT TO addresses), make
   final delivery of the message, or hand it off using some mechanism
   outside the SMTP-provided transport environment.  Of course, neither
   of the latter require that the list of MX records be examined
   further.

   If it determines that it should relay the message without rewriting
   the address, it MUST sort the MX records to determine candidates for
   delivery.  The records are first ordered by preference, with the
   lowest-numbered records being most preferred.  The relay host MUST
   then inspect the list for any of the names or addresses by which it
   might be known in mail transactions.  If a matching record is found,
   all records at that preference level and higher-numbered ones MUST be
   discarded from consideration.  If there are no records left at that
   point, it is an error condition, and the message MUST be returned as
   undeliverable.  If records do remain, they SHOULD be tried, best
   preference first, as described above.
}}}