SPF и лимит 10 DNS-запросов
Синтаксис SPF, рекурсивные include, void lookup и постоянные ошибки.
Определение и границы
Синтаксис SPF, рекурсивные include, void lookup и постоянные ошибки.
Сначала определите смысл и ограничения результата и только затем меняйте рабочую конфигурацию.
Как это работает
SPF разрешает серверы для SMTP envelope-идентичности. ip4 и ip6 не требуют DNS, а include, a, mx, exists, ptr и redirect могут его использовать. Проверка проходит по вложенным политикам до первого совпадения.
Как читать результат
Лимит RFC — 10 механизмов, вызывающих DNS, во всей цепочке, а не десять токенов корневой записи. Более двух void lookup также считаются ошибкой. Квалификаторы означают pass (+), fail (-), softfail (~) и neutral (?).
Корректные и ошибочные примеры
Сравните нормализованные примеры. В технических значениях используются документальные диапазоны и зарезервированные имена.
v=spf1 ip4:192.0.2.0/24 include:_spf.example.net -allv=spf1 include:a.example include:b.example … include:k.example +all| Элемент | Назначение | Пример |
|---|---|---|
| ip4 / ip6 | 0 DNS terms | ip4:192.0.2.0/24 |
| include | 1 + nested terms | include:_spf.example.net |
| a / mx / exists | 1 DNS term | mx:example.com |
| ptr | Deprecated | ptr |
| redirect | 1 + nested terms | redirect=_spf.example.net |
| all | 0 DNS terms | -all |
Типовые проблемы
Длинные цепочки include, несколько SPF-записей, циклы redirect, устаревший ptr и +all делают политику ненадёжной. Одна TXT-запись может состоять из нескольких 255-байтных строк; несколько отдельных SPF-записей недопустимы.
Практический чек-лист
Считайте запросы рекурсивно до добавления отправителя, по возможности заменяйте широкие include стабильными сетями и завершайте запись осознанной политикой all.
Стандарты и первичные источники
Поведение протокола задают первичные спецификации. Документация провайдера может дополнять эксплуатационные требования, но не заменяет стандарт.