SPF Record Checker en Generator

Hoe controleer je een SPF-record

1. Vul hierboven een domeinnaam in. Een compleet e-mailadres mag ook; de tool gebruikt alleen het domeingedeelte.
2. Klik op SPF-record controleren. De check leest het huidige record uit in openbare DNS, precies zoals een ontvangende mailserver dat doet.
3. Lees eerst het overzicht. Dat toont direct of het record geldig is, waarschuwingen bevat of defect is.
4. Bekijk vervolgens de lijst met eventuele problemen. Elk punt legt uit wat er aangepast moet worden.
5. Daaronder wordt elk onderdeel van het record uitgelegd met de bijbehorende DNS-lookups. Vouw een include open om te zien wat de service erachter autoriseert.

De link in de adresbalk herhaalt deze controle. Je kunt deze URL delen met een collega of je hostingprovider. Let op een beperking: een ontvangende server toetst SPF aan het IP-adres van de verzendende server. Deze tool heeft geen e-mailbericht om te analyseren en valideert het record zelf in DNS. Dynamische SPF-macro’s die afhangen van het verzendende IP kunnen niet live worden geëvalueerd.

Wat is een SPF-record?

Een SPF-record is een TXT-record in de DNS van een domein. Het vermeldt welke mailservers namens dat domein e-mail mogen versturen. SPF staat voor Sender Policy Framework en de officiële specificaties zijn vastgelegd in RFC 7208. Een domein dat Google Workspace gebruikt heeft doorgaans een record zoals dit:

v=spf1 include:_spf.google.com ~all

v=spf1 geeft aan dat het om een SPF-record gaat. include:_spf.google.com autoriseert alle verzendende servers uit de lijst van Google zelf. ~all verzoekt ontvangende servers om e-mail van niet-vermelde servers als verdacht te behandelen.

Wanneer een e-mail binnenkomt, leest de ontvangende server het domein uit het Return-Path (de envelope sender). De server haalt het SPF-record van dat domein op en controleert of het IP-adres van de afzender daarin voorkomt. SPF controleert niet het zichtbare Van-adres (From header). Daarom werkt SPF nauw samen met DKIM en DMARC. Lees SPF, DKIM en DMARC uitgelegd om te zien hoe deze drie standaarden elkaar aanvullen.

Sinds februari 2024 stelt Gmail strenge eisen aan SPF of DKIM voor alle verzenders, en beide voor bulkverzenders. Yahoo hanteert vergelijkbare regels.

Wat elk onderdeel van het SPF-record betekent

Een SPF-record bestaat uit termen gescheiden door spaties. Ontvangende servers lezen van links naar rechts en stoppen bij de eerste term die overeenkomt met de verzendende server.

Elk mechanisme kan beginnen met een kwalificatie (qualifier) die het resultaat bepaalt bij een match. + staat voor Pass en is de standaardwaarde (wordt meestal weggelaten). - staat voor Fail, ~ voor Softfail en ? voor Neutral. Daarom kan de term all eindigen als -all, ~all of ?all.

De mechanismen zijn hoofdletterongevoelig: Include: werkt exact hetzelfde als include:. RFC 7208 adviseert elk record af te sluiten met all of redirect. Zonder afsluitende term krijgen niet-vermelde servers een neutraal resultaat.

De strikte limiet van 10 DNS-lookups

Elke include, a, mx, ptr, exists en redirect dwingt de ontvangende mailserver om een DNS-opdracht uit te voeren. RFC 7208 staat maximaal 10 van deze lookups toe. Lookups binnen geneste include-records tellen mee, waardoor één enkele include al meerdere lookups kan verbruiken. ip4, ip6 en all kosten geen lookups. Als een record meer dan 10 lookups vereist, stopt de ontvangende server met een Permerror en faalt de SPF-controle.

De limiet van 10 is sneller bereikt dan gedacht. We hebben in openbare DNS de kosten van veelgebruikte diensten gemeten: Google Workspace kost 1 lookup, Microsoft 365 kost 1 lookup, Salesforce 2, Mailgun 5 en Freshdesk 7. Een organisatie op Google Workspace die Mailgun en Freshdesk toevoegt, zit al op 13 lookups. Een onderzoek uit 2024 naar SPF-records op .com, .net, .org en .se toonde aan dat 6,5% meer dan 10 lookups nodig had. De records van slechts twee hostingproviders veroorzaakten 83,7% van deze overschrijdingen.

Bovendien veranderen deze kosten doorlopend. De include van Google kostte tot december 2025 4 lookups, totdat Google de geneste includes verving door een platte lijst. Veel handleidingen en generators tonen nog het oude getal 4. Onze tool telt bij elke controle de actuele actieve lookups in DNS.

Het overschrijden van de limiet laat e-mail niet altijd direct overal falen. Zoals Microsoft toelicht, evalueren servers van links naar rechts en stoppen ze bij de eerste match. E-mail van een provider die vooraan staat kan slagen, terwijl een latere provider faalt. Dit zorgt voor willekeurige bezorgproblemen, tenzij je het hele record doorlicht.

Er geldt nog een tweede limiet: lookups die niets opleveren (void lookups), zoals een include die verwijst naar een opgeheven domein. RFC 7208 schrijft voor dat ontvangende servers moeten stoppen na 2 opeenvolgende void lookups.

Onder de 10 DNS-lookups blijven

1. Verwijder includes van verouderde marketingtools en diensten die je niet meer gebruikt.
2. Verwijder includes die leveranciers niet langer vereisen. Mailchimp, Postmark, Brevo en Klaviyo hebben geen include meer nodig op je hoofddomein. SendGrid en Amazon SES routeren via een subdomein. Bekijk de lijst hieronder.
3. Gebruik ip4 en ip6 voor je eigen mailservers in plaats van a of mx. RFC 7208 beveelt deze volgorde aan en IP-adressen kosten 0 DNS-lookups.
4. Verstuur bulk- of marketingmail via een subdomein zoals nieuwsbrief.voorbeeld.nl. Elk subdomein heeft een eigen SPF-record en een eigen quotum van 10 lookups.

Sommige diensten bieden SPF-flattening aan, waarbij includes worden omgezet in directe IP-adressen. Dit bespaart lookups, maar externe providers wijzigen hun IP-reeksen regelmatig. Een platgeslagen record wordt dan snel ongeldig. Microsoft ontraadt flattening voor dynamische clouddiensten en adviseert minimaal elk kwartaal een handmatige audit.

SPF-includes voor Google Workspace, Microsoft 365 en andere diensten

Dit zijn de officiële include-waarden uit de documentatie van veelgebruikte diensten, inclusief het aantal DNS-lookups zoals gemeten op 12 oktober 2026. Controleer altijd de documentatie van je eigen account voor regionale afwijkingen.

HubSpot geeft elk account een unieke include eindigend op hubspotemail.net. Kopieer deze uit je HubSpot-instellingen. Deze kost 1 lookup.

Diensten die meestal geen SPF-include nodig hebben

SPF wordt gecontroleerd op het Return-Path-adres en niet op het zichtbare Van-adres. Veel moderne verzendplatforms gebruiken hun eigen domein voor bounces of een CNAME-subdomein. Een include op je hoofddomein kost alleen onnodige DNS-lookups.

• Mailchimp. Mailchimp configureert authenticatie via CNAME-records voor DKIM.
• Postmark. Postmark gebruikt zijn eigen Return-Path-domein.
• Brevo. Brevo vereist geen SPF-record op het hoofddomein behalve bij dedicated IP.
• Klaviyo. Klaviyo vereist geen SPF-include op het hoofddomein.
• SendGrid. SendGrid plaatst SPF op een specifiek subdomein tijdens domeinauthenticatie.
• Amazon SES. SES vereist dit alleen op een aangepast MAIL FROM-subdomein.

Onze checker markeert deze overbodige includes direct als ze in je record staan.

Hoe maak je een SPF-record aan

Gebruik het tabblad Aanmaken hierboven als interactieve SPF-generator. Vink de diensten aan die namens jouw domein mail versturen; de tool stelt het record samen en bewaakt het aantal DNS-lookups. Laad een bestaand record eerst in om het aan te vullen zonder instellingen te overschrijven. Volg deze stappen:

1. Breng alle verzendende bronnen in kaart: e-mailsuite, nieuwsbrieven, CRM, helpdesk, facturatie en websiteformulieren. DMARC-rapporten tonen verzenders die je over het hoofd hebt gezien.
2. Zoek de officiële include-waarde van elke dienst op of vink de dienst aan in de tool. Gebruik voor eigen servers directe IP-adressen.
3. Kies de afsluiting: ~all of -all. Het volgende gedeelte legt het verschil uit.
4. Publiceer het als één enkel TXT-record op het hoofddomein (@ in je DNS-paneel). Als er al een record staat dat begint met v=spf1, pas dat dan aan in plaats van een tweede toe te voegen.
5. Wacht enkele minuten op DNS-synchronisatie en controleer het domein opnieuw met deze SPF-checker.

Elk verzendend subdomein heeft een eigen SPF-record nodig, omdat subdomeinen het record van het hoofddomein niet overnemen. Een domein dat nooit mail verstuurt moet beschermd worden met: v=spf1 -all. RFC 7208 noemt dit een bewezen best practice tegen spoofing. Het Britse NCSC adviseert om bij inactieve domeinen ook DMARC met p=reject en een Null MX-record in te stellen.

Een record van meer dan 255 tekens moet binnen hetzelfde TXT-record worden opgesplitst in meerdere strings tussen aanhalingstekens. Ontvangende servers voegen deze strings zonder spaties samen; plaats spaties dus binnen de aanhalingstekens. Raadpleeg je DNS-provider voor de exacte invoer bij lange waarden.

~all of -all: welke afsluiting moet je kiezen

Grote e-mailproviders hebben hier verschillende visies op:

• Google adviseert ~all (Softfail).
• Het M3AAWG, een mondiaal samenwerkingsverband van e-mailproviders, raadt ~all aan zodat ontvangende servers mail niet weigeren vóórdat DMARC is geëvalueerd.
• Microsoft adviseert -all (Fail), mits DKIM en DMARC volledig zijn ingericht.

Het gevaar van -all is dat sommige ontvangende servers berichten tijdens de SMTP-verbinding direct weigeren, nog vóór DMARC wordt getoetst. De officiële standaard RFC 9989 (DMARC 2026) benadrukt dat deze geweigerde berichten niet in DMARC-rapporten verschijnen, waardoor afleverproblemen onzichtbaar blijven.

In de praktijk is ~all de veiligste keuze voor actieve domeinen, zeker zolang je nog niet alle verzendbronnen in kaart hebt. Met een actief DMARC-beleid op quarantine of reject bepaalt DMARC de afhandeling. Gebruik -all voor domeinen die nooit e-mail verzenden. Gebruik nooit +all (laat iedereen toe) en vermijd ?all (neutral, gelijk aan geen beveiliging).

Wat betekenen de resultaten van de SPF-check

Ontvangende mailservers hanteren gestandaardiseerde statussen voor SPF-uitkomsten in de Authentication-Results headers en DMARC-rapporten :

Veelvoorkomende SPF-fouten en oplossingen

Een onderzoek uit 2023 naar 12 miljoen populaire domeinen wees uit dat 56,5% een SPF-record had en dat 2,9% van die records ernstige fouten bevatte. De meest voorkomende fout was een include of redirect naar een domein zonder SPF, op de voet gevolgd door het overschrijden van de lookup-limiet.

Twee SPF-records op hetzelfde domein

Dit ontstaat vaak wanneer een handleiding aangeeft “voeg dit TXT-record toe” en er een tweede record wordt aangemaakt naast het bestaande. Twee records leveren direct een Permerror op. Voeg alle termen samen in één enkel TXT-record dat begint met v=spf1 en eindigt met één all.

Een include die nergens naar verwijst

Als een include verwijst naar een domein zonder geldig SPF-record, faalt de hele controle met een Permerror. Dit ontstaat door typefouten of opgeheven leveranciers. Verwijder de include of werk de waarde bij.

+all, ?all of geen afsluitend all-mechanisme

+all autoriseert het hele internet en schakelt bescherming uit. ?all of het weglaten van all geeft een neutraal resultaat. Sluit je record altijd af met ~all of -all.

ptr-mechanisme in het record

RFC 7208 raadt ptr met klem af. Het is traag, kost een lookup en is storingsgevoelig bij DNS-problemen. Vervang ptr door directe ip4- en ip6-vermeldingen.

Typefouten en verkeerde leestekens

Een spatie na een dubbele punt, een onvolledig IPv4-adres of een onbekend trefwoord veroorzaken een Permerror. Een subtielere fout is include=example.com met een gelijkheidsteken: dit wordt genegeerd als onbekende modifier waardoor de dienst nooit geautoriseerd raakt. Onze checker spoort dit direct op.

Drie hardnekkige fabels over SPF

• “Een SPF-record mag geen hoofdletters bevatten.” RFC 7208 specificeert dat mechanismen volledig hoofdletterongevoelig zijn.
• “Een SPF-record mag maximaal 255 tekens lang zijn.” De limiet van 255 tekens geldt per afzonderlijke string. Langere records worden opgedeeld in meerdere aaneengesloten strings binnen hetzelfde DNS TXT-record.
• “Je mag maximaal 10 include-mechanismen gebruiken.” De limiet van 10 geldt voor het totale aantal gegenereerde DNS-lookups, niet voor het aantal geschreven include-termen.

SPF als onderdeel van e-mailauthenticatie

Een SPF-pass heeft grenzen. In de studie uit 2023 autoriseerde 34,7% van de domeinen indirect meer dan 100.000 IP-adressen. Bovendien faalt SPF bij automatische e-mail forwarding, omdat de doorsturende server niet in jouw SPF-record staat.

DKIM vangt dit op met een cryptografische handtekening op het bericht zelf, die bij doorsturen intact blijft. DMARC controleert of het domein in het Van-adres overeenkomt met het domein dat door SPF of DKIM is goedgekeurd, en vertelt ontvangende servers wat ze bij falen moeten doen. Configureer de overige protocollen met de DKIM generator en de DMARC generator. Gebruik de MX lookup om je inkomende servers te controleren.

Authenticatie helpt niet tegen verzending naar niet-bestaande adressen. Die leiden tot bounces die je reputatie beschadigen. Controleer losse adressen met de e-mail checker of valideer complete lijsten met de bulk e-mail verifier. Zoek je een beknopte definitie voor je team, bekijk dan het SPF-record overzicht in de begrippenlijst.