TXT против SPF-записей для серверов Google: SPF-запись, одна или обе?

Согласно документации Google,
https://support.google.com/a/bin/answer.py?hl=ru&answer=178723

В ней четко указано: создайте TXT-запись, содержащую следующий текст: v=spf1 include:_spf.google.com ~all

Почему это не является SPF-записью?

RFC4408 определяет SPF-записи, но, похоже, они на самом деле не используются
https://www.rfc-editor.org/rfc/rfc4408#section-3.1.1

Так ли это? Должен ли я создать и TXT, и SPF?

Спасибо

Я понимаю, что это довольно старый вопрос, но, если кто-то еще наткнется на него, вот что я нашел. Похоже, что тип записи SPF теперь устарел. См:

Исследования показывают, что RRTYPE 99 не имел значительного использования, и, на самом деле, его существование и механизм, определенные в [RFC4408], привели к некоторым проблемам совместимости. Соответственно, его использование теперь устарело, и новые реализации не должны его использовать.

Источник: https://datatracker.ietf.org/doc/html/draft-ietf-spfbis-4408bis-15#section-13.1

Смотрите также сообщение на форуме запросов функций cPanel по этой теме http://features.cpanel.net/responses/ability-to-create-spf-type-99-records.

Пожалуйста, ознакомьтесь со статусом RFC4408 “Категория: Экспериментальная” и определением этого статуса.

Также, из RFC

Признается, что текущая практика (использование TXT-записи) не является оптимальной, но она необходима, поскольку существует ряд реализаций DNS-серверов и резолверов, которые не могут обрабатывать новый тип RR.

и, в конце концов, SPF RR не имеет никакой добавленной ценности по сравнению с версией TXT

Я бы создал оба варианта, так как у вас есть такая возможность. После завершения вы можете протестировать это с помощью этого тестера аутентификации электронной почты, который даст вам полный диагноз отправленного вами письма, сообщая, правильно ли вы все настроили.

Согласно ответу satyenshah от 19 июля 2017 года на этот пост:

Специальная запись type=SPF так и не прижилась. Политики отправителя, использующие записи “type=TXT, были установлены слишком хорошо в начале 2000-х, чтобы запись type=SPF смогла закрепиться в 2010-х. Ваш авторитетный DNS-сервер, вероятно, поддерживает публикацию SPF-записи, но почтовые серверы MX в Интернете удовлетворены запросами только к записи TXT.

Крупные сервисы (включая gmail.com и yahoo.com) публикуют только запись type=TXT для SPF. Их администраторы поняли, что запись type=SPF не нужна.

В большинстве случаев нет вреда в публикации политики SPF вашего домена с обеими типами записей. Два предостережения:

1. Вам нужно будет тщательно следить за синхронизацией этих двух записей вручную. Когда вы обновляете один экземпляр своей записи политики, вы должны помнить об обновлении другого.
2. В зависимости от вашего DNS-сервера запрос type=ANY может включать как TXT, так и SPF записи в ответе, увеличивая размер ответа.
   Это само по себе имеет два недостатка.
   • Во-первых, вы становитесь более уязвимыми к атакам DDoS через усиление/рефлексию DNS. Во-вторых, если размер любого ответа вашего домена находится в пределах 512-байтового порога между UDP/TCP,
   • вы можете столкнуться с ошибкой, вызванной неопределенностью в RFC для протокола DNS. Это редкость, но такое бывает.

Информация об сетевых инструментах (если указанный вами домен показывает запись SPF) говорит:

Дополнительная информация о записи Spf была объявлена устаревшей.
Имя хоста вернуло запись SPF, которая была объявлена устаревшей

Использование альтернативных типов DNS RR, которые раньше поддерживались во время экспериментальной фазы SPF, было прекращено в 2014 году. SPF-записи теперь должны публиковаться только как ресурсная запись DNS TXT (тип 16) [RFC1035]. См. RFC 7208 для получения дополнительной информации об этом изменении.

Согласно разделу 3.1 RFC 7208: В период разработки SPF требования к присвоению нового типа DNS RR были более строгими, чем сегодня, и поддержка развертывания новых типов DNS RR не была внедрена в DNS-серверах и системах провизии. В результате разработчики SPF обнаружили, что легче и практичнее следовать типу RR TXT для SPF.

Тем не менее, я также читал, что некоторые люди сообщали о проблемах с доставкой электронной почты до тех пор, пока они не добавили запись SPF.

Учитывая, что google только предоставляет TXT-записи, это хороший признак того, что наличие записи TXT само по себе должно работать.

Недавно любой, кто рассматривает этот вопрос, столкнулся с проблемами, связанными с наличием и SPF, и TXT записей. Я видел недавнюю проблему, когда записи txt и spf у клиента были не одинаковыми. Если обе записи будут одинаковыми, это может быть нормально. SPF был в txt, но не вся txt была в spf, что привело к недействительности SPF.

Учитывая, что с момента публикации RFC прошло уже 7 лет, я считаю, что любой, кто до сих пор использует DNS-серверы, которые не могут обрабатывать неизвестные RRтипы, в конечном итоге сам виноват в том, что не обновил программное обеспечение. (Также учитывайте, что, не обновляя, сколько людей знают о возможных уязвимостях, от которых они остаются уязвимыми). RFC 4408 говорила о том, что перегрузка типа TXT RR была временной мерой до того, как IANA выпустила тип RR SPF (тип 99), что также произошло 7 лет назад.

Поэтому я утверждаю, что использование типа TXT RR для целей SPF устарело давно. Люди, работающие с резолверами, которые проверяют только тип TXT, неисправны.

Я не согласен с тем, что тип RR SPF не “добавляет ценности”. Он исключает машинно-обработанные данные из образовательного пригласительного DNS RR.