SPF vs DKIM vs DMARC: wat elk écht doet
Heb je ooit e-mailauthenticatie voor een domein ingericht, dan ben je drie acroniemen tegengekomen: SPF, DKIM en DMARC. Ze worden vaak in één adem genoemd, maar doen fundamenteel verschillende dingen.
De verwarring is begrijpelijk. Ze staan allemaal in DNS, beschermen allemaal je e-mailreputatie en moeten allemaal samenwerken. Maar ze met elkaar verwarren is als een slot, een sleutel en een beveiligingscamera door elkaar halen: samen vormen ze een systeem, maar ze zijn niet hetzelfde.
Dit doet elk écht, in gewone taal.
De korte versie
| Standaard | Wat het doet | Analogie |
|---|---|---|
| SPF | Bepaalt welke servers e-mail voor je domein mogen versturen | Een lijst met toegelaten bezoekers bij de receptie |
| DKIM | Bewijst dat een e-mail onderweg niet is gewijzigd | Een lakzegel op een envelop |
| DMARC | Vertelt ontvangers wat ze moeten doen als de SPF- of DKIM-controle mislukt | Een bordje: "als het zegel kapot is, niet bezorgen" |
Een e-mail moet minstens voor SPF of DKIM slagen om DMARC te laten werken. En voor betrouwbare e-mailbezorging heb je alle drie nodig.
SPF: de bezoekerslijst
Sender Policy Framework is een DNS-record dat opsomt welke IP-adressen e-mail voor je domein mogen versturen. Het is de oudste van de drie (RFC 4408, 2006) en de eenvoudigste.
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
Wanneer een ontvangende server een e-mail krijgt die beweert van yourdomain.com te komen, zoekt die je SPF-record op en
controleert of het IP-adres van de verzendende server op de lijst staat.
Waar SPF goed in is:
- Stopt eenvoudige domeinspoofing
- Snel te controleren: ontvangers kunnen al op SMTP-niveau weigeren
- Goed begrepen en breed ondersteund
Wat SPF niet doet:
- Het ondertekent of versleutelt het bericht niet
- Het voorkomt niet dat e-mail van een legitieme afzender na doorsturen alsnog voor de controle zakt (dit heet "SPF-breuk bij doorsturen")
- Het vertelt ontvangers niet wat ze moeten doen wanneer de controle mislukt
~all of -all aan je SPF-record toevoegen beschermt je niet
automatisch. Heeft je record meer dan 10 DNS-lookups, dan geeft de hele SPF-controle een PermError terug en wordt je beleid
volledig genegeerd. Een record dat er streng uitziet maar kapot is, is net zo goed als helemaal geen record.
DKIM: het lakzegel
DomainKeys Identified Mail gebruikt public-keycryptografie om je uitgaande e-mails te ondertekenen. Je genereert een
sleutelpaar, zet de publieke sleutel in een DNS-record (selector._domainkey.yourdomain.com) en je mailserver ondertekent elk
uitgaand bericht met de privésleutel.
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."
Wanneer een ontvanger je e-mail krijgt, zoekt die de publieke sleutel op in je DNS, controleert de handtekening en gaat na of berichttekst en headers overeenkomen. Zo ja, dan is de e-mail DKIM-geverifieerd.
Waar DKIM goed in is:
- Bewijst dat de e-mail onderweg niet is gewijzigd
- Overleeft het doorsturen van e-mail (SPF breekt, DKIM niet)
- Biedt een cryptografische laag die SPF niet kan bieden
Wat DKIM niet doet:
- Het verifieert niet de afzender, alleen de handtekening. Een aanvaller kan DKIM voor zijn eigen domein instellen en e-mails ondertekenen die nog steeds beweren van jou te komen (al zouden die zakken voor de DMARC-alignment)
- Het voorkomt niet dat iemand onondertekende e-mail uit naam van je domein verstuurt
- Het vertelt ontvangers niet wat ze moeten doen als de controle mislukt
google._domainkey.yourdomain.com of selector1._domainkey.yourdomain.com.
DMARC: de beleidsmaker
Domain-based Message Authentication, Reporting & Conformance is de laag bovenop SPF en DKIM. Het zegt tegen ontvangende mailservers: "Als een e-mail die beweert van mijn domein te komen voor SPF én DKIM zakt, doe er dan dit mee."
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100
DMARC introduceert ook het begrip alignment: zelfs als een e-mail afzonderlijk voor SPF of DKIM slaagt, moet het domein in de
From:-header overeenkomen met het domein dat in de SPF-controle of de DKIM-handtekening is gebruikt. Dat voorkomt een
geavanceerde aanval waarbij iemand namens yourdomain.com verstuurt via zijn eigen geauthenticeerde server.
Drie DMARC-beleidsregels:
p=none: alleen monitoren. Geen actie. Gebruikt om data te verzamelen vóór handhavingp=quarantine: e-mails die de controle niet doorstaan als spam markerenp=reject: e-mails die de controle niet doorstaan direct weigeren. Het strengste beleid
Waar DMARC goed in is:
- Geeft je controle over hoe ontvangers niet-geauthenticeerde e-mail behandelen
- Levert dagelijkse/wekelijkse rapporten (
rua) die laten zien wie e-mail uit naam van je domein verstuurt - Essentieel voor merkbescherming tegen spoofing van je exacte domeinnaam
Wat DMARC niet doet:
- Het authenticeert e-mail niet zelf, maar steunt op de resultaten van SPF en DKIM
- Het herstelt geen kapotte SPF- of DKIM-configuraties
- Het helpt niet als SPF-PermErrors je SPF-controles ongemerkt ongeldig maken
p=none direct naar p=reject gaan zonder eerst je rapporten te bekijken, is een
uitstekende manier om legitieme e-mail kwijt te raken. Monitor altijd een paar weken voordat je het beleid aanscherpt.
Hoe ze samenwerken
Zie het als een systeem van drie lagen:
- SPF controleert wie het bericht verstuurde (server-IP)
- DKIM controleert wat er is verstuurd (berichtintegriteit)
- DMARC beslist wat er moet gebeuren wanneer iets misgaat
Om voor DMARC te slagen, moet een e-mail minstens voor SPF of DKIM slagen én daarbij aligned zijn met het
domein in de From:-header.
Daarom zie je soms e-mails die voor DMARC slagen terwijl de SPF-controle mislukt: DKIM was geldig en aligned, en dat is genoeg. Omgekeerd kan
een e-mail voor SPF slagen en toch voor DMARC zakken als er geen DKIM-handtekening is en het SPF-domein niet aligned is met het
From:-domein.
De meest voorkomende fouten
-
SPF is kapot zonder dat je het weet.
Dit gebeurt voortdurend. Het record is syntactisch geldig, dus DNS-tools melden "OK", maar geneste includes duwen het over de 10 lookups. Elke SPF-controle levert een PermError op. Je DMARC-rapporten tonen schrikbarende hoeveelheden mail die voor SPF zakt, zonder dat je dat ooit wist. -
DMARC op p=reject zonder monitoring.
Schakel je over naarrejectvoordat je hebt bevestigd dat al je legitieme afzenders voor authenticatie slagen, dan raak je ongemerkt e-mail kwijt. Begin metp=none, lees je rapporten en schaal dan op. -
Verouderde DKIM-selectors.
DKIM-sleutels kunnen verlopen of worden vervangen zonder dat je DNS wordt bijgewerkt. Een selector die vorig jaar werkte, kan vandaagNXDOMAINteruggeven, waardoor DKIM-verificatie mislukt voor elke e-mail die nog met de oude sleutel is ondertekend. -
Externe afzenders niet gedekt.
Je richt DMARC in voor je domein, maar je CRM verstuurt marketingmail via een ander subdomein zonder SPF of DKIM. Die e-mails zakken volledig voor authenticatie.
Waar begin je?
Zet je dit voor het eerst op of controleer je een bestaande configuratie? Volg deze stappen:
- Controleer je SPF-record: bekijk het volledige aantal lookups, inclusief geneste includes
- Controleer DKIM: ga na of DKIM correct is gepubliceerd voor elke e-maildienst die je gebruikt
-
Start DMARC met
p=noneen een rapportadres (rua) dat je ook echt leest - Bekijk de rapporten 2-4 weken voordat je overstapt naar
p=quarantineofp=reject - Monitor continu: IP-wijzigingen bij aanbieders, sleutelrotaties en nieuwe diensten hebben allemaal invloed op je authenticatieketen