質問全体では、RFC7505が有用なものを追加する理由に答えるために考慮に入れる必要があるいくつかの異なる側面に触れています。
まず、RFC7505より前のメール配信方法の定義には、アドレスレコードを持つ名前に対してメール配信を試行しないことを明確に示す方法がありません。
RFC7505セクション1から：
SMTPクライアントには、ドメインの電子メールを受け入れるサーバーを識別するための規定のシーケンスがあります。[RFC5321]のセクション5でこれについて詳しく説明しています。本質的に、SMTPクライアントは最初にDNS MX RRを検索し、それが見つからない場合、DNS AまたはAAAA RRの検索にフォールバックします。したがって、これにより、電子メールサービスのセマンティクスでDNSレコード（プライマリミッションが異なる）がオーバーロードされます。
ドメインにMXレコードがない場合、送信者はドメインのAまたはAAAAレコードのアドレスにあるホストにメールを配信しようとします。A / AAAAアドレスにSMTPリスナーが存在しない場合、送信メール転送エージェント（MTA）が断念する前に、メッセージ配信が長期間（通常は1週間）繰り返し試行されます。これにより、メールの宛先が誤っている場合に送信者への通知が遅れ、送信者のリソースが消費されます。
このドキュメントでは、ドメインへの配信試行を防ぐための専用のSMTPリスナーを作成することなく、ドメインへのすべてのメール配信試行をすぐに失敗させるnull MXを定義しています。
次に、RFC7505がこれをどのように実装するかという問題があります（IN MX 0 .）。
RFC7505セクション3から：
Null MXを指定するMXリソースレコード
ドメインが電子メールを受け入れないことを示すために、優先順位番号0と長さゼロのラベルで構成されるRDATAセクションを含む単一のMX RR（[RFC1035]を参照）をアドバタイズします。 「交換ドメインとして、ドメインのメールエクスチェンジャーが存在しないことを示す。「。」以来 は有効なホスト名ではないため、null MXレコードを通常のMXレコードと混同することはできません。
の用法 "。" 使用可能なサービスがないことを意味する疑似ホスト名は、SRV RR [ RFC2782 ]でモデル化され、同様の意味を持ちます。
ヌルMXをアドバタイズするドメインは、他のMX RRをアドバタイズしてはなりません。
（強調を追加）
ここに記載されているように、「null MX」の実装の詳細は、SRVRRタイプから既に確立されたパターンに基づいています。SRVRRタイプは多かれ少なかれRRタイプの一般化バージョンであるため、これを模倣することは理にかなっていMXます。
そのため、SRVRRタイプを定義するときに、基本的にすでに決定が行われています。
だから、なぜ利用しないの.invalidですか？
RFC2606セクション2から：
「.invalid」は、無効であることが確実であり、一見して無効であることが明らかなドメイン名のオンライン構築での使用を目的としています。
ここで見られるように、この予約済みTLDは人間が消費するためのものです。ソフトウェアでこれを特別に処理することを定義した先例はありません。
確かに別の方法で実装できたかもしれ.ませんが、有効なホスト名ではないため、とにかく通常の使用を妨げることのない最小限の使用方法を選択しました。