Можно ли использовать ключевые слова a, mx и include вместе в SPF?

Можно ли использовать ключевые слова a, mx и include вместе в SPF?

Можно ли использовать их в одной и той же записи SPF? Например:

Значение TXT:v=spf1 mx a ptr ip4:46.16.60.0/23 a:cdmon.com mx:mail.solarmora.com include:srv.cat ~all

решение1

Да, вы можете объединить все эти ключевые слова, просто убедитесь, что вы не достигли максимального лимита поиска10 поисков записей адресов:https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4

  • Ключевые слова a и ptr приводят к одному поиску
    • Ключевое слово ptr устарело и больше не должно использоваться.
  • ключевое слово mx приводит к такому же количеству поисков, сколько доменов возвращает запись MX
  • ключевые includeслова включают указанную запись SPF, которая:
$ dig srv.cat TXT +short
"v=spf1 a a:include"

Тогда как a:includeприводит к ошибке, так как домен includeне существует.

решение2

Технически возможно смешивать любые механизмы, но все, кроме механизмов ip4и ip6, вызовет дополнительные DNS-поиски, и существует общий лимит в 10 DNS-запросов (RFC 7208, 4.6.4). Каждый aвызывает один дополнительный поиск, а каждый — mxнесколько, в зависимости от количества серверов MX за ним. Также, includeвозможно, есть цепочечный механизм, который также учитывается до предела.

Вам следует тщательно подумать, какие серверы действительно отправляют электронную почту с домена какотправитель конвертаи ограничьте вашу запись SPF, чтобы она содержала только требуемые серверы. Поскольку ваша запись SPF теперь собрана, похоже, вы не обладаете этими знаниями и пытаетесь добавить все "на всякий случай". Политика заканчивается на ~all, что делает все остальное толькомягкий сбой. Это не предотвращает злоупотребления эффективно; рассмотрите возможность использования -all, вместо этого.

Также,не использоватьptr(RFC 7208, 5.5):

Примечание: этот механизм медленный, он не так надежен, как другие механизмы в случаях ошибок DNS, и он создает большую нагрузку на серверы имен .arpa. Если он используется, для хостов домена должны быть установлены надлежащие записи PTR, и этот ptrмеханизм ДОЛЖЕН быть одним из последних проверенных механизмов. После многих лет опыта развертывания SPF был сделан вывод, что он не нужен и вместо него следует использовать более надежные альтернативы. Однако он все еще используется как часть протокола SPF, поэтому совместимые check_host() реализации ДОЛЖНЫ его поддерживать.

Связанный контент