SPF, DKIM en DMARC instellen en oplossen: een stappenplan

Als iemand je vertelt dat je e-mails niet aankomen omdat je "SPF-record te veel DNS-lookups heeft" of je "DKIM-handtekening niet aligned is met je RFC5322.From-domein", dan begrijpt iedereen dat je je laptop het liefst uit het raam gooit.

Maar het zit zo: SPF, DKIM en DMARC instellen is veel eenvoudiger dan die afkortingen doen vermoeden. De meeste mensen hebben hun e-mailauthenticatie binnen een uur op orde. En in 2026 is het verplicht.

Deze gids neemt je in gewone taal mee door elke stap.

Waarom e-mailauthenticatie in 2026 verplicht is

Wat vroeger een best practice was, is nu een harde eis.

In februari 2024 begonnen Gmail en Yahoo e-mailauthenticatie af te dwingen bij bulkverzenders. Gmail ging in november 2025 over op regelrechte weigering van berichten die niet voldoen. Microsoft volgde in mei 2025 en weigert e-mails van verzenders van grote volumes zonder goede SPF, DKIM en DMARC-alignment.

Domeinen met volledige authenticatie hebben een veel betere inbox placement. Zonder authenticatie komen veel van je e-mails niet eens in de spammap, omdat ze al bouncen voordat ze een mailbox bereiken.

Wat zijn SPF, DKIM en DMARC? (De eenvoudige versie)

Zie e-mailauthenticatie als de beveiligingscontrole op een vliegveld:

SPF is je ticket. Het vertelt ontvangende servers welke mailservers e-mail namens je domein mogen versturen. Zoals een gastenlijst die zegt: "deze mensen mogen naar binnen".

DKIM is je paspoort. Het voegt een cryptografische handtekening toe aan elke e-mail, die bewijst dat er onderweg niet met het bericht is geknoeid en dat het echt van je domein komt.

DMARC is de beveiligingsbeambte. Het controleert of SPF of DKIM is geslaagd, beslist wat er met fouten gebeurt (niets, quarantaine of weigeren) en stuurt je rapporten over wie je domein gebruikt om e-mail te versturen.

Je hebt ze alle drie nodig. Zo stel je ze stuk voor stuk in.

Zo stel je SPF in (Sender Policy Framework)

Wat SPF doet

SPF is een DNS-record van het type TXT met een lijst van elke server die namens je domein e-mail mag versturen. Als Gmail een e-mail ontvangt die van yourdomain.com zegt te komen, controleert het je SPF-record om te zien of de verzendende server op de lijst staat.

Stap 1: controleer of je al een SPF-record hebt

Ga naar een SPF-checker en vul je domein in. Je ziet een van drie uitkomsten: geen record gevonden, record gevonden met fouten, of record gevonden en in orde.

Belangrijk: je kunt maar ÉÉN SPF-record per domein hebben. Meerdere records maken de authenticatie volledig kapot.

Stap 2: breng al je verzenddiensten in kaart

Maak een lijst van elk platform dat e-mail vanaf je domein verstuurt. Veelvoorkomende zijn:

• Je e-mailprovider (Google Workspace, Microsoft 365)
• Marketingplatforms (Mailchimp, HubSpot, ActiveCampaign)
• Diensten voor transactionele e-mail (SendGrid, Postmark, Mailgun)
• CRM-systemen (Salesforce, HubSpot)
• Supporttools (Zendesk, Intercom, Freshdesk)

Stap 3: bouw of werk je SPF-record bij

Elke dienst vermeldt de include-waarde voor SPF in de eigen documentatie. Je record ziet er zo uit:

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

• v=spf1 geeft aan dat dit een SPF-record is
• Elke include: autoriseert de servers van die dienst
• ~all geeft een soft fail voor alles wat niet op de lijst staat (best practice, omdat DMARC dan de handhaving regelt)

Stap 4: voeg het toe aan je DNS

Log in bij je domeinregistrar (GoDaddy, Cloudflare, Namecheap, enzovoort), ga naar de DNS-instellingen en voeg het TXT-record toe of werk het bij.

Veelgemaakte fouten bij SPF

Te veel DNS-lookups. SPF heeft een harde limiet van 10 DNS-lookups. Elke include: telt als minstens één, en sommige veroorzaken extra lookups. Ga je boven de 10, dan geeft de hele SPF-check permerror terug (RFC 7208, sectie 4.6.4), en niets waarschuwt je als dat gebeurt. Gebruik een tool voor SPF-flattening als je tegen deze limiet aanloopt.

-all gebruiken in plaats van ~all. De hard fail (-all) vertelt servers dat ze niet-overeenkomende e-mails direct moeten weigeren, nog voordat ze DKIM of DMARC controleren. Gebruik soft fail (~all) en laat DMARC de handhaving regelen.

Een verzenddienst vergeten. Dat CRM dat je zes maanden geleden toevoegde? Die factuurtool? Versturen ze e-mail vanaf je domein en staan ze niet in je SPF-record, dan falen die berichten op authenticatie.

Zo stel je DKIM in (DomainKeys Identified Mail)

Wat DKIM doet

DKIM voegt een cryptografische handtekening toe aan elke uitgaande e-mail. De ontvangende server toetst die handtekening aan een publieke sleutel in je DNS om te controleren of de e-mail echt en ongewijzigd is.

Stap 1: genereer DKIM-sleutels bij je e-mailprovider

Anders dan bij SPF begint het instellen van DKIM in het dashboard van je verzendplatform. Elke grote provider heeft een handleiding voor DKIM. Zoek in hun documentatie op "DKIM setup" of "email authentication".

De provider genereert twee dingen:

• Een publieke sleutel (een TXT-record dat je aan je domein toevoegt)
• Een privésleutel (waarmee de server je uitgaande e-mails ondertekent)

Stap 2: voeg de publieke sleutel toe aan je DNS

Het record heeft een specifieke selector (zoals google._domainkey.yourdomain.com) en een lange reeks tekens. Voeg het toe als TXT-record in je DNS-instellingen.

Stap 3: schakel DKIM-ondertekening in

Ga terug naar je e-mailprovider en zet DKIM-ondertekening aan. Deze stap is cruciaal: veel mensen voegen het DNS-record toe en denken dat ze klaar zijn. De publieke sleutel toevoegen is maar de helft van het werk.

Stap 4: herhaal dit voor elke verzenddienst

Elk platform dat e-mail vanaf je domein verstuurt, heeft een eigen DKIM-configuratie nodig. Allemaal: je marketingtool, je dienst voor transactionele e-mail, je CRM.

Zo controleer je of DKIM werkt

Stuur een testmail naar een Gmail-account. Open hem en klik op de drie puntjes → "Origineel weergeven". Zoek naar DKIM: PASS in de authenticatieresultaten.

Veelgemaakte fouten bij DKIM

Ondertekening niet inschakelen na het toevoegen van het DNS-record. Komt vooral voor bij Google Workspace, waar mensen het DNS-record toevoegen en DKIM nooit aanzetten in de beheerconsole.

Sleutels van 1024 bits gebruiken. Gebruik sleutels van 2048 bits voor sterkere beveiliging. De meeste providers doen dat inmiddels standaard, maar controleer het met de DKIM-lookup.

Geen DKIM bij secundaire verzenders. Ondertekent je marketingplatform met DKIM maar je transactionele dienst niet, dan gaan die transactionele berichten zonder handtekening de deur uit.

Zo stel je DMARC in (Domain-based Message Authentication, Reporting and Conformance)

Wat DMARC doet

DMARC bouwt voort op SPF en DKIM. Het controleert of een van beide protocollen is geslaagd en of het domein aligned is met je zichtbare "From"-adres. Daarna vertelt het ontvangende servers wat ze met fouten moeten doen. Ook stuurt het je rapporten over elke e-mail die met je domein is verstuurd, ook e-mails die jij niet hebt verstuurd.

Stap 1: zorg eerst dat SPF en DKIM werken

DMARC is van allebei afhankelijk. Stel DMARC pas in als je hebt bevestigd dat SPF en DKIM slagen. Google raadt aan na het instellen van SPF en DKIM minstens 48 uur te wachten voordat je DMARC inschakelt.

Stap 2: begin met de monitoringmodus

Voeg dit TXT-record toe aan je DNS op _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

• p=none vertelt ontvangers dat ze nog niets met fouten moeten doen, alleen rapporten sturen
• rua=mailto:... bepaalt waar de aggregaatrapporten naartoe gaan

Stap 3: bekijk de DMARC-rapporten 2 tot 4 weken lang

DMARC-rapporten laten elk IP-adres zien dat e-mail verstuurt als jouw domein, welke slagen voor authenticatie en welke falen.

Let op: legitieme verzenddiensten die falen op authenticatie (herstel hun SPF/DKIM), onbevoegde verzenders die je domein proberen te spoofen (daarom heb je DMARC nodig) en alignmentproblemen tussen je From-domein en je SPF- of DKIM-domeinen.

Stap 4: ga over op handhaving

Zodra je hebt bevestigd dat alle legitieme e-mail slaagt voor authenticatie:

Quarantine (stuurt fouten naar spam):

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Reject (blokkeert fouten volledig; dit is de gouden standaard):

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Veelgemaakte fouten bij DMARC

Meteen naar p=reject springen. Dwing je weigering af voordat je hebt bevestigd dat alle legitieme verzenders slagen, dan blokkeer je je eigen e-mails. Begin altijd met p=none.

Nooit verder komen dan p=none. Aan de andere kant publiceren veel organisaties een policy die alleen monitort en dwingen ze die nooit af. Een p=none-policy kijkt alleen mee; hij beschermt je niet tegen spoofing. Het hele punt is om bij quarantine of reject uit te komen.

Alignmentfouten. DMARC vereist dat het domein dat SPF of DKIM gebruikt aligned is met je zichtbare From-adres. Verstuurt je marketingtool met een return-path van bounce.marketingtool.com terwijl je From you@yourdomain.com is, dan is SPF niet aligned, zoals de DMARC alignment checker laat zien bij elk bericht dat je erin plakt. In dat geval heb je DKIM-alignment nodig.

De juiste volgorde

Als je vanaf nul begint:

1. Eerst SPF: het makkelijkst in te stellen, het snelste effect
2. Dan DKIM: meer werk (moet in elk verzendplatform worden ingesteld), maar cruciaal
3. Dan DMARC: pas als SPF en DKIM werken. Begin met p=none en ga in 2 tot 4 weken over op handhaving

Het doorvoeren van DNS-wijzigingen kan tot 48 uur duren, dus raak niet in paniek als wijzigingen niet meteen zichtbaar zijn.

Instellen en vergeten werkt niet

Hier gaat het bij de meeste mensen mis. Ze stellen authenticatie één keer in en controleren het daarna nooit meer. Dan voegt iemand in het team een nieuwe e-mailtool toe, het SPF-record wordt niet bijgewerkt en ineens faalt de helft van hun e-mails wekenlang op authenticatie voordat iemand het merkt.

E-mailauthenticatie vraagt om doorlopend onderhoud:

• Controleer je records maandelijks als je infrastructuur stabiel is
• Controleer direct na elke wijziging (nieuw domein, nieuwe ESP, nieuw CRM)
• Monitor doorlopend op afwijkingen in de configuratie

MailVitals automatiseert deze monitoring. Het controleert doorlopend de configuratie van SPF, DKIM en DMARC op al je domeinen en waarschuwt je direct als er iets stukgaat, voordat je deliverability eronder lijdt.

👉 Gerelateerd: Waarom komen mijn e-mails in spam terecht?

Bronnen

• RFC 7208: Sender Policy Framework (SPF), de syntaxis van het SPF-record, ~all en -all, de regel van één record en de limiet van 10 lookups.
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, hoe DKIM-handtekeningen, selectors en publieke sleutels in DNS werken.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), de huidige DMARC-standaard: alignment, de policies p=none/quarantine/reject en aggregaatrapporten.
• Set up DMARC (Google Workspace Help), het advies van Google voor het uitrollen van DMARC, waaronder de wachttijd van 48 uur na SPF en DKIM.
• Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders (Microsoft Tech Community), de regels voor SPF, DKIM en DMARC die Outlook.com afdwingt bij domeinen die meer dan 5.000 berichten per dag versturen.