Что такое механизм ptr в SPF — и почему он до сих пор встречается в 950 631 записях? (2026)

Q: Что использовать вместо ptr?

Блоки ip4:/ip6: для серверов, которыми вы управляете, или документированный include: вашего провайдера. Оба детерминированы, быстры и надёжны — всё то, чем ptr не является.

Q: Учитывается ли ptr в лимите SPF из 10 запросов?

Да — каждый ptr стоит как минимум одного из десяти DNS-запросов, которые получатель выполнит, прежде чем сдаться с ошибкой PermError. В записях, уже нагруженных механизмами include:, именно мёртвый механизм может оказаться тем, что перевесит вас за предел.

Опубликовано 2026-07-03

Данные на 2026-06-29 · методология v7. Сводная перепись по 261 миллионам оценённых доменов. Все цифры сводные — никогда не запись отдельного бизнеса. См. как мы оцениваем.

ptr — это механизм SPF, который авторизует отправителей через обратный DNS-запрос, — и сам стандарт SPF говорит «не используйте его» ещё с 2014 года. Спустя 12 лет его по-прежнему публикуют 950 631 доменов. Это примерно 1 из 146 от 139 миллионов SPF-записей в интернете, несущих механизм, который спецификация объявила устаревшим ещё до того, как некоторые из этих доменов были зарегистрированы.

Что ptr должен был делать

ptr говорит: «принимай почту с любого сервера, чей обратный DNS разрешается обратно в мой домен». Звучит изящно — не нужно вести списки IP. На практике же он требует, чтобы получатель выполнил обратный запрос по подключающемуся IP, а затем прямым подтверждением проверил каждое возвращённое имя хоста. RFC 7208 (§5.5) объявил его устаревшим прямыми словами: механизм «медленный, не так надёжен, как другие механизмы, в случае ошибок DNS, и создаёт большую нагрузку на серверы имён .arpa» — и предписывает, что его «СЛЕДУЕТ НЕ использовать» (SHOULD NOT be used).

Почему в 2026 году это по-прежнему ловушка

Три причины, по которым механизм, объявленный устаревшим 12 лет назад, всё ещё важен:

Он расходует ваш бюджет запросов. Каждый ptr учитывается в жёстком пределе SPF — 10 DNS-запросов на проверку — том самом лимите, превышение которого обнуляет всю запись с ошибкой PermError. Механизм, который ничего надёжного не делает, всё равно отнимает бюджет, необходимый вашим реальным механизмам include:.
Он даёт непредсказуемые сбои. Обратный DNS — наименее поддерживаемый уголок большинства сетей. Когда запрос ptr истекает по тайм-ауту или прямое подтверждение не срабатывает, ваша легитимная почта теряет прохождение SPF, на которое рассчитывала.
Некоторые получатели вообще его пропускают. Поскольку стандарт объявляет его устаревшим, некоторые реализации просто игнорируют ptr — так что отправители, которых он должен был авторизовать, изначально никогда не были защищены.

Откуда он берётся

Сегодня почти никто не выбирает ptr сознательно. Он появляется по наследству: инструкция по настройке, написанная в 2009 году, шаблон, скопированный из старой конфигурации сервера, «рабочая» запись, перенесённая без изменений через три переезда хостинга. Именно этот шаблон наша перепись видит по каждому устаревшему, но всё ещё присутствующему механизму: старый совет не умирает, его копируют и вставляют. Домены, несущие ptr, не беспечны — они следуют инструкциям, которые вывели из обращения 12 лет назад.

Как это исправить — бесплатно, за пять минут

Найдите свою SPF-запись (dig TXT yourdomain.com или проверьте бесплатно).
Если она содержит ptr, определите, какие серверы на неё полагались.
Замените ptr точной формой: блоком ip4:/ip6: для серверов, которыми вы управляете, или тем include:, который документирует ваш провайдер.
Раз уж вы здесь, убедитесь, что запись заканчивается настоящим квалификатором — см. ~all против -all.

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

Что означает ptr в SPF-записи? Он авторизует любой сервер, чей обратный DNS разрешается в ваш домен. RFC 7208 §5.5 объявил его устаревшим в 2014 году как медленный и ненадёжный и указывает, что его СЛЕДУЕТ НЕ использовать, — и всё же 950 631 доменов по-прежнему публикуют его по состоянию на 2026-06-29.

Бывает ли механизм ptr в SPF когда-либо уместным? Он всё ещё разбирается синтаксически, и некоторые получатели по-прежнему его оценивают, — но стандарт советует не использовать его во всех случаях, некоторые получатели его игнорируют, и он тратит один из ваших десяти DNS-запросов. Не существует современной конфигурации, где ptr был бы верным ответом.

Что использовать вместо ptr? Блоки ip4:/ip6: для серверов, которыми вы управляете, или документированный include: вашего провайдера. Оба детерминированы, быстры и надёжны — всё то, чем ptr не является.

Учитывается ли ptr в лимите SPF из 10 запросов? Да — каждый ptr стоит как минимум одного из десяти DNS-запросов, которые получатель выполнит, прежде чем сдаться с ошибкой PermError. В записях, уже нагруженных механизмами include:, именно мёртвый механизм может оказаться тем, что перевесит вас за предел.

Проверьте свою запись на призраков

Механизм, объявленный устаревшим 12 лет назад и всё ещё сидящий в вашем DNS, — это ровно то, чего никто не ищет. На поиск уходит полминуты.

Проверьте свой домен → · Исправить SPF → · Две SPF-записи = ни одной → · Модель зрелости SPF → · Только сводные данные. Данные хранятся и обрабатываются в ЕС.