Waarom faalt SPF na het toevoegen van een nieuwe tool?

Vermoedelijk passeer je de 10 DNS-lookup limiet uit RFC 7208. Elke include:, a, mx, ptr en exists: telt mee, recursief. Boven de 10 wordt je hele SPF-record als ongeldig beschouwd door ontvangers.

TOOL

SPF / DKIM / DMARC checker

Valideer in één klik je mail-authenticatie. Drie DNS-records die het verschil maken tussen 'mijn mails komen aan' en 'alles wordt als spam gemarkeerd' — sinds Google en Outlook DMARC verplicht zijn voor bulk-zenders nóg belangrijker.

← Alle tools

Wanneer gebruik je deze SPF/DKIM/DMARC checker?

Mail-authenticatie is verantwoordelijk voor 80% van mijn deliverability-tickets. Als ik een ticket binnenkrijg met "klanten zeggen dat onze mails niet aankomen", begin ik altijd hier — vóórdat ik in mailbox-instellingen of relay-logs duik. Concrete situaties waarin deze tool het werk versnelt:

Mail komt niet aanKlanten of leveranciers zeggen dat je mails in hun spam belanden of helemaal niet aankomen. SPF/DKIM/DMARC valideren is de eerste stap.
Na het toevoegen van een mailtoolMailchimp, Brevo, SendGrid, een CRM — elke nieuwe verzender vergt een SPF-update. Hier zie je direct of de include op de juiste plek staat.
DMARC-rolllout monitorenTijdens de stap van p=none naar p=quarantine of p=reject: check of alle eigen mailstromen in alignment zijn voor je strenger gaat.
Spoofing-claim onderzoekenIemand verstuurt mail met jouw domein als afzender? Check of SPF strict genoeg is en DMARC actief op p=reject staat.
Vendor-onboarding (M365, Workspace)Bij migratie naar Microsoft 365 of Google Workspace verifiëren of SPF en DKIM correct zijn opgezet voor de eerste mail wordt verstuurd.

Hoe lees je het resultaat?

SPF Geeft aan welke servers vanaf jouw domein mogen versturen. Eindigend op ~all (softfail) of -all (fail). Een ?all (neutral) of +all (allow all) is fout en maakt SPF nutteloos.
DKIM Cryptografische handtekening op elke uitgaande mail. Selector verschilt per provider — M365 = selector1/selector2, Google = google, Mailchimp = k1, SendGrid = s1/s2.
DMARC Beleidsregel die ontvangers vertelt wat ze met niet-gevalideerde mail moeten doen. p=reject = strikt, p=quarantine = naar spam, p=none = alleen rapporteren.
rua Mailadres waar geaggregeerde DMARC-rapporten naartoe gaan (XML-bestanden 1x per dag). Onmisbaar voor monitoring tijdens de roll-out.
pct Percentage mails waarop de policy wordt toegepast. pct=100 = alles, pct=10 = 10% van mails (handig bij gefaseerde uitrol).

De 10 DNS-lookup limiet voor SPF

SPF heeft een hard limiet van 10 DNS-lookups per record (RFC 7208 §4.6.4). Elke include:, a, mx, ptr, exists: en redirect= telt mee — ip4: en ip6: niet. Includes nesten recursief: een include: die zelf 3 includes heeft kost je 4 lookups in totaal.

Boven de 10 lookups krijg je een permerror en je hele SPF wordt als ongeldig beschouwd — alsof je 'm niet had. Je krijgt geen waarschuwing, alles werkt prima totdat je één extra tool toevoegt en dan bouncen mails plotseling overal. Heb ik tientallen keren meegemaakt.

Wat ik vaak tegenkom

Twee SPF-records, beide actief. Klant had jaren geleden SPF gezet voor de oude mailprovider, en bij switch naar M365 een twééde SPF erbij geplakt. Resultaat: Gmail rejecteert alles. RFC staat maar één SPF per domein toe — twee = PermError = totaal kapot.

SPF op limiet door dode tools. Klant had includes voor 4 oude marketing-tools die ze al jaren niet meer gebruikten. Telden samen voor 8 lookups. Toen ze Brevo toevoegden gingen ze over de 10 en klapten alle nieuwsbrieven om in spam.

DMARC zonder rua. Iemand had p=reject staan zonder rapportage-mailadres. Daardoor geen idee dat de eigen ERP-mails al maanden als spoofing werden geweigerd, totdat klanten gingen mokken over uitblijvende facturen.

Veelgestelde vragen

Wat is het verschil tussen ~all en -all in SPF?

~all (softfail) zegt: "mail van onbekende servers is verdacht, maar mag geleverd worden — vaak in spam." -all (fail) zegt: "weiger het direct."

Bij een nieuw SPF-record start je met ~all en upgrade je naar -all zodra je zeker weet dat alle legitieme verzendbronnen erin staan. Direct op -all beginnen geeft veel risico op je eigen mail blokkeren.

Waarom faalt SPF na het toevoegen van een nieuwe mailtool?

Vermoedelijk passeer je de 10 DNS-lookup limiet. Elke include:, a, mx, ptr en exists: telt mee — recursief, dus een include die zelf 3 includes heeft kost je 4 lookups. Boven de 10 wordt je hele SPF-record als ongeldig beschouwd door ontvangers.

De fix: ongebruikte includes opruimen, of "flatten" naar ip4:/ip6:. Bij twijfel: vraag me — herstel achteraf is duurder dan preventie.

Welke DKIM-selector gebruikt mijn provider?

De gangbare selectors per provider:

Microsoft 365: selector1 en selector2
Google Workspace: google
Mailchimp: k1, k2, k3
SendGrid: s1 en s2
Mailgun: mg of pic
Brevo (Sendinblue): mail

Bij twijfel kun je in het admin-paneel van je mailprovider de DKIM-instellingen bekijken — daar staat altijd welke selector je moet gebruiken in DNS.

Moet ik DMARC direct op p=reject zetten?

Niet meteen. Begin altijd met p=none zodat je rapportages krijgt zonder mail te blokkeren. Na 4–6 weken monitoring stap je naar p=quarantine. Pas als alle eigen mailstromen kloppen en in alignment zijn met SPF/DKIM, ga je naar p=reject.

Direct op p=reject beginnen zonder monitoring blokkeert vaak je eigen newsletters, ERP-meldingen of CRM-mails — en je hebt geen idee waarom.

Kan ik twee SPF-records hebben?

Nee. RFC 7208 staat maar één SPF-record per domein toe. Twee records leiden tot een PermError waardoor SPF compleet faalt. Je moet ze samenvoegen tot één regel met meerdere include:-statements:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all

Werkt SPF ook voor subdomeinen?

Ja, maar elk subdomein dat mail verstuurt heeft zijn eigen SPF-record nodig. SPF op het hoofddomein dekt automatisch het 'helo' van de mailserver maar niet automatisch alle subdomeinen.

Voor subdomeinen die geen mail versturen plaats je v=spf1 -all — zo voorkom je dat spoofers je noreply.voorbeeld.nl misbruiken.