Defaults.Exposed › Oplossingen › Guides

SPF PermError: hoe u "too many DNS lookups" oplost zonder uw e-mail te breken (2026)

Gepubliceerd 2026-07-08

Cijfers per 2026-06-29 · methodologie v7. Geaggregeerde censusgegevens over 261 miljoen beoordeelde domeinen. Zie hoe wij beoordelen.

Minstens 797.263 domeinen overschrijden SPF’s limiet van 10 DNS-lookups, volgens de Defaults.Exposed-census van 261.086.232 domeinen — op 139 miljoen SPF-publiceerders. Voorbij tien lookups stopt een ontvanger en geeft PermError terug: uw SPF is ongeldig, en DMARC telt een PermError als een fail.

De oplossing kent een strikte volgorde, en de meeste gidsen doen het achterstevoren. Tel uw echte, opgeloste lookups; verwijder dode en ongebruikte includes — dat alleen al lost de meeste records op; verplaats bulkverzenders naar subdomeinen met een eigen SPF-budget; flatten alleen als laatste redmiddel, en alleen met geautomatiseerde herflattening, want statisch flattenen verrot en breekt aflevering stilletjes.

Wat betekent “SPF PermError: too many DNS lookups”?

RFC 7208 §4.6.4 beperkt elke SPF-controle tot 10 DNS-lookups. Voorbij tien stopt de ontvanger en geeft PermError terug — het hele record wordt als kapot behandeld, niet alleen het deel dat over budget gaat. Dezelfde sectie voegt een minder bekend tweede plafond toe: hoogstens 2 “void lookups” (opvragingen die geen antwoord of NXDOMAIN opleveren), dus een paar dode include:-vermeldingen voor opgezegde diensten kunnen uw SPF op zichzelf al ongeldig maken.

Het gevolg is erger dan “geen SPF”: DMARC behandelt een PermError als een SPF-fail, dus een domein dat zijn eigen SPF breekt, is niet-geauthenticeerd op het SPF-onderdeel van elke DMARC-evaluatie. Is DKIM niet ingesteld of breekt het onderweg, dan faalt die mail nu ronduit DMARC.

Eén censuscijfer laat zien hoe wreed dit faalpatroon is: 112.215 domeinen publiceren een strikt -all-record dat ongeldig is door lookup-overschrijding — op de 54.655.923 domeinen die überhaupt -all publiceren. Hun eigenaren deden het lastige deel — kozen het strikte eind — en één include te veel schakelde het hele record uit. Ze zien er strikt uit; ze zijn kapot. Voor het volledige cijferbeeld, zie het SPF PermError-rapport.

Waarom brak mijn SPF terwijl ik niets veranderde?

Omdat het budget meestal wordt opgemaakt door andermans records. Elke include: wordt recursief geëvalueerd, en elk lookup-mechanisme daarbinnen telt mee voor uw tien. Eén regel in uw DNS-paneel kan vier of vijf lookups kosten zodra hij is opgelost. Een provider nestelt nog één include, en uw SPF sterft zonder één wijziging in uw eigen zone.

De grote platforms zijn niet het probleem: Google en Microsoft hebben allebei hun eigen SPF geflatteend — _spf.google.com en spf.protection.outlook.com breiden uit naar platte IP-lijsten die nul interne lookups kosten (geverifieerd tegen live DNS, juli 2026). Echte overschrijdingen komen van diep geneste include-ketens in hostingpanelen, en van eerlijke SaaS-stapeling — postvak plus nieuwsbrief plus CRM plus helpdesk, elk “maar één include”. Niemand voegt met opzet de elfde lookup toe; die komt als optelsom van redelijke beslissingen. Daarom is de rand van de klif zo druk: 2.119.539 domeinen zitten op precies 9–10 opgeloste lookups — ongeveer 1 op 66 van alle SPF-publiceerders, vandaag prima, ongeldig op de dag dat iemand nog één include plakt. Het 99e-percentiel SPF-record lost al op naar 9 lookups. Is uw stack SaaS-zwaar, dan behandelt de gids SPF faalt voor SaaS-tools de leverancier-voor-leverancier-versie.

Welke onderdelen van een SPF-record tellen als DNS-lookups?

Tel het opgeloste totaal, niet de zichtbare regels. Vier includes kunnen vier lookups zijn, of veertien.

Hoe los ik “too many DNS lookups” op zonder e-mail te breken?

1. Voer de gratis scan uit voordat u aan DNS komt. Die lost uw volledige include-keten op en toont uw echte lookup-aantal, zodat u het werkelijke probleem repareert — niet het record zoals het in uw paneel verschijnt. (Zegt de scan dat u helemaal geen SPF hebt, dan is dat een andere storing — zie “SPF record not found”.)
2. Verwijder eerst dode en ongebruikte includes. De tool die u in 2023 liet vallen, de include van de oude host die een migratie overleefde, duplicaten, elk ptr-mechanisme. Dode includes zijn dubbel schadelijk: ze verbranden lookup-budget en zijn de gebruikelijke bron van void lookups. De meeste te-hoge records komen alleen al in deze stap weer onder de 10. Draagt uw record nog steeds mechanismen van een vorige provider, volg dan de opschoongids voor migraties.
3. Controleer of elke resterende include nog iets doet. Ontvangers evalueren SPF tegen het Return-Path-domein (RFC5321.MailFrom), niet de From-header — en veel SaaS-tools zetten hun eigen bounce-domein op het Return-Path, dus hun include in uw record doet niets behalve budget opmaken. Behoud includes alleen voor diensten die uw domein als Return-Path gebruiken; schakel voor de rest de aangepaste-domein-DKIM van de leverancier in.
4. Verplaats bulkverzenders naar subdomeinen. Nieuwsbrieven vanaf news.yourdomain.com, transactionele mail vanaf mail.yourdomain.com. Elk subdomein krijgt zijn eigen SPF-record met een vers budget van 10 lookups, en een probleem in de ene stroom lekt niet meer door naar de andere.
5. Overweeg pas dán flattenen — en alleen geautomatiseerd flattenen. Zie hieronder.
6. Scan opnieuw ter bevestiging dat u ruim onder de 10 zit — streef naar marge, niet precies naar 10, anders sluit u zich weer aan bij de 2,1 miljoen domeinen op de rand van de klif. Werk vervolgens alles af wat de scan verder markeert op de pagina repareer SPF.

Moet ik mijn SPF-record flattenen?

Flattenen vervangt includes door de onderliggende ip4:/ip6:-blokken, die nul lookups kosten. Het werkt — en met de hand gedaan is het een storing in aflevering met vertraagde werking.

Providers roteren verzend-IP’s routinematig en melden dat aan niemand. Een statische IP-lijst is correct op de dag dat u hem plakt en binnen enkele maanden stilletjes fout — en omdat de storing zich uit als anderen die uw mail niet ontvangen, komt u er laat achter. Krijgt u met snoeien en subdomeinen de limiet onder controle, stop daar dan; kopieer nooit de IP-blokken van een derde partij met de hand als permanente oplossing.

Veelgestelde vragen

Betekent een SPF PermError dat mijn e-mail stopt met afleveren? Niet meteen — dat maakt het gevaarlijk. DMARC telt een PermError als een SPF-fail, dus aflevering leunt volledig op DKIM; ontbreekt DKIM of breekt het onderweg, dan faalt u DMARC. Van 139 miljoen SPF-publiceerders in onze census (per 2026-06-29) verkeert minstens 797.263 in deze toestand — de meeste zonder het te weten.

Mijn record heeft maar vier includes — hoe kan het dan over de 10 lookups zitten? Includes worden recursief geteld: alles binnen elke include (en binnen diens includes) wordt belast op uw budget, dus vier zichtbare regels kunnen oplossen naar veertien lookups. Tel met een resolvend hulpmiddel, niet met het oog — het oplossen van de ketens is hoe ons PermError-rapport ~100× meer kapotte domeinen vond dan oppervlakkig tellen laat zien.

Ik eindig mijn record met -all — dan ben ik toch beschermd? Alleen als het record evalueert. Onze census (per 2026-06-29) vond 112.215 domeinen wier strikte -all-records ongeldig zijn door lookup-overschrijding. Een strikte qualifier op een PermError-record beschermt niets.

Geldt de limiet van 10 lookups per include of voor het hele record? De hele evaluatie: RFC 7208 §4.6.4 beperkt de volledige controle tot 10, plus hoogstens 2 void lookups. Elk subdomein heeft zijn eigen record en budget — daarom werkt stap 4.

Tellen ip4- en ip6-vermeldingen mee voor de limiet? Nee — IP-mechanismen kosten niets, precies waarom flattenen het aantal verlaagt.

Stuur de eigenaar het rapport

Repareert u dit voor een klant of werkgever, rond de klus dan af met bewijs. Voer de gratis scan opnieuw uit na uw wijzigingen en stuur het beoordeelde rapport door naar de bedrijfseigenaar: gewone taal, gedateerd, PermError verdwenen. Dat is het bewijsstuk dat ze nodig hebben voor de cyberverzekeringsverlenging en de volgende beveiligingsvragenlijst van een klant — het verschil tussen “ik heb wat DNS-records veranderd” en een gedocumenteerd voor-en-na.

Controleer uw domein gratis

Zie uw echte, opgeloste lookup-aantal — en alles wat SPF, DKIM en DMARC verder aangaat — privé en alleen voor de eigenaar.

Controleer uw domein → · Repareer SPF → · SPF faalt voor SaaS-tools → · SPF instellen op GoDaddy → · Hoe wij beoordelen → · Uitsluitend geaggregeerde gegevens. Gegevens opgeslagen en verwerkt in de EU.