MTAがMXレコードを処理する方法を指定するRFCは、RFC974、RFC1123セクション5.3.4、RFC2821セクション5、およびRFC5321セクション5です。
RFC974のステータスはHISTORICになりました。それによると、MTAはドメインに関連付けられたMXレコードのリストをクエリすることが期待され、すべての（または固定数の）SMTPサーバーを優先順に昇格するように「推奨」されます。同じ設定値を持つ複数のMXレコードがある場合、MTAは、成功するまですべてのSMTPサーバーにメッセージを配信しようとする必要があります。試行の順序はMTAの選択です。つまり、RFCは、SMTPサーバーにランダムに接続する必要があるか、DNSサーバーが指定した順序で接続する必要があるかを決定しません。さらに、RFCは、複数のAレコードを参照するMXレジスタの処理方法を規定していません。
(...) If the list of MX RRs is not empty, the mailer should try to deliver
the message to the MXs in order (lowest preference value tried
first). The mailer is required to attempt delivery to the lowest
valued MX. Implementors are encouraged to write mailers so that they
try the MXs in order until one of the MXs accepts the message, or all
the MXs have been tried. A somewhat less demanding system, in which
a fixed number of MXs is tried, is also reasonable. Note that
multiple MXs may have the same preference value. In this case, all
MXs at with a given value must be tried before any of a higher value
are tried. In addition, in the special case in which there are
several MXs with the lowest preference value, all of them should be
tried before a message is deemed undeliverable. (...)
RFC1123ステータスはINTERNET STANDARDです。セクション5.3.4は、MXレコードの処理方法に関するRFC974手順を「洗練」することを目的としています。現在は、MTAがすべてのSMTPサーバーを優先順位の高い順に1つ成功するまで試行する必要があります。ただし、試行回数の構成可能な制限は引き続き許可されます。同じ設定値を持つ複数のMXレコードがある場合、RFCは、ランダムに1つのレコードを選択することをMTAに推奨します（要求しません）。ただし、MXレコードが複数のAレコード（IPv4アドレス）を参照している場合、RFCは、MTAがDNSサーバーによって指定された順序で、成功するまでこれらすべてのアドレスにアクセスすることを要求します。
(...) When it succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address,
because of (a) multiple MX records, (b) multihoming, or both.
To provide reliable mail transmission, the sender-SMTP MUST be
able to try (and retry) each of the 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, a host SHOULD try at
least two addresses.
The following information is to be used to rank the host
addresses:
(1) Multiple MX Records -- these contain a preference
indication that should be used in sorting. If there are
multiple destinations with the same preference and there
is no clear reason to favor one (e.g., by address
preference), then the sender-SMTP SHOULD pick one at
random to spread the load across multiple mail exchanges
for a specific organization; note that this is a
refinement of the procedure in [DNS:3].
(2) Multihomed host -- 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 (see Section 6.1.3.4 below)
to have ordered this list by decreasing preference, and
SMTP MUST try them in the order presented.
(...)
[DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974,
January 1986.
RFC2821ステータスはPROPOSED STANDARDです。このRFCはRFC974を廃止し、MXレコード処理の範囲では、RFC1123とは少し異なります。前者は優先度の値が等しい複数のMXレコードからSMTPサーバーをランダムに選択する必要がありますが、後者はそれを推奨するだけです。
(...) Multiple MX records contain a preference indication that MUST be used
in sorting (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 SMTP MUST try them in the
order presented. (...)
RFC5321ステータスはDRAFT STANDARDです。このRFCはRFC2821を廃止し、DNS解決のコンテキストでは、基本的に同じサーバールックアップ手順を書き換え、IPv6アドレスを参照するMXレコードの処理について少し説明する新しいセクションを提示します。
(...) 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.
(...) 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.
(...) 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. (...)
最近のメール転送エージェントは少なくともRFC2821またはRFC5321の手順に従っていると思います。そのため、3つのDNS設定すべてがフェイルオーバー機能を提供します。ただし、ロードバランシングを改善できるのは最初のセットアップだけです。2番目または3番目のセットアップを試す場合は、DNSサーバーがランダムな順序で応答を配信することを確認する必要があります。さらに、DNSレコードはMTA自体または再帰DNSサーバーのいずれかによってキャッシュされる可能性があるため、ランダム性は保証されません。mail1.example.comほとんどのメッセージが届くと思います。
2番目と3番目のセットアップに対して私の意見を向けるもう1つの理由は、1つのIPアドレスへの複数の名前の参照です。インターネットのメールサーバーは、通常、マッピングIP address => PTR => hostname => A => IP addressが一致しないホストからのメッセージを拒否するため（Postfixの制限reject_unknown_client_hostnameと同様）、PTRレコードの設定には特別な注意が必要になります。
MXレコードをランダムな順序で試行しないクライアントは、すでにRFC2821およびRFC5321標準に違反しています。したがって、これらのクライアントがセカンダリIPアドレスを自動的に試すことも保証されていないと思います。そのため、私は最も単純なDNS構成を好みます。
example.com. 1200 IN MX 10 mail1.example.com.
example.com. 1200 IN MX 10 mail2.example.com.
mail1.example.com. 1200 IN A 172.16.10.1
mail2.example.com. 1200 IN A 172.16.10.2
編集： RFC1123への参照を追加しました。