Проверка SPF-записи

Назначение и принципы работы SPF-записей

Запись SPF (Sender Policy Framework) представляет собой специальную текстовую TXT-запись в DNS домена, которая указывает, каким почтовым серверам разрешено отправлять электронную почту от имени этого домена. При получении письма принимающий почтовый сервер проверяет SPF-запись отправителя, чтобы убедиться, что исходящий узел авторизован владельцем домена. Это помогает предотвратить подделку адресов и снижает вероятность попадания легитимных писем в спам.

Инструмент Проверка SPF-записи предназначен для локального разбора структуры SPF-записи, оценки создаваемой ею нагрузки на систему DNS и выявления потенциальных проблем в синтаксисе или политике безопасности.

Входные данные и процесс анализа

Для проведения анализа в поле ввода Значение SPF TXT необходимо вставить текстовую строку SPF-записи. Длина вводимого значения ограничена и не должна превышать 20 000 символов. Если запись превышает этот лимит, инструмент выведет сообщение об ошибке: Эта запись необычно велика. Ограничьте её 20 000 символами.. Если поле ввода оставить пустым, отобразится ошибка: Сначала вставьте SPF-запись.. При вводе неподдерживаемого формата данных выводится сообщение: Введите поддерживаемую SPF-запись..

Инструмент автоматически обрабатывает структуру записи:

• Запись должна начинаться с версии протокола v=spf1.
• Если запись состоит из нескольких частей, заключённых в кавычки (типичный формат хранения длинных TXT-записей в DNS), эти фрагменты автоматически объединяются перед началом анализа. При этом формируется примечание: Заключённые в кавычки части DNS TXT были объединены перед анализом..

Выходные результаты и структура разбора

После обработки записи инструмент формирует подробный отчет Анализ SPF, содержащий несколько информационных блоков:

1. Сводка SPF: общие количественные показатели записи.
   • Прямые условия DNS: расчетное количество DNS-запросов, которые будут инициированы непосредственно терминами данной записи.
   • Механизмы: общее число обнаруженных механизмов авторизации.
   • Риски: количество найденных проблем синтаксиса и угроз безопасности.
2. Разобранные условия: таблица, детализирующая каждый элемент записи.
   • Условие: конкретный выделенный терм (например, include:example.com или ip4:192.0.2.0/24).
   • Тип: классификация терма. Возможные варианты: Версия (для v=spf1), Механизм, Модификатор или Неизвестно.
   • Значение или квалификатор: извлеченные параметры терма или префиксы авторизации (+, -, ~, ?).
   • Использует DNS: статус Да или Нет, указывающий, требует ли данный терм выполнения DNS-запроса.
3. Примечания по синтаксису и политике: список предупреждений и ошибок. Если запись составлена идеально, отображается сообщение: Во вставленной записи не найдено рисков синтаксиса или политики..

Лимит на DNS-запросы и его значение

Одним из важнейших правил спецификации SPF является ограничение на количество DNS-запросов при проверке записи. Стандарт разрешает выполнение не более 10 DNS-запросов для полной оценки всей цепочки авторизации.

Каждый механизм include, a, mx, ptr, exists, а также модификатор redirect в составе проверяемой записи увеличивают счетчик DNS-запросов на единицу. Механизмы ip4, ip6 и all обрабатываются локально и не требуют DNS-запросов.

Если вставленная запись превышает установленный лимит, инструмент фиксирует нарушение: Эта запись уже содержит ‹detail› условий, вызывающих DNS-запросы, что превышает лимит SPF в 10.. Превышение этого лимита критично для доставляемости писем: почтовые серверы получателей обязаны трактовать проверку, вышедшую за рамки 10 запросов, как постоянную ошибку (PermError), что часто приводит к отклонению писем или их жесткой фильтрации.

Поскольку инструмент выполняет локальный анализ без отправки сетевых запросов, он оценивает только первый уровень записи. В связи с этим выводится предупреждение: Цели include или redirect могут добавить больше DNS-запросов, чем учитывает эта оценка первой записи..

Правила синтаксиса и риски политик безопасности

Инструмент проверяет SPF-запись на соответствие строгим правилам построения и выявляет следующие ошибки и нерекомендуемые практики:

• Нарушения структуры версии: Запись обязана начинаться с v=spf1. Если версия отсутствует, выводится ошибка: Запись должна начинаться с v=spf1.. Если этот терм находится не в начале, фиксируется нарушение: Условие ‹term›: v=spf1 должно быть первым условием.. Наличие нескольких объявлений версии вызывает ошибку: Запись содержит более одного условия v=spf1..
• Неизвестные элементы: Любые нераспознанные механизмы помечаются предупреждением: Условие ‹term›: «‹detail›» не является распознанным механизмом SPF..
• Проблемы значений: Если параметры механизмов пропущены или повреждены, выводится сообщение: Условие ‹term›: значение ‹detail› отсутствует или имеет неверный формат..
• Ошибки IP-адресов: Некорректные сетевые адреса вызывают ошибки: Условие ‹term›: введите допустимый адрес IPv4 или диапазон CIDR. либо Условие ‹term›: введите допустимый адрес IPv6 или диапазон CIDR..
• Ошибки модификаторов: Повторяющиеся модификаторы вызывают ошибку: Условие ‹term›: модификатор ‹detail› встречается более одного раза.. Модификаторы не могут иметь квалификаторы политики, иначе фиксируется нарушение: Условие ‹term›: модификатор не может иметь квалификатор +, -, ~ или?..
• Логика механизма all: Использование нескольких механизмов all затрудняет чтение политики: Условие ‹term›: несколько механизмов all затрудняют проверку политики.. Любые термы, расположенные после all, никогда не будут достигнуты при проверке, о чем сообщает предупреждение: Условия после all недостижимы при проверке SPF.. Если в записи одновременно присутствуют all и redirect, последний игнорируется: redirect игнорируется, поскольку запись также содержит all..
• Небезопасные и неэффективные политики:
  • Использование +all фактически разрешает отправку писем с любых серверов в мире: +all разрешает любого отправителя и обычно лишает SPF смысла..
  • Использование ?all не дает четких указаний принимающей стороне: ?all возвращает нейтральный результат и почти не даёт получателям указаний политики..
  • Отсутствие терминальных механизмов: Запись не содержит ни all, ни redirect, поэтому не совпавшие отправители получают нейтральный результат..
• Устаревшие механизмы: Использование механизма ptr крайне не рекомендуется из-за медлительности и низкой надежности обратных DNS-запросов: Механизм ptr не следует публиковать, поскольку он медленный и ненадёжный..

Конфиденциальность и локальная обработка

Анализ SPF-записи полностью выполняется непосредственно в вашем веб-браузере. Введенный текст не отправляется на внешние серверы, не загружается и не сохраняется в базах данных. Инструмент не выполняет активных сетевых запросов к DNS, не проверяет IP-адреса отправителей и не имитирует ответы реальных почтовых серверов.

---

Часто задаваемые вопросы

Как рассчитывается оценка числа DNS-запросов SPF?

Оценка учитывает условия include, a, mx, ptr, exists и redirect во вставленной записи. Вложенные и перенаправленные записи могут добавлять запросы, поэтому локальная проверка не определяет окончательное рекурсивное число.

Что произойдёт, если SPF потребует более 10 DNS-запросов?

Получатели SPF должны считать проверку, превысившую лимит в 10 условий с DNS-запросами, постоянной ошибкой. Лимит охватывает всю цепочку include и redirect, а не только первую запись.

Доказывает ли результат без ошибок, что моя настройка SPF работает?

Нет. Эта страница проверяет только вставленный текст. Она не запрашивает DNS, не раскрывает записи провайдера, не проверяет IP отправителя и не подтверждает ответ принимающего почтового сервера.