Вопрос в целом затрагивает несколько разных аспектов, которые необходимо учитывать, чтобы ответить, почему RFC7505 добавляет что-то полезное.
Во-первых, определение порядка доставки почты до RFC7505 не имеет способа четко указать, что не следует предпринимать попытки доставки почты для имени, имеющего адресные записи.
Из RFC7505 раздел 1 :
У клиентов SMTP есть предписанная последовательность для идентификации сервера, который принимает электронную почту для домена. Раздел 5 [RFC5321] описывает это подробно; по сути, SMTP-клиент сначала ищет DNS MX RR, и, если он не найден, он возвращается к поиску DNS A или AAAA RR. Следовательно, это перегружает запись DNS (которая имеет другое основное предназначение) семантикой службы электронной почты.
Если в домене нет записей MX, отправители будут пытаться доставлять почту хостам по адресам в записях домена A или AAAA. Если на адресах A / AAAA нет прослушивателей SMTP, будет предпринята попытка доставки сообщения в течение длительного периода времени, обычно в течение недели, до того как агент передачи почты (MTA) откажется. Это задержит уведомление отправителя в случае перенаправления почты и потребит ресурсы у отправителя.
Этот документ определяет нулевой MX, который приведет к немедленному сбою всех попыток доставки почты в домен, не требуя от доменов создания SMTP-прослушивателей, предназначенных для предотвращения попыток доставки.
Тогда возникает вопрос, как RFC7505 реализует это ( IN MX 0 .).
Из RFC7505 раздел 3 :
Записи ресурса MX, указывающие нулевой MX
Чтобы указать, что домен не принимает электронную почту, он объявляет одну запись MX RR (см. Раздел 3.3.9 [RFC1035]) с разделом RDATA, состоящим из номера предпочтения 0 и метки нулевой длины, записанной в основных файлах как ". ", как домен обмена, для обозначения отсутствия почтового обменника для домена. Поскольку "." не является допустимым именем хоста, пустая запись MX не может быть перепутана с обычной записью MX.
Использование "." в качестве псевдо-имени хоста, означающего, что никакая доступная услуга не смоделирована на SRV RR [ RFC2782 ], где оно имеет аналогичное значение.
Домен, который рекламирует нулевой MX, НЕ ДОЛЖЕН рекламировать другие MX RR.
(выделение добавлено)
Как отмечено здесь, подробности реализации для «нулевого MX» основаны на уже установленном шаблоне из SRVтипа RR. Имеет смысл имитировать это, поскольку SRVтип RR более или менее является обобщенной версией типа MXRR.
Итак, решение по существу было принято уже при определении SRVтипа RR .
Итак, почему бы не использовать .invalid?
Из RFC2606 раздел2 :
«.invalid» предназначен для использования в онлайновом построении доменных имен, которые, несомненно, являются недействительными и которые, на первый взгляд, являются недействительными.
Как можно увидеть здесь, этот зарезервированный TLD предназначен для потребления человеком. Нет прецедента определения специальной обработки этого в программном обеспечении.
Конечно, это могло бы быть реализовано каким-то другим способом, но они решили использовать минимальный подход к использованию ., который не является допустимым именем хоста и, таким образом, не мешает нормальному использованию в любом случае.