Wat is het SPF ptr-mechanisme — en waarom staat het nog in 950.631 records? (2026)

Q: Wat moet ik gebruiken in plaats van ptr?

ip4:/ip6:-blokken voor servers die je zelf beheert, of de gedocumenteerde include: van je provider. Beide zijn deterministisch, snel en betrouwbaar — alles wat ptr niet is.

Q: Telt ptr mee voor de SPF-limiet van 10 lookups?

Ja — elke ptr kost minstens een van de tien DNS-lookups die een ontvanger uitvoert voordat hij het opgeeft met een PermError. Op records die al volgestapeld zijn met include:-mechanismen kan het dode mechanisme net degene zijn die je over de limiet duwt.

Gepubliceerd 2026-07-03

Cijfers per 2026-06-29 · methodologie v7. Geaggregeerde census over 261 miljoen beoordeelde domeinen. Alle cijfers zijn geaggregeerd — nooit het record van een individueel bedrijf. Zie hoe we beoordelen.

ptr is een SPF-mechanisme dat afzenders autoriseert via een reverse-DNS-lookup — en de SPF-standaard zelf zegt sinds 2014 “gebruik het niet”. 12 jaar later publiceren 950.631 domeinen het nog steeds. Dat is ongeveer 1 op de 146 van de 139 miljoen SPF-records op het internet die een mechanisme dragen dat de specificatie afschafte nog voordat sommige van die domeinen geregistreerd waren.

Wat ptr had moeten doen

ptr zegt: “accepteer e-mail van elke server waarvan de reverse DNS teruggeleid wordt naar mijn domein.” Het klinkt elegant — geen IP-lijsten om te onderhouden. In de praktijk vereist het dat de ontvanger een reverse lookup doet op het verbindende IP en vervolgens elke hostnaam die daaruit komt via een forward-lookup bevestigt. RFC 7208 (§5.5) schafte het in duidelijke woorden af: het mechanisme is “traag, minder betrouwbaar dan andere mechanismen bij DNS-fouten, en legt een grote belasting op de .arpa-nameservers” — en schrijft voor dat het “SHOULD NOT be used” (niet gebruikt zou moeten worden).

Waarom het in 2026 nog steeds een valkuil is

Drie redenen waarom een mechanisme dat 12 jaar geleden werd afgeschaft er nog steeds toe doet:

Het verbrandt je lookup-budget. Elke ptr telt mee voor het harde plafond van SPF van 10 DNS-lookups per controle — de limiet die, eenmaal overschreden, het hele record ongeldig maakt met een PermError. Een mechanisme dat niets betrouwbaars doet, kost je nog steeds het budget dat je echte include:-mechanismen nodig hebben.
Het faalt onvoorspelbaar. Reverse DNS is de slechtst onderhouden hoek van de meeste netwerken. Wanneer de ptr-lookup een time-out geeft of de forward-bevestiging mislukt, verliest je legitieme e-mail de SPF-pass waarop ze rekende.
Sommige ontvangers slaan het volledig over. Omdat de standaard het afschaft, negeren sommige implementaties ptr simpelweg — dus de afzenders die het had moeten autoriseren, waren van meet af aan nooit beschermd.

Waar het vandaan komt

Bijna niemand kiest tegenwoordig nog voor ptr. Het komt binnen door overerving: een installatiehandleiding geschreven in 2009, een template gekopieerd uit een oude serverconfiguratie, een “werkend” record dat intact door drie hostingverhuizingen is meegemigreerd. Dat is het patroon dat onze census ziet bij elk afgeschaft-maar-aanwezig mechanisme: oud advies sterft niet uit, het wordt gekopieerd en geplakt. De domeinen die ptr dragen zijn niet nonchalant — ze volgen instructies die 12 jaar geleden zijn ingetrokken.

Hoe je het oplost — gratis, vijf minuten

Zoek je SPF-record (dig TXT yourdomain.com of gratis controleren).
Als het ptr bevat, bepaal welke servers erop vertrouwden.
Vervang de ptr door de precieze vorm: een ip4:/ip6:-blok voor servers die je zelf beheert, of de include: die je provider documenteert.
Nu je toch bezig bent, controleer of het record eindigt in een echte qualifier — zie ~all vs -all.

Veelgestelde vragen

Wat betekent ptr in een SPF-record? Het autoriseert elke server waarvan de reverse DNS teruggeleid wordt naar jouw domein. RFC 7208 §5.5 schafte het in 2014 af als traag en onbetrouwbaar, en zegt dat het NIET gebruikt zou moeten worden — toch publiceren 950.631 domeinen het nog steeds per 2026-06-29.

Is het SPF ptr-mechanisme ooit geldig? Het parseert nog steeds, en sommige ontvangers evalueren het nog — maar de standaard raadt het in alle gevallen af, sommige ontvangers negeren het, en het verbruikt een van je tien DNS-lookups. Er is geen moderne configuratie waarin ptr het juiste antwoord is.

Wat moet ik gebruiken in plaats van ptr? ip4:/ip6:-blokken voor servers die je zelf beheert, of de gedocumenteerde include: van je provider. Beide zijn deterministisch, snel en betrouwbaar — alles wat ptr niet is.

Telt ptr mee voor de SPF-limiet van 10 lookups? Ja — elke ptr kost minstens een van de tien DNS-lookups die een ontvanger uitvoert voordat hij het opgeeft met een PermError. Op records die al volgestapeld zijn met include:-mechanismen kan het dode mechanisme net degene zijn die je over de limiet duwt.

Controleer je record op spoken

Een mechanisme dat 12 jaar geleden werd afgeschaft en nog steeds in je DNS staat, is precies het soort ding waar niemand naar zoekt. Kijken kost een halve minuut.

Controleer je domein → · SPF repareren → · Twee SPF-records = geen → · Het SPF-volwassenheidsmodel → · Alleen geaggregeerde gegevens. Gegevens opgeslagen en verwerkt in de EU.