Hoe u een SPF-record flattent

Een SPF-record flattenen betekent dat u de mechanismen die DNS-lookups veroorzaken — include:, a, mx, exists, ptr en redirect — vervangt door de expliciete ip4:- en ip6:-reeksen waarnaar ze herleiden. Het resultaat is een record dat exact dezelfde verzenders autoriseert, maar ontvangende servers dwingt om veel minder (idealiter nul) DNS-query’s te doorlopen, waardoor u veilig onder de RFC 7208-limiet van 10 lookups blijft. Deze gids doorloopt het proces stap voor stap, laat zien hoe een geflattend record eruitziet, en legt uit hoe u het accuraat houdt zodra het live staat.

Deze pagina maakt deel uit van onze uitgebreidere gids over SPF flattening. Als u het handmatige werk volledig wilt overslaan, klapt de SPF Checker elke include uit en telt hij uw lookups in enkele seconden.

Waarom u een SPF-record in de eerste plaats zou flattenen

SPF-authenticatie is onder RFC 7208 begrensd op 10 DNS-lookups per evaluatie. Elke include:-, a-, mx-, exists- en redirect-term telt mee in dat budget, en elk daarvan kan verdere recursieve lookups veroorzaken binnen het domein waarnaar het verwijst. Voeg een marketingplatform, een CRM, een helpdesk en een facturatiedienst toe, en één enkel v=spf1-record kan stilletjes opzwellen tot 15-40 lookups.

Wanneer u de limiet overschrijdt, retourneren ontvangers een PermError. Een PermError laat niet slechts één bericht falen — het maakt het hele record ongeldig, zodat legitieme mail van elke geautoriseerde bron op SPF kan gaan falen. Omdat er niets luidruchtig bounct, merken teams het vaak pas op wanneer een klant een ontbrekende factuur of wachtwoordherstelmail meldt.

Flattening lost dit op door die indirecte mechanismen vooraf te herleiden en de ruwe IP-adressen te publiceren. Een ontvanger die een volledig geflattend record evalueert, doet eenvoudige IP-matching zonder recursieve DNS-doorloop, wat ook snellere validatie betekent en geen blootstelling aan een tijdelijke DNS-storing van een derde partij.

Hoe een geflattend SPF-record eruitziet

Hier is een typisch niet-geflattend record dat op drie includes leunt:

v=spf1 include:_spf.google.com include:vendor.com include:vendor2.net -all

Elke include is minstens één lookup, en de include van Google nest er in zijn eentje nog verschillende meer. Geflattend wordt dezelfde autorisatie een directe lijst van IP-adressen:

v=spf1 ip4:203.0.113.5 ip4:192.168.1.1 ip4:185.23.45.67 -all

Er vinden geen lookups plaats op het moment van evaluatie, omdat elk geautoriseerd adres al is uitgeschreven. Het -all-kwalificatieteken blijft behouden zodat het beleid streng blijft.

Hoe u een SPF-record flattent, stap voor stap

Stap 1: Zoek en controleer uw huidige record

Haal uw bestaande SPF-record op met een dig TXT yourdomain.com-query (of het dashboard van uw DNS-aanbieder) en bevestig dat u precies één v=spf1-TXT-record heeft. Meerdere SPF-records op dezelfde naam zijn op zichzelf al een PermError. Noteer welke mechanismen lookups veroorzaken (include, a, mx, exists, redirect, ptr) tegenover de kosteloze ip4/ip6-vermeldingen die u ongewijzigd kunt behouden.

Stap 2: Tel uw lookups

Meet, voordat u iets verandert, hoe ver u over budget zit. Haal uw domein door de SPF Checker, die recursief elke include uitklapt en u een exact aantal lookups geeft. Als u op 8 of meer zit, of al een PermError ziet, is flattening (of delegatie) gerechtvaardigd. Als u op 3 of minder stabiele includes zit, hoeft u wellicht helemaal niet te flatten.

Stap 3: Herleid elk mechanisme recursief tot IP-adressen

Dit is de kern van flattening. Herleid voor elke lookup-veroorzakende term tot expliciete adressen:

Mechanisme	Hoe u het herleidt	Resultaat
include:	Haal het SPF-record van het doel op en klap zijn mechanismen recursief uit	ip4:/ip6: voor elk IP dat het autoriseert
a	Herleid de A/AAAA-records van het domein	Eén ip4:/ip6: per adres
mx	Herleid MX-records, en vervolgens de A/AAAA van elke mailhost	ip4:/ip6: voor elk MX-host-IP
ptr	Flatten niet — het is verouderd, traag en onbetrouwbaar	Verwijder het
exists:	Meestal niet te flatten (afhankelijk van runtime-macro’s)	Behoud ongewijzigd of isoleer naar een subdomein
ip4/ip6	Al statisch	Behoud ongewijzigd

Doorloop de graaf depth-first en houd bij welke domeinen u al heeft bezocht, zodat u circulaire includes kunt detecteren — als een include terugverwijst naar een domein dat al op uw resolutie-stack staat, stop dan en behoud het als een include in plaats van eindeloos te blijven doorlopen.

Stap 4: Ontdubbel en aggregeer CIDR’s

Recursieve expansie produceert overlappingen. Twee leveranciers kunnen een IP delen, of u verzamelt mogelijk verschillende aangrenzende /25-blokken die netjes samengaan tot een /24. Ontdubbel elk adres en aggregeer vervolgens aangrenzende reeksen tot supernetten alleen wanneer de vereniging volledig binnen de geautoriseerde ruimte van één aanbieder blijft. Te ver aggregeren over ongerelateerde aanbieders autoriseert IP-adressen die u niet beheert — een beveiligingsregressie, geen optimalisatie.

Stap 5: Let op de recordgrootte

DNS-TXT-strings zijn beperkt tot 255 tekens per aangehaald segment; langere records moeten worden opgesplitst in meerdere aaneengeschakelde strings binnen hetzelfde record. Als praktische vuistregel houdt u de totale response onder ongeveer 450-900 bytes om UDP-fragmentatie en middlebox-problemen te voorkomen. Als de geflattende lijst te groot is, splits de IP-adressen dan in hulplabels (bijv. spf-a.example.com, spf-b.example.com) die elk alleen ip4/ip6-vermeldingen bevatten en neem ze op vanuit het hoofdrecord — elk hulplabel kost één lookup, dus houd het totaal ≤ 10.

Stap 6: Bevestig het all-kwalificatieteken opnieuw en valideer

Voeg uw oorspronkelijke afsluitende mechanisme toe — -all voor strikte handhaving wordt aanbevolen voor productieverzenders. Haal het record vervolgens opnieuw door een SPF-validator om te bevestigen dat de syntaxis schoon is, dat er nog steeds maar één record is, en dat het aantal lookups is waar u het verwacht. Als u voorzichtig migreert, kunt u kort publiceren met ~all en daarna overschakelen naar -all zodra monitoring stabiele slaagpercentages toont.

Stap 7: Publiceer met een lage TTL en verhoog die daarna

Verlaag, voordat u publiceert, de TTL van het record tot 60-300 seconden, zodat een eventuele fout snel kan worden gecorrigeerd. Publiceer het nieuwe geflattende record, controleer of het correct herleidt vanaf meerdere publieke resolvers (Google, Cloudflare, Quad9), en let op uw DMARC-aggregatierapporten voor een eventuele daling in de SPF-slaagpercentages. Zodra alles stabiel is, verhoogt u de TTL weer naar 1-4 uur.

De keerzijde: geflattende records verouderen

Hier is het probleem waar de meeste mensen die met de hand flatten over struikelen. Op het moment dat u flattent, is uw record een momentopname. Wanneer Google, Mailchimp, Amazon SES of een andere aanbieder zijn verzendende IP-adressen roteert — en grote ESP’s doen dit voortdurend — komt uw hardgecodeerde lijst niet langer overeen met de werkelijkheid. Mail vanaf de nieuwe IP-adressen faalt stilzwijgend op SPF, en u bent terug bij verloren facturen en mislukte wachtwoordherstellingen, behalve dat de oorzaak nu onzichtbaar is omdat het record er goed uitziet.

CDN-gestuurde en marketingverzenders zijn de ergste boosdoeners: interne AutoSPF-gegevens over meer dan 1.200 domeinen tonen dat CDN-gestuurde verzenders 8-15% van hun IP-set maandelijks doorroteren, tegenover minder dan 0,5% voor interne mailservers. Een aanbieder met hoge churn blindelings flatten is vragen om problemen.

De praktische lessen:

• Flatten stabiele bronnen (on-prem relays, statische cloud-IP’s) agressief.
• Laat volatiele ESP’s als includes staan, of isoleer ze achter een gedelegeerd subdomein zoals mail-out.example.com dat de root met één enkele lookup opneemt.
• Behandel flattening nooit als een eenmalige klus — het vereist continue herresolutie.

Automatiseer opnieuw flatten met AutoSPF

Elke keer dat een leverancier van IP-adressen wisselt de stappen 1-7 met de hand doen, is niet realistisch. Dit is precies waarvoor de geautomatiseerde SPF flattening-dienst van AutoSPF is gebouwd. Hij voert het bovenstaande deterministische flattening-algoritme continu uit: hij scant uw includes elke 15 minuten opnieuw, en wanneer de IP-adressen van een upstream-aanbieder veranderen, werkt hij uw gepubliceerde record automatisch bij via de API van uw DNS-aanbieder — met atomaire swaps, gefaseerde TTL’s en rollback in één klik als een canary-controle faalt.

Cruciaal is dat AutoSPF herleidt naar exact dezelfde IP-adressen als waar uw includes naartoe herleiden — het verbreedt de autorisatie nooit met te brede CIDR-samenvoegingen, zodat u niet per ongeluk verzenders autoriseert die u niet bedoelde. U houdt een klein, stabiel record aan de root; AutoSPF houdt het op de achtergrond correct.

Om te beslissen welke van uw bronnen u flattent versus delegeert, zie onze gids over de beste SPF flattening-tools. Als u het hardcoderen van IP-adressen liever helemaal vermijdt, vergelijk dan de aanpakken in SPF flattening versus macro’s. En voordat u flattent, is het de moeite waard te bevestigen dat de wijziging uw andere authenticatierecords niet verstoort — zie beïnvloedt SPF flattening DKIM en DMARC.

Veelgestelde vragen

Breekt het flatten van een SPF-record DKIM of DMARC?

Nee, mits correct uitgevoerd. Flattening verandert alleen welke IP-adressen SPF autoriseert — het raakt DKIM-handtekeningen of DMARC-uitlijning niet aan. Het risico is indirect: als een verouderd geflattend record legitieme mail op SPF laat falen, kan dat de DMARC-slaagpercentages naar beneden trekken. Houd het record opnieuw herleid en beide blijven gezond.

Hoeveel DNS-lookups gebruikt een geflattend SPF-record?

Een volledig geflattend record gebruikt nul DNS-lookups op het moment van evaluatie, omdat elk geautoriseerd IP-adres expliciet is vermeld als ip4:/ip6:. Als u enkele volatiele includes aanhoudt of IP-adressen in hulplabels splitst, voegt elk daarvan één lookup toe — houd het totaal simpelweg op of onder de RFC 7208-limiet van 10.

Kan ik ptr- en exists-mechanismen flatten?

Over het algemeen niet. ptr is verouderd, traag en zou simpelweg moeten worden verwijderd. exists: steunt doorgaans op runtime-macro’s (die MAIL FROM of HELO op het moment van controle evalueren), dus het kan niet worden herleid tot een statische IP-lijst. Behoud exists ongewijzigd, of isoleer het naar een gedelegeerd subdomein om de impact op de lookups te beperken.

Hoe vaak moet een geflattend SPF-record worden bijgewerkt?

Zo vaak als uw verzenders hun IP-adressen wijzigen. Interne mailservers kunnen wekenlang stabiel zijn, maar grote ESP’s en CDN’s kunnen dagelijks van adres wisselen. Daarom is handmatige flattening fragiel en scant AutoSPF elke 15 minuten opnieuw, waarbij het automatisch een bijgewerkt record publiceert telkens wanneer een upstream-IP-set verandert.

Wat gebeurt er als mijn geflattende record te groot wordt?

DNS-TXT-records zijn beperkt tot 255 tekens per string, en te grote records lopen het risico op UDP-fragmentatie. Als de geflattende IP-lijst te groot is, splits deze dan in hulplabels (die elk alleen ip4/ip6-vermeldingen bevatten) en neem ze op vanuit het hoofdrecord, of delegeer volatiele aanbieders naar een subdomein. Streef ernaar de totale response onder ~900 bytes te houden en de lookups ≤ 10.

Moet ik mijn SPF-record handmatig flatten of een tool gebruiken?

Handmatige flattening werkt voor een eenmalige oplossing, maar het kan aanbieders die IP-adressen roteren niet bijhouden — een met de hand geflattend record de-autoriseert stilzwijgend verzenders zodra een upstream-reeks verandert. Een beheerde tool zoals AutoSPF handelt de recursieve resolutie, de ontdubbeling, het groottebeheer en de continue herflattening voor u af, en dat is waarom het de aanbevolen aanpak is voor alles dat verder gaat dan één statische verzender.