SPF, DKIM & DMARC: wat ze zijn, hoe u ze configureert en waarom het belangrijk is
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)
- U verstuurt een e-mail vanaf
hello@uwdomein.comvia uw e-mailserviceprovider (ESP). - De ontvangende server ziet dat de e-mail beweert afkomstig te zijn van
uwdomein.com. - Hij zoekt het SPF-record op in de DNS van
uwdomein.com. - 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."
- De ontvangende server controleert of het IP dat de e-mail daadwerkelijk heeft verstuurd overeenkomt met het SPF-record.
- 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 isinclude:_spf.google.com-- autoriseert Google Workspace om namens uw domein te verstureninclude: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
+allin 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)
- Uw mailserver maakt een unieke cryptografische hash van de headers en body van de e-mail.
- Hij ondertekent deze hash met uw privesleutel en voegt de handtekening toe aan de e-mailheader als een
DKIM-Signature-veld. - De ontvangende server ziet de DKIM-handtekening en haalt er de selector en het domein uit.
- Hij gebruikt de selector om de publieke sleutel op te zoeken in uw DNS (bijv.
selector1._domainkey.uwdomein.com). - Hij gebruikt de publieke sleutel om de handtekening te verifieren aan de hand van de e-mailinhoud.
- 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:
- 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.
- Voeg het DKIM-record toe aan uw DNS. U ontvangt een TXT- of CNAME-record met een host zoals
google._domainkeyen een lange waarde die de publieke sleutel bevat. Voeg het toe bij uw DNS-provider. - 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.
- Controleer of het werkt. Stuur een test-e-mail en controleer in de headers of
dkim=passverschijnt. 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 hierOntvangende 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
TussenniveauE-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 beschermingE-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 isp=none-- alleen monitoring, geen actie bij mislukkingenrua=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=noneconfigureren 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:
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.
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.
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.
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.
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.
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