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 de tudo, a definição pré-RFC7505 de como a entrega de correio deve ser feita não tem uma maneira de indicar claramente que nenhuma tentativa de entrega de correio deve ser feita para um nome que tenha registros de endereço.
De RFC7505 seção 1 :
SMTP clients have a prescribed sequence for identifying a server
that accepts email for a domain. Section 5 of [RFC5321] covers
this in detail; in essence, the SMTP client first looks up a DNS MX
RR, and, if that is not found, it falls back to looking up a DNS A
or AAAA RR. Hence, this overloads a DNS record (that has a
different primary mission) with an email service semantic.
If a domain has no MX records, senders will attempt to deliver mail
to the hosts at the addresses in the domain's A or AAAA records. If
there are no SMTP listeners at the A/AAAA addresses, message delivery
will be attempted repeatedly for a long period, typically a week,
before the sending Mail Transfer Agent (MTA) gives up. This will
delay notification to the sender in the case of misdirected mail and
will consume resources at the sender.
This document defines a null MX that will cause all mail delivery
attempts to a domain to fail immediately, without requiring domains
to create SMTP listeners dedicated to preventing delivery attempts.
Depois, há a questão de como o RFC7505 implementa isso ( IN MX 0 . ).
De RFC7505 seção 3 :
-
MX Resource Records Specifying Null MX
To indicate that a domain does not accept email, it advertises a
single MX RR (see Section 3.3.9 of [RFC1035]) with an RDATA section
consisting of preference number 0 and a zero-length label, written in
master files as ".", as the exchange domain, to denote that there
exists no mail exchanger for a domain. Since "." is not a valid host
name, a null MX record cannot be confused with an ordinary MX record.
The use of "." as a pseudo-hostname meaning no service available is
modeled on the SRV RR [RFC2782] where it has a similar meaning.
A domain that advertises a null MX MUST NOT advertise any other MX
RR.
(ênfase adicionada)
Como é observado aqui, os detalhes de implementação para o "MX nulo" são baseados em um padrão já estabelecido do tipo SRV RR. Faz sentido imitar isso, pois o tipo SRV RR é mais ou menos uma versão generalizada do tipo MX RR.
Assim, a decisão já foi tomada quando da definição do SRV tipo RR .
Então, por que não usar .invalid ?
De RFC2606 seção2 :
".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.
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 forma diferente, mas eles escolheram usar a abordagem mínima de usar . , que não é um nome de host válido e, portanto, não interfere no uso normal.