As RFCs que especificam como um MTA deve manipular os registros MX são RFC974 , seção 5.3.4 da RFC1123 , seção 5 da RFC2821 e seção 5 da RFC5321 .
O status RFC974 agora é HISTÓRICO . Segundo ele, espera-se que os MTA consultem a lista de registros MX associados a um domínio e sejam "encorajados" a experimentar todos (ou um número fixo de) servidores SMTP, em ordem crescente de preferência. Se houver vários registros MX com um valor de preferência igual, os MTA devem tentar entregar a mensagem a todos os servidores SMTP até que um seja bem-sucedido. A ordem das tentativas é uma opção do MTA, ou seja, o RFC não decide se os servidores SMTP devem ser contatados aleatoriamente ou na ordem fornecida pelo servidor DNS. Além disso, o RFC não decide como manipular um registro MX que faça referência a vários registros A.
(...) 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. (...)
O status RFC1123 é INTERNET STANDARD . A Seção 5.3.4 tem como objetivo "refinar" os procedimentos do RFC974 sobre como lidar com registros MX. Agora, exige que os MTA tentem todos os servidores SMTP em ordem crescente de preferência até que um seja bem-sucedido. No entanto, ainda permite um limite configurável para o número de tentativas. Se houver vários registros MX com um valor de preferência igual, a RFC recomenda (e não exige) os MTAs para selecionar um registro aleatoriamente. No entanto, se um registro MX fizer referência a vários registros A (endereços IPv4), o RFC exigirá que os MTA entrem em contato com todos esses endereços até que um seja bem-sucedido, na ordem fornecida pelo servidor 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.
O status RFC2821 é PADRÃO PROPOSTO . Essa RFC obsoleta a RFC974 e, no escopo do tratamento de registros MX, difere um pouco da RFC1123. Enquanto o primeiro EXIGE uma seleção aleatória de um servidor SMTP entre vários registros MX com um valor de preferência igual, o último apenas o RECOMENDA.
(...) 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. (...)
O status RFC5321 é DRAFT STANDARD . Esse RFC obsoleta o RFC2821 e, no contexto da resolução do DNS, basicamente reescreve o mesmo procedimento de pesquisa do servidor e apresenta uma nova seção que discute levemente o manuseio dos registros MX que referenciam endereços IPv6.
(...) 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. (...)
Eu acho que um agente moderno de transferência de mensagens segue pelo menos os procedimentos RFC2821 ou RFC5321, portanto, todas as três configurações de DNS fornecem recursos de failover. No entanto, apenas a primeira configuração pode fornecer um melhor balanceamento de carga. Se você tentar a segunda ou a terceira configuração, precisará garantir que o servidor DNS forneça respostas em uma ordem aleatória. Além disso, os registros DNS podem ser armazenados em cache pelos próprios MTA ou por servidores DNS recursivos, portanto, a aleatoriedade não pode ser garantida. Eu acho mail1.example.comque receberá a maioria das mensagens.
Outro motivo que direciona minha opinião para a segunda e terceira configurações é a referência de vários nomes a um endereço IP. Servidores de correio na Internet geralmente rejeitam mensagens de hosts cujo mapeamento IP address => PTR => hostname => A => IP addressnão corresponde (assim como a restrição Postfix reject_unknown_client_hostname ), portanto, você terá que ter um cuidado especial ao definir registros PTR.
Clientes que não tentam registros MX em uma ordem aleatória já estão violando os padrões RFC2821 e RFC5321. Portanto, acho que não há garantia de que esses clientes também tentem o endereço IP secundário automaticamente. Por isso, prefiro a configuração DNS mais simples:
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
EDIT: Adicionado referências ao RFC1123.