SPF flattening: de limiet van 10 lookups oplossen

De limiet van 10 lookups uitgelegd

SPF (Sender Policy Framework) faalt met een permerror wanneer een ontvangende mailserver meer dan 10 DNS-lookups moet uitvoeren om je SPF-record te resolven. Dat komt door geneste include-statements: bevat je record een provider en bevat die provider weer een andere dienst, dan telt elke stap mee voor de limiet. Om dit op te lossen gebruik je SPF flattening, waarbij deze recursieve lookups worden vervangen door een statische lijst met IP-adressen.

Als engineer die verantwoordelijk is voor deliverability zie ik dit probleem het vaakst opduiken bij "wildgroei aan leveranciers". Een bedrijf begint met één transactionele provider, voegt een marketingtool toe, daarna een CRM, en ineens is het SPF-record een kaartenhuis. Wordt de 11e lookup geactiveerd, dan stopt de ontvangende server met zoeken en retourneert hij een permanente fout. Je e-mail wordt dan niet alleen als spam gemarkeerd, maar mogelijk volledig geweigerd, omdat de authenticatiecontrole fundamenteel is mislukt.

Hoe de lookuplimiet werkt

Volgens RFC 7208 bestaat de limiet om Denial of Service-aanvallen (DoS) op de DNS-infrastructuur te voorkomen. Zonder limiet zou een kwaadwillende een circulaire verwijzing of een enorme keten van includes kunnen maken, waardoor de ontvangende server voor één e-mail honderden queries moet uitvoeren.

Wat telt als lookup?

Niet elk mechanisme in je SPF-record is gratis. De volgende mechanismen veroorzaken een DNS-query:

• include: de meest voorkomende boosdoener. Deze laat de server het SPF-record van een ander domein opzoeken.
• a: vraagt het A-record van het domein op.
• mx: vraagt de MX-records van het domein op.
• ptr: vraagt de reverse DNS op (dit is echter verouderd en moet je vermijden).
• exists: vraagt een specifiek domein op om te zien of het bestaat.

Mechanismen zoals ip4 en ip6 zijn gratis, omdat het IP-adres expliciet in het record staat.

De anatomie van een lookupketen

Neem dit hypothetische SPF-record:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendhq.cc ~all

Op het eerste gezicht zijn dat 3 lookups. Maar als _spf.google.com nog drie include-statements bevat en spf.protection.outlook.com er vier, zit je al op 10 lookups. Had het record van SendHQ ook een include, dan heb je de limiet bereikt. Dat is een "include-keten".

De permerror herkennen

Weet je niet zeker of je de limiet hebt bereikt, dan kun je je records valideren met de E-mail-DNS-checker van SendHQ. In een ruwe log of een tool voor headeranalyse zie je een resultaat zoals dit:

spf=permerror (too many DNS lookups)

Dit is iets anders dan een softfail (~all) of een fail (-all). Een permerror betekent dat de SPF-controle niet kon worden voltooid. De ontvanger kan dan niet verifiëren of de afzender gemachtigd is, wat er vaak toe leidt dat de e-mail wordt verworpen of door strenge filters wordt gemarkeerd.

Wat is SPF flattening?

SPF flattening is het proces waarbij alle include-, a- en mx-mechanismen worden omgezet in een platte lijst met ip4- en ip6-adressen.

Voorbeeld: voor en na

Voor (recursief):

v=spf1 include:_spf.example.com include:_spf.vendor.com ~all

(Stel dat _spf.example.com resolvet naar 1.2.3.4 en _spf.vendor.com naar 5.6.7.8)

Na (flattened):

v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ~all

Door het record om te zetten in een lijst met IP's daalt het aantal lookups van 2 (of meer) naar 0. De ontvangende server ziet de IP's direct en valideert de afzender zonder verdere DNS-queries.

De afwegingen van flattening

Flattening is een krachtige oplossing, maar brengt een aanzienlijke onderhoudslast met zich mee.

1. Het probleem van verouderde IP's

Met een include-statement delegeer je het beheer van IP-adressen aan de provider. Voegt Amazon SES of SendGrid een nieuwe IP-range aan de infrastructuur toe, dan werken zij hun eigen SPF-record bij en blijft je e-mail gewoon stromen.

Flatten je die records in je eigen DNS, dan ben jij voortaan verantwoordelijk voor die IP's. Wijzigt de provider een IP en werk je je platte lijst niet bij, dan faalt de SPF-authenticatie van je e-mails. Dat is de belangrijkste reden waarom handmatige flattening gevaarlijk is voor transactionele e-mail met een hoog volume.

2. Limieten voor de lengte van records

DNS-records hebben een maximale lengte. Eén string in een TXT-record is beperkt tot 255 tekens. Je kunt meerdere strings samenvoegen, maar sommige oudere DNS-parsers hebben moeite met erg lange records. Flatten je te veel providers, dan kan je SPF-record te groot worden om correct te worden verwerkt.

Include-ketens oplossen

Loop je tegen de limiet van 10 lookups aan, volg dan deze volgorde van oplossingen, van de veiligste naar de meest ingrijpende.

Stap 1: controleren en opschonen

Controleer je record op providers die je niet meer gebruikt. Veel teams hebben nog include-statements voor diensten waarmee ze drie jaar geleden zijn gestopt. Verwijder elke provider die niet langer namens jou e-mail verstuurt.

Stap 2: gebruik subdomeinen voor verschillende soorten verkeer

Dit is de meest professionele architecturale oplossing. Zet niet elke dienst op je hoofddomein, maar verdeel ze op functie:

• Hoofddomein (example.com): zakelijke e-mail (Google Workspace/Outlook).
• Transactioneel subdomein (mail.example.com): SendHQ of Amazon SES.
• Marketingsubdomein (news.example.com): Mailchimp of Klaviyo.

Elk subdomein heeft een eigen SPF-record en een eigen limiet van 10 lookups. Zo isoleer je het risico en voorkom je dat de complexe SPF-keten van een marketingtool je cruciale transactionele e-mails breekt.

Stap 3: dynamische SPF flattening

Dynamische flattening is een dienst die de include-ketens van je providers realtime bewaakt en je DNS-record automatisch bijwerkt met de actuele IP-adressen. Dat lost het probleem van "verouderde IP's" op door het bijwerken via een API te automatiseren.

SPF in de context van moderne bezorging

Het is belangrijk om te begrijpen dat SPF maar één onderdeel van de authenticatiepuzzel is. Om te zorgen dat je e-mail door de ontvangende server wordt geaccepteerd, moet je SPF afstemmen op DKIM en DMARC. Een gedetailleerd overzicht van die samenhang vind je in de gids van SendHQ over DKIM, SPF en DMARC.

Acceptatie vs. bezorging vs. plaatsing

Als engineer maak ik onderscheid tussen deze drie fasen:

1. Acceptatie: de ontvangende server accepteert de verbinding en het bericht. Een SPF-permerror kan ertoe leiden dat een server het bericht op SMTP-niveau weigert, zodat het nooit wordt geaccepteerd.
2. Bezorging: het bericht wordt geaccepteerd en in de mailbox (of een map) van de gebruiker geplaatst.
3. Inboxplaatsing: het bericht belandt in de primaire inbox in plaats van in de spammap.

SPF flattening lost een probleem met acceptatie op. Het garandeert geen inboxplaatsing. Plaatsing wordt bepaald door afzenderreputatie, content en engagementmetrics.

Speciale aandachtspunten voor AI-agents

Nu steeds meer AI-agents e-mails via API's versturen, neemt het risico op SPF-problemen toe, omdat agents grote volumes e-mail over verschillende domeinen kunnen versturen. Behandel het versturen van e-mail bij het bouwen van agentworkflows als een extern neveneffect.

Idempotentie en goedkeuring

Agents mogen nooit zonder veiligheidsmechanisme e-mails in een lus versturen. Gebruik een idempotentiesleutel om te voorkomen dat de retrylogica van je agent dezelfde transactionele e-mail tien keer naar een klant stuurt. Implementeer daarnaast voor belangrijke e-mails een goedkeuringsstap met een mens in de lus voordat de API-call wordt gedaan.

Kostenanalyse van verzendproviders

Houd bij het kiezen van een provider voor je SPF-record rekening met de kosten van het volume dat je verstuurt. Op basis van de prijzen van september 2026:

• Amazon SES: kost a la carte 0.10 USD per 1.000 e-mails (prijzen van Amazon SES). Voor 50.000 e-mails is dat ongeveer 5 USD. De nieuwe abonnementsniveaus die op 21 juli 2026 zijn ingevoerd, zijn Essentials (0.16 USD per 1.000), Pro (0.22 USD per 1.000 plus 105 USD/maand/regio) en Enterprise (0.23 USD per 1.000 plus 500 USD/maand).
• Postmark: 15 USD per maand voor 10.000 e-mails, met overschrijdingen tussen 1.80 en 1.20 USD per 1.000 (prijzen van Postmark). 50.000 e-mails kosten bij de niveaus van Postmark ongeveer 66 USD.
• Resend: het gratis niveau biedt 3.000 e-mails per maand (met een maximum van 100/dag). Pro kost 20 USD per maand voor 50.000 e-mails, met overschrijdingen tegen 0.90 USD per 1.000 (prijzen van Resend).
• Mailgun: 15 USD per maand voor 10.000 e-mails, met overschrijdingen van 1.80 tot 1.10 USD per 1.000 (prijzen van Mailgun).
• SendGrid: het gratis niveau is nu een proefperiode van 60 dagen en Essentials begint bij 19.95 USD per maand (prijzen van SendGrid).

Checklist voor SPF-probleemoplossing

Vermoed je een probleem met de lookuplimiet? Loop dan deze checklist door:

• Voer een DNS-check uit op het hoofddomein en alle verzendende subdomeinen.
• Tel het totale aantal include-, a-, mx- en exists-mechanismen.
• Traceer de include-ketens van elke provider om te zien of deze geneste lookups hebben.
• Identificeer en verwijder ongebruikte providers.
• Beoordeel of verkeer naar een dedicated subdomein kan worden verplaatst (bijv. notifications.example.com).
• Implementeer dynamische SPF-flattening als de limiet nog steeds wordt overschreden.
• Verifieer dat het uiteindelijke record de limiet van 255 tekens per string niet overschrijdt.

Overzichtstabel: SPF-mechanismen

Mechanisme | DNS-lookup? | Risico | Aanbeveling

ip4 / ip6 | Nee | Laag | Gebruiken voor statische IP's

include | Ja | Hoog | Spaarzaam gebruiken, ketens bewaken

a | Ja | Gemiddeld | Waar mogelijk vermijden, ip4 gebruiken

mx | Ja | Gemiddeld | Waar mogelijk vermijden

ptr | Ja | Hoog | Niet gebruiken (verouderd)

Door je SPF-records proactief te beheren, voorkom je de permerror die je deliverability om zeep helpt nog voordat je e-mail het spamfilter bereikt. Of je nu een eenvoudige API gebruikt of een complex agentsysteem: een slanke DNS-configuratie is de beste manier om te zorgen dat je transactionele e-mail wordt geaccepteerd.

Een complete set tools voor het beheer van je domeinauthenticatie vind je op https://sendhq.cc.