Ce este mecanismul SPF ptr — și de ce mai apare în 950,631 înregistrări? (2026)

Q: Ce ar trebui să folosesc în locul lui ptr?

Blocuri ip4:/ip6: pentru serverele pe care le controlezi, sau include:-ul documentat de furnizorul tău. Ambele sunt deterministe, rapide și fiabile — tot ceea ce ptr nu este.

Q: Se numără ptr în limita SPF de 10 căutări?

Da — fiecare ptr costă cel puțin una dintre cele zece căutări DNS pe care un destinatar le va efectua înainte de a renunța cu un PermError. La înregistrările deja încărcate cu mecanisme include:, mecanismul mort poate fi cel care te împinge peste limită.

Publicat 2026-07-03

Cifre valabile la 2026-06-29 · metodologie v7. Recensământ agregat pe 261 milioane de domenii evaluate. Toate cifrele sunt agregate — niciodată înregistrarea unei anumite companii. Vezi cum evaluăm.

ptr este un mecanism SPF care autorizează expeditorii printr-o căutare DNS inversă — iar standardul SPF însuși spune „nu îl folosiți” încă din 2014. 12 ani mai târziu, 950,631 de domenii îl publică în continuare. Asta înseamnă aproximativ 1 din 146 dintre cele 139 milioane de înregistrări SPF de pe internet care poartă un mecanism pe care specificația l-a declarat depășit înainte ca unele dintre aceste domenii să fie înregistrate.

Ce trebuia să facă ptr

ptr spune: „acceptă corespondența de la orice server al cărui DNS invers se rezolvă înapoi la domeniul meu.” Sună elegant — nicio listă de IP-uri de întreținut. În practică, cere ca destinatarul să facă o căutare inversă pe IP-ul care se conectează, apoi să confirme prin căutare directă fiecare nume de gazdă care revine. RFC 7208 (§5.5) l-a declarat depășit în cuvinte clare: mecanismul este „lent, nu la fel de fiabil ca alte mecanisme în cazul erorilor DNS și impune o cerință mare de resurse serverelor de nume .arpa” — și indică faptul că „NU AR TREBUI folosit.”

De ce rămâne o capcană în 2026

Trei motive pentru care un mecanism declarat depășit acum 12 ani încă are importanță:

Îți consumă bugetul de căutări. Fiecare ptr se numără în plafonul strict al SPF de 10 căutări DNS per verificare — limita care, odată depășită, anulează întreaga înregistrare cu un PermError. Un mecanism care nu face nimic fiabil îți costă totuși bugetul de care au nevoie mecanismele tale reale include:.
Eșuează imprevizibil. DNS-ul invers este colțul cel mai puțin întreținut al majorității rețelelor. Când căutarea ptr expiră sau confirmarea directă eșuează, corespondența ta legitimă pierde trecerea SPF pe care se baza.
Unii destinatari îl ignoră complet. Deoarece standardul îl declară depășit, unele implementări pur și simplu ignoră ptr — așa că expeditorii pe care trebuia să îi autorizeze nu au fost niciodată protejați de la bun început.

De unde provine

Aproape nimeni nu alege ptr astăzi. Ajunge prin moștenire: un ghid de configurare scris în 2009, un șablon copiat dintr-o configurație veche de server, o înregistrare „funcțională” migrată intactă prin trei mutări de găzduire. Acesta este tiparul pe care recensământul nostru îl observă la fiecare mecanism depășit-dar-prezent: sfaturile vechi nu mor, ci sunt copiate și lipite. Domeniile care poartă ptr nu sunt neglijente — urmează instrucțiuni care au fost retrase acum 12 ani.

Cum îl repari — gratuit, în cinci minute

Găsește-ți înregistrarea SPF (dig TXT domeniultau.com sau verifică gratuit).
Dacă conține ptr, identifică ce servere se bazau pe el.
Înlocuiește ptr cu forma precisă: un bloc ip4:/ip6: pentru serverele pe care le controlezi, sau include:-ul documentat de furnizorul tău.
Cât ești acolo, confirmă că înregistrarea se termină cu un calificator real — vezi ~all vs -all.

Întrebări frecvente

Ce înseamnă ptr într-o înregistrare SPF? Autorizează orice server al cărui DNS invers se rezolvă în domeniul tău. RFC 7208 §5.5 l-a declarat depășit în 2014 ca fiind lent și nesigur și spune că NU AR TREBUI folosit — totuși 950,631 de domenii îl publică în continuare la 2026-06-29.

Este vreodată valid mecanismul SPF ptr? Încă se interpretează, iar unii destinatari încă îl evaluează — dar standardul îl dezaprobă în toate cazurile, unii destinatari îl ignoră, iar el cheltuiește una dintre cele zece căutări DNS ale tale. Nu există nicio configurație modernă în care ptr să fie răspunsul corect.

Ce ar trebui să folosesc în locul lui ptr? Blocuri ip4:/ip6: pentru serverele pe care le controlezi, sau include:-ul documentat de furnizorul tău. Ambele sunt deterministe, rapide și fiabile — tot ceea ce ptr nu este.

Se numără ptr în limita SPF de 10 căutări? Da — fiecare ptr costă cel puțin una dintre cele zece căutări DNS pe care un destinatar le va efectua înainte de a renunța cu un PermError. La înregistrările deja încărcate cu mecanisme include:, mecanismul mort poate fi cel care te împinge peste limită.

Verifică-ți înregistrarea de fantome

Un mecanism declarat depășit acum 12 ani, care stă încă în DNS-ul tău, este exact genul de lucru pe care nimeni nu îl caută. Căutarea durează o jumătate de minut.

Verifică-ți domeniul → · Repară SPF → · Două înregistrări SPF = niciuna → · Modelul de maturitate SPF → · Doar date agregate. Date stocate și procesate în UE.