Registros MX informar aos clientes SMTP onde um domínio recebe mensagens. Eles não autorizam, por si só, um serviço a enviar como esse domínio. Uma configuração de recebimento confiável requer nomes de host de troca utilizáveis, pontos de extremidade SMTP acessíveis e um plano para falhas temporárias, não apenas uma pesquisa MX verde.
Interprete a preferência corretamente
Referências: RFC 5321 §5.1, RFC 2181 §10.3.
Cada registro MX contém uma preferência numérica e um nome de host de troca. Números de preferência mais baixos são tentados antes de números mais altos. Quando não há uma razão clara para favorecer um destino de preferência igual, RFC 5321 exige a randomização da ordem para distribuir a carga. A ordem deles em uma resposta DNS não é uma designação de servidor primário estável. Todas as rotas anunciadas devem ser planejadas e operacionais.
Um nome de host do Exchange deve ter registros A ou AAAA utilizáveis e não deve ser um CNAME. Não coloque um literal de IP no campo de troca MX . Resolva cada troca separadamente e teste o serviço SMTP anunciado. Uma resposta de endereço por si só não pode mostrar se o ponto final aceita correio para o domínio do destinatário.
Distinguir MX ausente, inutilizável e nulo
Referências: RFC 5321 §5.1, RFC 7505 §3.
SMTP tem uma regra MX implícita quando uma pesquisa bem-sucedida não retorna registros MX : ele trata o próprio domínio como destino e procura seus registros de endereço. Isso não é permissão para ignorar registros MX explícitos quebrados e usar o endereço do site do domínio. Um erro temporário DNS também difere de uma ausência definitiva e normalmente leva a filas e novas tentativas.
Um MX nulo é uma declaração explícita de que o domínio não aceita correio: um único MX com preferência zero e o rótulo raiz como exchange, comumente exibido como 0 .. RFC 7505 diz para não publicar outros registros MX junto com ela. Nenhum MX e MX nulo são, portanto, configurações diferentes.
Trabalhe através de acessórios de roteamento
O acessório sintético A tem example.com. MX 10 mx1.example.com. e example.com. MX 20 mx2.example.com.. O primeiro hospedeiro tem A 192.0.2.10; o segundo tem A 192.0.2.20. A ordem de preferência esperada é mx1 antes de mx2. Uma falha na conexão com mx1 pode causar outra tentativa de entrega permitida; isso não prova que mx2 aceitou a mensagem.
O dispositivo B remove ambos os registros MX , mas sai example.com. A 192.0.2.30. Sob a regra MX implícita, esse endereço se torna o destino SMTP potencial. Em vez disso, o Fixture C publica apenas example.com. MX 0 .; a interpretação esperada é que o domínio não aceita correspondência. O dispositivo D retém os registros MX de A, mas remove os endereços de ambas as exchanges. O resultado esperado são rotas explícitas inutilizáveis, e não um retorno ao ápice Um recorde.
Reproduza a parte DNS em um laboratório consultando MX para cada equipamento isolado e A/AAAA para cada troca retornada. Registre a ordem e classificação selecionadas. Use um servidor SMTP controlado para testar novas tentativas e aceitação, se necessário. Os endereços da documentação e os resultados descritos são ilustrativos e não medições de produção.
Verifique a rota comercial
Referências: RFC 7208 §5.4, RFC 5321 §4.2.5.
Mantenha o roteamento de entrada separado do SPF política. Um SPF MX O mecanismo pode tornar explicitamente os endereços associados ao MX relevantes para uma avaliação SPF , mas a publicação MX por si só não cria essa autorização. A mudança de provedores de entrada pode, portanto, também afetar uma política SPF existente que usa MX e merece uma revisão separada.
Durante uma migração, verifique o provisionamento de destinatários, as respostas SMTP e a segurança do transporte em todas as trocas ativas antes de remover a rota antiga. Uma troca de backup pode aceitar spam ou rejeitar destinatários legítimos se configurada de forma diferente. Registre quem é o proprietário de cada endpoint e quais evidências fecham a mudança; não compare a aceitação SMTP com a colocação na caixa de entrada ou com a leitura da mensagem por um ser humano.
Execução de roteamento isolado capturado
A captura histórica retida, inspecionada para esta revisão, mas não executada novamente, registra que em 7 de novembro de 2026 às 20:34:42 UTC, um dispositivo de loopback executado retornou o conjunto MX 10 mx1.example.com. e 20 mx2.example.com. da porta 127.0.0.1 42125. Um cliente Python 3.12.14 usando dnspython 2.9.2 classificou essas preferências. O mapa de endpoint de laboratório explícito enviou mx1 para 127.0.0.1 porta 45271 e mx2 para porta 37481; este mapa de portas substitui o roteamento público da porta 25 apenas dentro do equipamento.
Com os dois ouvintes em execução, mx1 retornou 220, aceito EHLO com 250, aceito CORREIO DE e RCPT TO com 250, inseriu DADOS com 354 e voltou 250 mensagens sintéticas aceitas; descartado localmente. Depois de fechar apenas o ouvinte principal, a próxima execução será gravada Erro de conexãoRefused para mx1 e a mesma sequência de aceitação em mx2. Nenhum correio externo, destinatário real ou entrega de caixa de correio foi envolvido.
Para reproduzir, inicie dois acessórios SMTP de loopback, consulte o respondedor MX do laboratório, mapeie seus nomes de troca para os ouvintes e envie uma mensagem sintética inofensiva com Python smtplib. Repita depois de fechar o primário. Retenha a resposta da ligação, o mapa de endpoint, a transcrição do cliente/servidor, os carimbos de data e hora e as versões da ferramenta. O equipamento capturado usa um servidor SMTP deliberadamente pequeno e demonstra apenas novas tentativas orientadas por preferência; não é um teste de conformidade de uma produção MTA ou evidência de failover de produção.
Mantenha o escopo da evidência explícito
A transcrição arquivada confirma apenas o comportamento do acessório de loopback descrito acima, incluindo seu mapeamento de porta personalizado e descarte local. A captura e o aproveitamento da fonte permanecem inalterados; esta revisão não repetiu o tráfego SMTP nem inferiu failover de produção a partir do teste histórico.