Defaults.Exposed

Defaults.Exposed › Звіти

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

Опубліковано 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” — та вказує, що його “НЕ СЛІД використовувати.”

Чому у 2026 році це досі пастка

Три причини, чому механізм, визнаний застарілим 12 років тому, досі має значення:

Звідки він береться

Майже ніхто не обирає ptr сьогодні. Він потрапляє за успадкуванням: інструкція з налаштування, написана у 2009 році, шаблон, скопійований зі старої конфігурації сервера, “робочий” запис, перенесений без змін через три переїзди хостингу. Це та закономірність, яку наш перепис бачить у кожному застарілому, але наявному механізмі: стара порада не вмирає, її копіюють і вставляють. Домени, що несуть ptr, не безтурботні — вони дотримуються інструкцій, які були виведені з обігу 12 років тому.

Як це виправити — безкоштовно, за п’ять хвилин

  1. Знайдіть свій SPF-запис (dig TXT yourdomain.com або перевірте безкоштовно).
  2. Якщо він містить ptr, визначте, які сервери на нього покладалися.
  3. Замініть ptr точною формою: блоком ip4:/ip6: для серверів, якими ви керуєте, або include:, який документує ваш провайдер.
  4. Поки ви цим займаєтеся, переконайтеся, що запис закінчується справжнім кваліфікатором — див. ~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 → · Лише агреговані дані. Дані зберігаються та обробляються в ЄС.