Mi az SPF ptr mechanizmus – és miért van még mindig 950,631 rekordban? (2026)

Q: Mit használjak a ptr helyett?

ip4:/ip6: blokkokat az általad kezelt szerverekhez, vagy a szolgáltatód dokumentált include:-ját. Mindkettő determinisztikus, gyors és megbízható – minden, ami a ptr nem.

Q: Beleszámít a ptr az SPF 10-lekérdezéses korlátba?

Igen – minden ptr legalább egyet elhasznál abból a tíz DNS-lekérdezésből, amelyet a fogadó elvégez, mielőtt PermError-ral feladja. Az include: mechanizmusokkal már amúgy is teli rekordokon éppen a halott mechanizmus lehet az, amely átlök a határon.

Közzétéve 2026-07-03

Adatok eddig: 2026-06-29 · v7 metodológia. Aggregált census 261 millió osztályozott domainen. Minden adat aggregált – soha nem egy adott vállalkozás rekordja. Lásd: hogyan osztályozunk.

A ptr egy SPF mechanizmus, amely a küldőket fordított DNS-lekérdezéssel hitelesíti – és maga az SPF szabvány 2014 óta azt mondja: „ne használd”. 12 évvel később 950,631 domain még mindig közzéteszi. Ez nagyjából minden 146. az internet 139 millió SPF-rekordja közül, amely olyan mechanizmust hordoz, amelyet a specifikáció még azelőtt elavulttá nyilvánított, hogy ezek egy részét regisztrálták volna.

Mit kellett volna a ptr-nek csinálnia

A ptr azt mondja: „fogadj el levelet bármely szerverről, amelynek a fordított DNS-e visszavezet a domainemre.” Elegánsan hangzik – nincsenek karbantartandó IP-listák. A gyakorlatban azonban azt igényli, hogy a fogadó fél fordított lekérdezést végezzen a csatlakozó IP-n, majd előre-irányban megerősítse minden visszakapott hosztnevet. Az RFC 7208 (§5.5) egyértelmű szavakkal elavulttá nyilvánította: a mechanizmus „lassú, DNS-hibák esetén nem olyan megbízható, mint más mechanizmusok, és nagy erőforrás-igényt támaszt az .arpa névszerverekkel szemben” – és arra utasít, hogy „NEM AJÁNLOTT használni.”

Miért csapda ez még 2026-ban is

Három ok, amiért egy 12 éve elavulttá nyilvánított mechanizmus még mindig számít:

Felemészti a lekérdezési keretedet. Minden ptr beleszámít az SPF kemény felső korlátjába, amely ellenőrzésenként 10 DNS-lekérdezés – ez az a határ, amelyet túllépve az egész rekord PermError-ral érvénytelenné válik. Egy mechanizmus, amely semmi megbízhatót nem tesz, mégis elveszi azt a keretet, amelyre a valódi include: mechanizmusaidnak szüksége van.
Kiszámíthatatlanul hibázik. A fordított DNS a legtöbb hálózat legkevésbé karbantartott zuga. Amikor a ptr lekérdezés időtúllépéssel elszáll vagy az előre-irányú megerősítés meghiúsul, a legitim leveled elveszíti azt az SPF-átjutást, amelyre számított.
Egyes fogadók teljesen kihagyják. Mivel a szabvány elavultnak nyilvánítja, egyes implementációk egyszerűen figyelmen kívül hagyják a ptr-t – így a küldők, amelyeket hitelesítenie kellett volna, eleve nem voltak védve.

Honnan származik

Ma szinte senki nem választja a ptr-t. Öröklés útján kerül oda: egy 2009-ben írt beállítási útmutató, egy régi szerverkonfigból másolt sablon, egy „működő” rekord, amely három hosting-váltáson át változatlanul vándorolt tovább. Ez a minta, amit a censusunk minden elavult-de-jelenlévő mechanizmusnál lát: a régi tanács nem hal meg, hanem másolják-beillesztik. A ptr-t hordozó domainek nem hanyagok – olyan utasításokat követnek, amelyeket 12 éve visszavontak.

Hogyan javítsd ki – ingyen, öt perc alatt

Keresd meg az SPF-rekordodat (dig TXT yourdomain.com vagy ellenőrizd ingyen).
Ha tartalmaz ptr-t, azonosítsd, mely szerverek támaszkodtak rá.
Cseréld le a ptr-t a pontos formára: egy ip4:/ip6: blokkra az általad kezelt szerverekhez, vagy az include:-ra, amelyet a szolgáltatód dokumentál.
Ha már ott vagy, ellenőrizd, hogy a rekord valódi kvalifikátorral végződik-e – lásd ~all vs -all.

Gyakran ismételt kérdések

Mit jelent a ptr egy SPF-rekordban? Bármely szervert hitelesít, amelynek fordított DNS-e a domainedbe vezet vissza. Az RFC 7208 §5.5 2014-ben lassúként és megbízhatatlanként elavulttá nyilvánította, és azt mondja, hogy NEM AJÁNLOTT használni – mégis 950,631 domain még mindig közzéteszi 2026-06-29 állapot szerint.

Érvényes-e valaha az SPF ptr mechanizmus? Még mindig értelmezhető, és egyes fogadók még mindig kiértékelik – de a szabvány minden esetben ellene javasol, egyes fogadók figyelmen kívül hagyják, és elhasznál egyet a tíz DNS-lekérdezésedből. Nincs olyan modern konfiguráció, ahol a ptr lenne a helyes válasz.

Mit használjak a ptr helyett? ip4:/ip6: blokkokat az általad kezelt szerverekhez, vagy a szolgáltatód dokumentált include:-ját. Mindkettő determinisztikus, gyors és megbízható – minden, ami a ptr nem.

Beleszámít a ptr az SPF 10-lekérdezéses korlátba? Igen – minden ptr legalább egyet elhasznál abból a tíz DNS-lekérdezésből, amelyet a fogadó elvégez, mielőtt PermError-ral feladja. Az include: mechanizmusokkal már amúgy is teli rekordokon éppen a halott mechanizmus lehet az, amely átlök a határon.

Ellenőrizd a rekordodat kísértetek után

Egy 12 éve elavulttá nyilvánított mechanizmus, amely még mindig ott ül a DNS-edben, pontosan az a fajta dolog, amit senki nem keres. A keresés fél percet vesz igénybe.

Ellenőrizd a domained → · SPF javítása → · Két SPF-rekord = egy sem → · Az SPF-érettségi modell → · Csak aggregált adatok. Az adatokat az EU-ban tároljuk és dolgozzuk fel.