A questão como um todo aborda alguns aspectos diferentes que precisam ser levados em consideração para responder por que o RFC7505 acrescenta algo útil.
Primeiro, a definição anterior à RFC7505 de como a entrega de correio deve ser feita não tem como indicar claramente que nenhuma tentativa de entrega de correio deve ser feita para um nome que tenha registros de endereço.
Na seção 1 do RFC7505 :
Os clientes SMTP têm uma sequência prescrita para identificar um servidor que aceita email para um domínio. Seção 5 de [RFC5321] aborda isso em detalhes; em essência, o cliente SMTP primeiro consulta um RR de DNS MX e, se isso não for encontrado, volta a procurar um RR de DNS A ou AAAA. Portanto, isso sobrecarrega um registro DNS (que tem uma missão principal diferente) com uma semântica de serviço de email.
Se um domínio não tiver registros MX, os remetentes tentarão enviar email para os hosts nos endereços nos registros A ou AAAA do domínio. Se não houver ouvintes SMTP nos endereços A / AAAA, a entrega da mensagem será tentada repetidamente por um longo período, geralmente uma semana, antes que o MTA (agente de transferência de email) desista. Isso atrasará a notificação ao remetente no caso de correio mal direcionado e consumirá recursos no remetente.
Este documento define um MX nulo que fará com que todas as tentativas de entrega de correio em um domínio falhem imediatamente, sem exigir que os domínios criem ouvintes SMTP dedicados a impedir tentativas de entrega.
Depois, há a questão de como o RFC7505 implementa isso ( IN MX 0 .).
Na seção 3 do RFC7505 :
Registros de recursos MX que especificam MX nulo
Para indicar que um domínio não aceita email, ele anuncia um único MX RR (consulte a Seção 3.3.9 de [RFC1035]) com uma seção RDATA que consiste no número de preferência 0 e um rótulo de comprimento zero, gravado em arquivos mestres como ". ", como o domínio de troca, para indicar que não existe um trocador de correio para um domínio. Desde a "." não é um nome de host válido, um registro MX nulo não pode ser confundido com um registro MX comum.
O uso de "." como um pseudo-hostname, significando que nenhum serviço disponível é modelado no SRV RR [ RFC2782 ], onde ele tem um significado semelhante.
Um domínio que anuncia um MX nulo NÃO DEVE anunciar nenhum outro MX RR.
(enfase adicionada)
Conforme observado aqui, os detalhes de implementação do "MX nulo" são baseados em um padrão já estabelecido do SRVtipo RR. Faz sentido imitar isso, pois o SRVtipo RR é mais ou menos uma versão generalizada do MXtipo RR.
Portanto, a decisão já foi tomada essencialmente ao definir o SRVtipo de RR .
Então, por que não fazer uso .invalid?
Na seção2 do RFC2606 :
".invalid" destina-se ao uso na construção online de nomes de domínio que certamente são inválidos e que é óbvio à primeira vista são inválidos.
Como pode ser visto aqui, este TLD reservado é para consumo humano. Não há precedentes para definir um tratamento especial disso no software.
Certamente poderia ter sido implementado de alguma maneira diferente, mas eles optaram por usar a abordagem mínima de uso ., que não é um nome de host válido e, portanto, não interfere no uso normal.