Het SPF PermError-rapport: 100× meer domeinen overschrijden de 10-lookup-limiet dan de zichtbare tellingen laten zien (2026)

Q: Hoe verlaag ik mijn SPF-lookup-telling?

Verwijder ongebruikte includes en ptr, vlak je eigen infrastructuur af naar ip4:/ip6:, verplaats bulkverzenders naar subdomeinen, en tel opnieuw na elke nieuwe tool. De reparatiegids loopt het stap voor stap door.

Gepubliceerd 2026-07-03

Cijfers per 2026-06-29 · methodologie v7, plus een keten-prijsberekeningspas uitgevoerd op 2026-07-03. Uit de census van 261 miljoen beoordeelde domeinen hebben we elk SPF-include:-doel dat 100 keer of vaker wordt aangehaald opgezocht — 10.842 doelen die 95,2% van alle include-verwijzingen dekken — en de vastgehouden keten van elk domein tegen die kaart geprijsd. Onopgeloste staartdoelen telden als nul en de keteninhoud weerspiegelt de dag van resolutie, dus de kop is een conservatieve, naar de ondergrens gerichte benadering: we zeggen “minstens”. Uitsluitend geaggregeerd; nooit het record van een individueel bedrijf. Zie hoe we beoordelen.

Hoeveel domeinen overschrijden de SPF 10-lookup-limiet?

Minstens 797.263 — omdat SPF een zelfvernietiging in de standaard heeft ingebouwd, en de trigger zich verbergt waar eigenaren die niet kunnen zien. RFC 7208 §4.6.4 begrenst een SPF-check op 10 DNS-lookups; voorbij tien stopt de ontvanger en retourneert PermError, en een PermError-record beschermt niets. Tel alleen de lookups die zichtbaar zijn in het record zelf — zoals de meeste tooling doet, en zoals onze eigen census deed tot aan dit rapport — en je vindt ongeveer 8.000 overtreders (7.958, om precies te zijn). Prijs de include:-ketens die die records daadwerkelijk binnenhalen, en de telling bereikt 797.263: ongeveer 100 keer zo groot.

Waarom kunnen eigenaren het niet zien aankomen?

Omdat het budget wordt opgemaakt door de records van andere mensen. include:onetool.example.com leest als één regel in je DNS-paneel — maar de ontvanger moet dat record ook ophalen, en elk lookup-mechanisme tellen dat het bevat, recursief. Een record met drie includes kan elf kosten. Op de dag dat je over de limiet ging, veranderde er niets in je eigen zone; een provider nestelde er één include bij, en je SPF stierf zonder waarschuwing.

Erger nog, DMARC behandelt een PermError als een fail op de SPF-poot — dus een domein dat op deze manier zijn SPF brak, faalt nu de helft van zijn eigen authenticatie.

Wat de keten-prijsberekening aantrof

Bevinding	Domeinen
Over de 10-lookup-limiet, ketens geprijsd	797.263
Over de limiet met alleen zichtbare mechanismen geteld	7.958
Over de limiet terwijl ze eindigen op strikte `-all`	112.215
Op exact 9–10 lookups — de rand van de afgrond	2.119.539

Twee verhalen in die tabel — het derde, de rand van de afgrond, krijgt zijn eigen sectie hieronder:

Zichtbare tellingen missen ~99% van het defect. De zichtbare-mechanisme-telling vindt 7.958; het prijzen van de ketens vindt 797.263. Vrijwel alle schade wordt geërfd van wat de includes includen.
112.215 van de gebroken records eindigen op -all. Hun eigenaren deden alles goed — beklommen de muur, kozen de strikte afsluiting — en één include te veel maakte het geheel ongeldig. Strikt ogen en gebroken zijn is de hardste faalmodus in e-mailbeveiliging.

2,1 miljoen domeinen staan op één tool afstand van de afgrond

Het getal dat lezers die nu in orde zijn zou moeten verontrusten: 2.119.539 domeinen komen uit op exact 9 of 10 lookups — vandaag onder de limiet, dood op de dag dat iemand er nog één platform aan koppelt. Dat is ongeveer 1 op 66 van alle SPF-publishers, en het past bij de vorm van de verdeling: het 99e-percentiel SPF-record zit al op 9 lookups. Meld je aan voor nog één marketingtool, plak zijn “voeg gewoon deze include toe”-regel, en een record dat bij het ontbijt onder de limiet zat, is tegen de lunch ongeldig.

Wiens schuld is het? Steeds vaker die van de stack

De grootste providers hebben stilletjes hun SPF afgevlakt — Googles _spf.google.com en Microsofts spf.protection.outlook.com breiden nu uit tot kale IP-lijsten die nul interne lookups kosten (we hebben beide geverifieerd tegen live DNS tijdens deze analyse). De uitbarstingen komen van elders: hostingpaneel-ketens die drie lagen diep nestelen, regionale providers wiens include op zichzelf al 7–10 lookups kost, en de eerlijke opeenstapeling van SaaS — mailbox plus nieuwsbrief plus CRM plus helpdesk, elk “gewoon één include”. Bijna niemand voegt de elfde lookup met opzet toe. Hij arriveert als de som van redelijke beslissingen.

Hoe controleer en repareer je de jouwe — gratis

Tel je echte totaal — onze gratis check lost je keten op, of gebruik een willekeurige SPF-lookup-teller.
Snoei dood gewicht: tools die je niet meer gebruikt, dubbele includes, en het verouderde ptr-mechanisme.
Vlak alleen af wat je zelf beheert. Een diepe include vervangen door zijn IP-blokken werkt voor je eigen infrastructuur; IP’s van derden veranderen zonder aankondiging.
Geef bulkverzenders een subdomein. Nieuwsbrieven van news.yourdomain.com krijgen hun eigen record en hun eigen 10-lookup-budget.

Veelgestelde vragen

Wat is de SPF 10 DNS-lookup-limiet? RFC 7208 §4.6.4 staat maximaal 10 DNS-lookups toe om één SPF-record te evalueren — inclusief de lookups binnen elke include:, recursief geteld. Overschrijding retourneert PermError: het record wordt als ongeldig behandeld en biedt geen bescherming.

Wat betekent SPF PermError? Een permanente evaluatiefout — de ontvanger kon je record niet verwerken (te veel lookups, meerdere records, of gebroken syntaxis) en behandelt je domein alsof het geen bruikbare SPF heeft. DMARC telt het als een fail op de SPF-poot.

Hoeveel domeinen overschrijden de SPF-lookup-limiet? Minstens 797.263 van 139 miljoen SPF-publishers, volgens onze keten-prijsberekeningspas — ongeveer 100× de 7.958 die zichtbaar zijn zonder ketens op te lossen. Nog eens 2.119.539 zitten op 9–10 lookups, één include van de limiet.

Stopt een PermError de bezorging van mijn e-mail? Meestal niet — ontvangers gaan verder zonder SPF, en je mail leunt op DKIM en reputatie. Wat stopt met werken is bescherming: vervalsers worden niet langer geweigerd, en elke DMARC-check van je mail verliest zijn SPF-poot. Het is onzichtbaar tot het duur wordt.

Hoe verlaag ik mijn SPF-lookup-telling? Verwijder ongebruikte includes en ptr, vlak je eigen infrastructuur af naar ip4:/ip6:, verplaats bulkverzenders naar subdomeinen, en tel opnieuw na elke nieuwe tool. De reparatiegids loopt het stap voor stap door.

Ontdek je echte getal

De mechanismen die je kunt zien zijn niet je lookup-telling — het opgeloste getal is dat wat ontvangers berekenen, en het is een check van 30 seconden.

Controleer je domein → · Repareer SPF → · Het SPF-maturiteitsmodel → · Twee SPF-records = geen → · De ptr-val → · Uitsluitend geaggregeerde data. Data opgeslagen en verwerkt in de EU.