Beperkingen SPF-records: Begrijpen van SPF-limieten in e-mailverificatie

Sender Policy Framework of SPF volstaat niet als het gaat om het beveiligen van zakelijke e-mails tegen phishing en spamming aanvallen. SPF is een e-mailverificatieprotocol dat de e-mailontvanger beschermt tegen gespoofde e-mails door te controleren of het verzendende IP-adres is geautoriseerd in het DNS-record van het domein. SPF's limiet op het maximale aantal DNS-opzoekingen en het niet op elkaar afstemmen van het Van-adres en het domein veroorzaken echter implementatiefouten die leiden tot problemen met de bezorgbaarheid van e-mail. DMARC bouwt voort op SPF (en DKIM) om verbeterde beveiliging en rapportage te bieden. Deze blog bespreekt deze SPF-problemen en hoe DMARC helpt deze SPF-beperkingen te overwinnen.

Wat zijn de beperkingen van het SPF Record?

Er zijn 3 belangrijke SPF beperkingen die het een beetje lastig maken om te implementeren en te onderhouden.

1. De SPF 10-zoeklimiet

Wanneer een gebruiker de DNS-server opvraagt, worden zijn validatorbronnen zoals bandbreedte, tijd, CPU en geheugen gebruikt. Om belasting van de validator te voorkomen, is er een SPF limiet van 10 extra lookups. De DNS query voor de SPF policy record zelf telt echter niet mee voor deze limiet.

Volgens RFC7208 paragraaf 4.6.4moet de mailserver van de ontvanger niet verder verwerken zodra de limiet van 10 opzoekingen is bereikt. In zo'n geval weigert de e-mail de SPF-validatie met een Permerror-fout. SPF Permerror is een van de berichten die vaak voorkomen in het SPF implementatieproces. Het veroorzaakt niet-aflevering van e-mail en treedt op als er meerdere SPF-records bestaan op één domein, als er een syntaxfout optreedt of als de SPF-recordlimieten worden overschreden. Wanneer u deze limiet overschrijdt, wordt de SPF-implementatie als ongeldig beschouwd en mislukt uw e-mail bij SPF, wat mogelijk schadelijk is voor uw e-mailafleveringspercentage.

U kunt de gratis SPF record checker gebruiken om deze fout te herstellen en beveiligde e-mailconversaties te garanderen.

Bovendien is volgens de RFC een DNS-query van een hostnaam die gevonden wordt in een MX-record niet meer dan 10 A-records of AAAA-records genereren. Als een DNS PTR query meer dan 10 resultaten oplevert, worden alleen de eerste 10 resultaten weergegeven en gebruikt.

2. Het door mensen leesbare Van-adres

De tweede SPF-beperking is dat SPF-records van toepassing zijn op specifieke Return-Path domeinen (ook bekend als de afzender van de envelop of MFrom) en niet op het Van-adres (header afzender of Van-adres) dat ontvangers zien in hun e-mailclients. Ontvangers besteden over het algemeen niet veel aandacht aan het verborgen Return-Path adres en richten zich alleen op het zichtbare From adres wanneer ze een e-mail openen. Hackers maken gebruik van deze maas in de wet om phishing-aanvallen uit te voeren door een vals domein te gebruiken in hun Return Path-adres (dat SPF passeert) en het Van-adres te vervalsen met een legitiem of legitiem uitziend adres. Omdat de meeste mensen zich niet bewust zijn van het Return Path-adres en het niet controleren, kunnen aanvallers met deze truc gemakkelijk SPF-bescherming omzeilen.

3. Problemen met het doorsturen van e-mails

SPF heeft nog een kritiek storingspunt dat de bezorgbaarheid van e-mail kan schaden. Als je SPF hebt geïmplementeerd op je domein en iemand stuurt je e-mail door, dan kan de doorgestuurde e-mail worden geweigerd vanwege je SPF-beleid. Dat komt omdat het doorstuurproces de server die het bericht verstuurt (en zijn IP-adres) verandert, maar het Van-adres van de oorspronkelijke afzender blijft vaak hetzelfde. De ontvangende server ziet het originele Van adres, maar controleert het IP adres van de *doorsturende* server in het SPF record van de originele afzender. Omdat het IP-adres van de doorsturende server meestal niet is opgenomen in het SPF-record van de oorspronkelijke afzender, mislukt de controle, waardoor de doorgestuurde e-mail mogelijk wordt geweigerd of als spam wordt gemarkeerd.

De invloed van de grootte van SPF-records op e-mailaflevering

Als een ontvanger de SPF-recordlimiet overschrijdt, mislukt de SPF-controle en treedt er een Permerror op. Je kunt deze fout waarnemen wanneer je DMARC-monitoring gebruikt. De ontvanger kan kiezen hoe om te gaan met e-mails met een Permerror-fout. Ze kunnen ervoor kiezen om de invoer te weigeren, wat betekent dat de e-mail wordt teruggestuurd. Sommige ontvangers configureren het om een 'neutraal' SPF resultaat te tonen (alsof er geen SPF wordt gebruikt). Ze kunnen ook kiezen voor 'fail' of 'softfail', wat betekent dat e-mails die niet voldoen aan de SPF-verificatiecontroles niet worden geweigerd, maar in de spammap terechtkomen. 

Deze resultaten worden ook bepaald door rekening te houden met de resultaten van DMARC, DKIM en spamrating. Het overschrijden van de SPF-limiet heeft invloed op de bezorgbaarheid van e-mails door de kans te verkleinen dat e-mails in de primaire inbox van de beoogde ontvangers terechtkomen.

De validator beoordeelt het SPF-beleid van links naar rechts en wanneer er een overeenkomst is gevonden op het IP-adres van de afzender, stopt het proces. Afhankelijk van de afzender bereikt een validator nu niet altijd de lookup limiet, zelfs als het SPF beleid meer dan 10 lookups vereist om volledig te evalueren. Dit zorgt voor problemen bij het identificeren van SPF record limiet-gerelateerde e-mail deliverability problemen. 

Hoe het aantal vereiste opzoekingen verminderen?

Voor sommige domeineigenaren is het moeilijk om binnen de SPF-limiet van 10 lookups te blijven, omdat de gewoonten bij het uitwisselen van e-mail aanzienlijk zijn veranderd sinds 2006 (toen RFC4408 werd geïmplementeerd). Nu gebruiken bedrijven meerdere cloud-gebaseerde programma's en diensten met één domein. Hieronder volgen enkele manieren om deze veelvoorkomende SPF-beperking te omzeilen.

• Ongebruikte services verwijderen

Beoordeel je SF-record en kijk of er ongebruikte of niet-vereiste services zijn. Controleer het op de 'include' of andere mechanismen die domeinen weergeven van services die niet langer in gebruik zijn.

• De standaard SPF-waarden verwijderen

Het standaard SPF-beleid is meestal ingesteld op 'v=spf1 a mx'.. Aangezien de meeste A en AAAA records gebruikt worden voor webservers die geen e-mails mogen versturen, vandaar de 'a' en 'mx' mechanisme niet nodig.

• Vermijd het gebruik van de ptr Mechanisme

De ptr mechanisme wordt sterk afgeraden vanwege de zwakke beveiliging en onbetrouwbaarheid. Het mechanisme veroorzaakt het SPF limietprobleem doordat er meer lookups nodig zijn. Daarom moet het zoveel mogelijk vermeden worden.

• Vermijd het gebruik van de mx Mechanisme

De mx mechanisme wordt gebruikt voor het ontvangen van e-mails en niet noodzakelijk voor het verzenden ervan. Daarom kun je het vermijden om binnen de SPF record limiet te blijven die is ingesteld op lookups. Als je een cloud-gebaseerde e-mail service gebruiker bent, gebruik dan de 'include' mechanisme.

• IPv6 of IPv4 gebruiken 

De IPv4 en IPv6 hebben geen extra lookups nodig, wat betekent dat ze je helpen de SPF-limiet van niet meer dan 10 lookups niet te overschrijden. Je moet de twee mechanismen echter regelmatig bijwerken en onderhouden, omdat ze vatbaarder zijn voor fouten als ze niet opnieuw worden geconditioneerd.

• Overweeg SPF Record Afvlakking

Sommige bronnen beweren dat hoe platter (of korter) het SPF beleid, hoe beter de domeinreputatie. Ze suggereren deze methode om binnen de SPF record limieten te blijven die zijn ingesteld op lookups. Afvlakking houdt in dat mechanismen zoals 'include' worden vervangen door de werkelijke IP-adressen waarnaar ze verwijzen, waardoor het aantal DNS-opzoekingen dat nodig is tijdens de validatie direct wordt verminderd. Flattening vereist echter zorgvuldig beheer; als de IP-adressen achter een inbegrepen service veranderen, wordt het geflatteerde record verouderd en moet het handmatig worden bijgewerkt om te voorkomen dat legitieme e-mails de SPF-controles niet doorstaan. Automatische SPF flattening tools kunnen helpen dit proces te beheren.

De rol van DMARC in het overwinnen van SPF-beperkingen

DMARC pakt de SPF-beperking van het menselijk leesbare Van adres aan door een overeenkomst of afstemming te vereisen tussen het menselijk leesbare Van veld domein en het domein dat door SPF wordt geverifieerd (het Return-Path domein).

Dus als een e-mail de SPF-controles doorstaat (wat betekent dat het verzendende IP-adres geautoriseerd is voor het Return-Path-domein), maar het Return-Path-domein is niet hetzelfde als het From-adresdomein, dan mislukt de DMARC-uitlijning voor SPF. Om een e-mail door DMARC te laten komen, moet deze voldoen aan SPF *met* afstemming of DKIM *met* afstemming. Dit voorkomt de veelvoorkomende phishingtactiek waarbij het Van-adres wordt gespoofed terwijl het Return-Path door SPF komt. DMARC introduceert ook rapportagemogelijkheden, waardoor domeineigenaren feedback krijgen over e-mails die claimen van hun domein afkomstig te zijn, inclusief verificatieresultaten (SPF, DKIM, DMARC, uitlijning) en informatie over versturende bronnen. Deze zichtbaarheid helpt bij het identificeren van misconfiguraties, doorstuurproblemen en kwaadwillige spoofingpogingen.

Hoe helpt het afvlakken van SPF-records bij het overwinnen van de 10 DNS-opzoeklimiet

SPF-record afvlakken is een techniek die wordt gebruikt om SPF-records (Sender Policy Framework) te optimaliseren om de 10 DNS-opzoeklimiet voor SPF te omzeilen. De 10 DNS lookup limiet is een beperking opgelegd door veel DNS resolvers, die het aantal DNS queries beperkt dat kan worden uitgevoerd bij het verifiëren van een SPF record voor een domein.

Wanneer een e-mail wordt ontvangen, vraagt de mailserver van de ontvanger het DNS-domein van de afzender om zijn SPF-record om te controleren of de afzender geautoriseerd is om e-mails vanaf dat domein te versturen. SPF records gebruiken vaak mechanismen zoals "include", "a", "mx" en "ptr" die DNS opzoekingen vereisen. Als het SPF record veel van zulke mechanismen bevat, vooral geneste includes (waar het SPF record van een included domein ook includes bevat), kan het snel de 10 DNS lookup limiet overschrijden, wat leidt tot SPF verificatie fouten (Permerror) en potentiële e-mail afleveringsproblemen.

Om deze beperking te omzeilen, wordt SPF recordafvlakking gebruikt. SPF-recordafvlakking is een techniek die opzoekmechanismen (voornamelijk 'include', maar mogelijk ook 'a' en 'mx') in een SPF-record vervangt door de overeenkomstige IP-adressen of CIDR-bereiken. Dit vermindert het aantal DNS-query's dat nodig is om het SPF-record te verifiëren, omdat de IP-adressen direct worden vermeld in plaats van dat ze verder moeten worden opgezocht.

Door het SPF-record af te vlakken, wordt het aantal DNS-query's dat nodig is om het SPF-record te verifiëren aanzienlijk verminderd, waardoor e-mailberichten door de SPF-verificatie komen, zelfs als de oorspronkelijke recordstructuur tot meer dan 10 DNS-zoekopdrachten zou hebben geleid. Deze techniek helpt SPF Permerrors voorkomen en vermindert het risico van SPF record validatie mislukkingen als gevolg van DNS query time-outs of tijdelijke DNS server problemen. Zoals eerder vermeld, vereisen afgevlakte records echter onderhoud om accuraat te blijven wanneer onderliggende IP-adressen veranderen.

Uitdagingen van het implementeren van SPF in grote ondernemingen

SPF heeft de beperking van niet meer dan 10 lookups afgedwongen om DoS- en DDoS-aanvallen tegen DNS-infrastructuur tijdens SPF-validatie. Helaas kunnen deze lookups erg snel oplopen, vooral in grote bedrijven. Vroeger beheerden bedrijven vaak hun eigen mailservers, maar nu zijn ze sterk afhankelijk van een groot aantal verzenders van derden voor marketing, transactie-e-mails, CRM, ondersteuningssystemen, enz. Elke service van derden vereist vaak een 'include'-mechanisme in het SPF-record, wat telt als één lookup, en hun eigen SPF-records kunnen nog meer lookups bevatten. Dit creëert een probleem omdat het toevoegen van meerdere services er al snel voor kan zorgen dat het domein de limiet van 10 lookups bereikt of overschrijdt, wat leidt tot de Permerror-problemen die hierboven zijn beschreven. Het beheren van deze vele bronnen en binnen de limiet blijven terwijl alle legitieme mail geautoriseerd wordt, wordt een grote uitdaging.

• Over
• Laatste berichten

Ahona Rudra

Expert domein- en e-mailbeveiliging bij PowerDMARC

Ahona is de Marketing Manager bij PowerDMARC, met 5+ jaar ervaring in het schrijven over cybersecurity onderwerpen, gespecialiseerd in domein- en e-mailbeveiliging. Ahona heeft een postdoctorale graad in Journalistiek en Communicatie, en heeft haar carrière in de beveiligingssector sinds 2019 verstevigd.

Laatste berichten van Ahona Rudra (Bekijk alle berichten)

• DMARC MSP-casestudy: hoe Pablo Herreros het beheer van DNS-records voor klanten vereenvoudigde met PowerDMARC - 10 december 2025
• SMB1001 & DMARC: wat kleine en middelgrote bedrijven moeten weten over naleving van e-mailbeveiliging - 8 december 2025
• Beste domeinanalysers voor e-mailbeveiliging in 2026 - 5 december 2025