SPF record instellen voor domeineigenaren, IP of include kiezen

Publiceer één TXT-record met v=spf1 dat al je verzendbronnen autoriseert via ip4, ip6 of include-statements. Start met ~all (softfail) tijdens de testfase, controleer met een SPF-checker of je onder de 10 DNS-lookups blijft, en schakel pas over naar -all (hardfail) zodra alle legitieme afzenders geslaagd zijn. Zo voorkom je dat spoofers jouw domein misbruiken, zonder dat je eigen mail per ongeluk wordt geweigerd. Lees voor meer achtergrond over IP spoofing en waarom e-mailauthenticatie zoals SPF relevant is.

Kort samengevat:

• Zorg dat je SPF-record niet meer dan 10 DNS-lookups bevat, want een elfde lookup leidt automatisch tot een PermError en verstoringen in de e-mailbezorging.
• Gebruik ~all tijdens de testfase om spoofing te voorkomen, en schakel pas over naar -all nadat alle legitieme afzenders geslaagd zijn en je zeker bent dat geen legitieme mail wordt geweigerd.
• Verwijder oude of dubbel uitgegeven SPF-records, want meerdere v=spf1-regels voor hetzelfde domein maken het record ongeldig en veroorzaken fouten.
• Test altijd je SPF-record na publicatie en wijziging met een online checker en door headers te controleren, om zeker te zijn dat het correct wordt geëvalueerd door ontvangende servers.
• Vermijd mechanismen als ptr en mx waar mogelijk, omdat ze DNS-queries kosten en de limiet kunnen overschrijden, waardoor je tegen probleemlimieten aanloopt.

Inhoudsopgave

• Wat is een SPF-record en waarom heb je het nodig?
• Hoe evalueert een mailserver jouw SPF-record?
• SPF-syntaxis: welke mechanismen kosten DNS-lookups?
• Hoe voeg je een SPF TXT-record toe in DNS?
• Werkt je SPF-record echt? Zo test je het
• Wat zijn de meest voorkomende SPF-fouten?
• NLXS-praktijkperspectief op SPF-beheer
• Hulp nodig bij een waterdichte SPF-configuratie?
• Waar vind je de officiële SPF-documentatie?
• Wat het gedoe rond SPF eigenlijk verraadt
• Bronnen

Wat is een SPF-record en waarom heb je het nodig?

Een SPF-record is een gewoon TXT-record in je DNS dat altijd begint met de tag v=spf1. Daarna volgt een lijst van servers en diensten die namens jouw domein e-mail mogen versturen. Ontvangende mailservers controleren dit tijdens de SMTP-sessie tegen het domein in MAIL FROM of HELO, niet tegen het “van”-adres dat je in Outlook of Gmail ziet.

SPF lost maar één probleem op: wie mag mail sturen namens je domein op envelop-niveau. Het zegt niets over de inhoud of over het zichtbare afzenderadres, en daar zit meteen de belangrijkste beperking.

• SPF controleert alleen het envelopadres, niet het “From”-veld dat de ontvanger ziet.
• DKIM ondertekent de e-mailinhoud digitaal, onafhankelijk van de verzendende server.
• DMARC combineert beide resultaten en bepaalt wat er gebeurt bij een mismatch.

Zonder DKIM en DMARC blijft SPF een half verhaal. Wil je die combinatie in één keer goed neerzetten, lees dan ook hoe DANE, DKIM en SPF samen zakelijke e-mail beveiligen.

Hoe evalueert een mailserver jouw SPF-record?

Een ontvangende server leest het SPF-record strikt van links naar rechts. Zodra een mechanisme matcht met het IP-adres van de verzendende server, stopt de evaluatie en geldt de bijbehorende qualifier als uitslag. Dit heet first-match wins, en het verklaart waarom de volgorde van je mechanismen er echt toe doet.

Vier qualifiers bepalen het resultaat: + betekent pass (toegestaan, en de standaard als je niets opgeeft), - betekent fail (hardfail, weigeren), ~ betekent softfail (accepteren maar markeren) en ? betekent neutral (geen uitspraak). Een record als v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all autoriseert eerst dat IP-bereik, dan alles wat Google’s SPF-record toestaat, en behandelt de rest als verdacht.

Loopt de evaluatie mis door foutieve syntax, dubbele v=spf1-records voor hetzelfde domein of te veel DNS-lookups, dan levert dat een PermError op. RFC 7208 stelt expliciet dat een domein maximaal één SPF-record mag publiceren; meerdere versies naast elkaar zijn ongeldig, ook als ze inhoudelijk overeenkomen.

SPF-syntaxis: welke mechanismen kosten DNS-lookups?

Niet elk mechanisme in je SPF-record is even duur. ip4 en ip6 vereisen geen enkele DNS-lookup, ze worden direct vergeleken. a, mx, include en ptr kosten daarentegen wél een lookup, en mx kan er zelfs meerdere veroorzaken als het domein meerdere mailservers heeft.

Statistiek om te onthouden: SPF-evaluatie staat maximaal 10 DNS-lookups toe per record, inclusief geneste includes. De elfde lookup levert automatisch een PermError op, ook als je verder alles correct hebt geconfigureerd.

Een paar voorbeelden die je in de praktijk tegenkomt:

• Eenvoudig: v=spf1 ip4:198.51.100.10 -all (één server, strikte afwijzing).
• Met een externe dienst: v=spf1 include:_spf.google.com ~all (alles wat Google’s eigen record toestaat).
• Combinatie: v=spf1 ip4:198.51.100.0/24 include:sendgrid.net include:_spf.google.com ~all.

Elke include trekt in feite een heel ander SPF-record naar binnen, met zijn eigen lookups. Stapel je vier of vijf verzendplatforms op deze manier, dan zit je sneller tegen de limiet dan je denkt. DNSimple raadt daarom aan om waar mogelijk mx en ptr te vermijden en stabiele IP-reeksen direct met ip4 of ip6 op te nemen. Het ptr-mechanisme is bovendien al jaren afgeraden vanwege de onvoorspelbare belasting die het op DNS-servers legt.

Hoe voeg je een SPF TXT-record toe in DNS?

De basisregel: er bestaat maar één juiste plek voor SPF, en dat is een TXT-record op het kale domein, niet op een subdomein zoals www. Zo pak je het stap voor stap aan.

1. Inventariseer al je verzendbronnen. Denk aan je hostingprovider, een marketingtool zoals Mailchimp, je CRM, en facturatiesoftware die automatisch mail verstuurt. Vergeet interne systemen niet die notificaties sturen.
2. Bouw de SPF-string op. Begin altijd met v=spf1, voeg per bron een ip4, ip6 of include toe, en sluit af met een all-mechanisme. Controleer de syntax handmatig of met een validator voordat je publiceert.
3. Publiceer het record. Ga naar het DNS-beheerpanel van je hostingprovider of domeinregistrar en voeg één TXT-record toe op het hoofddomein. Verwijder eventuele oude of dubbele SPF-records volledig, anders ontstaat er een PermError.
4. Test met ~all voordat je verhardt. Laat het record enkele dagen tot een week draaien met softfail, controleer je logs en headers, en schakel pas over naar -all zodra je zeker weet dat geen legitieme afzender wordt gemist.

Pro-tip: Werk je met meerdere merken of afdelingen die elk hun eigen verzendplatform gebruiken? Zet dan een apart, beheerd SPF-record op een subdomein en verwijs daarnaar met een redirect=modifier. Zo blijft je hoofddomein overzichtelijk en beperk je wijzigingen tot dat ene subdomein.

Werkt je SPF-record echt? Zo test je het

Publiceren is niet het eindpunt. Test altijd meteen na publicatie, en herhaal die controle na elke wijziging aan je verzendplatforms.

• Gebruik een online SPF-checker die het record parseert en het aantal DNS-lookups optelt, zodat je vóór de PermError ziet hoeveel ruimte je nog hebt.
• Verstuur een testmail naar een account waar je de volledige headers kunt inspecteren, en zoek naar het Received-SPF-veld met de uitslag: pass, softfail, fail of PermError.
• Herhaal de test bij elke nieuwe marketingtool, CRM-koppeling of factuursysteem dat je toevoegt, want elke nieuwe include telt mee in de lookup-limiet.

Een record dat er in de DNS-editor correct uitziet, hoeft in de praktijk niet foutloos te evalueren. Alleen een echte testmail met headeranalyse laat zien wat een ontvangende server werkelijk berekent.

Wat zijn de meest voorkomende SPF-fouten?

De meeste problemen komen terug op een handjevol oorzaken, en ze zijn allemaal te voorkomen met een korte checklist.

• Twee v=spf1-records naast elkaar. Dit gebeurt vaak wanneer een nieuwe marketingtool automatisch een eigen TXT-record toevoegt zonder het bestaande te overschrijven. Resultaat: een gegarandeerde PermError.
• De 10-lookup-limiet overschreden door te veel includes of een zwaar mx-mechanisme. PowerDMARC noemt dit een van de meest onderschatte oorzaken van mislukte e-mailbezorging.
• Verouderde includes van leveranciers die je niet meer gebruikt. Controleer periodiek, minstens elk kwartaal, of elke include nog een actieve verzendbron vertegenwoordigt.

Pro-tip: Overweeg SPF-afvlakking of een gehoste SPF-oplossing zodra je structureel tegen de lookup-limiet aanloopt door veel derde partijen. Dat verlicht het onderhoud, maar maakt je wel afhankelijk van een externe partij die IP-wijzigingen tijdig doorvoert.

NLXS-praktijkperspectief op SPF-beheer

Bij klanten zoals TU Eindhoven en JCI Breda draait SPF-beheer nooit om één record en klaar. NLXS inventariseert eerst alle verzendbronnen, bouwt daarna een werkend record, test het met ~all, en monitort structureel of leveranciers hun IP-reeksen wijzigen zonder dat te melden.

Dat laatste is precies waar het vaak misgaat: een marketingtool wisselt IP’s, niemand controleert de SPF-impact, en drie maanden later belanden facturen in de spamfolder. Onderdeel van ICT-diensten uitbesteden is precies dit soort stille controle, zodat jij niet zelf elke kwartaal je DNS moet nalopen.

Hulp nodig bij een waterdichte SPF-configuratie?

Een SPF-record zelf publiceren is één ding. Zorgen dat het record maanden later nog klopt, terwijl je marketingtool, CRM en facturatiesysteem allemaal hun eigen IP’s wijzigen, is een ander verhaal. NLXS neemt die controle structureel over als onderdeel van betrouwbare webhosting, inclusief DNS-beheer dat meegroeit met je verzendplatforms.

Twijfel je of je huidige DNS-configuratie nog klopt, of loop je vast op een PermError die je niet kunt herleiden? Vraag een gratis ICT-scan aan. NLXS controleert dan niet alleen je SPF-record, maar de volledige e-mailauthenticatie inclusief DKIM en DMARC, en levert binnen een dag een concreet advies zonder verrassingen in de kosten achteraf.

Waar vind je de officiële SPF-documentatie?

Voor de formele specificatie en de exacte lookup-regels raadpleeg je RFC 7208. Werk je met Microsoft 365, dan biedt de Microsoft-documentatie over SPF scenario’s op maat, terwijl Google’s SPF-richtlijnen een praktische aanvulling vormen.

Wat het gedoe rond SPF eigenlijk verraadt

De meeste artikelen over SPF behandelen het als een eenmalige technische taak: record aanmaken, publiceren, klaar. Dat beeld klopt niet, en het is precies waarom zoveel bedrijven jaren later ontdekken dat hun SPF-record al lang kapot is zonder dat iemand het merkte.

Wat mij opvalt: de 10-lookup-limiet wordt meestal gepresenteerd als een technisch randgeval, terwijl het in de praktijk de belangrijkste bottleneck is voor elk bedrijf dat meer dan twee of drie verzendplatforms gebruikt. Elke nieuwe SaaS-tool die automatisch mail verstuurt, elke marketingcampagne via een extern platform, ze voegen allemaal een include toe die niemand later weer verwijdert. Na een paar jaar groeien bedrijven organisch naar een record dat tegen de limiet aanschuurt, zonder dat er één duidelijk moment was waarop dat fout ging.

De echte les is dus niet “hoe stel ik SPF in”, maar “wie controleert dit over zes maanden nog”. Een record dat vandaag perfect werkt, is over een jaar net zo goed als de laatste keer dat iemand het heeft gecontroleerd.

— Ken

Bronnen

• RFC 7208 – Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
• SPF record syntax: validation reference – DNSimple
• SPF Permerror: limiet voor te veel DNS-lookups herstellen – PowerDMARC

Aanbevelingen

• Jouw host voor Domeinverificatie
• DANE, DKIM en SPF voor veilige zakelijke e-mail
• DNS-records uitleg: wat ze doen en hoe je ze instelt