SPF PermError oplossen in 2026

Gepubliceerd op 3 juni 2026 · 4 min. leestijd · spFlat!

Overschrijdt je SPF-record de limiet van 10 DNS-lookups, dan weigeren ontvangende mailservers het met een PermError: een permanente fout. Je e-mail krijgt geen softfail, maar loopt keihard vast.

Wat het veroorzaakt, hoe je het herkent en hoe je het definitief oplost, lees je hieronder.

Wat is een SPF PermError?

Met SPF (Sender Policy Framework) geven domeineigenaren aan welke mailservers namens hen e-mail mogen versturen. De SPF-specificatie (RFC 7208) legt tijdens de SPF-evaluatie een harde limiet op van 10 DNS-lookups.

Overschrijdt je record die limiet, dan geeft de ontvangende mailserver een PermError terug en stopt de SPF-controle volledig. Het gevolg verschilt per ontvanger:

• Strikte ontvangers (Gmail, Outlook.com) behandelen het als SPF-fail.
• Mildere ontvangers behandelen het als neutral of softfail.
• Hoe dan ook krijgt je bezorgbaarheid een klap.

Waarom gebeurt dit?

De limiet van 10 lookups is snel bereikt, omdat elk SPF-include:-statement als één lookup telt, maar daarachter ook meer lookups kan verbergen.

Veelvoorkomende boosdoeners:

• Google Workspace (include:_spf.google.com): voegt intern zo'n 4 à 5 lookups toe
• Microsoft 365 (include:spf.protection.outlook.com): voegt zo'n 2 à 3 lookups toe
• Mailchimp, SendGrid, Mailgun, Mandrill, HubSpot, Salesforce: elk minstens 1 lookup
• Eigen a:- of mx:-mechanismen met meerdere A/AAAA-records

Een gemiddeld middelgroot bedrijf met Gmail, Outlook, Mailchimp en één CRM zit op papier al op 8 tot 12 lookups, maar de werkelijke keten komt vaak ruim boven de 15 uit zodra geneste includes zijn opgelost.

Hoe herken je het?

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

Ga naar spflat.cloud, voer je domein in en klik op Controleren. De tool lost je volledige SPF-keten op, inclusief alle geneste includes, en laat precies zien hoeveel lookups je verbruikt.

Optie 2: Handmatige dig-keten

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

Dit geeft een ruwe telling, maar slaat geneste includes over, tenzij je het script uitbreidt met diepere loops.

Optie 3: Online SPF-validators

Tools zoals dmarcian.com of mxtoolbox.com kunnen helpen, maar veel daarvan stoppen bij 10 lookups en kijken niet verder. Dat geeft een vals gevoel van veiligheid.

Zo los je het op (de moeilijke manier)

Wil je dit handmatig doen?

1. Los elke include:, a:, mx: en ptr: 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 in je DNS

Voor:

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

Na handmatig afvlakken:

v=spf1 ip4:209.85.128.0/17 ip4:40.92.0.0/15 ip4:209.61.151.0/24 ~all

Zo los je het op (de slimme manier)

Precies dit probleem lost spFlat! voor je op:

1. Controleer je domein op spflat.cloud en zie direct hoeveel lookups je nu gebruikt
2. Voeg je domein met je huidige includes toe aan spFlat!
3. Publiceer één DNS-record: spFlat! bewaakt IP-wijzigingen van aanbieders 24/7 en houdt je record automatisch bij

Geen handmatige lookups. Geen spreadsheets met IP-wijzigingen. Geen nachtelijk debuggen omdat Google zijn ranges heeft gewijzigd.

Preventie

Is je SPF-record eenmaal afgevlakt, houd het dan zo op orde:

• Voeg nieuwe e-maildiensten toe via spFlat! en wijzig het TXT-record niet rechtstreeks
• Houd DMARC-rapporten in de gaten: een plotselinge daling van het aantal berichten met SPF-alignment is vaak het eerste teken van een IP-wijziging bij een aanbieder
• Gebruik geautomatiseerde monitoring: spFlat! bewaakt je records met 99,9% uptime vanaf 12 locaties wereldwijd