Een technische deep dive in SPF, DKIM en DMARC voor developers

De meeste developers maken op dezelfde manier kennis met SPF, DKIM en DMARC: er belandt een afleverbaarheidsprobleem op je bord, je zoekt naar de oplossing, en je plakt drie DNS-records uit een helpartikel in je zonebestand. De e-mails komen weer aan. Je gaat verder. De records worden magische bezweringen: aanwezig, werkend, en volstrekt ondoorzichtig.

Dat werkt, tot het niet meer werkt. Een doorgestuurde e-mail faalt op authenticatie om redenen die krankzinnig lijken. Een subdomein wordt ineens geweigerd. Gmail begint je wachtwoordresets in quarantaine te zetten in de week nadat je een nieuwe marketingtool aan hetzelfde domein hebt gehangen. Nu moet je echt debuggen, en "ik heb de records geplakt die het artikel me gaf" is geen mentaal model waarmee je kunt debuggen.

Dit artikel bouwt dat model op. Aan het einde zou je naar een raw DMARC-record en een gefaalde authenticatieheader moeten kunnen kijken en kunnen beredeneren waarom het faalde, in plaats van alleen te weten welk Stack Overflow-antwoord je als volgende probeert.

TL;DR: SPF autoriseert welke servers namens jouw domein mogen verzenden. DKIM ondertekent het bericht cryptografisch, zodat manipulatie en vervalsing detecteerbaar zijn. DMARC koppelt die twee aan het domein dat je ontvangers daadwerkelijk zien in het From:-veld; die koppeling heet alignment, en dat is het onderdeel dat iedereen vergeet. Je hebt alle drie nodig, correct aligned, om te voldoen aan de bulk-verzenderregels die Gmail, Yahoo en Microsoft inmiddels afdwingen. De rest van dit artikel is het mentale model achter die records, zodat je ze kunt debuggen in plaats van alleen plakken.

Het probleem dat alle drie de protocollen oplossen

SMTP, het protocol dat vrijwel alle e-mail transporteert, werd in 1982 vastgelegd en ging ervan uit dat iedereen op het netwerk te vertrouwen was. Het kent geen enkel ingebouwd identiteitsbegrip. Niets in het basisprotocol weerhoudt een server ervan mail te versturen als [email protected]; het From:-adres is gewoon een header die de verzender zelf schrijft, zoals het afzenderadres op een envelop. Je kunt er opschrijven wat je wilt.

Dat ene ontwerpgat is waarom phishing werkt, en SPF, DKIM en DMARC zijn drie gelaagde antwoorden op één vraag: kan de ontvangende server erop vertrouwen dat dit bericht echt afkomstig is van het domein waar het vandaan zegt te komen? Elk protocol beantwoordt een ander deel van die vraag, en precies daarom heb je alle drie nodig in plaats van een favoriet te kiezen.

Een handig kader voordat we de diepte ingaan: SPF controleert de envelop, DKIM controleert de inhoud, en DMARC controleert of een van die twee ook echt overeenkomt met de naam die de mens leest. Houd dat vast terwijl we ze een voor een behandelen.

SPF: welke servers namens jou mogen spreken

Sender Policy Framework is de simpelste van de drie. Je publiceert een TXT-record met de servers die mail voor jouw domein mogen versturen. Een ontvangende server zoekt dat record op en controleert of de verbindende server op de lijst staat.

Dit is wat AhaSend je laat publiceren:

Name: @ (of je subdomein)
Type: TXT
Value: v=spf1 include:spf.ahasend.com ~all

Lees het van links naar rechts. v=spf1 declareert de versie. include:spf.ahasend.com betekent "vertrouw ook alles wat spf.ahasend.com publiceert": een delegatie, zodat AhaSend zijn verzendende IP's kan wijzigen zonder dat jij ooit nog aan je DNS hoeft te komen. ~all is het vangnet aan het einde: de ~ is een soft fail, die ontvangers vertelt mail van niet-vermelde servers te accepteren maar als verdacht te markeren. Een -all zou een hard fail zijn (direct weigeren), en +all autoriseert het complete internet, een configuratiefout die ongeveer gelijkstaat aan helemaal geen SPF hebben.

Twee dingen waar developers voortdurend over struikelen.

Ten eerste: een domein mag maar één SPF-record hebben. Als je al SPF hebt voor Google Workspace en je voegt een tweede TXT-record toe voor je e-mailprovider, dan heb je geen twee policies, maar een ongeldige configuratie, en de meeste ontvangers laten die falen. Je voegt ze samen tot één record door de nieuwe include vóór het laatste mechanisme te zetten:

OUD:   v=spf1 include:_spf.google.com ~all
NIEUW: v=spf1 include:_spf.google.com include:spf.ahasend.com ~all

Ten tweede, en dit is de subtiele die zich uitbetaalt zodra we bij DMARC zijn: SPF authenticeert het verkeerde adres. Het controleert de envelope sender (ook wel return-path of MAIL FROM), het adres dat de verzendende servers op SMTP-niveau met elkaar afstemmen. Dat is níet het From:-adres dat je ontvanger in de mailclient ziet. Die twee verschillen meestal, en op de meeste e-mailplatformen wijst de envelope sender naar het domein van de provider zelf, voor bounce-afhandeling. Een bericht kan dus SPF halen voor bounces.provider.com terwijl het [email protected] aan de mens toont. SPF alleen bewijst daarom vrijwel niets over de naam in het From:-veld. Onthoud dat: het is de hele reden dat DMARC bestaat.

DKIM: een handtekening die bewijst dat er niets is gemanipuleerd

DomainKeys Identified Mail dicht een ander gat. SPF zegt: "deze server mag verzenden." DKIM zegt: "dit specifieke bericht komt echt van dit domein en is onderweg niet gewijzigd."

De mechaniek is gewone public-key-cryptografie. AhaSend beheert een private key en ondertekent elk uitgaand bericht — een gecanonicaliseerde set headers plus een hash van de body — wat een DKIM-Signature-header oplevert. Jij publiceert de bijbehorende publieke sleutel in DNS. De ontvangende server haalt je publieke sleutel op, berekent de hash over de ondertekende inhoud opnieuw en verifieert de handtekening. Is de body of een ondertekende header na het ondertekenen aangepast, dan klopt de hash niet meer en faalt DKIM.

Wat je publiceert hangt af van of je domein managed of handmatige DNS gebruikt. AhaSend zet nieuwe domeinen standaard op managed DNS, met twee CNAME-records die terugwijzen naar sleutels die AhaSend host:

Name: managed._domainkey.(jouw domein)
Type: CNAME
Value: [AhaSend-alias uit je dashboard]

Name: managed2._domainkey.(jouw domein)
Type: CNAME
Value: [AhaSend-alias uit je dashboard]

Die prefix managed._domainkey is de selector. Selectors laten één domein meerdere DKIM-sleutels tegelijk dragen: een bericht noemt zijn selector in de DKIM-Signature-header, en de ontvanger weet precies welke publieke sleutel hij moet ophalen. Dat maakt sleutelrotatie veilig: AhaSend kan met een verse sleutel onder een nieuwe selector ondertekenen terwijl de oude nog geldig is, zonder enige downtime. Daarom krijg je bij de managed setup meteen twee selectors: één actief, één stand-by voor de volgende rotatie. Door beide nu te publiceren heeft een toekomstige rotatie geen enkele DNS-wijziging van jou meer nodig. (AhaSend roteert DKIM-sleutels automatisch, een feature die de meeste providers je met de hand laten doen, als het al kan.)

Op een legacy of expliciet handmatig domein zie je in plaats daarvan één TXT-record met de publieke sleutel er direct in:

Name: [selector]._domainkey.(jouw domein)
Type: TXT
Value: [de publieke DKIM-sleutel]

De cruciale eigenschap van DKIM, en de reden dat het de ruggengraat van moderne authenticatie is: de handtekening overleeft doorsturen. SPF breekt zodra een bericht via een mailinglijst of doorstuurregel wordt gerelayed, want de doorsturende server staat niet op jouw SPF-lijst. De DKIM-handtekening reist met het bericht mee, dus zolang de ondertekende inhoud intact is, blijft die verifieerbaar. Houd ook deze gedachte vast.

DMARC: alles terugkoppelen aan de naam die de mens ziet

Nu de uitbetaling. We hebben twee protocollen die elk iets authenticeren, maar — cruciaal — iets anders dan het zichtbare From:-adres. SPF authenticeert de envelope sender. DKIM authenticeert het domein dat de ondertekenaar in de handtekening zette. Geen van beide zegt op zichzelf iets over het jouwdomein.nl dat je ontvanger daadwerkelijk leest. Een phisher kan SPF en DKIM halen voor een domein dat hij wél beheert, terwijl hij het jouwe spooft in de From:-regel.

DMARC dicht precies dat gat met één concept: alignment. Een bericht haalt DMARC wanneer het SPF of DKIM haalt en het domein dat slaagde overeenkomt met het domein in de zichtbare From:-header. Die match is het hele punt. Geauthenticeerd zijn is niet genoeg; je moet geauthenticeerd zijn als het domein dat je beweert te zijn.

Dit is het record dat AhaSend aanraadt:

Name: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; sp=none; adkim=r; aspf=r;

Tag voor tag:

• v=DMARC1: de versie, verplicht vooraan.
• p=quarantine: het beleid voor mail die alignment niet haalt: naar spam. De drie opties zijn none (alleen monitoren, gewoon bezorgen), quarantine (als verdacht behandelen) en reject (op SMTP-niveau weigeren). Hieronder meer over kiezen.
• sp=none: het beleid voor subdomeinen, hier alleen monitoren. Handig wanneer nog niet al je subdomeinen geauthenticeerde mail versturen en je ze niet wilt breken terwijl je dat uitzoekt.
• adkim=r en aspf=r: relaxed alignment voor DKIM en SPF. Relaxed betekent dat het geauthenticeerde domein alleen hetzelfde organisatiedomein hoeft te delen met het From:-adres: mail.jouwdomein.nl alignt met jouwdomein.nl. Het alternatief, s (strict), eist een exacte match. Relaxed is voor vrijwel iedereen de juiste default; strict breekt zodra je vanaf een subdomein verstuurt.

Weet je de twee feiten nog die we eerder markeerden? Hier worden ze verzilverd. SPF authenticeert de envelope sender, die meestal van je provider is, dus in de meeste setups alignt SPF niet met je From:-domein en leunt DMARC op DKIM voor de pass. En omdat DKIM doorsturen overleeft, is DKIM-alignment ook wat je mail geauthenticeerd houdt wanneer die via een mailinglijst wordt gerelayed. DKIM doet het zware werk; SPF is de reserve. Dat is geen eigenaardigheid van AhaSend, het geldt in de hele industrie, en het is waarom "even SPF instellen" nooit genoeg was.

Je beleid kiezen: none → quarantine → reject

DMARC is het ene record dat je in fases moet uitrollen in plaats van het op dag één op de strengste stand te zetten.

Begin op p=none. Het verandert niets aan de bezorging; het is pure monitoring. Omdat elk DMARC-record aggregaatrapporten kan opvragen (voeg een rua=mailto:...-tag toe die naar een mailbox of een DMARC-analyticsdienst wijst), laat none je zien welke bronnen als jouw domein versturen en of ze alignment halen, voordat je iets gaat blokkeren. Je ontdekt vrijwel altijd een legitieme verzender die je was vergeten: een CRM, een helpdesk, een facturatietool.

Zodra je rapporten laten zien dat elke legitieme bron netjes alignt, ga je naar p=quarantine (fouten naar spam) en uiteindelijk p=reject (fouten worden botweg geweigerd). reject is het doel — het is het enige beleid dat een gespoofte e-mail daadwerkelijk uit de inbox houdt — maar er met monitoringdata naartoe groeien betekent dat je er komt zonder je eigen salarisnotificaties in een zwart gat te laten verdwijnen.

Waarom dit niet langer optioneel is

E-mailauthenticatie was ooit een afleverbaarheidsoptimalisatie. Sinds 2024 is het een toegangseis, en de regels zijn geschreven in precies de alignment-termen die je zojuist hebt geleerd. Google en Yahoo rolden gezamenlijke bulk-verzenderregels uit die in februari 2024 ingingen, en Microsoft sloot in mei 2025 aan. Verstuur je meer dan 5.000 berichten per dag naar hun gebruikers, dan controleert de gateway nu of je authenticeert met zowel SPF als DKIM, een DMARC-record publiceert (p=none is de ondergrens die aan de regel voldoet, niet het doel) en die DMARC aligned houdt met je From:-domein, plus one-click unsubscribe aanbiedt en je spamklachtenpercentage onder 0,3% houdt.

Die middelste eis is het hele artikel in één regel: de providers willen niet zomaar authenticatie, ze willen aligned authenticatie, want alignment is de enige variant die een phisher niet kan faken. Mis het en bulkmail wordt aan de gateway afgeknepen of geweigerd; geen spammap, geen tweede kans. En hoewel de harde drempels voor bulkverzenders gelden, voeden dezelfde signalen de reputatiescoring die bepaalt waar jouw transactionele mail terechtkomt. Een verificatiemail is waardeloos als hij aankomt nadat de gebruiker het heeft opgegeven, en dit zijn de records die bepalen of hij überhaupt aankomt.

Debuggen wanneer iets faalt

Hier is het model in actie. Wordt een bericht gemarkeerd, open dan de raw headers en zoek de Authentication-Results-regel die je ontvanger toevoegde:

Authentication-Results: mx.google.com;
  dkim=pass header.d=jouwdomein.nl;
  spf=pass smtp.mailfrom=bounces.provider.com;
  dmarc=pass (p=QUARANTINE) header.from=jouwdomein.nl

Nu kun je hem lezen. dkim=pass header.d=jouwdomein.nl: DKIM geverifieerd en het ondertekenende domein is van jou, dus dit gaat alignen. spf=pass smtp.mailfrom=bounces.provider.com: SPF geslaagd, maar voor het bounce-domein van de provider, niet je From:-domein, dus SPF alignt hier niet. dmarc=pass ... header.from=jouwdomein.nl: DMARC slaagde toch, omdat het maar één aligned mechanisme nodig heeft en DKIM dat leverde. Dit is de normale, gezonde toestand van de meeste setups, en nu weet je waarom, in plaats van het te hopen.

Wanneer DMARC faalt, is het vrijwel altijd een van deze drie: DKIM ondertekent niet met jouw domein (dus er is niets aligned om op terug te vallen), je hebt adkim=s/aspf=s gezet en een subdomein-mismatch struikelt over strict alignment, of een legitieme externe tool verstuurt als jouw domein zonder überhaupt geauthenticeerd te zijn — precies de ontdekking waarvoor de rapportage van p=none is ontworpen.

Eén hele klasse van deze bugs kan op AhaSend simpelweg niet voorkomen. Je kunt niet verzenden via een domein waarvan de DNS niet correct is geconfigureerd, want AhaSend verifieert SPF, DKIM en DMARC continu in plaats van eenmalig bij de setup. Een record dat wegdrijft of een sleutel die niet meer resolvet, faalt snel en zichtbaar op het moment van verzenden, in plaats van een week lang stilletjes je inboxplaatsing uit te hollen voordat iemand het merkt. De volledige record-voor-record-walkthrough, inclusief de optionele return-path-, tracking- en MX-records, staat in de domain setup guide.

Het model, in één alinea

SPF somt de servers op die namens jouw domein mogen verzenden, maar authenticeert de envelop, niet de zichtbare afzender. DKIM ondertekent het bericht zelf, zodat manipulatie detecteerbaar is en authenticatie doorsturen overleeft. DMARC is de sluitsteen: het eist dat SPF of DKIM niet alleen slaagt maar ook alignt met het From:-adres dat je ontvanger daadwerkelijk leest, en het laat je opschalen van monitoren naar botweg weigeren naarmate je rapportagedata het vertrouwen verdient. Krijg alle drie aligned en je hebt meer gedaan voor je afleverbaarheid — en het vertrouwen van je gebruikers — dan welke onderwerpregel-tweak dan ook.

Begin gratis met AhaSend →