SPF flattening

SPF flattening is de praktijk waarbij u elk mechanisme in uw SPF-record dat een lookup veroorzaakt - include:, a, mx, ptr, exists en redirect= - herleidt tot de concrete IP-adressen die erachter schuilgaan, en die adressen vervolgens rechtstreeks publiceert als ip4:- en ip6:-vermeldingen. Het doel is eenvoudig: uw record binnen de strikte limieten houden die ontvangende mailservers afdwingen, zodat legitieme e-mail authenticatie blijft doorstaan naarmate uw verzendinfrastructuur groeit.

Deze pagina is het knooppunt voor alles rond SPF flattening. Zij legt uit wat flattening is, waarom de 10-lookuplimiet het probleem forceert, hoe het proces stap voor stap verloopt en waar de echte afwegingen en risico’s liggen. Van hieruit kunt u dieper ingaan op de specifieke taken: hoe u een SPF-record flattent, de beste SPF flattening-tools, of SPF flattening DKIM en DMARC beïnvloedt, het uitvoeren ervan op Cloudflare, en hoe flattening zich verhoudt tot SPF flattening versus macro’s.

Wat is SPF flattening?

Een SPF-record is één enkel TXT-record dat begint met v=spf1 en dat aan ontvangende mailservers aangeeft welke hosts e-mail voor uw domein mogen versturen. Wanneer u een dienst toevoegt - een CRM, een marketingplatform, een helpdesk, een aanbieder van transactionele e-mail - voegt u er doorgaans een include: voor toe. Elke include: verwijst naar het SPF-record van een ander domein, en de ontvanger moet dat record ophalen op het moment van evaluatie. Die ophaalacties zijn DNS-lookups, en die lopen snel op.

SPF flattening neemt al die indirecte verwijzingen en herleidt ze vooraf. In plaats van de ontvanger te vragen include:_spf.google.com na te jagen via geneste _netblocks-records, somt een geflattend record simpelweg de onderliggende IP-reeksen op:

• Voor: v=spf1 include:sendgrid.net include:_spf.google.com a mx -all
• Na: v=spf1 ip4:149.72.0.0/16 ip4:167.89.0.0/17 ip4:64.233.160.0/19 ip6:2a00:1450:4000::/36 -all

Op het moment van evaluatie hoeft de ontvanger niet langer door includes te recurseren of A/MX-doelen op te lossen - hij vergelijkt eenvoudig het verbindende IP-adres met uw gepubliceerde CIDR-reeksen. Dat brengt het aantal DNS-lookups tijdens de uitvoering feitelijk terug tot nul en houdt uw record licht, snel en betrouwbaar.

“De 10-lookuplimiet is veruit de meest voorkomende reden waarom SPF-records van ondernemingen stilzwijgend breken”, zegt Brad Slavin, General Manager van DuoCircle en oprichter van AutoSPF. “Op basis van onze ervaring met het beheren van SPF voor meer dan 2.000 klantdomeinen is het faalpatroon altijd hetzelfde: een team voegt een nieuwe SaaS-tool toe, de bijbehorende include duwt het totaal voorbij de 10, en legitieme e-mail begint te falen - maar niemand merkt het tot een klant klaagt over ontbrekende facturen of wachtwoordherstel.”

Waarom de limiet van 10 DNS-lookups flattening afdwingt

Volgens RFC 7208 is de SPF-evaluatie begrensd op 10 DNS-mechanismelookups en 2 void lookups per controle. Het overschrijden van beide limieten levert een PermError op - een permanente fout die ontvangende servers vertelt dat uw e-mail niet geauthenticeerd kan worden. De server probeert het niet opnieuw en evalueert de rest van uw record niet. Hij stopt eenvoudigweg, en elk bericht vanaf uw domein faalt op SPF.

De valstrik is dat deze limiet onzichtbaar is totdat u hem overschrijdt. Een klein bedrijf dat via één aanbieder verstuurt, zal hem nooit bereiken. Maar moderne e-mailstacks stapelen routinematig meerdere ESP’s, een CRM, een supportdesk en interne mail op elkaar - en elk daarvan voegt een of meer lookups toe. Alleen Google Workspace verbruikt al ongeveer vier van uw tien lookups via zijn geneste includes. Voeg Salesforce, Mailchimp, SendGrid en Zendesk toe en u komt gemakkelijk uit op twaalf tot vijftien. De elfde lookup wordt nooit geëvalueerd, dus welke dienst zich toevallig voorbij dat punt bevindt, verliest stilzwijgend zijn autorisatie.

Hier is welke mechanismen meetellen:

Veroorzaakt een DNS-lookup	Veroorzaakt geen lookup
include:example.com	ip4:x.x.x.x[/CIDR]
a, a:example.com	ip6:…
mx, mx:example.com	all
ptr (afgeraden door RFC 7208)
exists:domain
redirect=example.com

Omdat ip4:- en ip6:-mechanismen geen resolutie vereisen, ruilt flattening elk lookupgedreven mechanisme in voor lookupvrije mechanismen. Dat is het volledige mechanisme waarmee flattening u compliant houdt. Een snelle manier om te zien waar u vandaag staat, is uw domein door de SPF Checker te halen, die elke include uitklapt en uw lookups telt.

Waarom flattening ertoe doet voor bezorgbaarheid en beveiliging

De 10-lookuplimiet is niet zomaar een technische voetnoot - hij ligt precies op het pad tussen uw e-mail en de inbox.

Bezorgbaarheid. DMARC steunt op SPF en DKIM. Als uw SPF-record een PermError retourneert, behandelt DMARC dat als een fout, en kan legitieme e-mail in quarantaine worden geplaatst of worden geweigerd. Sinds 2024 vereisen Google, Yahoo en Microsoft dat bulkverzenders authenticeren met SPF, DKIM en DMARC, en zij weigeren niet-conforme berichten nu ronduit in plaats van ze naar de spammap te sturen. Samen bestrijken die aanbieders ongeveer 90% van een typische consumentenlijst, dus één record dat over de limiet gaat, kan de bezorging aan het grootste deel van uw publiek in één keer afsnijden.

Beveiliging. Wanneer SPF faalt, verliezen ontvangende servers het vermogen om uw legitieme e-mail te onderscheiden van vervalste berichten. Dat is precies het gat dat phishing en business email compromise uitbuiten. Door SPF geldig - en binnen de limiet - te houden, bewaart u het authenticatiesignaal dat u onderscheidt van een aanvaller die zich voordoet als uw domein.

Beheerbaarheid. Naarmate uw merk groeit, groeit ook de lijst platforms die namens u versturen. Flattening bundelt een uitdijende keten van includes tot één overzichtelijke lijst van IP-reeksen die eenvoudig te lezen, te controleren en te doorgronden is.

Hoe SPF flattening werkt, stap voor stap

Of het nu handmatig of geautomatiseerd gebeurt, flattening volgt dezelfde pijplijn:

1. Ontdekking. Lees uw huidige SPF-TXT-record en identificeer elk mechanisme dat een lookup veroorzaakt - include, a, mx, exists, redirect.
2. Recursieve resolutie. Volg elke include-keten, haal het SPF-record van het doel op en recurseer tot alle upstream-inhoud bekend is. Los a/mx-doelen op naar hun A/AAAA-records om zowel IPv4- als IPv6-adressen te verzamelen.
3. Ontdubbelen en comprimeren. Voeg overlappende reeksen samen en aggregeer aaneengesloten blokken in CIDR-notatie, zodat het record compact blijft.
4. Publiceren. Herschrijf het record als v=spf1 ip4:… ip6:… -all, met inachtneming van de TXT-limiet van 255 tekens per string (splits indien nodig in meerdere aaneengeschakelde strings), en werk uw DNS bij.
5. Valideren. Bevestig de syntaxis, controleer of het aantal lookups 0-1 is, en verstuur testmail om te bevestigen dat SPF=pass en DMARC=pass.

Voor de volledige stapsgewijze uitleg met commando’s en specifieke informatie per DNS-aanbieder, zie hoe u een SPF-record flattent.

De keerzijde: een geflattend record is geen eenmalige oplossing

Flattening lost het lookupprobleem op, maar introduceert een nieuw probleem. Wanneer u een dynamische include: vervangt door statische IP-adressen, neemt u de verantwoordelijkheid op u om die IP-adressen actueel te houden. Aanbieders wisselen hun verzendinfrastructuur voortdurend, en zij stellen u er zelden van op de hoogte wanneer zij dat doen.

“Het misverstand rond SPF flattening is dat het een eenmalige oplossing zou zijn”, zegt Adam Lundrigan, CTO van DuoCircle en architect van de flattening-engine van AutoSPF. “IP-reeksen van leveranciers veranderen constant - Google roteerde zijn _netblocks in 2025 alleen al drie keer. Een geflattend record dat niet automatisch opnieuw wordt herleid, veroudert en de-autoriseert stilzwijgend legitieme verzenders. Daarom scant AutoSPF elke 15 minuten opnieuw.”

Dit is het allerbelangrijkste om te begrijpen over flattening. Een handmatig opgebouwd geflattend record is accuraat op de dag dat u het publiceert en raakt daarna langzaam achterhaald. Wanneer een aanbieder een nieuwe IP-reeks toevoegt, begint e-mail vanaf die reeks te falen op SPF - en omdat de fout stilzwijgend is, komt u er meestal achter via een geweigerde factuur of een gemist wachtwoordherstel, niet via een waarschuwing. In AutoSPF-telemetrie over 1.200 domeinen verlaagde flattening de PermError-percentages met 93% en verbeterde het de DMARC-slaagpercentages met 7-12% in de eerste 30 dagen - maar alleen wanneer het record actueel werd gehouden. De mediane IP-churn van ESP’s ligt op 2-4 wijzigingen per week voor aanbieders met een hoog volume.

De overige afwegingen die het overwegen waard zijn:

• Recordgrootte. Flattening kan een TXT-record richting de DNS-groottelimieten duwen. Streef ernaar de responses onder ongeveer 1.000-1.200 bytes te houden om UDP-fragmentatie en truncatie te voorkomen, en geef de voorkeur aan geaggregeerde CIDR-reeksen boven het opsommen van individuele adressen.
• Over-autorisatie. Sommige includes autoriseren veel meer van het internet dan u daadwerkelijk gebruikt. Door te controleren en te snoeien voordat u flattent, houdt u uw aanvalsoppervlak klein.

Handmatig, gescript of geautomatiseerd?

Er zijn drie manieren om te flatten, met zeer uiteenlopende risicoprofielen:

• Handmatig. Vraag voor elke include de huidige IP-adressen op, aggregeer ze en publiceer met de hand. Gratis en volledig onder uw controle, maar arbeidsintensief en gevoelig voor veroudering zodra een aanbieder van IP-adressen wisselt. Alleen praktisch voor kleine, statische omgevingen.
• Gescript. Een Python- of Go-script recurseert includes, lost A/MX op, voegt CIDR-reeksen samen en pusht via API volgens een schema naar DNS. Herhaalbaar en controleerbaar, maar u bent zelf verantwoordelijk voor de randgevallen, de loop-beveiliging en de doorlopende betrouwbaarheid.
• Geautomatiseerde (dynamische) dienst. Een gehoste dienst herleidt uw includes continu opnieuw, detecteert IP-wijzigingen en publiceert automatisch opnieuw. Dit neemt de onderhoudslast volledig weg, tegen de prijs van een beheerde afhankelijkheid.

Voor elke organisatie die dynamische aanbieders gebruikt zoals Google Workspace, Microsoft 365, SendGrid of Amazon SES verdient een geautomatiseerde aanpak sterk de voorkeur - de hele moeilijkheid van flattening zit in het bijhouden van de churn, en dat is precies wat automatisering afhandelt. Een volledige vergelijking van de opties vindt u in beste SPF flattening-tools.

Waar AutoSPF past

De automatische SPF flattening-dienst van AutoSPF is speciaal gebouwd voor het onderhoudsprobleem dat flattening riskant maakt. Hij ontdekt en klapt uw geneste includes uit, lost de volledige A/MX/AAAA-ketens op, ontdubbelt en comprimeert reeksen tot minimale CIDR-blokken, en publiceert een gevalideerd, groottebewust geflattend record dat onder de 10-lookuplimiet blijft.

Twee zaken onderscheiden hem:

• Hij scant elke 15 minuten opnieuw en werkt uw record automatisch bij op het moment dat de IP-adressen van een upstream-aanbieder veranderen - zodat een geflattend record nooit stilzwijgend veroudert.
• Hij herleidt naar exact dezelfde IP-adressen als waar uw includes naartoe herleiden - geen brede, te ruime reeksen en geen over-autorisatie. Uw geflattende record autoriseert precies de hosts die uw echte includes autoriseren, en niets meer.

Daarbovenop biedt hij geversioneerde records met rollback in één klik, canary-/staging-publicatie en drift-waarschuwingen wanneer e-mail binnenkomt vanaf IP-adressen buiten uw huidige geflattende set. Hij integreert rechtstreeks met grote DNS-aanbieders zoals Route 53, Cloudflare, Google Cloud DNS en Azure DNS. Voor en na elke wijziging kunt u met de SPF Checker bevestigen dat het record schoon herleidt.

Flattening bij verschillende DNS-aanbieders en op schaal

De mechanismen van flattening zijn overal gelijk, maar het publiceren verschilt per platform. Bij Cloudflare bijvoorbeeld beheert u het TXT-record via het dashboard of de API en moet u rekening houden met het chunkinggedrag voor strings - de details worden behandeld in Cloudflare SPF flattening.

Op SaaS-schaal - duizenden tenants, meerdere verzendstromen - is het winnende patroon gelaagd: segmenteer mailstromen naar subdomeinen (bijvoorbeeld mkt.example.com voor marketing, tx.example.com voor transactioneel), centraliseer beleid met redirect= naar één klein canoniek record, flatten aanbieders met hoge churn volledig tot geaggregeerde ip4/ip6-sets, en automatiseer de verversing met diff-gebaseerde publicatie zodat ongewijzigde records nooit DNS-churn veroorzaken. Zware verzenders naar subdomeinen delegeren houdt bovendien uw organisatiedomein slank en vereenvoudigt de DMARC-uitlijning.

Verandert flattening DKIM of DMARC?

Flattening verandert alleen hoe geautoriseerde verzenders worden uitgedrukt in SPF - ip4/ip6 in plaats van include - niet uw domeinidentiteit of uw DKIM-handtekeningen. Zolang de geflattende SPF gepubliceerd is op het domein dat wordt gebruikt in uw MAIL FROM/Return-Path, blijft de DMARC-uitlijning onaangetast, en door de PermError te elimineren verbetert het doorgaans de DMARC-slaagpercentages wanneer SPF de uitgelijnde identifier is. De volledige relatie, inclusief hoe DKIM vaak de uitlijning draagt voor bulkverzenders, wordt behandeld in beïnvloedt SPF flattening DKIM en DMARC.

Flattening versus SPF-macro’s

Traditionele flattening herleidt includes vooraf tot statische IP-adressen, en daarom heeft het constante verversing nodig. SPF-macro’s slaan een andere weg in: zij gebruiken dynamische expansie zodat één record een feitelijk onbeperkt aantal verzenders kan autoriseren zonder ooit de 10-lookuplimiet te raken - tegen de prijs van extra complexiteit en zwakkere resolverondersteuning. Welke aanpak bij u past, hangt af van uw infrastructuur en uw bereidheid tot onderhoud; de volledige uitsplitsing staat in SPF flattening versus macro’s.

Veelgestelde vragen

Wat is SPF flattening in eenvoudige bewoordingen?

SPF flattening is het proces waarbij u de include:-, a- en mx-mechanismen in uw SPF-record vervangt door de daadwerkelijke IP-adressen waarnaar ze herleiden. Dit geeft ontvangende mailservers een kant-en-klare lijst van geautoriseerde IP-adressen in plaats van hen te dwingen DNS-lookups uit te voeren, wat uw record binnen de 10-lookuplimiet houdt die is gedefinieerd door RFC 7208 en authenticatiefouten voorkomt.

Waarom is SPF flattening nodig?

Flattening wordt nodig wanneer uw domein de limiet van de SPF-specificatie van 10 DNS-lookups per evaluatie overschrijdt. Zodra u die limiet passeert, retourneert SPF een PermError en faalt elk bericht vanaf uw domein op authenticatie, wat er ook toe kan leiden dat DMARC faalt. Omdat de meeste organisaties verschillende externe verzenders gebruiken die elk includes toevoegen, bereiken groeiende domeinen het plafond snel en hebben zij flattening nodig om compliant te blijven.

Verbetert SPF flattening de bezorgbaarheid van e-mail?

Ja. Door de PermError- en TempError-condities te elimineren die worden veroorzaakt door te veel lookups of trage upstream-includes, houdt flattening SPF betrouwbaar geslaagd. In klantgegevens van AutoSPF verlaagde de overgang van 12-18 lookups naar een volledig geflattend record de SPF-gerelateerde DMARC-fouten met meer dan 80% en verbeterde het de inboxplaatsing van marketingmail met 10-15% tijdens piekverzendingen.

Hoe vaak moet een geflattend SPF-record worden bijgewerkt?

Zo vaak als uw aanbieders van IP-adressen wisselen. ESP’s met hoge churn zoals SendGrid en Mailchimp rechtvaardigen verversingen om de 12-24 uur, stabiele suites zoals Google Workspace en Microsoft 365 dagelijks, en statische zelfgehoste reeksen wekelijks. Een handmatig onderhouden record raakt vrijwel altijd achterhaald - AutoSPF omzeilt dit door elke 15 minuten opnieuw te scannen en automatisch opnieuw te publiceren wanneer een upstream-reeks verandert.

Is handmatige SPF flattening veilig?

Handmatige flattening is alleen veilig voor kleine, statische omgevingen waar verzendende IP-adressen zelden veranderen. Voor elk domein dat dynamische aanbieders gebruikt, raakt een handmatig opgebouwd record achterhaald zodra een aanbieder zijn infrastructuur roteert, waardoor legitieme verzenders stilzwijgend worden ge-de-autoriseerd. Geautomatiseerde flattening verdient sterk de voorkeur op elke reële schaal, omdat het bijhouden van de churn van aanbieders het lastige deel is.

Moet ik -all of ~all gebruiken na flattening?

Gebruik -all (hard fail) wanneer u er zeker van bent dat uw geflattende lijst volledig is en actief wordt bewaakt, aangezien dit ontvangers het duidelijkste signaal geeft om vervalste e-mail te weigeren. Gebruik ~all (soft fail) tijdens de uitrol of terwijl u nog regelmatig verzenders toevoegt. Een goede praktijk is om ~all aan te houden totdat DMARC-rapporten een schoon slaagvenster tonen, en dan aan te scherpen naar -all.