Eu entendo que você não deve apontar um registro MX em um endereço IP diretamente, mas deve , em vez apontá-lo para um Aregistro, que, por sua vez, aponta para o endereço IP do servidor de correio.

Mas, em princípio, por que isso é necessário?

A idéia por trás do registro MX é especificar um host ou hosts que possam aceitar correio para um domínio. Conforme especificado na RFC 1035 , o registro MX contém um nome de domínio. Portanto, ele deve apontar para um host que possa ser resolvido no DNS. Não foi possível usar um endereço IP, pois seria interpretado como um nome de domínio não qualificado, que não pode ser resolvido.

Os motivos para isso na década de 1980, quando as especificações foram originalmente escritas, são quase os mesmos de hoje: um host pode estar conectado a várias redes e usar vários protocolos.

Nos anos 80, não era incomum haver gateways de correio conectados à Internet (relativamente nova) que usava TCP / IP e a outras redes herdadas, que costumavam usar outros protocolos. A especificação do MX dessa maneira permitiu registros DNS que poderiam identificar como alcançar um host em uma rede diferente da Internet, como o Chaosnet . Na prática, porém, isso quase nunca aconteceu; praticamente todo mundo reprojetou suas redes para se tornar parte da Internet.

Hoje, a situação é que um host pode ser alcançado por vários protocolos (IPv4 e IPv6) e por vários endereços IP em cada protocolo. Um único registro MX não pode listar mais de um endereço; portanto, a única opção é apontar para um host, onde todos os endereços desse host podem ser consultados. (Como uma otimização de desempenho, o servidor DNS enviará os registros de endereço para o host na seção adicional de resposta, se tiver registros autorizados, salvando uma viagem de ida e volta.)

Também existe a situação em que seus trocadores de correio são fornecidos por terceiros (por exemplo, Google Apps ou Office 365). Você aponta seus registros MX para os nomes de host, mas pode ocorrer que o provedor de serviços precise alterar os endereços IP dos servidores de correio. Como você apontou para um host, o provedor de serviços pode fazer isso de forma transparente e você não precisa fazer alterações nos seus registros.

O DNS como protocolo possui alguns tipos diferentes de valores, que não são intercambiáveis.

É importante observar que o DNS é um protocolo binário com mapeamentos rigorosos entre o tipo de registro e o tipo de dados que esse registro contém.

Por exemplo:
Um Aregistro mantém um endereço IPv4 (4 bytes de dados, comprimento fixo).
Um AAAAregistro mantém um endereço IPv6 (16 bytes de dados, comprimento fixo).

Um MXregistro, por outro lado, possui um nome (uma sequência de rótulos no formato <int number of bytes> <label> <int number of bytes> <label> <int 0>, comprimento variável).

Não é possível que um MXregistro tenha um endereço IP como dados.

Vou jogar isso como um palpite. Claro, estou em casa com gripe, então talvez eu esteja louco.

A RFC 974 afirma:

A primeira etapa do remetente em LOCAL é emitir uma consulta para MX RRs para REMOTE. É altamente recomendável que essa etapa seja executada toda vez que um remetente tentar enviar a mensagem. A esperança é que as alterações no banco de dados do domínio sejam usadas rapidamente pelos remetentes de correspondência, e assim os administradores do domínio poderão rotear novamente as mensagens em trânsito para hosts defeituosos, simplesmente alterando os bancos de dados do domínio.

Ao exigir um nome em vez de IP, incentiva vigorosamente essa prática. Os nomes podem permanecer os mesmos e, no caso de balanceamento de carga ou DR, você não precisará se preocupar em alterar o próprio registro MX e aguardar a propagação do DNS.

Alguns servidores de email (como o exim) especificamente não permitem o envio para registros MX que apontam para um endereço IP puro; portanto, você precisa usar um FQDN para que ele seja compatível. Isso ocorre porque a maioria dos servidores espera que o registro MX contenha um nome de host, não um IP (é para isso que servem os registros A).

Editar: para elaborar, no DNS, cada registro possui requisitos rígidos para o tipo de dados que cada registro pode conter. No caso de registros MX, é apenas um nome de host .

No RFC 1025, os registros MX apontam apenas para um RR (registro de recurso) de um registro A ou CNAME.

Portanto, o servidor de email que envia o email solicita o RR de um registro MX, o registro mx lista os registros A dos servidores, o servidor de email faz uma pesquisa direta para obter um registro A e encaminha o email via smtp para o host de serviço listado como um servidor de email 'disposto' a receber email para esse domínio.

Sua pergunta - Por que o correio não pode ser enviado para um endereço IP

Resposta - por causa da confiança

Muitas das regras em vigor sobre email evoluíram para manter a confiança entre os domínios de que as mensagens enviadas e recebidas são realmente válidas. Tudo isso é reduzir o SPAM.

• Pesquisas reversas de IP
• Uma pesquisa de nome encaminhado para esse assunto

Todos esses componentes essenciais para uma fundação na qual um servidor de correio é construído têm pelo menos algum componente pequeno, criado para criar comunicações confiáveis ​​e reduzir a comunicação não confiável.

Referência - RFC 1035 e 974

https://www.ietf.org/rfc/rfc1035.txt35

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

O objetivo dos MXregistros é que um aplicativo (transferência de correio) possa aprender sobre o host a ser usado. No nível do aplicativo, os nomes de host são a coisa certa a ser usada (não os endereços IP).

Além disso, adicionar o conceito de registro de tipo variante ao DNS apresenta uma série de complicações e, portanto, um ponto de entrada para problemas, contratempos de implementação, desafios de segurança. Por exemplo, 1.2.3.4.example.com.é um nome de host válido (sim, mesmo à luz da RFC1034, 3.5). A especificação deste host como MXem um arquivo de configuração de ligação para example.com pode parecer

.  MX 10  1.2.3.4

e presumivelmente é exatamente o mesmo que um registro MX com um IP deve parecer. E mesmo para transferir as informações em um datagrama DNS requer alguns additoins peculiares; a maneira mais simples seria introduzir um novo tipo de registro de recurso, por MXAexemplo, para desambiguação. Mas, novamente, por que introduzir o fardo de um novo tipo de registro quando

. MXA 10 5.6.7.8

sempre pode ser substituído por

. MX 10 dummy
dummy A 5.6.7.8

(e seria suportado por clientes DNS também sem conhecimento sobre MXAregistros)?