Een veilig SPF-record aanmaken

Een veilig SPF-record (Sender Policy Framework) bevat elke server die namens je domein mail mag versturen, blijft onder de limiet van 10 DNS-lookups en eindigt op -all, zodat niet-geautoriseerde afzenders worden geweigerd in plaats van alleen gemarkeerd. Gaat een van die drie mis, dan weigeren ontvangende mailservers legitieme mail of laten ze gespoofte mail ongemerkt door.

SPF is gedefinieerd in RFC 7208 (die de oudere RFC 4408 vervangt) en wordt gepubliceerd als een gewoon DNS-TXT-record: er is geen apart SPF-recordtype meer dat actief wordt gebruikt. In deze handleiding bouw je stap voor stap een record dat zowel correct als robuust is.

Wat is een SPF-record precies?

Een SPF-record is een TXT-record op je domein dat ontvangende mailservers vertelt welke IP-adressen en hosts mail mogen versturen met jouw domein in het envelope-from-adres (Return-Path). Als iemand je mailt en beweert you@yourdomain.com te zijn, controleert de ontvangende server het SPF-record van je domein om te zien of het verzendende IP-adres op de goedgekeurde lijst staat.

Een eenvoudig record ziet er zo uit:

v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

Elk onderdeel is een mechanisme dat van links naar rechts wordt geëvalueerd:

Met onze gratis DNS-lookuptool kun je controleren wat een domein op dit moment publiceert, en met de SPF-generator bouw je vanaf nul een syntactisch geldig record.

Welke mechanismen en qualifiers moet je gebruiken?

SPF-mechanismen beschrijven wat er gecontroleerd wordt; qualifiers beschrijven wat er moet gebeuren als een controle overeenkomt.

Mechanismen:

• ip4 / ip6 — komt overeen met een specifiek adres of CIDR-blok, kost geen lookup
• a — komt overeen met het eigen A/AAAA-record van het domein
• mx — komt overeen met hosts uit de MX-records van het domein
• include — haalt het SPF-beleid van een ander domein op (gebruikelijk voor Google Workspace, Microsoft 365 en ESP's)
• exists — komt overeen als een DNS-lookup een willekeurig A-record oplevert
• ptr — komt overeen op basis van reverse-DNS-lookups

Qualifiers, die vóór een mechanisme staan:

• + Pass (standaard, wordt zelden expliciet geschreven)
• - Fail (hard fail: weigeren)
• ~ SoftFail (accepteren maar markeren, vaak in de spammap)
• ? Neutral (geen echt oordeel: liever vermijden)

WarningVermijd ptr volledig. RFC 7208 markeert het expliciet als niet aanbevolen, omdat reverse-DNS-lookups traag en onbetrouwbaar zijn en zwaar drukken op de lookuplimiet.

Gebruik voor de afsluitende catch-all -all zodra je zeker weet dat elke legitieme bron op de lijst staat. ~all is een redelijke tussenstap zolang je nog afzenders aan het opsporen bent, maar als permanent beleid ondermijnt het het hele nut van SPF. En een verdwaalde +all geeft letterlijk iedereen toestemming om je domein te spoofen. Beschouw +all als een kritieke misconfiguratie, niet als een soepele instelling.

De limiet van 10 lookups: de valkuil die de meeste SPF-records breekt

Hier gaat het bij de meeste teams mis. RFC 7208 §4.6.4 beperkt een SPF-evaluatie tot 10 DNS-lookups per controle. Elke include, a, mx, ptr, exists en redirect telt mee voor die limiet; ip4 en ip6 niet, omdat die geen lookup nodig hebben.

Kom je boven de 10, dan is het resultaat een PermError, en die behandelen ontvangende servers als een kapotte of mislukte controle, niet als een pass. Dit is een heel gebruikelijke storing: een domein voegt Google Workspace toe, daarna Microsoft 365 voor een gedeelde inbox, vervolgens een marketingplatform, een CRM en een helpdesktool, elk met een eigen geneste include:-keten. Niemand merkt dat het totale aantal lookups ongemerkt boven de 10 uitkomt, totdat de deliverability stilletjes daalt.

Twee dingen maken dit nog erger:

• mx is een verborgen vermenigvuldiger. Gebruik je mx in je SPF-record, dan kost dat één lookup voor de MX-query zelf, plus één extra lookup voor elke MX-host die daaruit terugkomt.
• Void lookups zijn beperkt tot 2. Een void lookup is elk mechanisme dat niets oplevert: een include: die verwijst naar een host zonder SPF-record, of een a/mx voor een naam die niet meer bestaat. Meer dan twee daarvan levert ook een PermError op, dus één uitgefaseerde afzender die je vergeten bent te verwijderen kan het hele record ongemerkt breken.

Blijf onder de tien en houd je SPF-record compact

Meer dan 10 lookups krijg je niet, dus het record moet je zorgvuldig beheren in plaats van er alleen maar dingen aan toe te voegen:

• Controleer je include:-ketens. Elke provider die je toevoegt, brengt zijn eigen geneste lookups mee. Maak een lijst van elke afzender die echt mail verstuurt als jou en schrap de rest: het oude CRM, de marketingtool uit de proefperiode, het nieuwsbriefplatform waar je vorig jaar mee bent gestopt.
• Kies liever ip4:/ip6: dan mx en a. Statische IP-mechanismen kosten nul lookups. Publiceert een afzender vaste IP-adressen, zet die dan rechtstreeks in je record in plaats van te leunen op mx, dat zich vermenigvuldigt met elke MX-host die het oplevert.
• Wees voorzichtig met flattening. "SPF flattening" zet je includes om in kale IP-adressen om onder de limiet te blijven, maar die IP-adressen zijn van je providers en veranderen zonder waarschuwing. Een geflattend record moet je dus monitoren, anders begint het ongemerkt legitieme mail te weigeren.

Sluit af met een hard fail, zodra je het zeker weet

Het laatste mechanisme bepaalt het beleid voor alles wat niet expliciet is toegestaan:

• ~all (softfail) vertelt ontvangers: "waarschijnlijk niet van ons, maar accepteer het wel". Dat is de veilige standaard zolang je nog afzenders aan het opsporen bent.
• -all (hardfail) vertelt ze: "staat het niet op deze lijst, weiger het dan". Dat is de veilige eindsituatie, maar stap er pas op over als je zeker weet dat het record compleet is, anders bounce je je eigen mail.

En SPF is maar één poot van de kruk: publiceer ook DKIM, zodat je mail cryptografisch wordt ondertekend, en een DMARC-beleid, zodat ontvangers weten wat ze moeten doen als een controle mislukt. Zo krijg je bovendien rapporten wanneer iemand je spooft.

Niet instellen en vergeten

Een veilig SPF-record is geen eenmalige klus. Afzenders komen en gaan, providers wijzigen hun IP-adressen en het aantal lookups loopt vanzelf op. Niets daarvan kondigt zichzelf aan: je merkt het pas als de deliverability daalt. De DNS Security Advisor van InfraNest bewaakt SPF, DKIM en DMARC voor elk domein dat je beheert, telt je actuele lookups en waarschuwt je voordat je over de tien gaat of een void lookup het record breekt. Zo blijft "veilig" ook echt veilig.