Defaults.Exposed › Rapporten

Waarom faalt mijn SPF? Het SaaS 10-lookup-probleem voor UK- en EU-afzenders (2026)

Gepubliceerd 2026-07-09

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

Als SPF faalt voor een bedrijf dat SaaS-tools gebruikt in de UK of EU, is de meest waarschijnlijke oorzaak één RFC-regel die je nooit hoefde te kennen: voorbij 10 DNS-lookups retourneert SPF geen “fail” — het retourneert PermError, wat betekent dat het record wordt behandeld alsof het niet bestaat. Al 797.263 domeinen hebben die grens overschreden. Nog eens 2.119.539 bevinden zich op exact 9–10 lookups — één nieuwe tool verwijderd van dezelfde afgrond.

Waarom faalt SPF als je een SaaS-tool toevoegt?

SPF werkt door de mailservers op te sommen die gemachtigd zijn e-mail te verzenden namens jouw domein. Moderne bedrijven draaien geen eigen mailservers — ze gebruiken Google Workspace voor interne e-mail, Mailchimp voor campagnes, HubSpot voor salessequenties, Pipedrive voor CRM-outreach. Elk platform geeft je een include:-regel om in je DNS te plakken.

Het probleem: elke include: is zelf een DNS-lookup. En elk record binnen dat include kan recursief meer lookups activeren. RFC 7208 §4.6.4 stelt een harde limiet van tien. Voorbij tien stopt de ontvangende mailserver met evalueren en retourneert PermError — en een PermError is geen zachte fout die in spam belandt. Het betekent dat je SPF-record als afwezig wordt behandeld. E-mailauthenticatie faalt op het SPF-been.

Je ziet dit niet in je DNS-paneel. De teller vuurt alleen tijdens live evaluatie. Je kunt drie include:-regels in je zichtbare record hebben en toch twaalf lookups diep zitten, omdat elk leveranciers-SPF-record zijn eigen sub-includes binnenhaalt.

Hoeveel domeinen hebben de limiet al overschreden?

Al 797.263. Dat is het aantal nadat we elke SPF include:-doelstelling die 100 keer of meer wordt gerefereerd hebben opgelost — 10.842 afzonderlijke doelstellingen die 95,2% van alle include-referenties dekken — en de volledige keten van elk domein hebben geprijsd. De oppervlaktetelling (wat je zou vinden door alleen de zichtbare regels in een record te tellen) vindt ruwweg 7.958. Het keten-geprijsde cijfer is 100 keer groter, omdat bijna alle schade onzichtbaar is binnen include-doelstellingen.

De situatie die een Europees bedrijf het meest treft:

Europese hostingproviders en zwakke SPF-standaardinstellingen

De hostingprovider waarmee je bent begonnen maakt uit — want sommige stellen SPF-standaardinstellingen in die al meerdere van je tien lookups verbruiken voordat je ook maar één SaaS-tool aansluit.

Onder de grootste hostingproviders die door Europese domeinen in onze census worden gebruikt:

IONOS springt eruit: 1,0% van de IONOS-gehoste domeinen heeft handhavende DMARC, wat betekent dat de overgrote meerderheid helemaal geen zinvolle afzenderauthenticatie heeft. OVH-domeinen doen het beter op de SPF strict-instelling (43,7%) maar zakken toch naar 2,2% op DMARC-handhaving — SPF alleen, zonder DMARC om het te koppelen aan de From:-header, beschermt alleen de envelop, niet wat de ontvanger ziet.

Microsoft 365 is de positieve uitzondering: 85,0% van de Microsoft-gehoste domeinen gebruikt strikt SPF, grotendeels omdat Microsoft’s mail-flow wizard standaard -all instelt. Google Workspace stelt standaard ~all (softfail) in, waardoor 92% van zijn domeinen zonder strikte beveiliging blijft.

Hoe je je SPF-fout in minder dan 60 seconden diagnosticeert

De snelste controle is een gratis tool die de volledige lookup-keten evalueert — niet alleen het zichtbare record. Voer nslookup -type=TXT joudomein.com uit op de opdrachtregel en tel elke include: die je ziet. Zoek vervolgens elk van die records op en tel die van hen. Als je vingers op raken voordat de includes op raken, zit je in de gevarenzone.

Een betrouwbaardere aanpak: controleer je domein hier — de scanner evalueert de volledige opgeloste keten, markeert PermError en laat zien welke mechanismen je lookup-budget verbruiken.

Drie diagnostische uitkomsten:

• PermError — je zit al boven de tien. Elke e-mail die je verstuurt faalt de SPF-controle bij de ontvanger.
• Op 9–10 lookups — je staat op de rand. De volgende SaaS-integratie topt je over de rand.
• Softfail (~all) in plaats van hardfail (-all) — je zit onder de limiet maar het record is te permissief ingesteld om echte bescherming te bieden. Zie het SPF-misconfiguratierapport voor het volledige beeld over -all vs ~all.

Hoe je SPF repareert als je meerdere SaaS-tools gebruikt

Er zijn drie aanpakken, in volgorde van duurzaamheid:

1. Controleer en snoei. Begin met het opsommen van elke include: in je huidige record. Verwijder elk platform dat je niet meer gebruikt — oude ESP’s, CRM-tools uit eerdere contracten, platforms die je hebt getest maar verlaten. Dit is gratis en herstelt vaak meerdere lookups. Elke verwijderde include: kan 1–3 sub-lookups elimineren.

2. Flatten je SPF-record. SPF-flattening lost alle include:-doelstellingen op in hun onderliggende IP-bereiken en schrijft ze rechtstreeks als ip4:- en ip6:-mechanismen in je record. IP-mechanismen activeren geen lookups, zodat een gevlakt record tientallen verzendingsbronnen kan opnemen en toch op nul lookups blijft. Het nadeel: je moet opnieuw flattenen wanneer een leverancier zijn verzendende IP’s bijwerkt, wat zonder aankondiging gebeurt. De meeste bedrijven gebruiken een betaalde SPF-flattening-service (PowerDMARC, EasyDMARC, Dmarcian en anderen bieden dit aan) of bouwen een monitoringworkflow.

3. Gebruik SPF-macro’s. RFC 7208-macro’s laten je records bouwen die per controle één DNS-lookup uitvoeren en dynamisch antwoorden, in plaats van een keten van includes. Macro’s vereisen DNS-hosting-ondersteuning en enige implementatie-inspanning, maar ze zijn de architecturaal zuivere oplossing voor organisaties met veel SaaS-afzenders.

Na het repareren van SPF, koppel het aan DMARC-handhaving — SPF zonder DMARC authenticeert alleen de envelopafzender, niet het From:-adres in de header dat ontvangers zien.

Veelgestelde vragen

Waarom slaagt mijn SPF-record voor mijn DNS-tool maar faalt het toch in e-mailheaders? De meeste DNS-lookuptools tellen alleen de mechanismen die zichtbaar zijn in je eigen record, niet de sub-lookups die deze mechanismen activeren. Je kunt twee include:-regels hebben en toch over de limiet zitten als het record van elke leverancier er nog meerdere bevat. Alleen een keten-pricingstool (of een ontvangende mailserver) telt de volledige diepte. Controleer je domein om het echte ketenaantal te zien.

Betekent SPF-falen dat mijn e-mails in spam terechtkomen? PermError (te veel lookups) betekent dat het SPF-been van authenticatie een niet-resultaat retourneert — effectief afwezig. DMARC evalueert zowel SPF als DKIM; als DKIM slaagt, kan DMARC toch slagen ondanks de SPF PermError. Als geen van beide slaagt, faalt DMARC, en de uitkomst hangt af van je DMARC-beleid. Bij p=none wordt e-mail nog steeds bezorgd maar de fout wordt gelogd. Bij p=quarantine of p=reject wordt e-mail gefilterd of teruggestuurd. Repareer SPF zodat je niet alleen op DKIM vertrouwt.

Hoeveel lookups gebruikt een typische SaaS-stack? Het p99 SPF-record in onze census zit al op 9 lookups — precies op de limiet — voordat er iets wordt toegevoegd. Een Google Workspace-record voegt 3–4 lookups toe; Mailchimp voegt 1–2 toe; HubSpot voegt 1–3 toe afhankelijk van hun huidige configuratie. Drie gangbare tools plus de standaard van je hostingprovider is vaak genoeg om over de tien te tippen.

Is SPF-flattening veilig? Ja, mits je het actueel houdt. Flattening converteert include:-ketens naar statische IP-bereiken — als een leverancier hun verzendende IP’s roteert en je niet opnieuw flattent, begin je hun e-mail af te wijzen. De meeste organisaties gebruiken een beheerde flattening-service die bewaakt op IP-wijzigingen in plaats van het handmatig bij te houden.

Mijn SPF is al jaren zo — waarom faalt het nu ineens? Omdat je leveranciers hun SPF-records hebben bijgewerkt, niet die van jou. Elke keer dat een SaaS-platform een nieuw verzendend IP-bereik toevoegt of een andere include nest, stijgt de ketenkosten zonder enige wijziging aan jouw kant. De 10-lookup-limiet wordt live geëvalueerd bij ontvangst van berichten, dus een leverancierswijziging op dinsdagochtend kan je SPF dinsdagmiddag al breken.

Verbetert het repareren van SPF de e-mailbezorging? Het verwijdert een bron van authenticatiefout, wat een vereiste is voor consistente bezorging — vooral omdat Google en Yahoo nu DMARC-afstemming afdwingen voor bulkverzenders. SPF alleen is niet het hele plaatje: combineer het met DKIM en DMARC voor volledige e-mailauthenticatie.

Controleer je SPF gratis

Als je niet zeker weet of je SPF-record over de lookuplimiet zit — of te zwak is ingesteld om je domein te beschermen — voer dan een gratis controle uit. Het evalueert de volledige opgeloste keten en laat je precies zien waar het budget wordt besteed.

Controleer je domein → · Repareer SPF → · Het SPF PermError-rapport → · SPF-misconfiguratierapport → · Het SPF-adoptierijpheidsmodel → · Repareer DMARC → · Uitsluitend geaggregeerde gegevens. Gegevens opgeslagen en verwerkt in de EU.