Gratis SPF-record- controle

Wat is SPF en waarom is het in 2026 belangrijk?

Sender Policy Framework (SPF) is een van de drie pijlers van moderne e-mailauthenticatie, naast DKIM en DMARC. Gedefinieerd in RFC 7208, laat het een domeinhouder een lijst geautoriseerde verzendservers in DNS publiceren zodat ontvangende mailproviders kunnen verifiëren dat inkomende berichten daadwerkelijk komen van waar ze beweren. Zonder SPF kan iedereen e-mail versturen die zich voordoet als jouw domein — en moderne providers zoals Gmail en Yahoo dumpen niet-geauthenticeerde mail stilzwijgend in spam.

In 2026 is SPF niet langer optioneel. De bulkverzendervereisten van Gmail en Yahoo (uitgerold in 2024 en sindsdien aangescherpt) verplichten SPF en DKIM voor elk domein dat meer dan 5.000 berichten per dag verstuurt. Microsoft 365 en Apple Mail handhaven vergelijkbare standaarden. Een misgeconfigureerd of ontbrekend SPF-record vertaalt zich nu direct in spamfolderplaatsing, gederfde omzet en merkschade. Het goede nieuws: SPF is een van de goedkoopste, snelste deliverability-winsten — een correct geconfigureerd TXT-record kan inboxplaatsing van de ene op de andere dag met 20–40% verhogen.

Anatomie van een SPF-record

Elk SPF-record is één DNS TXT-record met door spaties gescheiden mechanismen. Hier is een typisch voorbeeld voor een domein dat Google Workspace en Mailgun gebruikt:

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.10 ~all

• v=spf1 — de versietag. Elk SPF-record moet hiermee beginnen. Er is geen v=spf2; het protocol is in meer dan tien jaar niet veranderd.
• ip4: / ip6: — ip4: en ip6: — expliciet toegestane IP-adressen of CIDR-bereiken. ip4:203.0.113.0/24 autoriseert een heel subnet. Dit zijn de goedkoopste mechanismen omdat ze nul DNS-lookups triggeren.
• include: — haalt het SPF-record van een ander domein binnen. include:_spf.google.com vertelt ontvangers ook mail te accepteren van elke server die Google voor zijn tenants autoriseert. Elke include telt als één DNS-lookup, en eventuele geneste includes tellen ook.
• a / mx — a en mx — autoriseren de IP-adressen van het A-record (de webserver van het domein) of de MX-records (de inkomende mailservers). Spaarzaam gebruiken: veel domeinen hebben webservers die geen mail zouden moeten versturen.
• Qualifiers bepalen het resultaat. ~all (soft fail) markeert niet-matchende mail als verdacht maar accepteert hem — handig tijdens testen. -all (hard fail) weigert niet-matchende mail direct — de aanbevolen productie-instelling. ?all (neutraal) doet niets en is nutteloos. +all autoriseert expliciet elk IP op het internet — gebruik dit nooit; het staat gelijk aan je voordeur openzetten met een bordje "neem aub mijn identiteit aan".

5 veelvoorkomende SPF-fouten en hoe je ze oplost

Te veel DNS-lookups (RFC 7208-limiet: 10)

SPF staat maximaal 10 DNS-lookups per evaluatie toe. Elke include:, a:, mx:, exists: en redirect= telt mee. Geneste includes tellen ook — bevat include:_spf.google.com zelf vier includes, dan zijn dat vijf lookups voor dat ene mechanisme. De limiet overschrijden triggert een PermError en de meeste ontvangers behandelen dat als een hard fail. Fix: audit elke include met onze SPF-checker hierboven, verwijder ongebruikte vendors, vervang include: door ip4:-blokken waar de vendor statische ranges publiceert, of gebruik een flattening-service.

PermError: SPF-recordsyntax ongeldig

Veelvoorkomende syntaxfouten zijn het ontbreken van het v=spf1-prefix, puntkomma's gebruiken in plaats van spaties, ongewenste tekens overhouden van copy-paste, of de qualifier (~all) midden in het record zetten in plaats van aan het eind. Ontvangers zien dit als een configuratiefout en laten SPF direct zakken. Fix: plak het exacte record in een validator, zoek naar verborgen Unicode-tekens, en zorg dat mechanismen door spaties zijn gescheiden met de all-qualifier als laatste.

Meerdere SPF-records (moeten samengevoegd)

RFC 7208 verbiedt expliciet meer dan één v=spf1 TXT-record op hetzelfde domein. Dit gebeurt meestal wanneer het ene team Google Workspace toevoegt en het andere SendGrid zonder af te stemmen. Ontvangers die twee records zien werpen een PermError. Fix: combineer in één enkel record. v=spf1 include:_spf.google.com include:sendgrid.net ~all vervangt beide losse records.

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

Forwarding breekt SPF

Wanneer een ontvanger je bericht doorstuurt naar een ander adres verandert het verbindende IP, maar de Return-Path blijft van jou — en SPF faalt op de doorstuurhop. Dit is by design maar veroorzaakt false negatives. Fix: vertrouw op DKIM voor alignment (DKIM overleeft forwarding), implementeer SRS op uitgaande forwarders die je beheert, en accepteer dat SPF alleen niet voldoende is — wat precies de reden is waarom DMARC SPF óf DKIM vereist, niet beide.

Verwarring over subdomein-erfelijkheid

SPF wordt niet geërfd. mail.example.com en example.com zijn aparte hosts en hebben aparte SPF-records nodig. Een veelvoorkomende bug: bedrijf publiceert SPF op de apex maar een marketingtool verstuurt vanuit updates.example.com — ontvangers zien geen SPF-record op het subdomein en je mail faalt op alignment. Fix: publiceer v=spf1 -all op elk subdomein dat nooit mail zou moeten versturen, en een echt beleid op elk subdomein dat dat wel doet.

Stapsgewijze SPF-setup

1. Inventariseer alle verzendservices

Lijst elk systeem dat mail verstuurt namens jouw domein: marketingplatforms (Mailchimp, HubSpot), transactionele providers (SendGrid, Postmark, Resend), CRM's, supportdesks (Zendesk, Intercom), payroll, payment processors en je eigen applicatieservers. Mis je er één, dan wordt legitieme mail geweigerd zodra je je record publiceert.

2. Kies een fail-policy (~all vs -all)

Begin met ~all (soft fail) tijdens de eerste 1–2 weken terwijl je DMARC-rapporten monitort op onverwachte bronnen. Zodra je hebt bevestigd dat elke legitieme afzender in het record staat en DMARC-rapporten 100% slagingspercentages tonen, schakel over naar -all voor maximale bescherming.

3. Bouw het record

Gebruik door vendors gepubliceerde include:-mechanismen waar mogelijk (bijv. include:_spf.google.com). Voor services zonder include, gebruik ip4: met hun gepubliceerde IP-ranges. Houd het record onder de limiet van 10 lookups door elke include en zijn geneste lookups te tellen. Eindig met één enkele qualifier — ~all of -all — nooit beide.

4. Voeg het TXT-record toe aan DNS

In het controlpanel van je DNS-provider, maak een nieuw TXT-record aan met host = @ (of de apex van je domein) en value = de volledige SPF-string tussen aanhalingstekens. TTL van 3600 (1 uur) is een goede default. Quoteert je DNS-provider automatisch, gebruik dan geen dubbele quotes.

5. Valideren en monitoren

Gebruik de checker hierboven om te verifiëren dat het record schoon parseert, het lookup-aantal onder 10 blijft en de policy correct staat. Stuur dan testmails naar mail-tester.com en je eigen Gmail-/Outlook-accounts. Zet DMARC op met rua=-rapporten om bronnen op te vangen die je hebt gemist. Monitor continu — vendor-IP's veranderen, includes worden toegevoegd, en een SPF-record dat zes maanden geleden schoon was kan stilletjes breken.

Hoe je onder de limiet van 10 DNS-lookups blijft

De limiet van 10 lookups is op schaal de meest voorkomende oorzaak van SPF-failures. Elke include: triggert een DNS-query, en elke include die zelf includes bevat triggert er meer — Salesforce's SPF kan bijvoorbeeld in zijn eentje resolven naar 8+ lookups. Drie strategieën houden je onder de limiet. Ten eerste: meedogenloos auditen. Elke vendor die je niet meer gebruikt moet uit het record. Run onze checker maandelijks en verwijder dode includes.

Ten tweede: vervang include: door ip4: waar vendors stabiele IP-ranges publiceren. SendGrid, Mailgun en Amazon SES publiceren allemaal statische blokken; ip4:198.61.254.0/24 gebruiken in plaats van include:sendgrid.net kost nul lookups in plaats van twee. De wisselwerking is onderhoud — wanneer de vendor nieuwe IP's toevoegt moet je handmatig updaten.

Ten derde: gebruik SPF-flattening-services (bijv. easydmarc.com, dmarcian) voor onvermijdelijke geneste includes. Deze services lossen al je includes op tot een platte lijst van ip4:-blokken en herpubliceren ze als één gehost SPF-record waarnaar je verwijst met één include. Het nadeel is operationele afhankelijkheid van een derde partij — vet ze zorgvuldig en monitor op uitval.

SPF, DKIM en DMARC: hoe ze samenwerken

SPF alleen is niet genoeg. De drie protocollen vormen een gelaagde verdediging: SPF authenticeert het IP van de verzendende server, DKIM ondertekent de berichtinhoud cryptografisch, en DMARC bindt de twee aan het zichtbare From-adres en vertelt ontvangers wat te doen wanneer authenticatie faalt. SPF breekt onder forwarding; DKIM overleeft forwarding maar is moeilijker uit te rollen omdat het een sleutelpaar genereren en de public key in DNS toevoegen vereist. Samen slaagt DMARC-alignment als óf SPF óf DKIM slaagt — dus beide uitrollen geeft je redundantie en volledige dekking in real-world bezorgscenario's waar forwarding, mailinglijsten en ARC-vertrouwensketens gangbaar zijn. Zonder DMARC zijn SPF en DKIM alleen diagnostische tools; ontvangers gebruiken de resultaten mogelijk losjes of negeren ze. Met DMARC op p=reject committeer je je publiek aan je authenticatiebeleid en instrueer je elke ontvanger op aarde om gespoofede mail direct te droppen. Dit is de moderne e-mailbeveiligingsstandaard, en het begint met een schoon SPF-record. De aanbevolen uitrolvolgorde is: eerst SPF (één TXT-record, directe impact), daarna DKIM (sleutelgeneratie plus DNS), daarna DMARC op p=none met rua=-rapporten voor twee weken monitoring, en daarna progressief aanscherpen tot p=quarantine en uiteindelijk p=reject. Monitoring overslaan is de meest voorkomende oorzaak van legitieme mail die wegvalt tijdens DMARC-uitrol.

Gmail- en Yahoo-vereisten in 2026

Sinds februari 2024 vereisen Gmail en Yahoo dat alle bulkafzenders (5.000+ berichten per dag naar hun gebruikers) SPF, DKIM en DMARC publiceren, een one-click unsubscribe-header onderhouden (List-Unsubscribe met Post URL), en spamklachten onder 0,3% houden zoals gemeten in Postmaster Tools. Microsoft 365 handhaaft vergelijkbare regels via SmartScreen, en Apple Mail volgt DMARC strict over iCloud en managed Apple ID's. In 2026 zijn deze standaarden verder aangescherpt: DMARC moet op p=quarantine of strikter staan voor niet-geauthenticeerd bulkverkeer, ARC-trust is toegevoegd aan de evaluatieketen voor doorgestuurde mail, en klachtenpercentages boven 0,1% triggeren al verminderde bezorging vóór de harde 0,3%-grens. Falen is geen zachte waarschuwing — je mail gaat naar spam of wordt direct geweigerd op de SMTP-laag. Zelfs niet-bulkafzenders worden steeds vaker geraakt omdat filters generaliseren: een B2B-afzender met 200 mails per dag profiteert nog steeds van schone SPF, DKIM en DMARC omdat Gmail's machine-learning-classifiers dezelfde authenticatiesignalen hergebruiken om elk bericht te scoren. De bottom line: SPF is geen best practice meer — het is een deliverability-vereiste. Run de checker hierboven vandaag om te bevestigen dat je SPF slaagt, ga dan door naar DKIM en DMARC om de stack compleet te maken.

Gerelateerde gidsen

• DMARC Policy Setup Guide — How SPF fits into the full email authentication stack