Czym jest mechanizm ptr w SPF — i dlaczego wciąż występuje w 950 631 rekordach? (2026)

Q: Czego powinienem używać zamiast ptr?

Bloków ip4:/ip6: dla serwerów, które kontrolujesz, lub udokumentowanego przez twojego dostawcę include:. Oba są deterministyczne, szybkie i niezawodne — czyli wszystkim tym, czym ptr nie jest.

Q: Czy ptr liczy się do limitu 10 zapytań SPF?

Tak — każdy ptr kosztuje co najmniej jedno z dziesięciu zapytań DNS, które odbiorca wykona, zanim zrezygnuje z błędem PermError. W rekordach już naszpikowanych mechanizmami include: to właśnie martwy mechanizm może być tym, który przeważy szalę.

Opublikowano 2026-07-03

Dane na dzień 2026-06-29 · metodologia v7. Zbiorczy spis obejmujący 261 milionów ocenionych domen. Wszystkie liczby mają charakter zbiorczy — nigdy nie dotyczą rekordu konkretnej firmy. Zobacz jak oceniamy.

ptr to mechanizm SPF, który autoryzuje nadawców na podstawie odwrotnego zapytania DNS — a sam standard SPF mówi „nie używaj go” od 2014 roku. 12 lat później 950 631 domen wciąż go publikuje. To mniej więcej 1 na 146 spośród 139 milionów rekordów SPF w internecie, które zawierają mechanizm wycofany ze specyfikacji, zanim część tych domen w ogóle zarejestrowano.

Co ptr miał robić

ptr mówi: „przyjmuj pocztę z dowolnego serwera, którego odwrotny DNS rozwiązuje się z powrotem do mojej domeny”. Brzmi elegancko — żadnych list adresów IP do utrzymywania. W praktyce wymaga to od odbiorcy wykonania odwrotnego zapytania dla łączącego się adresu IP, a następnie potwierdzenia w przód każdej zwróconej nazwy hosta. RFC 7208 (§5.5) wycofał go wprost: mechanizm jest „wolny, mniej niezawodny niż inne mechanizmy w przypadku błędów DNS i nakłada duże obciążenie zasobów na serwery nazw .arpa” — i nakazuje, że „NIE POWINIEN być używany”.

Dlaczego w 2026 roku wciąż jest pułapką

Trzy powody, dla których mechanizm wycofany 12 lat temu wciąż ma znaczenie:

Zużywa twój budżet zapytań. Każdy ptr liczy się do twardego limitu SPF wynoszącego 10 zapytań DNS na weryfikację — limitu, którego przekroczenie unieważnia cały rekord błędem PermError. Mechanizm, który nie robi nic niezawodnego, wciąż zajmuje budżet, którego potrzebują twoje prawdziwe mechanizmy include:.
Zawodzi w nieprzewidywalny sposób. Odwrotny DNS to najbardziej zaniedbany zakątek większości sieci. Gdy zapytanie ptr przekroczy limit czasu lub potwierdzenie w przód się nie powiedzie, twoja legalna poczta traci przepustkę SPF, na której polegała.
Niektórzy odbiorcy całkowicie go pomijają. Ponieważ standard go wycofuje, część implementacji po prostu ignoruje ptr — więc nadawcy, których miał autoryzować, od początku nigdy nie byli chronieni.

Skąd się bierze

Prawie nikt dziś nie wybiera ptr świadomie. Pojawia się przez dziedziczenie: przewodnik konfiguracyjny napisany w 2009 roku, szablon skopiowany ze starej konfiguracji serwera, „działający” rekord przeniesiony w nienaruszonej postaci przez trzy przeprowadzki hostingowe. To wzorzec, który nasz spis widzi w każdym wycofanym, ale wciąż obecnym mechanizmie: stare porady nie umierają, są kopiowane i wklejane. Domeny zawierające ptr nie są niedbałe — kierują się instrukcjami wycofanymi 12 lat temu.

Jak to naprawić — bezpłatnie, w pięć minut

Znajdź swój rekord SPF (dig TXT twojadomena.com lub sprawdź bezpłatnie).
Jeśli zawiera ptr, ustal, które serwery na nim polegały.
Zastąp ptr precyzyjną formą: blokiem ip4:/ip6: dla serwerów, które kontrolujesz, lub mechanizmem include:, który dokumentuje twój dostawca.
Skoro już przy tym jesteś, upewnij się, że rekord kończy się prawdziwym kwalifikatorem — zobacz ~all a -all.

Najczęściej zadawane pytania

Co oznacza ptr w rekordzie SPF? Autoryzuje dowolny serwer, którego odwrotny DNS rozwiązuje się do twojej domeny. RFC 7208 §5.5 wycofał go w 2014 roku jako wolny i zawodny oraz mówi, że NIE POWINIEN być używany — a mimo to 950 631 domen wciąż go publikuje na dzień 2026-06-29.

Czy mechanizm ptr w SPF jest kiedykolwiek zasadny? Wciąż się parsuje, a niektórzy odbiorcy nadal go oceniają — ale standard odradza go we wszystkich przypadkach, część odbiorców go ignoruje, a zużywa jedno z twoich dziesięciu zapytań DNS. Nie ma nowoczesnej konfiguracji, w której ptr jest właściwą odpowiedzią.

Czego powinienem używać zamiast ptr? Bloków ip4:/ip6: dla serwerów, które kontrolujesz, lub udokumentowanego przez twojego dostawcę include:. Oba są deterministyczne, szybkie i niezawodne — czyli wszystkim tym, czym ptr nie jest.

Czy ptr liczy się do limitu 10 zapytań SPF? Tak — każdy ptr kosztuje co najmniej jedno z dziesięciu zapytań DNS, które odbiorca wykona, zanim zrezygnuje z błędem PermError. W rekordach już naszpikowanych mechanizmami include: to właśnie martwy mechanizm może być tym, który przeważy szalę.

Sprawdź swój rekord pod kątem duchów

Mechanizm wycofany 12 lat temu, wciąż tkwiący w twoim DNS, to dokładnie ten rodzaj rzeczy, których nikt nie szuka. Sprawdzenie zajmuje pół minuty.

Sprawdź swoją domenę → · Napraw SPF → · Dwa rekordy SPF = żaden → · Model dojrzałości SPF → · Wyłącznie dane zbiorcze. Dane przechowywane i przetwarzane w UE.