O que é um registro MX e como funciona a prioridade?

O que significa o número de prioridade em um registro MX?

Todo registro MX tem duas partes: um número de preferência (prioridade) e um nome de host. A RFC 5321 afirma claramente que os registros com número mais baixo são os mais preferidos. Um registro com preferência 10 é tentado antes de um com preferência 20, e um registro com preferência 0 é tentado antes dos dois. O número em si não tem significado além da ordenação; um domínio poderia usar 10 e 20, ou 5 e 50, com o mesmo comportamento.

Quando dois ou mais registros MX compartilham a mesma preferência mais baixa, o remetente não escolhe um arbitrariamente nem usa sempre o primeiro da lista. A RFC 5321 exige que o servidor de envio randomize a escolha entre eles para distribuir a carga entre vários servidores de e-mail. Dois servidores na preferência 10 recebem, ao longo do tempo, aproximadamente metade das conexões cada um, e é assim que um domínio equilibra a carga de e-mails recebidos entre servidores idênticos sem nenhuma configuração especial do lado de quem envia.

Como um servidor de envio escolhe qual host de e-mail usar?

Um servidor de envio consulta todos os registros MX do domínio de destino, ordena por preferência e conecta primeiro ao host de menor número. Se vários registros empatarem nesse número mais baixo, ele escolhe um aleatoriamente entre esse grupo. Só quando todos os hosts do nível de preferência atual falham em aceitar a conexão é que o remetente passa para o grupo de preferência seguinte, e assim por diante.

É por isso que uma configuração comum usa uma preferência baixa para o servidor de e-mail principal e uma preferência mais alta para um servidor de backup: o e-mail normal chega ao principal, e o backup só é contatado quando o principal está inacessível.

O que acontece se o servidor de e-mail preferido não responder?

Nada é entregue instantaneamente ao próximo host da lista após uma única tentativa falhada, do jeito que um navegador poderia tentar outro servidor. Um servidor de envio que não consegue se conectar ao host de maior preferência tenta o próximo host desse mesmo nível de preferência, depois desce para hosts do próximo número de preferência se nenhum responder. Se todos os servidores de e-mail listados estiverem inacessíveis, a mensagem fica em fila e o servidor de envio tenta de novo mais tarde em vez de devolver a mensagem imediatamente, já que uma interrupção de e-mail costuma ser temporária. Por quanto tempo exatamente uma mensagem fica em fila antes de ser devolvida como não entregável é uma escolha de configuração de cada sistema de envio, não algo controlado pelo registro MX.

Por que um registro MX precisa apontar para um nome de host, nunca para um endereço IP ou um CNAME?

O valor de um registro MX é sempre um nome de domínio, nunca um endereço IP direto. Esse nome de domínio então precisa do seu próprio registro A ou AAAA para que o servidor de envio consiga resolvê-lo para um endereço. A RFC 2181, seção 10.3, é explícita sobre a outra restrição: o nome de domínio usado como valor de um registro NS, ou como parte do valor de um registro MX, não pode ser um alias, ou seja, não pode ser um CNAME.

O motivo está em como os resolvedores de DNS otimizam uma consulta MX. Quando um resolvedor consulta registros MX, ele normalmente também busca os registros de endereço de cada host de troca na mesma consulta, uma etapa chamada processamento da seção adicional, para que o servidor de envio não precise de uma segunda consulta para resolver o nome do host. Esse atalho não segue um CNAME, então um registro MX que aponta para um alias perde esse ganho de velocidade e, em alguns resolvedores, pode falhar a consulta por completo. A correção é sempre apontar o registro MX diretamente para o nome de host real (o destino do CNAME).

O que acontece quando um domínio não tem nenhum registro MX?

O SMTP define um comportamento de fallback para esse caso. A RFC 5321, seção 5.1, diz que, se um domínio não retornar nenhum registro MX, o endereço é tratado como se estivesse associado a um registro MX implícito, com preferência 0, apontando para esse próprio host, ou seja, o remetente recorre ao registro A ou AAAA do domínio e tenta entregar o e-mail diretamente ao servidor que esse endereço resolve.

Esse fallback é uma rede de segurança para domínios que nunca configuraram e-mail algum, não um substituto para um registro MX de verdade. Um servidor web raramente roda um serviço de e-mail, então o e-mail para um domínio sem registro MX costuma simplesmente falhar ao tentar se conectar. Um domínio que intencionalmente não aceita e-mail não deve depender do silêncio; a forma padrão de declarar isso explicitamente é um único registro MX com preferência 0 e o destino escrito como um único ponto, definido na RFC 7505 como um "null MX" justamente para que os remetentes consigam diferenciar "nenhum serviço de e-mail configurado" de "configuração incorreta".

Como ler uma consulta MX real?

A saída da linha de comando deixa a estrutura de prioridade e nome de host bem concreta:

dig MX example.com +short
10 mail.example.com.
20 mail2.example.com.

Aqui, mail.example.com é tentado primeiro porque 10 é menor que 20; mail2.example.com só recebe uma tentativa de conexão se o primeiro estiver inacessível. Dois registros com o mesmo número, como 10 mail.example.com. e 10 mail2.example.com., seriam divididos de forma aproximadamente igual entre os dois.

A ferramenta gratuita de consulta MX consulta os registros MX de um domínio a partir da própria rede de pontos de verificação da HostTracker de uma só vez e lista cada nome de host de servidor de e-mail distinto que aparece, junto com os locais que o retornaram, útil para confirmar se todo local está vendo o mesmo conjunto de servidores em vez de uma resposta desatualizada ou parcialmente propagada. Ela lista os nomes de host dos servidores de e-mail em si, e não o valor numérico de prioridade, então trate cada resultado como um dos servidores de e-mail do domínio, não como uma ordem classificada; para os números de prioridade, uma consulta de linha de comando como a acima é a fonte direta. Um registro MX só diz para onde o e-mail deve ir, não se ele será aceito quando chegar lá, veja o que é um registro SPF para a verificação que decide quem tem permissão para enviá-lo.

Perguntas frequentes

Um domínio pode ter mais de um registro MX?

Sim, e a maioria dos domínios em produção tem. Vários registros permitem que um remetente use um servidor de backup, ou distribua a carga entre vários servidores igualmente preferidos quando os valores de preferência empatam.

Um registro MX afeta o envio de e-mails de saída?

Não. Um registro MX só diz a outros servidores para onde entregar e-mails endereçados a esse domínio. Qual servidor um domínio usa para enviar e-mail é uma configuração separada no sistema de envio e não tem relação com os próprios registros MX dele.

Posso apontar um registro MX diretamente para um endereço IP?

Não. O padrão de DNS para registros MX só permite um nome de host como destino, e esse nome de host precisa então do seu próprio registro A ou AAAA. Alguns provedores de DNS rejeitam de imediato um endereço IP digitado em um campo MX.

O que é um registro "null MX"?

Um único registro MX com preferência 0 e o destino definido como um único ponto, definido na RFC 7505. Ele diz explicitamente aos servidores de envio que um domínio não aceita e-mail algum, em vez de deixá-los adivinhar a partir de uma lista MX vazia.

Por que vejo o mesmo número de preferência em dois nomes de host diferentes?

Isso é balanceamento de carga intencional. Servidores de e-mail listados com preferência idêntica devem ser intercambiáveis, e os remetentes são obrigados a escolher entre eles de forma aleatória, em vez de sempre favorecer o primeiro da lista.

Uma mudança em um registro MX tem efeito imediato?

Não mais rápido do que o TTL do registro permite. Como qualquer registro de DNS, um valor MX alterado pode continuar resolvendo para a resposta antiga em resolvedores que já a tinham em cache, até que essa entrada de cache expire.