As RFCs que especificam como um MTA deve lidar com registros MX são RFC974 , < href="https://www.rfc-editor.org/rfc/pdfrfc/rfc1123.txt.pdf"> RFC1123 seção 5.3.4 , RFC2821 seção 5 e RFC5321 seção 5 .
O status RFC974 agora é HISTÓRICO . De acordo com ele, espera-se que os MTAs 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 MTAs devem tentar entregar a mensagem a todos os servidores SMTP até que um seja bem-sucedido. A ordem das tentativas é uma escolha do MTA, ou seja, o RFC não determina se os servidores SMTP devem ser contatados aleatoriamente ou na ordem dada pelo servidor DNS. Além disso, o RFC não rege como lidar com 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 é PADRÃO DA INTERNET . Seção 5.3.4 visa "refinar" os procedimentos RFC974 sobre como lidar com registros MX. Agora, é necessário que o MTA tente todos os servidores SMTP em ordem crescente de preferência até que um seja bem-sucedido. No entanto, ainda permite um limite configurável no número de tentativas. Se houver vários registros MX com um valor de preferência igual, o RFC recomenda (e não requer) 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 MTAs contatem 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 de RFC2821 é PROPOSTO PADRÃO . Este RFC se torna obsoleto com o RFC974 e, no escopo do gerenciamento de registros MX, difere ligeiramente do RFC1123. Enquanto o primeiro REQUER uma seleção aleatória de um servidor SMTP entre vários registros MX com um valor de preferência igual, o último apenas 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 é o PROJETO DE PADRÃO . Esse RFC obsoleta o RFC2821 e, no contexto da resolução do DNS, ele basicamente reescreve o mesmo procedimento de pesquisa do servidor e apresenta uma nova seção que discute um pouco o tratamento de registros MX que fazem referência a 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. (...)
Acho que um agente de transferência de e-mail moderno segue pelo menos os procedimentos RFC2821 ou RFC5321, portanto, todas as três configurações de DNS fornecem recursos de failover. No entanto, somente a primeira configuração pode fornecer um melhor balanceamento de carga. Se você tentar a segunda ou a terceira configuração, terá que certificar-se de que seu servidor DNS entrega respostas em uma ordem aleatória. Além disso, os registros DNS podem ser armazenados em cache, seja por próprios MTA ou por servidores DNS recursivos, para que a aleatoriedade não possa ser garantida. Acho que mail1.example.com receberá a maioria das mensagens.
Outro motivo que direciona minha opinião contra a segunda e terceira configurações é a referência de vários nomes para um endereço IP. Servidores de correio na Internet normalmente rejeitam mensagens de hosts cujo mapeamento IP address => PTR => hostname => A => IP address não corresponde (como a restrição do Postfix reject_unknown_client_hostname ), então você terá que tomar um cuidado especial ao configurar registros PTR.
Clientes que não testam 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 causa disso, eu prefiro a configuração de 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
EDITAR: Adicionadas referências ao RFC1123.