SPF Permerror: Hoe te veel DNS-lookups te verhelpen

Sender Policy Framework (SPF) is een methode voor e-mailverificatie waarmee domeineigenaren kunnen bepalen welke mailservers berichten mogen verzenden met hun domeinnaam. Wanneer een bericht binnenkomt, controleren ontvangende mailservers SPF om te zien of het afkomstig is van een van die goedgekeurde bronnen, voordat ze beslissen hoe ze het moeten behandelen.

Tijdens SPF-validatie wijst een PermError op een permanent probleem in het SPF-record waardoor het niet correct kan worden geëvalueerd. Dit gebeurt meestal wanneer het record de DNS-lookup-limiet overschrijdt of structurele problemen bevat die de verwerking van SPF verstoren. In plaats van af en toe te mislukken, mislukt de authenticatie elke keer.

Wanneer dat gebeurt, kunnen zelfs legitieme e-mails verdacht lijken voor ontvangende servers. Berichten kunnen worden geweigerd, naar spam worden doorgestuurd of ook DMARC-fouten veroorzaken, allemaal omdat het SPF-record zelf niet betrouwbaar kan worden geëvalueerd.

Als u SPF PermError wilt oplossen, is het belangrijk om eerst te begrijpen wat de oorzaak ervan is. In dit artikel bespreken we de meest voorkomende oorzaken van SPF PermError en leggen we praktische manieren uit om deze op te lossen, zodat uw e-mails correct worden geauthenticeerd en in de juiste inbox terechtkomen.

Wat is SPF Permerror?

Een SPF Permerror is een permanente fout in je SPF record, wat betekent dat er iets mis mee is waardoor het niet meer werkt.

Een Permerror-resultaat wordt geretourneerd door ontvangende mailservers wanneer uw SPF-record een kritiek probleem heeft waardoor het niet kan worden geëvalueerd, zoals onjuiste syntaxis, te veel DNS-lookups (meer dan de 10-limiet) of ongeldige mechanismen. In tegenstelling tot een gewone SPF "fail" (wat betekent dat een e-mail niet door de authenticatie kwam), geeft een Permerror aan dat het SPF record zelf kapot is of verkeerd geconfigureerd. Dit heeft niet alleen invloed op de deliverability, maar kan ook uw DMARC bescherming verzwakken als SPF het enige mechanisme is dat u gebruikt om uw e-mail af te stemmen.

Waarom heeft SPF een 10 DNS Lookup Limiet?

Je denkt misschien dat de 10 DNS lookup limiet in SPF beperkend is, maar daar is een goede reden voor.

Volgens RFC 7208bestaat deze limiet voornamelijk voor veiligheids- en prestatiedoeleinden. Specifiek helpt het ontvangende mailservers te beschermen tegen Denial-of-Service (DoS) aanvallen veroorzaakt door overmatige DNS queries.

Dit is hoe het misbruikt kan worden:

Een bedreigende actor kan een kwaadaardig SPF-record maken dat honderden DNS-opzoekingen triggert door naar meerdere domeinen of inclusies te verwijzen. Dit kan worden gekoppeld aan een vervalst domein dat zich voordoet als een vertrouwd bedrijf. Elke keer dat een ontvangende server zo'n e-mail probeert te valideren, wordt deze gedwongen om al deze zoekopdrachten uit te voeren, waardoor de server vertraagt of zelfs crasht.

Door DNS lookups te beperken tot 10, helpt SPF:

• De prestaties van e-mailverwerking op peil houden
• Beschermen tegen aanvallen van uitputting van bronnen
• Betrouwbaarheid tegen spoofing verbeteren door beter ontwerp van SPF-records aan te moedigen

Wat veroorzaakt SPF-fouten?

Een SPF Permerror kan worden veroorzaakt door verschillende problemen, waaronder overmatige DNS lookups, syntaxisfouten, verkeerd geconfigureerde records of zelfs te grote SPF entries. Laten we de meest voorkomende oorzaken eens op een rijtje zetten:

1. SPF-syntaxis fouten

Een onjuiste opmaak of ongeldige syntaxis in het SPF-record kan leiden tot een Permerror, die een juiste evaluatie verhindert.

Veel voorkomende oorzaken:

• Ontbrekende of verkeerd geplaatste tekens (bijvoorbeeld aanhalingstekens " of dubbele punten 🙂
• Ongeldige of misvormde mechanismen of kwalifiers (bijvoorbeeld, gebruik van include_spf.example.com in plaats van include:spf.example.com)
• Onjuiste macrodefinities of niet-ondersteunde macro's
  

Voorbeelden:

❌ v=spf1 include_spf.example.com -all → ontbrekende dubbele punt in include

❌ v=spf1 +mx a:mail.example.com -all → + qualifier is onnodig en wordt vaak verkeerd gebruikt

2. Problemen met de DNS-configuratie

Hierbij gaat het om problemen met de DNS-setup in verband met je SPF-record.

Veel voorkomende problemen:

• SPF-record dat verwijst naar onbestaande of verkeerd geconfigureerde domeinen
• Ontbrekende SPF-records op domeinen waarnaar wordt verwezen
• Ongeldige of verouderde DNS-recordtypes (bijv. gebruik van SPF-records in plaats van TXT)
  

Een voorbeeld:

Uw domeinverwijzingen omvatten:spf.partner.com, maar spf.partner.com bestaat niet of heeft geen TXT-record, waardoor de SPF-evaluatie mislukt.

3. Te veel DNS-lookups

SPF staat slechts 10 DNS lookups toe tijdens de evaluatie van records, zoals gedefinieerd in RFC 7208, Paragraaf 4.6.4. Dit is een veiligheidsmaatregel om misbruik te voorkomen (bijvoorbeeld Denial-of-Service aanvallen) en evaluaties licht te houden.

Wat telt als een lookup:

• opnemen
• a, mx, ptr
• bestaat, omleiden
  

Lege zoekopdrachten (query's die geen DNS-gegevens opleveren) zijn ook beperkt tot 2.

Gemeenschappelijke oorzaak:

Een SPF record met veel include: mechanismen of geneste includes die gezamenlijk de 10-lookup limiet overschrijden.

4. Circulaire omvat

Circular includes treden op wanneer SPF-records in een lus naar elkaar terugverwijzen, waardoor oneindige resolutiecycli ontstaan.

Een voorbeeld:

• Domein A: v=spf1 include:domeinB.com -all
• Domein B: v=spf1 include:domeinA.com -all

Deze cirkelvormige verwijzing zorgt ervoor dat SPF-evaluatie mislukt, wat vaak resulteert in een Permerror.

5. Ongeldige mechanismen of kwalificaties

Het gebruik van niet-erkende of deprecated mechanismen in je SPF-record kan resulteren in een Permerror.

Veelgemaakte fouten:

• Typos zoals ip6v in plaats van ip6
• Niet-ondersteunde mechanismen zoals all:, ptr: verkeerd gebruikt
• Onnodig of onjuist gebruik van + of ? aanduidingen
  

Een voorbeeld:

❌ v=spf1 ptr:mail.example.com -all → ontmoedigd mechanisme
❌ v=spf1 ip4v:192.0.2.0/24 -all → ongeldig mechanisme (ip4v moet ip4 zijn)

6. Oversized SPF-records

SPF-records moeten voldoen aan beperkingen qua grootte:

• Elke tekenreeks in een TXT-record moet ≤ 255 tekens zijn.
• De totale lengte van een TXT-record mag niet langer zijn dan 512 bytes.
  

Oorzaken van te grote records:

• Te veel IP's, bevat of mechanismen
• Dubbele of onnodige invoer

Een voorbeeld:

Een record als v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 include:spf1.example.com include:spf2.example.com include:spf3.example.com include:spf4.example.com -all kan DNS limieten of grootte beperkingen overschrijden.

Hoe te veel DNS-lookups uw e-mails verstoren

Als je SPF-record meer dan 10 DNS-opzoekingen veroorzaakt, kan dit de aflevering van je e-mail ernstig verstoren. Dit is wat er kan gebeuren:

• Vertragingen bij levering: E-mailservers kunnen de verwerking vertragen wanneer ze je SPF record proberen te evalueren, waardoor de aflevering vertraagd wordt.
• Time-out fouten: Te veel lookups kunnen leiden tot time-outs tijdens SPF-evaluatie, waardoor berichten stilletjes mislukken of worden verwijderd.
• Afgewezen e-mails: Sommige ontvangende servers kunnen e-mails met SPF Permerror weigeren of markeren om hun infrastructuur te beschermen.
• DMARC mislukt: Als uw DMARC-beleid is gebaseerd op SPF-afstemming, kan een mislukte SPF-controle DMARC doorbreken en de betrouwbaarheid van uw domein verminderen.

Hoe SPF-fouten herstellen (stap voor stap)

Handmatige oplossingen

• Verwijder ongebruikte include-mechanismen

Loop elke include: in je SPF-record na en controleer of deze nog steeds nodig is. Als het gekoppeld is aan een service die je niet meer gebruikt, verwijder het dan.

• Vervang include door IP-adressen (indien statisch)

Als een include: gewoon naar een statisch IP of klein IP-bereik wijst, vervang het dan direct door een ip4: of ip6: mechanisme om een DNS lookup te vermijden.

• PTR-mechanismen elimineren

PTR wordt afgeraden door RFC 7208 vanwege prestatie- en betrouwbaarheidsproblemen. Verwijder het volledig om het aantal zoekacties te verminderen en fouten te voorkomen.

• Consolideren inclusief domeinen

Sommige diensten (bijv. e-mailplatforms of providers) bieden meerdere SPF-vermeldingen. Controleer hun documentatie, want vaak bieden ze een enkele geconsolideerde vermelding die je kunt gebruiken in plaats van meerdere.

• Gebruik waar mogelijk ip4 / ip6

Als je de IP's van je verzendservers kent, voeg ze dan direct toe met ip4: of ip6: in plaats van te vertrouwen op mechanismen zoals MX of A die lookups vereisen.

Best practice: gebruik een automatische SPF-afvlakkingstool

Automatisch afvlakken van SPF is het proces van het dynamisch omzetten van meerdere "include" verklaringen en andere DNS-gebaseerde lookups in een vereenvoudigde lijst van IP-adressen. Deze aanpak vermindert het aantal DNS-opzoekingen tijdens SPF-controles.

Handmatig SPF-afvlakken lijkt misschien een snelle oplossing, maar brengt ernstige risico's met zich mee. Als uw e-mailserviceprovider zijn verzend-IP's wijzigt, wordt deze wijziging niet doorgevoerd in uw SPF-record, tenzij u deze handmatig bijwerkt. Daarom is voortdurende monitoring en handmatige bewerking nodig om aan de vereisten te blijven voldoen. Een verouderde IP in uw afgevlakte record kan ervoor zorgen dat SPF niet meer werkt, wat van invloed is op de afleverbaarheid van e-mails en de DMARC-afstemming.

PowerSPF is onze gehoste SPF-afvlakking- en optimalisatietool die het hele proces automatiseert, zodat je je nooit meer zorgen hoeft te maken over opzoeklimieten of IP-veranderingen.

• Automatische updates wanneer leveranciers van IP-adres veranderen: Wij houden uw SPF-record in realtime bijgewerkt.
• Eenmalige installatie: Eenmaal instellen en verder geen omkijken naar. Geen doorlopend onderhoud.
• Het aantal opzoekingen blijft laag: Uw SPF-record blijft overzichtelijk en voldoet aan de RFC-richtlijnen en -beperkingen.

Belangrijkste verschillen tussen SPF Fail en SPF Permerror

Voorkom te veel DNS-lookups en andere SPF-fouten

Het voorkomen van SPF-fouten vereist voortdurende aandacht, vooral wanneer uw e-mailinfrastructuur verandert en er in de loop van de tijd nieuwe diensten van derden worden toegevoegd. Een aantal consistente werkwijzen helpen u om uw SPF-records geldig en veilig binnen de protocolgrenzen te houden (zelfs als uw configuratie blijft evolueren).

Door de instellingen van uw e-mailserviceprovider up-to-date te houden, zorgt u ervoor dat geautoriseerde verzendbronnen in overeenstemming blijven met uw SPF-record. Wanneer providers hun verzendinfrastructuur bijwerken of wijzigingen aanbevelen om domeinen toe te voegen, kan het niet doorvoeren van deze updates leiden tot authenticatiefouten.

Het is net zo belangrijk om uw SPF-configuratie te controleren wanneer leveranciers worden toegevoegd, verwijderd of vervangen. Marketingplatforms, factureringssystemen, ondersteuningstools en automatiseringsdiensten versturen vaak e-mails namens uw domein, en bij elke wijziging moet worden gecontroleerd of uw SPF-record nog steeds alle actieve afzenders weergeeft.

Door een periodiek auditschema aan te houden, voorkomt u dat records te complex worden. Regelmatige controles maken het gemakkelijker om ongebruikte include-statements te verwijderen, DNS-lookups bij te houden en ervoor te zorgen dat het record binnen de SPF-lookup-limiet blijft voordat er fouten optreden.

Door alle services die namens uw domein e-mails versturen te documenteren, beschikt u over een duidelijk referentiepunt voor toekomstige updates. Een eenvoudig overzicht van goedgekeurde afzenders vermindert giswerk, versnelt het oplossen van problemen en helpt om een schone, betrouwbare SPF-configuratie te behouden.

Conclusie

SPF Permerror kan invloed hebben op je deliverability, domeingezondheid en beveiliging. Eenvoudige inspanningen zoals het verwijderen van overbodige mechanismen, het vervangen van mechanismen door IP-bereiken en het monitoren van deliverability kunnen al veel doen.

En voor organisaties die gedoe willen vermijden en tijd willen besparen, zijn er gehoste oplossingen zoals PowerSPF. Wilt u weten hoe het werkt en hoe het uw authenticatiebeleid kan veranderen?Planvandaag nogeen gratis demomet een van onze interne experts!

Veelgestelde vragen (FAQ's)

Kan SPF indien nodig meer dan 10 lookups uitvoeren?

Nee, SPF is strikt beperkt tot 10 DNS lookups tijdens evaluatie, zoals gedefinieerd in RFC 7208. Het overschrijden van deze limiet veroorzaakt een Permerror en uw e-mails kunnen worden geweigerd of gemarkeerd als spam.

Kan ik meerdere SPF-records hebben?

Nee. Je moet slechts 1 SPF-record per domein instellen dat al je verzendbronnen voor dat domein autoriseert. Meerdere records kunnen ze allemaal ongeldig maken en fouten veroorzaken.

Wat is de veiligste manier om Permerror te repareren?

De veiligste manier om Permerror op te lossen is door een gehoste SPF-oplossing zoals PowerSPF te gebruiken om SPF dynamisch te optimaliseren, met deskundige ondersteuning die 24/7 beschikbaar is.  

Is flattening veilig voor dynamische IP's?

Als uw provider dynamische IP-adressen gebruikt, kan handmatig afvlakken snel verouderd raken, wat SPF-fouten kan veroorzaken. Voor dynamische of vaak veranderende IP-adressen is de veiligste optie om een gehoste oplossing te gebruiken die automatisch IP-adressen voor u ophaalt en bijwerkt. 

• Over
• Laatste berichten

Maitham Al Lawati

Cyberbeveiligingsexpert, CEO bij PowerDMARC

Maitham is een technisch ondernemer, cyberbeveiligingsexpert, CEO en oprichter van PowerDMARC met meer dan 15 jaar ervaring in de sector. Maitham heeft een Global MBA van de Universiteit van Manchester en diverse professionele certificeringen waaronder CISSP, CISM, CRISC en ISC2 CCSP.

Laatste berichten van Maitham Al Lawati (Bekijk alle berichten)

• E-mailphishing en DMARC-statistieken: trends op het gebied van e-mailbeveiliging in 2026 - 6 januari 2026
• Hoe u 'Geen SPF-record gevonden' kunt oplossen in 2026 - 3 januari 2026
• SPF Permerror: Hoe te veel DNS-lookups te verhelpen - 24 december 2025