La pregunta en su conjunto toca algunos aspectos diferentes que todos deben tenerse en cuenta para responder por qué RFC7505 agrega algo útil.
En primer lugar, la definición anterior a RFC7505 de cómo se debe hacer la entrega de correo no tiene una manera de indicar claramente que no se deben realizar intentos de entrega de correo para un nombre que tenga registros de direcciones.
De RFC7505 sección 1 :
Los clientes SMTP tienen una secuencia prescrita para identificar un servidor que acepta correo electrónico para un dominio. La Sección 5 de [RFC5321] cubre esto en detalle; en esencia, el cliente SMTP primero busca un DNS MX RR y, si no se encuentra, recurre a buscar un DNS A o AAAA RR. Por lo tanto, esto sobrecarga un registro DNS (que tiene una misión principal diferente) con un servicio semántico de correo electrónico.
Si un dominio no tiene registros MX, los remitentes intentarán entregar el correo a los hosts en las direcciones en los registros A o AAAA del dominio. Si no hay escuchas SMTP en las direcciones A / AAAA, la entrega del mensaje se intentará repetidamente durante un largo período, generalmente una semana, antes de que el Agente de transferencia de correo (MTA) que se remite se rinda. Esto retrasará la notificación al remitente en el caso de correo mal dirigido y consumirá recursos en el remitente.
Este documento define un MX nulo que hará que todos los intentos de entrega de correo a un dominio fallen inmediatamente, sin requerir que los dominios creen escuchas SMTP dedicadas a prevenir los intentos de entrega.
Luego está la cuestión de cómo RFC7505 implementa esto ( IN MX 0 .).
De RFC7505 sección 3 :
Registros de recursos MX que especifican MX nulo
Para indicar que un dominio no acepta correo electrónico, anuncia un solo MX RR (consulte la Sección 3.3.9 de [RFC1035]) con una sección RDATA que consta del número de preferencia 0 y una etiqueta de longitud cero, escrita en archivos maestros como ". ", como dominio de intercambio, para indicar que no existe un intercambiador de correo para un dominio. Ya que "." no es un nombre de host válido, un registro MX nulo no se puede confundir con un registro MX ordinario.
El uso de "." como un pseudo-nombre de host que significa que no hay servicio disponible se modela en el SRV RR [ RFC2782 ] donde tiene un significado similar.
Un dominio que anuncia un MX nulo NO DEBE anunciar ningún otro MX RR.
(énfasis añadido)
Como se observa aquí, los detalles de implementación para el "MX nulo" se basan en un patrón ya establecido del SRVtipo RR. Tiene sentido imitar esto, ya que el SRVtipo RR es más o menos una versión generalizada del MXtipo RR.
Entonces, la decisión ya se había tomado esencialmente al definir el SRVtipo RR .
Entonces, ¿por qué no hacer uso de .invalid?
De RFC2606 sección2 :
".invalid" está destinado a usarse en la construcción en línea de nombres de dominio que seguramente no serán válidos y que es obvio a simple vista no lo son.
Como se puede ver aquí, este TLD reservado es para consumo humano. No hay precedentes de definir un manejo especial de esto en el software.
Seguramente podría haberse implementado de alguna manera diferente, pero eligieron seguir el enfoque mínimo de uso ., que no es un nombre de host válido y, por lo tanto, no interfiere con el uso normal de todos modos.