Какво е SPF ptr механизмът — и защо все още е в 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 се брои срещу твърдия таван на SPF от 10 DNS търсания на проверка — лимита, надхвърлянето на който анулира целия запис с PermError. Механизъм, не правещ нищо надеждно, все пак струва бюджета, нужен на реалните ви include: механизми.
Неуспява непредсказуемо. Обратният DNS е най-малко поддържаният ъгъл на повечето мрежи. Когато ptr търсането изтече или потвърждаването напред неуспее, легитимната ви поща губи SPF pass, на който е разчитала.
Някои получатели го пропускат изцяло. Тъй като стандартът го отказва, някои реализации просто игнорират 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.

Валиден ли е SPF ptr механизмът някога? Все още се парсва и някои получатели все още го оценяват — но стандартът съветва против него при всички случаи, някои получатели го игнорират и изразходва едно от десетте ви DNS търсания. Няма модерна конфигурация, при която ptr е правилният отговор.

Какво да използвам вместо ptr? Блокове ip4:/ip6: за сървъри, които контролирате, или документирания include: на вашия доставчик. И двата са детерминирани, бързи и надеждни — всичко, което ptr не е.

Брои ли ptr към SPF лимита от 10 търсания? Да — всяко ptr струва поне едно от десетте DNS търсания, които получателят ще извърши преди да се откаже с PermError. При записи, вече натоварени с include: механизми, мъртвият механизъм може да е именно онзи, който ви избутва над ръба.

Проверете записа си за призраци

Механизъм, остарял 12 години назад, все още стоящ в DNS, е точно видът нещо, за което никой не търси. Да погледнете отнема половин минута.

Проверете своя домейн → · Поправете SPF → · Два SPF записа = никакъв → · Моделът за зрялост на SPF → · Само агрегирани данни. Данните се съхраняват и обработват в ЕС.