SPF-record langer dan 255 tekens: 3 echte oplossingen (flattening, splitsen & compressie)

Gepubliceerd op 21 september 2026 · 5 min. leestijd · spFlat!

Eén character-string in een DNS-TXT-record mag niet langer zijn dan 255 octetten. Dat is een limiet van de DNS-codering (RFC 1035), geen SPF-uitvinding. Vlak je meerdere aanbieders af naar ip4:/ip6:-ranges op je eigen domein, dan bereik je die limiet snel, vaak nog eerder dan de limiet van 10 lookups.

De limiet van 255 octetten wordt vaak verkeerd begrepen. RFC 7208 verbiedt niet dat je een lange waarde splitst. Het verbiedt iets anders, en het praktische plafond ligt hoger dan 255 tekens. Hieronder lees je wat er echt misgaat en welke 3 oplossingen binnen de specificatie passen.

Wat de limiet van 255 tekens echt inhoudt

Een DNS-TXT-record wordt opgeslagen als een of meer character-strings. Elke string is maximaal 255 octetten lang. RFC 7208 §3.3 zegt: bevat één TXT-record meerdere strings, dan MOETEN ontvangers ze aan elkaar plakken zonder spaties toe te voegen. Zo kun je volgens de regels een SPF-beleid publiceren dat langer is dan 255 tekens.

Amazon SES doet dit al op amazonses.com: één TXT-record met twee strings tussen aanhalingstekens, die samen één v=spf1 … -all-beleid vormen. De huidige Outlook-SPF van Microsoft is op zichzelf al ~248 tekens lang, die van Google ~192. Zet je beide plus SendGrid als losse CIDR-blokken op je domein, dan zit je ruim boven de 255 tekens én boven een comfortabele grootte voor een DNS-antwoord via UDP.

Twee verschillende fouten worden vaak op één hoop gegooid als "te lang":

• Twee (of meer) v=spf1-TXT-records op dezelfde naam: RFC 7208 §3.2 maakt dat een PermError. Sommige DNS-panelen maken van een lange geplakte waarde een tweede record. Dat is de gevaarlijke splitsing.
• Eén TXT-record met meerdere strings: toegestaan. Het risico zit in het paneel, niet in de RFC: ontbrekende spaties bij het samenvoegen, of een totaal antwoord dat groter wordt dan de richtlijn van ~450 octetten / 512 bytes voor UDP in §3.4.

Oplossing 1: meerdere strings in één TXT-record (geldig, maar makkelijk fout te doen)

De weg die RFC 7208 bedoelt om voorbij 255 octetten per string te gaan, is werken met stukken tussen aanhalingstekens binnen één TXT-record:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com "
"include:sendgrid.net include:mailgun.org ~all"

Ontvangers plakken die strings aan elkaar zonder extra spatie. Zet de spatie aan het einde van het eerste stuk (zoals hierboven), anders plak je tokens aan elkaar en krijg je een syntaxfout. Route 53, Cloudflare en anderen beschrijven deze notatie met aanhalingstekens in hun documentatie; het openbare record van Amazon SES is een praktijkvoorbeeld.

Dit lost de limiet per string op. Het DNS-antwoord wordt er niet kleiner van, dus het beschermt je niet tegen UDP-truncatie. En maakt je paneel een tweede TXT-record aan in plaats van een tweede string, dan krijg je een PermError. Controleer na publicatie met dig TXT wat er werkelijk in DNS staat.

Oplossing 2: comprimeer het record (snelle winst, niet altijd genoeg)

Vaak kun je tekens besparen zonder de betekenis te veranderen:

• Verwijder redirect= of overbodige mechanismen als die er staan
• Laat ip4:/ip6:-vermeldingen weg die al door een include worden gedekt
• Verwijder dubbele vermeldingen (bijv. een ip4: die ook in een include zit)

Zo win je ruimte, maar je stelt het probleem alleen uit: elke nieuwe aanbieder duwt je weer richting beide limieten.

Oplossing 3: gehoste flattening (de oplossing die kort blijft én onder 10 lookups)

Elke opgeloste CIDR op je eigen domein zetten maakt het TXT-record meestal langer, niet korter. Het record dat klein blijft, is één include naar een flatteningdienst:

Voor (meerdere includes, geneste lookups of een enorme IP-lijst):

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org ~all

Na gehoste flattening (één lookup op je domein):

v=spf1 include:_yourdomain.spf.spflat.cloud ~all

Ontvangers doen één include-lookup. De lange IP-lijst staat op de hostnaam van de flatteningdienst, waar die over geldige TXT-strings kan worden verdeeld en actueel kan worden gehouden. Je gepubliceerde record blijft ruim onder 255 tekens én onder 10 lookups.

De conclusie

1. Meerdere strings in één TXT-record: correct volgens de RFC voor de stringlimiet van 255 octetten. Controleer dat je geen twee SPF-records hebt gepubliceerd en let op de UDP-grootte.
2. Compressie: prima als noodoplossing, maar schaalt niet.
3. Gehoste flattening met spFlat!: de duurzame oplossing. Eén korte include op je domein, lookups en grootte worden erachter afgehandeld. Gratis checker, daarna een proefperiode van 14 dagen.

Controleer je domein op spflat.cloud: bekijk het actuele aantal lookups (en of je tegen een PermError door de limiet van 10 lookups aanloopt) en of één extra aanbieder de evaluatie zou breken.