Um domínio sem Registro MX não é necessariamente um domínio que recusa correio. SMTP pode recorrer a uma pesquisa de endereço quando os dados MX estão ausentes. Null MX existe para afirmar que um domínio não aceita e-mail e evitar esse substituto ambíguo.
Publique a resposta explícita sem serviço
Referências: RFC 7505 §3.
RFC 7505 define Null MX como um único registro MX com preferência zero e o domínio raiz como sua troca: example.com . 300 EM MX 0 .. O ponto é significativo. Não é um espaço reservado para um nome de host e host local não é equivalente. Um domínio que anuncia Null MX também não deve anunciar outro registro MX .
Use Null MX somente depois de estabelecer que nenhum endereço naquele domínio exato precisa receber mensagens. Inclua recuperação de contas, compras, avisos legais, contas de função e endereços operacionais de baixo volume no inventário. Um domínio aparentemente inativo ainda pode ser o endereço de recuperação de alguém.
Separe os controles de recebimento e envio
Referências: RFC 7505 §4.2, RFC 7208 §5.1, RFC 9989 §4.10.1.
Null MX é uma declaração de recebimento. Ele não autentica e-mails enviados, publica um SPF política ou tornar um domínio imune à representação. RFC 7505 desaconselha MX nulo em domínios usados em endereços SMTP MailFrom ou mensagens De porque os destinatários podem rejeitar esse e-mail. Use um design revisado de endereço de recebimento e retorno para remetentes legítimos, em vez de tratar o Null MX como uma configuração de saída inofensiva.
Para um domínio que não pretende enviar nem receber, avalie os controles de saída explícitos como uma alteração separada. SPF v=spf1 -all é uma negação ilustrativa da identidade SPF exata quando nenhum remetente está autorizado. UM DMARC a política exige uma avaliação explícita do âmbito da política, dos subdomínios e dos relatórios. Não cole um conjunto de controles genérico em um domínio cujo inventário de envio esteja incompleto.
Teste a rota negativa deliberadamente
Referências: RFC 5321 §5.1, RFC 7505 §3.
Numa zona isolada, o dispositivo A tem noreceive.example . EM MX 0 . e um Um recorde para seu site. O roteamento de e-mail esperado reconhece Null MX em vez de retornar a esse endereço da web. O dispositivo B possui o registro A, mas não possui MX ; O comportamento MX implícito do SMTP é um caso diferente. O Fixture C combina Null MX com uma troca comum e é uma configuração inválida, não um design de failover suportado.
Consulta cavar @AUTH noreceive.example . MX + norecurse para cada fixture válido e retenha a resposta completa. Confirme se o caso Null MX retorna exatamente o registro único pretendido. Em seguida, use um remetente SMTP controlado para inspecionar seu manuseio sem enviar tráfego não solicitado para infraestrutura não relacionada. Os casos DNS são especificações de teste aqui; o comportamento real do remetente permanece pendente de execução.
Confirme o escopo exato
Referências: RFC 4592 §3.3, RFC 8767 §4.
Um MX nulo em example.com não é automaticamente um registro MX em sub.example.com. Teste nomes separadamente, incluindo curingas e ramificações delegadas. Ausência DNS , síntese de curingas e registros explícitos podem levar a rotas diferentes.
Documente a decisão de não recebimento com o proprietário da empresa e peça a um segundo revisor para verificar o plano de controle de não envio, quando aplicável. Este guia não afirma que tal aprovação tenha ocorrido. Reverta o processo DNS aprovado se um endereço necessário for descoberto, permitindo registros em cache. O fechamento precisa da rota publicada pretendida e de um inventário revisado de forma independente, e não apenas de um salvamento DNS bem-sucedido.
Pesquisa retida e plano de controle revisável
A captura histórica retida de 7 de novembro de 2026, inspecionada, mas não executada novamente para esta revisão, registra que uma consulta UDP autoritativa de loopback para o sintético noreceive.example MX retornou exatamente 0 .; a captura retida inclui consulta, resposta de transferência, horário UTC e ponto de extremidade de autoridade. O plano concreto de não envio que acompanha combina esse MX com um SPF -all política e uma política de rejeição DMARC ilustrativa para um dispositivo explicitamente considerado como não tendo correspondência legítima. Ele lista verificações de endereço de recuperação e de simulação de subdomínio, restrições de dados de relatórios, limites de teste de receptor e reversão. A avaliação independente desse plano é uma porta de revisão, não uma aprovação do proprietário da empresa. O inventário real do cliente e qualquer implantação pública permanecem sem verificação.
Mantenha o escopo da evidência explícito
A resposta nula MX histórica é preservada com seus bytes de ligação e ponto final de loopback. O seu plano de não envio associado continua a ser uma proposta sintética com pressupostos de inventário; nem sua retenção nem esta revisão de conteúdo fornecem a aprovação do cliente ou testam o manuseio real do receptor.