Three shield icons labeled SPF, DKIM, and DMARC with checkmarks protecting an email envelope on a dark background

SPF, DKIM & DMARC: wat ze zijn, hoe u ze configureert en waarom het belangrijk is

25 maart 2026 12 min leestijd E-mailauthenticatie

Uw e-mails zijn goed geschreven. Uw lijst is schoon. Uw verzendschema is regelmatig. Maar uw openingspercentages dalen en Gmail stuurt u voortdurend naar spam. Het probleem is misschien niet wat u verstuurt -- het probleem kan zijn dat u niet hebt bewezen dat u het echt zelf bent.

E-mailauthenticatie is de manier om aan e-mailproviders te bewijzen dat een e-mail die beweert van uw domein te komen, daadwerkelijk van uw domein afkomstig is. Zonder authenticatie kan iedereen uw "Van"-adres vervalsen en phishing-e-mails sturen die zich voordoen als uw merk. E-mailproviders weten dit -- daarom worden niet-geauthenticeerde e-mails standaard als verdacht beschouwd.

Drie protocollen vormen de ruggengraat van e-mailauthenticatie: SPF, DKIM en DMARC. Samen vertellen ze ontvangende servers wie namens u mag verzenden, dat berichten niet zijn gewijzigd en wat er moet gebeuren bij een mislukking. In deze gids leggen we alle drie in duidelijke taal uit, laten we precies zien hoe u elk ervan configureert en bespreken we de fouten die zelfs ervaren afzenders misleiden.

Wat is e-mailauthenticatie?

Wanneer u een brief per post verstuurt, kan de ontvanger het retouradres zien -- maar iedereen kan elk willekeurig retouradres op de envelop schrijven. E-mail werkt op dezelfde manier. Het "Van"-veld in een e-mail is gewoon tekst. Zonder authenticatie is er niets dat een spammer ervan weerhoudt een e-mail te versturen die lijkt te komen van u@uwdomein.com.

E-mailauthenticatie lost dit probleem op door verifieerbaar bewijs aan uw berichten toe te voegen. Het bestaat uit een reeks DNS-records en cryptografische technieken die ontvangende mailservers in staat stellen drie vragen te beantwoorden:

  • Is deze server geautoriseerd om e-mails voor dit domein te versturen? (SPF)
  • Is dit bericht gewijzigd nadat het is verzonden? (DKIM)
  • Wat moet ik doen als de authenticatie mislukt? (DMARC)

Beschouw het als het tonen van een legitimatiebewijs bij de deur. SPF is de gastenlijst. DKIM is het polsbandje dat bewijst dat u bij de ingang bent gecontroleerd. DMARC is de instructie aan de portier over wat hij moet doen als iemand niet overeenkomt.

SPF uitgelegd

Wat is SPF

SPF (Sender Policy Framework) is een DNS TXT-record dat elk IP-adres en elke mailserver vermeldt die geautoriseerd is om e-mails namens uw domein te versturen. Wanneer een ontvangende server een e-mail van uw domein ontvangt, raadpleegt hij uw SPF-record om te controleren of het IP van de verzendende server op de geautoriseerde lijst staat.

Als het IP overeenkomt, slaagt SPF. Als het niet overeenkomt, mislukt SPF -- en begrijpt de ontvangende server dat de e-mail mogelijk vervalst is.

Hoe SPF werkt (stap voor stap)

  1. U verstuurt een e-mail vanaf hello@uwdomein.com via uw e-mailserviceprovider (ESP).
  2. De ontvangende server ziet dat de e-mail beweert afkomstig te zijn van uwdomein.com.
  3. Hij zoekt het SPF-record op in de DNS van uwdomein.com.
  4. Het SPF-record zegt iets als: "Alleen deze servers mogen namens mij versturen: 192.0.2.1 en alles wat vermeld staat in het SPF-record van Mailchimp."
  5. De ontvangende server controleert of het IP dat de e-mail daadwerkelijk heeft verstuurd overeenkomt met het SPF-record.
  6. Als het overeenkomt: SPF slaagt. Als het niet overeenkomt: SPF mislukt.

Hoe SPF te configureren

Het configureren van SPF vereist het toevoegen van een enkel TXT-record aan de DNS van uw domein. Een typisch SPF-record ziet er als volgt uit:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

Laten we het ontleden:

  • v=spf1 -- geeft aan dat dit een SPF-record is
  • include:_spf.google.com -- autoriseert Google Workspace om namens uw domein te versturen
  • include:servers.mcsv.net -- autoriseert Mailchimp om namens uw domein te versturen
  • -all -- vertelt ontvangers om elke e-mail te weigeren die afkomstig is van een server die hierboven niet is vermeld

Om het te configureren: log in bij uw DNS-provider (GoDaddy, Cloudflare, Namecheap, etc.), ga naar DNS-records, voeg een nieuw TXT-record toe met de host ingesteld op @ (uw rootdomein) en plak uw SPF-waarde. Uw ESP vertelt u precies wat u moet toevoegen -- raadpleeg hun documentatie.

Veelvoorkomende SPF-fouten

  • Meerdere SPF-records. Uw domein kan slechts een SPF-record hebben. Als u er een tweede toevoegt (bijv. een voor Google, een voor Mailchimp), zijn beide ongeldig. Combineer ze in een enkel record met meerdere include:-instructies.
  • Te veel DNS-lookups. SPF heeft een limiet van 10 DNS-lookups. Elke include: telt als een lookup, en geneste includes tellen ook mee. Als u er meer dan 10 hebt, mislukt SPF automatisch voor elke e-mail die u verstuurt. Gebruik een SPF-afvlakkingstool als u de limiet bereikt.
  • Gebruik van +all in plaats van -all. De +all-vlag betekent "sta iedereen toe om als mijn domein te versturen" -- wat het hele doel van SPF tenietdoet. Gebruik altijd -all (strikte weigering) of minimaal ~all (zachte weigering).
  • Vergeten van externe afzenders. Als u een CRM, helpdesk of transactionele e-mailservice gebruikt, moeten hun servers ook in uw SPF-record staan. Veelvoorkomend scenario: marketing-e-mails slagen voor SPF, maar transactionele e-mails van uw helpdesk mislukken omdat u vergeten bent ze toe te voegen.

DKIM uitgelegd

Wat is DKIM

DKIM (DomainKeys Identified Mail) voegt een cryptografische digitale handtekening toe aan elke e-mail die u verstuurt. Deze handtekening wordt gegenereerd met behulp van een privesleutel die alleen uw verzendende server bezit. De bijbehorende publieke sleutel wordt gepubliceerd in uw DNS zodat iedereen de handtekening kan verifieren.

In tegenstelling tot SPF dat alleen de verzendende server controleert, verifieert DKIM dat de inhoud van de e-mail niet is gewijzigd na verzending. Als iemand uw e-mail onderschept en wijzigt, zal de DKIM-handtekening breken en weet de ontvangende server dat het bericht is gemanipuleerd.

Hoe DKIM werkt (stap voor stap)

  1. Uw mailserver maakt een unieke cryptografische hash van de headers en body van de e-mail.
  2. Hij ondertekent deze hash met uw privesleutel en voegt de handtekening toe aan de e-mailheader als een DKIM-Signature-veld.
  3. De ontvangende server ziet de DKIM-handtekening en haalt er de selector en het domein uit.
  4. Hij gebruikt de selector om de publieke sleutel op te zoeken in uw DNS (bijv. selector1._domainkey.uwdomein.com).
  5. Hij gebruikt de publieke sleutel om de handtekening te verifieren aan de hand van de e-mailinhoud.
  6. Als de handtekening overeenkomt: DKIM slaagt. Als deze niet overeenkomt: DKIM mislukt (het bericht is gewijzigd of de sleutel komt niet overeen).

Hoe DKIM te configureren

De DKIM-configuratie is iets complexer dan SPF omdat uw e-mailprovider een sleutelpaar moet genereren. Hier is het algemene proces:

  1. Genereer DKIM-sleutels in uw ESP. Ga naar de instellingen van uw e-mailprovider en zoek de sectie "DKIM" of "E-mailauthenticatie". De meeste providers (Google Workspace, Mailchimp, SendGrid, etc.) genereren de sleutels voor u en geven u een DNS-record om toe te voegen.
  2. Voeg het DKIM-record toe aan uw DNS. U ontvangt een TXT- of CNAME-record met een host zoals google._domainkey en een lange waarde die de publieke sleutel bevat. Voeg het toe bij uw DNS-provider.
  3. Activeer DKIM in uw ESP. Sommige providers vereisen dat u op "Authenticatie starten" of een vergelijkbare knop klikt nadat u het DNS-record hebt toegevoegd. Sla deze stap niet over.
  4. Controleer of het werkt. Stuur een test-e-mail en controleer in de headers of dkim=pass verschijnt. De meeste ESP's tonen de DKIM-status ook in hun dashboard.

Een DKIM DNS-record ziet er ongeveer als volgt uit:

Host: google._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Veelvoorkomende DKIM-fouten

  • DKIM niet configureren voor alle afzenders. Elke e-mailservice die u gebruikt heeft zijn eigen DKIM-sleutel nodig. Als u DKIM hebt geconfigureerd voor Google Workspace maar niet voor Mailchimp, zullen e-mails van Mailchimp de DKIM-controle niet doorstaan.
  • Te korte sleutellengte. Gebruik minimaal 1024-bits sleutels, maar de standaard in 2026 is 2048 bits. Sommige providers gebruiken standaard nog steeds 1024 -- schakel over naar 2048 indien mogelijk.
  • Sleutels niet roteren. Hoewel er geen verplicht rotatieschema is, is het jaarlijks roteren van DKIM-sleutels een best practice op het gebied van beveiliging. Als een privesleutel gecompromitteerd is, zou iemand e-mails kunnen ondertekenen die zich voordoen als afkomstig van uw domein.
  • DNS-record te lang voor een enkele TXT-invoer. Sommige DNS-providers hebben een limiet van 255 tekens per TXT-record. Als uw 2048-bits sleutel dit overschrijdt, moet u deze mogelijk opsplitsen in meerdere strings tussen aanhalingstekens. De documentatie van uw ESP laat zien hoe u dit doet.

DMARC uitgelegd

Wat is DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) is het protocol dat SPF en DKIM samenbrengt en een cruciaal ontbrekend onderdeel toevoegt: een beleid. DMARC vertelt ontvangende servers wat ze moeten doen wanneer een e-mail van uw domein de authenticatie niet doorstaat.

Zonder DMARC moeten ontvangende servers raden. Moeten ze de e-mail toch afleveren? In de spammap plaatsen? Volledig weigeren? Elke server neemt zijn eigen beslissing. DMARC geeft u controle door een duidelijk beleid in uw DNS te publiceren.

DMARC introduceert ook het concept van alignment. SPF en DKIM controleren verschillende delen van de e-mailheader. DMARC vereist dat minstens een van hen "aligneert" met het domein van het zichtbare "Van"-adres -- het adres dat uw ontvangers daadwerkelijk zien. Dit dicht een leemte waarin een aanvaller SPF kan doorstaan met een domein terwijl hij een geheel ander domein aan de ontvanger toont.

De DMARC-beleidsregels: none, quarantine en reject

DMARC biedt drie beleidsniveaus:

p=none (Alleen monitoring)

Begin hier

Ontvangende servers leveren alle e-mails af ongeacht de authenticatieresultaten, maar sturen u rapporten. Dit is de "observatiemodus" -- gebruik deze om alle legitieme afzenders te ontdekken voordat u een beleid afdwingt.

p=quarantine

Tussenniveau

E-mails die de authenticatie niet doorstaan worden naar de spam-/ongewenstemap gestuurd. Legitieme e-mails van geautoriseerde afzenders bereiken nog steeds de inbox. Dit is een goede tussenstap terwijl u verifieert dat alles werkt.

p=reject

Maximale bescherming

E-mails die de authenticatie niet doorstaan worden volledig geblokkeerd -- ze bereiken de ontvanger nooit, zelfs niet in de spam. Dit is de sterkste bescherming tegen domeinvervalsing en phishingaanvallen op uw merk.

Hoe DMARC te configureren

DMARC is een enkel TXT-record in uw DNS. Hier is de aanbevolen aanpak:

Stap 1: Begin met monitoring. Voeg dit TXT-record toe aan uw DNS:

Host: _dmarc.yourdomain.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
  • v=DMARC1 -- geeft aan dat dit een DMARC-record is
  • p=none -- alleen monitoring, geen actie bij mislukkingen
  • rua=mailto:... -- adres waarnaar geaggregeerde rapporten worden gestuurd (XML-rapporten die laten zien wie er met uw domein verstuurt en of ze de authenticatie doorstaan)

Stap 2: Bekijk de rapporten gedurende 2 tot 4 weken. U ontvangt XML-rapporten van de belangrijkste e-mailproviders. Deze rapporten tonen elk IP-adres dat e-mails verstuurt met uw domein en of SPF/DKIM slagen. Gebruik een DMARC-rapportanalysetool (zoals dmarcian of EasyDMARC) om de gegevens leesbaar te maken. Uw doel: ervoor zorgen dat al uw legitieme afzenders zowel SPF als DKIM doorstaan.

Stap 3: Schakel over naar quarantine. Zodra u zeker weet dat alle legitieme e-mails slagen:

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

Stap 4: Schakel over naar reject. Na nog een paar weken schone rapporten:

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

Schakel nooit direct over naar p=reject zonder eerst te monitoren. Als een legitieme afzender niet correct is geauthenticeerd, worden zijn e-mails stilletjes verwijderd -- en u weet het pas als iemand klaagt dat hij uw bericht nooit heeft ontvangen.

Veelvoorkomende DMARC-fouten

  • Direct overschakelen naar p=reject. Dit is de gevaarlijkste fout. Als u een vergeten externe afzender hebt die niet is geauthenticeerd (oude CRM, helpdesk, transactionele e-mailservice), worden zijn e-mails zonder enige waarschuwing geblokkeerd.
  • Geen rapportadres (rua) configureren. Zonder rapporten vliegt u blind. U kunt niet weten of legitieme e-mails mislukken of dat iemand uw domein vervalst.
  • DMARC-rapporten negeren. p=none configureren en nooit de rapporten bekijken maakt het hele doel ongedaan. Het punt van monitoring is problemen vinden voordat u een strenger beleid afdwingt.
  • Alignment-problemen. DMARC vereist dat het domein in SPF of DKIM overeenkomt (aligneert) met het zichtbare "Van"-domein. Als uw ESP vanuit een ander domein verstuurt en niet met de DKIM van uw domein ondertekent, zal DMARC mislukken zelfs als SPF slaagt.

SPF vs. DKIM vs. DMARC: vergelijking

Hier is een overzicht naast elkaar van wat elk protocol doet en waartegen het beschermt:

SPF DKIM DMARC
Wat het doet Vermeldt geautoriseerde verzendservers Voegt een cryptografische handtekening toe aan e-mails Definieert een beleid voor authenticatiemislukkingen
Type DNS-record TXT op het rootdomein TXT of CNAME op selector._domainkey TXT op het _dmarc-subdomein
Wat het controleert Of het IP van de verzendserver geautoriseerd is Of de berichtinhoud niet is gewijzigd Of SPF/DKIM aligneren met het zichtbare Van-domein
Wat het voorkomt Ongeautoriseerde servers die namens u versturen Manipulatie van de e-mail tijdens verzending Domeinvervalsing en phishing
Werkt het zelfstandig? Gedeeltelijk -- controleert niet de Van-header Gedeeltelijk -- geen beleid bij mislukking Nee -- vereist SPF en/of DKIM
Verplicht in 2026? Ja -- vereist door Gmail en Yahoo Ja -- vereist door Gmail en Yahoo Ja -- verplicht voor bulkverzenders

Het belangrijkste punt: elk protocol dicht een andere leemte. SPF alleen controleert niet het zichtbare "Van"-adres. DKIM alleen vertelt ontvangers niet wat ze moeten doen bij een authenticatiemislukking. DMARC alleen werkt niet zonder SPF of DKIM als ondersteuning. U hebt alle drie samen nodig.

Hoe authenticatie de afleverbaarheid beinvloedt

E-mailauthenticatie is een van de fundamentele pijlers van afzenderreputatie. E-mailproviders gebruiken authenticatie als basis vertrouwenssignaal. Het is geen garantie voor inboxplaatsing -- u hebt nog steeds schone lijsten, lage klachten en goede betrokkenheid nodig -- maar zonder authenticatie is alles wat u verder doet gecompromitteerd.

Dit is wat er op elk authenticatieniveau gebeurt:

  • Geen authenticatie: De meeste grote providers sturen uw e-mails naar de spammap of weigeren ze direct. Gmail is hierop steeds agressiever geworden sinds de update van de afzendervereisten in 2024.
  • Alleen SPF: Beter dan niets, maar u laat leemtes open. Doorgestuurde e-mails breken SPF, en er is geen bescherming tegen vervalsing van het domein in het zichtbare Van-veld.
  • SPF + DKIM: Aanzienlijk beter. U bewijst zowel serverautorisatie als berichtintegriteit. Maar zonder DMARC geen beleid en geen rapporten -- u kunt niet weten wanneer er mislukkingen optreden.
  • SPF + DKIM + DMARC (reject): De gouden standaard. Volledige authenticatie, volledige bescherming, volledig inzicht. Dit is wat Gmail en Yahoo van bulkverzenders eisen, en dit is waar elk domein naar moet streven.

Authenticatie is bijzonder cruciaal als u meerdere verzendservices gebruikt. Elke ESP, CRM, helpdesk en transactioneel e-mailsysteem dat namens uw domein verstuurt, moet correct geauthenticeerd zijn. Een enkele niet-geauthenticeerde afzender kan de reputatie van uw gehele domein schaden. Gebruik de ClearBounce Afleverbaarheidskit om uw authenticatiestatus te monitoren en problemen te detecteren voordat ze uw inboxplaatsing beinvloeden.

100%

van Gmail-bulkverzenders moet sinds 2024 SPF, DKIM en DMARC hebben

10%

hogere inboxplaatsing voor domeinen met DMARC p=reject vs. zonder DMARC

3.1 mld

vervalste e-mails dagelijks geblokkeerd door DMARC-beschermde domeinen wereldwijd

Veelvoorkomende authenticatiefouten

Zelfs afzenders die denken dat ze de authenticatie correct hebben geconfigureerd, hebben vaak verborgen problemen. Hier zijn de problemen die we het vaakst tegenkomen:

1. Meerdere SPF-records hebben Breekt SPF volledig

Uw domein kan slechts een SPF TXT-record hebben. Een tweede toevoegen (in plaats van samenvoegen) maakt beide ongeldig. Dit is de meest voorkomende SPF-configuratiefout.

2. De 10 SPF-lookup-limiet overschrijden Stille mislukking

Elk include:-, a-, mx- en redirect-mechanisme telt als een DNS-lookup. Veel afzenders overschrijden onbewust 10, waardoor SPF PermError retourneert voor elke verstuurde e-mail.

3. Vergeten externe afzenders te authenticeren Gedeeltelijke mislukking

Marketing-e-mails slagen, maar uw helpdesk, CRM of facturatiesysteem mislukt voor authenticatie omdat u vergeten bent ze aan SPF toe te voegen en DKIM te configureren. Elke verzendservice moet gedekt zijn.

4. Te snel overschakelen naar DMARC p=reject Blokkeert legitieme e-mails

Direct overschakelen naar reject zonder monitoringperiode betekent dat elke vergeten of verkeerd geconfigureerde afzender zijn e-mails stilletjes ziet verdwijnen. Begin altijd met p=none en bekijk eerst de rapporten.

5. DMARC-rapporten niet monitoren Gemist inzicht

DMARC configureren met p=none en de rapporten nooit lezen betekent dat u niet weet wanneer een afzender uitvalt, wanneer iemand uw domein vervalst of wanneer u klaar bent om een strenger beleid af te dwingen.

6. Zwakke DKIM-sleutels gebruiken Beveiligingsrisico

Sleutels van minder dan 1024 bits kunnen worden gekraakt, waardoor aanvallers e-mails kunnen ondertekenen die zich voordoen als afkomstig van uw domein. Gebruik 2048-bits sleutels en roteer ze jaarlijks. Sommige providers gebruiken standaard nog steeds 1024 -- controleer en upgrade.

E-mailauthenticatie-checklist

Gebruik deze checklist om te verifieren dat uw authenticatie correct is geconfigureerd. Het controleren van elk punt duurt slechts enkele minuten maar kan weken van afleveringsproblemen voorkomen:

Taak Protocol Prioriteit
Publiceer een enkel SPF-record met alle afzenders SPF Kritiek
Controleer of SPF minder dan 10 DNS-lookups gebruikt SPF Kritiek
Eindig het SPF-record met -all of ~all SPF Hoog
Configureer DKIM voor elke e-mailservice die u gebruikt DKIM Kritiek
Gebruik 2048-bits DKIM-sleutels (niet 1024 bits) DKIM Hoog
Publiceer een DMARC-record (begin met p=none) DMARC Kritiek
Configureer het DMARC-rapportadres (rua) DMARC Hoog
Bekijk DMARC-rapporten wekelijks DMARC Hoog
Schakel DMARC over naar p=quarantine na monitoring DMARC Gemiddeld
Schakel DMARC over naar p=reject wanneer u zeker bent DMARC Gemiddeld
Stuur test-e-mails en controleer of ze slagen in de headers Alle Hoog
Monitor regelmatig de blokkeerlijststatus Alle Hoog

Conclusie

E-mailauthenticatie is niet langer optioneel. Gmail, Yahoo en Microsoft gebruiken SPF, DKIM en DMARC als fundamenteel signaal om te beslissen of uw e-mails in de inbox of de spammap thuishoren. Sinds 2024 eisen Gmail en Yahoo alle drie expliciet voor bulkverzenders -- en de trend is duidelijk: authenticatievereisten zullen alleen maar strenger worden.

Het goede nieuws is dat het configureren van authenticatie een eenmalige inspanning is met permanente voordelen. Zodra uw SPF-, DKIM- en DMARC-records correct zijn geconfigureerd, profiteert elke e-mail die u verstuurt van het vertrouwen dat ze vestigen. U verbetert niet alleen de afleverbaarheid -- u beschermt uw merk tegen phishing- en spoofingaanvallen die uw reputatie en het vertrouwen van uw klanten kunnen schaden.

Authenticatie is echter slechts een onderdeel van de afleveringspuzzel. Een perfect geauthenticeerde e-mail die naar een ongeldig adres wordt gestuurd, bounct nog steeds. Een perfect ondertekende e-mail die naar een spam trap wordt gestuurd, schaadt nog steeds uw reputatie. Authenticatie vertelt e-mailproviders dat u bent wie u beweert te zijn. E-mailverificatie zorgt ervoor dat u verstuurt naar mensen die daadwerkelijk bestaan en van u willen horen. Samen vormen ze het fundament om consequent de inbox te bereiken.

Als u nog niet alle drie de protocollen hebt geconfigureerd, begin dan vandaag. Begin met SPF, dan DKIM, dan DMARC in monitoringmodus. Gebruik de bovenstaande checklist. Uw afzenderreputatie -- en uw inboxplaatsing -- zullen u dankbaar zijn.

Bescherm uw afleverbaarheid.

Authenticatie bewijst dat u een legitieme afzender bent. Schone lijsten bewijzen dat u een verantwoordelijke afzender bent. ClearBounce verwijdert ongeldige, risicovolle en verdachte e-mailadressen voordat ze bounces en blokkeerlijstplaatsingen veroorzaken die al uw authenticatiewerk tenietdoen.

100 gratis credits. Geen creditcard vereist.

Start gratis verificatie
CB

Team ClearBounce

25 maart 2026

Delen:

Meer op de blog