Te veel DNS-lookups: SPF PermError oplossen voor Google, Microsoft 365 & SendGrid

Gepubliceerd op 11 september 2026 · 6 min. leestijd · spFlat!

"Te veel DNS-lookups" is nog steeds de meest voorkomende reden dat SPF-records tijdens de evaluatie mislukken. De limiet van 10 lookups in RFC 7208 is een hard plafond: de 11e term die een DNS-query veroorzaakt, stopt de evaluatie met een PermError. Dat is niet hetzelfde als een SPF-fail, maar veel ontvangers (waaronder Gmail) behandelen het zo streng dat je bezorgbaarheid een flinke klap krijgt.

De valkuil is het tellen van alleen de include:-tokens die je hebt getypt. Ontvangers tellen de hele keten. Google Workspace en Microsoft 365 hebben hun eigen records onlangs afgevlakt, dus die twee lijken weinig te kosten. Voeg SendGrid, Mailgun of een CRM toe en het totaal gaat over de 10, zonder dat iemand de zichtbare delen van je TXT-record heeft gewijzigd.

Waarom "te veel DNS-lookups" optreedt

Elk include:, a, mx, ptr, exists en redirect= telt als een DNS-lookup. Geneste includes ook. Directe ip4:- en ip6:-mechanismen niet. De initiële lookup van je eigen SPF-TXT-record telt evenmin mee.

Een record met vijf includes kost geen vijf lookups:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org include:_spf.salesforce.com ~all

Als je die combinatie vandaag oplost, kom je doorgaans op 11 lookups uit, al boven de limiet:

• _spf.google.com: Google publiceert nu direct IP-ranges, dus 1 lookup
• spf.protection.outlook.com: Microsoft 365 is ook een afgevlakte IP-lijst, dus 1 lookup
• sendgrid.net bevat nog een geneste include:ab.sendgrid.net: 2 lookups
• mailgun.org waaiert uit via _spf.mailgun.org → _spf1/_spf2 plus het EU-record: 5 lookups
• _spf.salesforce.com gebruikt exists: bovenop de include: 2 lookups

Per aanbieder

Google Workspace

Je Google-include is één regel:

v=spf1 include:_spf.google.com ~all

In 2026 is dat record een lijst van ip4:/ip6:-ranges, dus het kost 1 lookup. Vroeger liep het via _netblocks.google.com, _netblocks2 en _netblocks3 (ongeveer 4 lookups). De oude netblock-namen bestaan nog, maar het SPF-record op het hoogste niveau van Google verwijst er niet meer naar. Op zichzelf goedkoop, maar nog steeds 1 van je 10.

Microsoft 365

Exchange Online gebruikt include:spf.protection.outlook.com. Dat record is momenteel ook een afgevlakte IP-lijst: 1 lookup. De valkuil zit in alles wat een Microsoft-omgeving daarna toevoegt: een marketingplatform, Dynamics, een beveiligingsgateway of een include voor een tweede tenant. Dat zijn extra lookups op een budget dat al deels is opgebruikt.

SendGrid

SendGrid bevat nog een geneste include:

include:sendgrid.net

sendgrid.net publiceert een lange IP-lijst én include:ab.sendgrid.net. Volledig opgelost kost dat 2 lookups. Samen met Google, Outlook, Mailgun en een CRM zit je al boven de 10.

Zo herken je het (voordat mail als niet-geauthenticeerd wordt behandeld)

Optie 1: de spFlat!-checker (gratis, geen account)

Ga naar spflat.cloud, voer je domein in en klik op Controleren. spFlat! lost de volledige keten inclusief geneste includes op en toont het aantal lookups dat een ontvanger zou tellen, niet alleen de tokens op het hoogste niveau.

Optie 2: handmatig met dig

dig TXT yourdomain.com +short | grep -o 'include:[^ ]*' | while read inc; do
  dig TXT ${inc#include:} +short
done

Dit geeft een ruwe telling, maar mist geneste includes tenzij je zelf verder de diepte in gaat. Juist daar zitten de extra lookups verstopt.

Zo los je het op

De moeilijke manier: handmatig afvlakken

1. Los elk include:, a: en mx: in je record op
2. Verzamel alle resulterende IP-adressen en CIDR-ranges
3. Bouw een nieuw record met alleen ip4:- en ip6:-mechanismen
4. Publiceer het en hoop dat de aanbieders hun ranges niet wijzigen

De slimme manier: spFlat!

spFlat! houdt het record dat een ontvanger evalueert onder de limiet van 10 lookups én actueel:

1. Controleer je domein en zie direct het echte aantal lookups
2. Voeg je verzenddiensten toe (Google, Microsoft 365, SendGrid, Mailgun en wat je verder echt gebruikt)
3. Publiceer één include, meestal v=spf1 include:_yourdomain.spf.spflat.cloud ~all (één lookup). spFlat! bewaakt IP-wijzigingen van aanbieders 24/7 en werkt het afgevlakte record achter dat include bij.

Preventie

• Voeg nieuwe diensten toe via spFlat! in plaats van het TXT-record rechtstreeks te bewerken
• Controleer opnieuw na elke wijziging van aanbieder: één nieuw include kan je ongemerkt over de limiet duwen
• Monitor DMARC-rapporten: een plotselinge daling in SPF-alignment is vaak het eerste teken van een kapotte keten