Uitleg over de limiet voor DNS-lookups bij SPF 10 (en hoe je dit kunt oplossen)

Om de beperkingen van SPF-records te begrijpen, moet je eerst de limiet van 10 DNS-lookups kennen. Als je SPF-record meer dan 10 DNS-lookups activeert, geven de ontvangende mailservers de foutmelding „SPF PermError: too many DNS lookups“ terug, en beschouwt DMARC dit als een harde fout. Dit leidt ertoe dat legitieme e-mails zonder waarschuwing worden geweigerd of naar de spamfolder worden gestuurd.

Deze limiet is afkomstig uit RFC 7208, waarin de SPF-evaluatie wordt beperkt tot tien DNS-query's per controle. Het probleem is dat de meeste domeinen deze limiet overschrijden zonder dat ze het doorhebben, vaak als gevolg van geneste includes en verouderde diensten.

In deze handleiding leert u wat meetelt voor de limiet, waarom SPF-records zonder waarschuwing mislukken en hoe u opzoekingsfouten definitief kunt verhelpen en voorkomen.

SPF-checker: Controleer het aantal opvragingen met onze gratis SPF-checker

Wat is de SPF 10 DNS-lookuplimiet?

De SPF-specificatie, zoals vastgelegd in RFC 7208, beperkt elke SPF-controle tot maximaal 10 mechanismen voor het opvragen van DNS-gegevens.

Simpel gezegd: elke keer dat een ontvangende mailserver je SPF-record controleert en daarvoor een extra DNS-query moet uitvoeren, telt dat mee voor deze limiet.

Deze zoekopdrachten worden geactiveerd door mechanismen zoals:

• opnemen
• a
• mx
• ptr
• bestaat
• doorsturen

Zodra de elfde controle nodig is, wordt de SPF-controle onmiddellijk gestopt en wordt het volgende geretourneerd:

SPF PermError: te veel DNS-opzoekingen

Elke DNS-opzoeking kost tijd en beslag op de bronnen van de ontvangende server, zoals CPU, bandbreedte en geheugen. Zonder een limiet zou een kwaadwillende gebruiker een SPF-record kunnen aanmaken met diep geneste includes, waardoor servers gedwongen worden honderden DNS-query’s uit te voeren.

Dit zou de SPF-controle in feite veranderen in een vector voor een denial-of-service-aanval (DoS).

Door een strikte limiet van 10 lookups op te leggen, zorgt de SPF-specificatie ervoor dat:

• voorspelbare verwerkingstijden voor e-mails
• bescherming tegen DNS-misbruik
• consistente prestaties in alle e-mailsystemen 

Wat telt mee voor de limiet van 10 DNS-opzoekingen per dag? 

Niet elk onderdeel van je SPF-record leidt tot een DNS-opzoeking. Weten wat wel en wat niet meetelt, is de snelste manier om het aantal opzoekingen te verminderen.

SPF-mechanismen die wel meetellen versus die niet meetellen

Daarom bevat: en mx de grootste oorzaak zijn van SPF-fouten, vooral wanneer ze geneste lookups bevatten.

Mechanismen die veel opzoekacties vereisen vervangen door directe ip4: of ip6: vermeldingen (waar mogelijk) is een van de meest effectieve manieren om binnen de limiet te blijven.

Een veelvoorkomend scenario: MSP’s die meerdere SPF-records van klanten beheren

Managed Service Providers hebben vaak te maken met SPF-limieten wanneer klanten meerdere e-mailplatforms gebruiken. Een typische MSP-klant maakt bijvoorbeeld gebruik van Office 365, Mailchimp, Salesforce en HubSpot, waarbij elk platform een `include`-instructie vereist, waardoor de limiet van 10 lookups al snel wordt bereikt.

Waarom je waarschijnlijk tegen de SPF-limiet aanloopt (geneste includes)

In je dossier staan misschien maar drie of vier inclusief: regels bevatten, maar je bereikt toch de limiet. Hier is waarom.

v=spf1 include:sendgrid.net include:_spf.google.com include:salesforce.com ~all

Op het eerste gezicht lijkt het alsof er drie DNS-lookups plaatsvinden, maar de SPF-controle houdt daar niet op. Elke `include` wordt recursief doorlopen.

Dit is wat er in werkelijkheid gebeurt:

1. include:sendgrid.net → Het SPF-record van SendGrid bevat 2 extra include: mechanismen → 3 lookups in totaal
2. voeg toe:_spf.google.com → Het SPF-record van Google bevat 3 extra mechanismen → 4 lookups in totaal
3. include:salesforce.com → Het SPF-record van Salesforce bevat 3 extra mechanismen → 4 lookups in totaal

Totaal: 11 DNS-opzoekingen

Elke omvat: die je toevoegt, is niet slechts één opzoekactie. Het is één opzoekactie plus het aantal SPF-record vereist. Daarom wordt de limiet veel sneller bereikt dan de meeste domeineigenaren verwachten, vooral bij gebruik van meerdere e-mailserviceproviders.

Waarom bestaat de SPF 10-zoeklimiet?

De limiet van 10 DNS-zoekopdrachten lijkt misschien beperkend, vooral voor organisaties die gebruikmaken van meerdere e-mailproviders, maar deze limiet is ingesteld om belangrijke veiligheids- en prestatieredenen die beheerders en beveiligingsteams moeten begrijpen.

Samenvatting: De opzoeklimiet beschermt de DNS-infrastructuur tegen misbruik en zorgt tegelijkertijd voor een tijdige verwerking van e-mail, maar vereist zorgvuldig beheer van SPF-records.

Denial-of-service-aanvallen voorkomen

De limiet van 10 extra zoekopdrachten is ingesteld om onredelijke belasting van het DNS te voorkomen en Denial-of-Service (DoS)-aanvallen te voorkomen.

Zonder deze limiet zou een aanvaller een SPF-record kunnen samenstellen met honderden geneste includes, waardoor elke ontvangende mailserver die een e-mail van dat domein verwerkt, gedwongen wordt een enorm aantal DNS-query’s uit te voeren. Dit zou DNS-servers kunnen overbelasten en de prestaties op het internet kunnen verslechteren.

Zorgen voor tijdige verwerking van e-mails

Elke DNS-opzoeking tijdens een SPF-controle zorgt voor extra vertraging in het e-mailbezorgingsproces. Als onbeperkte opzoekingen in SPF-records zouden worden toegestaan, zou de tijd die nodig is voor SPF-verificatie aanzienlijk kunnen toenemen, wat zou leiden tot time-outs bij DNS-query's en tijdelijke storingen van DNS-servers.

De limiet van 10 zoekopdrachten zorgt ervoor dat SPF-controles snel en betrouwbaar kunnen worden uitgevoerd zonder dat er knelpunten ontstaan in de bezorging van e-mails.

DNS-stabiliteit handhaven

De DNS-infrastructuur is een gedeelde hulpbron. Het toestaan van onbeperkte lookups tijdens SPF-authenticatie zou een buitensporige belasting vormen voor recursieve resolvers en gezaghebbende naamservers, met name voor afzenders met grote volumes.

De limiet beschermt het bredere DNS-ecosysteem door het aantal SPF-gerelateerde query's beheersbaar te houden.

Wat gebeurt er als u de SPF-zoeklimiet overschrijdt?

Het overschrijden van de limiet voor SPF-opzoekingen leidt niet alleen tot een kleine waarschuwing. Het veroorzaakt een ernstige fout die direct van invloed kan zijn op de vraag of uw e-mails de inbox van uw ontvangers bereiken.

SPF-controle stopt bij opzoeking 11

SPF wordt van links naar rechts geëvalueerd. Wanneer de ontvangende server het elfde DNS-querymechanisme of de elfde modifier in je SPF-record tegenkomt, stopt hij onmiddellijk met het verwerken van het record en retourneert hij:

SPF PermError: te veel DNS-opzoekingen

Dit is een permanente SPF-validatiefout, geen tijdelijke fout of neutraal resultaat. De ontvanger beschouwt het SPF-record als ongeldig omdat de authenticatie niet kan worden voltooid.

DMARC beschouwt een SPF PermError als een SPF-fout

Zodra SPF een PermError retourneert, interpreteert DMARC dit als een SPF-fout. Als SPF-alignment vereist was om DMARC te laten slagen, kan het bericht de DMARC-authenticatie volledig mislukken.

Het resultaat hangt dan af van:

• Uw DMARC-beleid (p=none, quarantaine, of afwijzen)
• De filterregels van de ontvangende server
• Of DKIM succesvol is doorgevoerd en correct is afgestemd

E-mails kunnen worden geweigerd, in quarantaine worden geplaatst of naar de spamfolder worden verplaatst

Wanneer SPF mislukt vanwege een PermError:

• Sommige providers kunnen de e-mail zonder meer weigeren
• Anderen kunnen het naar de spamfolder of quarantaine verplaatsen
• Beveiligingsfilters kunnen het bericht als verdacht of niet-geverifieerd markeren

Dit heeft vooral nadelige gevolgen bij strengere DMARC-beleidsregels, zoals p=quarantine of p=reject.

Microsoft-omgevingen zijn in dit opzicht bijzonder gevoelig. Outlook en Exchange Online hanteren strenge authenticatiecontroles, waardoor SPF PermErrors een aanzienlijke invloed kunnen hebben op de afleverbaarheid voor organisaties die e-mails versturen naar ontvangers in Office 365.

Omdat SPF van links naar rechts wordt geëvalueerd, kan het voorkomen dat sommige verzendende diensten met succes worden geauthenticeerd voordat de limiet voor het opzoeken is bereikt, terwijl andere later in de keten mislukken.

Dat betekent:

• Sommige e-mails lijken gewoon te worden afgeleverd
• Andere mislukken onverwacht bij de authenticatie
• Zonder DMARC-rapportage en SPF-analysetools wordt het lastig om het probleem vast te stellen

Daarom blijven problemen met de limiet voor SPF-lookups vaak onopgemerkt totdat de afleverbaarheid achteruitgaat of uit DMARC-rapporten blijkt dat er af en toe fouten optreden.

Andere oorzaken van de foutmelding SPF PermError

Het overschrijden van de limiet van 10 DNS-zoekopdrachten is de meest voorkomende oorzaak van een SPF PermError, maar het is niet de enige. PermErrors kunnen ook optreden wanneer:

• Meerdere SPF-records bestaan voor hetzelfde domein
• Het SPF-record bevat syntaxfouten
• Er worden verouderde of niet-ondersteunde mechanismen gebruikt
• Circulaire omvatten: statements creëren oneindige opzoeklussen

Elk van deze problemen kan de SPF-verificatie verstoren en de afleverbaarheid van e-mails negatief beïnvloeden.

Controleer uw DMARC-beleid om inzicht te krijgen in uw risico’s met een DMARC Record Checker

Elk van deze problemen kan leiden tot SPF-fouten en niet-bezorgde e-mails, dus het is belangrijk om je volledige SPF-configuratie regelmatig te controleren.

De SPF-limiet voor het opzoeken van ongeldige records: de andere beperking waar je mogelijk tegenaan loopt

De meeste SPF-handleidingen gaan niet verder dan de limiet van 10 DNS-lookups, maar er is nog een tweede beperking in RFC 7208 die tot dezelfde fout kan leiden, zelfs als je ruim onder de 10 lookups blijft: de limiet voor ongeldige lookups.

Een 'void lookup' is een DNS-verzoek dat geen bruikbaar resultaat oplevert.

Dit gebeurt wanneer een opzoekactie het volgende oplevert:

• NXDOMAIN (domein bestaat niet)
• NOERROR zonder records (lege reactie)

RFC 7208 beperkt de SPF-controle tot maximaal twee ongeldige zoekopdrachten per controle.

Als er voor de derde keer een ongeldige opzoekactie plaatsvindt, geeft de ontvangende server het volgende terug:

SPF-permanente fout

Dit betekent:

Er kan een SPF PermError worden gegenereerd, zelfs als je record minder dan 10 DNS-lookups bevat.

Dat maakt het opzoeken van void-records gevaarlijk, omdat ze moeilijker op te sporen zijn en vaak over het hoofd worden gezien bij SPF-controles.

Foutieve zoekresultaten zijn meestal het gevolg van verouderde of verkeerd geconfigureerde SPF-vermeldingen:

• omvat: verwijzen naar een domein dat geen SPF-record meer heeft
• een of mx mechanismen die verwijzen naar domeinen zonder geldige DNS-records
• Verouderde of buiten gebruik gestelde e-mailproviders
• Typefouten in domeinnamen binnen SPF-mechanismen

Zelfs één verouderde `include` kan bij elke SPF-controle onopgemerkt een ongeldige zoekopdracht genereren.

Dit is het verschil tussen de limiet van 10 zoekopdrachten en de limiet voor ongeldige zoekopdrachten:

Beide leiden tot hetzelfde resultaat: SPF PermError.

Om fouten bij het opzoeken van velden te voorkomen:

• Controleer je SPF-record regelmatig op verouderde omvatten: statements
• Verwijder diensten die u niet meer gebruikt
• Controleer of alle domeinen waarnaar wordt verwezen geldige DNS-records retourneren
• Gebruik een SPF-checker die ongeldige zoekopdrachten markeert, niet alleen het totale aantal zoekopdrachten

De SPF-checker van PowerDMARC detecteert zowel alle zoekopdrachten als ongeldige zoekopdrachten, zodat u deze verborgen fouten kunt opsporen voordat ze de afleverbaarheid beïnvloeden.

Hoe u kunt controleren of uw SPF-record de limiet overschrijdt

Nagaan of uw SPF-record de limiet van 10 DNS-lookups overschrijdt, is de eerste stap om problemen met de afleverbaarheid op te lossen. Er zijn verschillende manieren om een SPF-recordcontrole uit te voeren en uw huidige aantal lookups te verifiëren.

Samenvatting: Regelmatige SPF-monitoring met behulp van diagnostische tools en handmatige validatie helpt te voorkomen dat de opzoeklimiet wordt overschreden voordat dit gevolgen heeft voor de e-mailbezorging.

Gebruik een SPF-diagnosetool

Met behulp van een SPF-diagnosetool kunt u controleren of een SPF-record geldig is en correct functioneert. Deze tools analyseren uw SPF-record, tellen elke DNS-lookup inclusief geneste includes en markeren eventuele fouten of waarschuwingen.

Met de gratis SPF-recordchecker van PowerDMARC kunt u direct het totale aantal opvragingen bekijken, vaststellen welke mechanismen de meeste opvragingen verbruiken en verkeerde configuraties opsporen voordat deze tot bezorgingsproblemen leiden.

Uw SPF-record handmatig traceren

Als u uw SPF-record liever zelf inspecteert, kunt u de DNS-lookups handmatig tellen door elk mechanisme in het record door te lopen.

Begin met het SPF TXT-record van je domein en tel alle ‘include’, ‘a’, ‘mx’, ‘ptr’, ‘redirect’ en ‘exists’-verwijzingen. Zoek vervolgens voor elke 'include' het SPF-record van het domein waarnaar wordt verwezen op en tel ook de mechanismen die de opzoekactie veroorzaken.

Geneste inclusies tellen snel op, waardoor organisaties die meerdere e-mailserviceproviders gebruiken vaak zonder het te beseffen de limiet overschrijden.

Controleer de SPF-validatie in de loop van de tijd

SPF-records zijn niet statisch. Wanneer u e-mailserviceproviders toevoegt of verwijdert, van hostingomgeving verandert of uw e-mailinfrastructuur bijwerkt, verandert uw SPF-record ook. Het wordt aanbevolen om SPF-records te valideren na het aanbrengen van wijzigingen om te zorgen dat de limiet van 10 lookups wordt nageleefd.

Door continue monitoring in te stellen via het platform van PowerDMARC krijgt u continu inzicht in uw SPF-configuratie en wordt u gewaarschuwd wanneer wijzigingen ervoor zorgen dat uw record de limiet overschrijdt.

Hoe u uw SPF-record kunt repareren en optimaliseren

Als uw SPF-record de limiet van 10 DNS-lookups overschrijdt of nadert, zijn er verschillende praktische stappen die u kunt nemen om het aantal lookups te verminderen zonder dat dit ten koste gaat van de e-mailverificatie.

Samenvatting: SPF-optimalisatie omvat het verwijderen van ongebruikte services, het vervangen van mechanismen die veel opzoekacties vereisen door directe IP-adressen, en het implementeren van geautomatiseerd beheer voor complexe infrastructuren.

Controleer je huidige SPF-record en tel het aantal opzoekingen

Begin met het analyseren van uw SPF-record met behulp van een betrouwbare SPF-checker. Dit helpt je het totale aantal DNS-lookups te bepalen, inclusief geneste includes, en signaleert problemen zoals ongeldige lookups of verkeerde configuraties. Het laat ook zien welke mechanismen de meeste queries verbruiken.

Handmatig tellen is mogelijk, maar levert vaak onnauwkeurige resultaten op vanwege recursie binnen de opgenomen domeinen; maak daarom waar mogelijk gebruik van een hulpprogramma.

Verwijder ongebruikte of onnodige services

De meest eenvoudige optimalisatie is om uw SPF-record te controleren en alle mechanismen te verwijderen die verwijzen naar diensten die u niet langer gebruikt.

Na verloop van tijd voegen organisaties e-mailserviceproviders, marketingplatforms en tools van derden toe aan hun SPF-record, maar vergeten ze deze te verwijderen wanneer ze niet langer actief zijn.

Om het aantal vereiste zoekopdrachten te verminderen, moeten organisaties ongebruikte services uit hun SPF-record verwijderen. Dit betekent ook dat standaard SPF-waarden die tijdens de eerste installatie zijn toegevoegd, maar momenteel geen doel dienen, moeten worden verwijderd.

Vermijd ptr en beperk onnodige mx gebruik

De ptr wordt sterk afgeraden volgens de SPF-normen. Het voert voor elk verzendend IP-adres reverse DNS-lookups uit, waardoor het traag, onbetrouwbaar en lookup-intensief is. Verwijder het indien aanwezig en vervang het door directe IP-verwijzingen.

De mx -mechanisme kan ook het aantal zoekopdrachten opdrijven. Het lost eerst MX-records op en voert vervolgens extra zoekopdrachten uit voor elke bijbehorende mailserver. Als uw infrastructuur stabiel is, vervang dan mx door ip4: of ip6: vermeldingen voor een betere efficiëntie.

Vervang zoekintensieve mechanismen door ip4 of ip6

Elk 'include', 'a' en 'mx'-mechanisme vereist ten minste één DNS-opzoeking. Vervang deze waar mogelijk door ip4- of ip6-mechanismen die de geautoriseerde IP-adressen direct specificeren. Het gebruik van ip4- of ip6-mechanismen in SPF-records vereist geen extra lookups en kan helpen om de naleving van de lookup-limiet te handhaven.

Als het SPF-record van een e-mailserviceprovider bijvoorbeeld verwijst naar een bekende reeks statische IP-adressen, kunt u die IP's rechtstreeks vermelden in plaats van een 'include' te gebruiken die meerdere DNS-lookups activeert.

Gebruik SPF-afvlakking (tijdelijke oplossing)

SPF-afvlakking vervangt omvat: mechanismen met hun opgeloste IP-adressen, waardoor het aantal DNS-lookups tot bijna nul wordt teruggebracht. Om uw record snel weer onder de limiet te brengen, gebruikt u geautomatiseerde SPF-flattening en valideert u vervolgens het bijgewerkte record voordat u het publiceert.

Dit brengt echter ook nadelen met zich mee. Als een provider zijn IP-adressen wijzigt en uw record niet wordt bijgewerkt, kunnen legitieme e-mails de SPF-controle niet doorstaan. Handmatig aanpassen vereist voortdurende controle en onderhoud.

Gebruik Hosted SPF of SPF-macro's (permanente oplossing)

Voor stabiliteit op de lange termijn kunt u een gehoste SPF-oplossing zoals PowerDMARC overwegen. Deze systemen beheren uw SPF-record dynamisch met behulp van macro’s of externe resolutie, waardoor u automatisch binnen de opzoeklimieten blijft.

Deze aanpak voorkomt:

• Handmatige updates wanneer IP-adressen van leveranciers veranderen
• Risico’s van verouderde, samengevoegde gegevens
• Lopende onderhoudskosten

Dit is met name van groot belang voor organisaties die gebruikmaken van meerdere diensten van derden of die complexe e-mailinfrastructuren beheren.

Vermijd het ptr-mechanisme

Het gebruik van het ptr-mechanisme wordt sterk afgeraden, aangezien dit kan leiden tot een toename van het aantal benodigde opzoekingen, wat op zijn beurt weer tot Permerror-problemen kan leiden.

Het ptr-mechanisme voert voor elk IP-adres dat verbinding maakt een omgekeerde DNS-opzoeking uit, wat zowel traag als onbetrouwbaar is. De SPF-specificatie zelf raadt het gebruik ervan af. Als uw SPF-record momenteel een ptr-mechanisme bevat, verwijder dit dan en vervang het door directe IP-verwijzingen.

Minimaliseer het gebruik van het mx-mechanisme

Door het MX-mechanisme in SPF-records te vermijden, kunt u binnen de limiet van 10 DNS-zoekopdrachten blijven. Het MX-mechanisme zoekt eerst het MX-record van het domein op en voert vervolgens extra zoekopdrachten uit om het IP-adres van elke vermelde mailserver te achterhalen.

Als uw domein meerdere MX-records heeft, kan één enkel "mx"-mechanisme meerdere zoekopdrachten vergen. Vervang dit waar mogelijk door ip4- of ip6-vermeldingen voor uw mailservers.

Consolideren inclusief verklaringen

Als uw SPF-record meerdere 'include'-mechanismen bevat die naar gerelateerde diensten verwijzen, controleer dan of deze kunnen worden samengevoegd.

Sommige e-mailserviceproviders delen overlappende infrastructuur, wat betekent dat u mogelijk redundante zoekopdrachten uitvoert. Controleer elke opname om te bepalen of deze nog steeds nodig is en of de onderliggende IP-adressen rechtstreeks kunnen worden geraadpleegd.

Valideer na elke wijziging

Het valideren van SPF-records na het aanbrengen van wijzigingen is essentieel om te voldoen aan de limiet van 10 lookups.

Zelfs een kleine wijziging, zoals het toevoegen van één nieuwe ‘include’ voor een marketingplatform, kan ervoor zorgen dat je record de limiet overschrijdt als dit geneste lookups activeert. Controleer uw record na elke update met een SPF-diagnosetool om te bevestigen dat het nog steeds geldig is.

SPF-recordflattening: wat het is en wanneer u het moet gebruiken

Het 'afvlakken' van SPF-records is een techniek die wordt gebruikt om SPF-records te optimaliseren en zo de limiet van 10 DNS-lookups voor SPF te omzeilen. Het is een van de meest besproken oplossingen voor organisaties met complexe e-mailinfrastructuren, maar er zijn nadelen aan verbonden die belangrijk zijn om te begrijpen.

Voor een volledige optimalisatiegids over het optimaliseren van uw SPF-record, lees onze blog over SPF-optimalisatie

Hoe SPF-record flattening werkt

SPF-record flattening vervangt mechanismen die lookups veroorzaken in een SPF-record door hun overeenkomstige IP-adressen of CIDR-bereiken, waardoor het aantal DNS-query's dat nodig is om het SPF-record te verifiëren, wordt verminderd.

In plaats van een verwijzing zoals "include:emailprovider.com" op te nemen die een of meer DNS-lookups activeert, lost u die verwijzing op naar de onderliggende IP-adressen en vermeldt u deze rechtstreeks in uw record met behulp van ip4- of ip6-mechanismen.

Als ‘include:emailprovider.com’ bijvoorbeeld naar drie IP-adressen verwijst, vervangt het ‘flattening’-proces de ‘include’-instructie door die drie IPv4-vermeldingen. De SPF-controle levert nu hetzelfde resultaat op zonder dat er extra DNS-query's voor die provider nodig zijn.

Wanneer afvlakken helpt

Door een SPF-record af te vlakken, kan het aantal DNS-querymechanismen en modificatoren worden teruggebracht tot minder dan 10. Dit is met name handig wanneer:

• Uw domein verstuurt e-mails via veel externe diensten en het aantal inclusies alleen al overschrijdt 10.
• Je hebt ongebruikte diensten al verwijderd en waar mogelijk geconsolideerd, maar zit nog steeds boven de limiet.
• U hebt een snelle manier nodig om uw administratie in orde te brengen terwijl u een optimalisatiestrategie voor de langere termijn plant.

Waarom het handmatig afvlakken van SPF slechts een tijdelijke oplossing is

Door je SPF-record te vereenvoudigen, kun je het aantal lookups snel onder de limiet van 10 brengen, maar het handmatig vereenvoudigen van je SPF-record is geen oplossing voor de lange termijn, omdat dit weer andere risico’s met zich meebrengt die de e-mailbezorging net zo gemakkelijk kunnen verstoren.

Risico 1: Wijzigingen in de IP-adressen van leveranciers

De meeste e-mailproviders wijzigen of breiden hun verzend-IP-reeksen uit zonder dit vooraf aan te kondigen.

Wanneer je je SPF-record handmatig samenvoegt:

• je die IP-adressen hardcodeert in je DNS
• maar je provider blijft achter de schermen voortdurend in ontwikkeling

Zodra hun IP-lijst verandert, raakt je SPF-record verouderd en worden legitieme e-mails niet meer geverifieerd.

Risico 2: Grootte van het SPF-record (255 tekens + DNS-beperkingen)

Door het 'flattening'-proces worden vermeldingen met meerdere IP-adressen vervangen, wat je SPF-record snel kan doen opzwellen.

Dit leidt tot twee problemen:

• DNS TXT-records zijn beperkt tot 255 tekens per tekenreeks
• Te lange SPF-records kunnen het parseren verstoren of de DNS-limieten overschrijden

Als je probeert de opzoeklimieten aan te passen, kan dit onbedoeld leiden tot syntaxfouten of problemen met het afkappen van records.

Risico 3: Geen monitoring of inzicht

Handmatig afvlakken is een statisch proces. Er is geen ingebouwde manier om:

• detecteren wanneer IP-bereiken veranderen
• het aantal zoekopdrachten in de loop van de tijd
• u waarschuwen bij mislukte authenticatiepogingen

Dit betekent dat problemen vaak onopgemerkt blijven totdat de afleverbaarheid achteruitgaat.

Risico 4: Voortdurende onderhoudslast

Elke keer dat je:

• een nieuwe e-maildienst toevoegen
• infrastructuur aanpassen
• of als uw provider de IP-adressen bijwerkt

moet u uw SPF-record handmatig opnieuw opstellen en valideren.

Voor teams die meerdere domeinen of klanten beheren, wordt dit al snel onhoudbaar.

Handleiding SPF-afvlakking lost het symptoom (opzoeklimiet) op, niet de onderliggende complexiteit (dynamische infrastructuur).

Hier komen gehoste SPF-oplossingen om de hoek kijken.

In plaats van IP-adressen vast te leggen, beheren platforms zoals PowerDMARC uw SPF-record dynamisch met behulp van macro’s en geautomatiseerde updates, zodat u binnen de opzoeklimiet blijft zonder dat u voortdurend handmatig hoeft in te grijpen.

Andere beperkingen van SPF-records die u moet kennen

De limiet van 10 DNS-opzoekingen is de bekendste beperking van SPF, maar het is niet de enige. Domeineigenaren moeten zich bewust zijn van deze aanvullende beperkingen van SPF-records om onverwachte authenticatiefouten te voorkomen.

Samenvatting: Naast de limiet van 10 lookups kent SPF beperkingen met betrekking tot het aantal records, tekenlimieten, ongeldige lookups en doorstuurscenario's die van invloed zijn op e-mailverificatie.

Slechts één SPF-record per domein

De SPF-specificatie vereist dat elk domein slechts één SPF TXT-record publiceert.

Als het SPF-record meerdere SPF-records voor een domein bevat, kan dit leiden tot een SPF PermError, waardoor de ontvangende server de e-mail mogelijk weigert of verkeerd verwerkt. Als u extra afzenders wilt autoriseren, voeg deze dan toe aan uw bestaande SPF-record in plaats van een tweede record aan te maken.

SPF controleert het retourpad, niet het afzenderadres.

SPF verifieert het domein in het retouradres, niet het voor mensen leesbare veld 'Van' dat de ontvanger ziet. Dit betekent dat een aanvaller het adres 'Van' kan vervalsen en toch door SPF komt door een ander retouradresdomein te gebruiken.

DMARC vult deze leemte op door een overeenkomst of afstemming te vereisen tussen het voor mensen leesbare domein in het veld 'Van' en het domein dat door SPF is geauthenticeerd.

De limiet van 255 tekens

Hoewel een SPF-record in totaal meer dan 255 tekens kan bevatten, mag een enkel DNS TXT-record is beperkt tot 255 tekens. Langere SPF-records moeten worden opgesplitst in meerdere strings binnen hetzelfde TXT-record.

De meeste DNS-providers behandelen dit automatisch, maar verkeerd geconfigureerde splitsingen kunnen parseerfouten veroorzaken.

Limiet voor het opzoeken van ongeldige gegevens

Naast de limiet van 10 DNS-lookups beperkt de SPF-specificatie ook het aantal 'ongeldige lookups', dit zijn DNS-query's die geen records retourneren (een leeg antwoord of een NXDOMAIN-respons).

Het overschrijden van deze limiet, die doorgaans twee ongeldige zoekopdrachten is, kan ook een SPF PermError veroorzaken.

Geen bescherming voor doorgestuurde e-mails

Wanneer een e-mail wordt doorgestuurd, verandert het afzender-IP-adres in dat van de doorstuurserver, dat waarschijnlijk niet in het SPF-record van de oorspronkelijke afzender staat vermeld. Dit kan ertoe leiden dat de doorgestuurde e-mail de SPF-controle niet doorstaat, zelfs als het oorspronkelijke bericht legitiem was.

Beste praktijken om binnen de limiet voor SPF-opzoekingen te blijven

Om binnen de limiet van 10 DNS-lookups per dag te blijven, is voortdurende discipline vereist. Gebruik deze aanbevolen werkwijzen om uw record geoptimaliseerd te houden en onverwachte storingen te voorkomen:

• Controleer je SPF-record telkens wanneer je een verzendplatform toevoegt of verwijdert
• Plaats nooit meer dan één SPF-record per domein
• Vermijd de ptr mechanisme, verwijder het als het in je record voorkomt
• Gebruik ip4: en ip6: waar IP-bereiken stabiel en bekend zijn
• Stel DMARC -rapportage in om incidentele SPF-fouten vroegtijdig op te sporen
• Gebruik geautomatiseerde monitoring (zoals PowerDMARC) om meldingen te ontvangen wanneer het aantal zoekopdrachten verandert
• Overweeg Hosted SPF als u meer dan drie of vier externe verzendservices beheert

Hoe de gehoste SPF-dienst van PowerDMARC helpt om mislukte SPF-lookups te voorkomen 

Handmatig SPF-beheer raakt in moderne e-mailomgevingen al snel overbelast. Elk nieuw e-mailplatform, elke nieuwe marketingtool, elk nieuw CRM-systeem, elke nieuwe helpdesk of elke nieuwe clouddienst kan leiden tot extra SPF-verwijzingen, geneste lookups en extra onderhoudswerk.

Het handmatig afvlakken van SPF-records kan het aantal opzoekingen tijdelijk verminderen, maar dit leidt tot een ander probleem: het up-to-date houden van hardgecodeerde IP-adressen, aangezien leveranciers hun verzendinfrastructuur voortdurend aanpassen.

PowerDMARC’s Hosted SPF, of PowerSPF, pakt het onderliggende beheerprobleem aan door SPF-records bij te werken naarmate uw verzendinfrastructuur verandert. In tegenstelling tot statische SPF-flattening beheert Hosted SPF uw SPF-configuratie dynamisch op de achtergrond, waardoor organisaties aan RFC 7208 kunnen blijven voldoen zonder voortdurend DNS-onderhoud.

Met PowerSPF kunnen organisaties:

• SPF-records automatisch bijwerken wanneer de IP-adressen van leveranciers veranderen
• Gebruik SPF-macro's om binnen de limiet van 10 DNS-opzoekingen en de limieten voor de tekenlengte van DNS-namen te blijven
• Voer eenmalig een DNS-wijziging door in plaats van de SPF-records steeds handmatig aan te passen
• Beheer complexe SPF-configuraties bij meerdere leveranciers, met geneste includes, regionale infrastructuur en bedrijfsdomeinen
• Houd SPF-fouten, ongeldige lookups en authenticatieproblemen in de gaten voordat ze de afleverbaarheid beïnvloeden

Dit is met name van belang voor organisaties die tegelijkertijd gebruikmaken van platforms als Microsoft 365, Salesforce, HubSpot, SendGrid, Mailchimp en andere externe verzenders, waarbij geneste includes er ongemerkt toe kunnen leiden dat SPF-records de RFC-limieten overschrijden.

Met geautomatiseerde SPF-afvlakking, realtime opzoekmonitoring, foutmeldingen en tools voor SPF, DKIM, DMARC en BIMI helpt PowerDMARC organisaties om SPF-records binnen de opzoeklimiet te houden en een schonere authenticatie-instelling te behouden.

Controleer om te beginnen het aantal SPF-opzoekingen met de SPF-checker van PowerDMARC en identificeer problemen voordat ze de e-mailverificatie beïnvloeden.

Veelgestelde Vragen

1. Wat is de limiet voor DNS-lookups bij SPF 10?

De SPF-specificatie, zoals vastgelegd in RFC 7208, beperkt elke SPF-controle tot maximaal 10 mechanismen voor het opvragen van DNS-gegevens.

Als uw SPF-record tijdens de controle meer dan 10 lookups vereist, geeft de ontvangende server een SPF PermError terug, wat door DMARC als een fout wordt beschouwd. Dit kan ertoe leiden dat legitieme e-mails worden geweigerd of naar de spamfolder worden verplaatst.

2. Welke SPF-mechanismen tellen mee voor de limiet van 10 opzoekingen?

De volgende mechanismen leiden tot DNS-zoekopdrachten en tellen mee voor de limiet:

• opnemen
• a
• mx
• ptr
• bestaat
• omleiden=

Deze tellen niet mee:

• ip4, ip6 (directe IP-adressen)
• alles (catch-all)
• v=spf1 (versietag)
• De eerste DNS-verzoek om je SPF-record op te halen

3. Wat is een SPF PermError?

Er treedt een SPF PermError (permanente fout) op wanneer een ontvangende server uw SPF-record niet correct kan verwerken.

De meest voorkomende oorzaak is dat de limiet van 10 DNS-zoekopdrachten is overschreden, maar het kan ook gebeuren als gevolg van:

• syntaxfouten
• meerdere SPF-records
• Overtredingen van de limiet voor het opzoeken van gegevens
• de circulaire bevat

Als dit gebeurt, werkt SPF helemaal niet meer en kan dit gevolgen hebben voor de bezorging van e-mails.

4. Wat is de limiet voor het opzoeken van ongeldige SPF-records?

Naast de limiet van 10 zoekopdrachten legt RFC 7208 ook beperkingen op aan ongeldige zoekopdrachten, dat wil zeggen DNS-query’s die geen resultaat opleveren (NXDOMAIN of lege antwoorden).

De limiet is 2 ongeldige zoekopdrachten per SPF-controle.

Als je SPF-record een derde ongeldige opzoekactie veroorzaakt, geeft de ontvangende server een PermError terug, zelfs als het totale aantal opzoekacties minder dan 10 bedraagt.

5. Lost het SPF-flattening de limiet van 10 zoekopdrachten op?

Ja, maar slechts tijdelijk.

SPF-afvlakking vervangt vervangt mechanismen door directe IP-adressen, waardoor het aantal DNS-lookups wordt verminderd. Het vereist echter voortdurend onderhoud omdat e-mailserviceproviders hun IP-bereiken regelmatig bijwerken.

Als uw platgelegde record verouderd raakt, kunnen legitieme e-mails de SPF-controle niet doorstaan.

6. Hoe kan ik controleren hoeveel DNS-lookups mijn SPF-record gebruikt?

Je kunt een SPF-checker gebruiken om je record te analyseren en het aantal DNS-lookups te tellen, inclusief geneste verwijzingen.

De SPF-checker van PowerDMARC geeft het volgende weer:

• totaal aantal zoekopdrachten
• aantal opzoekingen
• welke mechanismen zoekopdrachten uitvoeren

Zo kunt u problemen opsporen voordat ze de afleverbaarheid beïnvloeden.

7. Wat is het verschil tussen SPF-flattening en SPF-macro's?

SPF-flattening vervangt includes statisch door IP-adressen, waardoor het aantal opzoekingen wordt verminderd, maar handmatige updates nodig zijn.

SPF-macro's (gebruikt in gehoste SPF-oplossingen) verwerken SPF-records dynamisch tijdens de evaluatie, waardoor u binnen de opzoeklimieten blijft zonder dat u handmatig IP-lijsten hoeft bij te houden.

Macro's zijn beter schaalbaar en geschikter voor complexe e-mailconfiguraties of configuraties waarbij meerdere leveranciers betrokken zijn.

8. Hoe vaak moet ik mijn SPF-record controleren?

Controleer je SPF-record:

• telkens wanneer u een e-maildienst toevoegt of verwijdert
• na aanpassingen aan de infrastructuur
• minstens één keer per maand

Bij complexe configuraties wordt continu toezicht aanbevolen om problemen met opzoeklimieten vroegtijdig op te sporen en een consistente afleverbaarheid te waarborgen.

• Over
• Laatste berichten

Ahona Rudra

Expert domein- en e-mailbeveiliging bij PowerDMARC

Ahona is marketingmanager bij PowerDMARC en heeft meer dan vijf jaar ervaring met het schrijven over cybersecurity, gespecialiseerd in domein- en e-mailbeveiliging. Ahona heeft een masterdiploma in journalistiek en communicatie, en heeft sinds 2019 haar carrière in de beveiligingssector verder uitgebouwd.

Laatste berichten van Ahona Rudra (Bekijk alle berichten)

• Hoe MSP’s de DMARC-instellingen van elke klant sneller kunnen beheren met de MCP-server van PowerDMARC - 25 mei 2026
• Hoe voeg je een IP-adres toe aan je SPF-record (stapsgewijze handleiding) - 11 mei 2026
• Avanan SPF-record: hoe u uw SPF voor Check Point Harmony Email instelt, repareert en optimaliseert - 7 mei 2026