SPF, DKIM en DMARC uitgelegd: zo bescherm je je e-maildomein in 2026

E-mail is nog steeds de meest misbruikte aanvalsvector voor phishing, CEO-fraude en spoofing. Wie zijn domein niet correct authenticeert, loopt twee risico's tegelijk: kwaadwillenden kunnen ongestoord uit jouw naam mailen, en je legitieme berichten belanden steeds vaker in de spamfolder. SPF, DKIM en DMARC zijn de drie DNS-gebaseerde standaarden die dat probleem oplossen. In deze gids leggen we uit hoe ze precies werken, hoe ze samenwerken, en welke strengere eisen Gmail, Yahoo en Microsoft sinds 2024 stellen.

Wat zijn SPF, DKIM en DMARC in het kort?

• SPF (Sender Policy Framework) geeft via een DNS-record aan welke servers mail mogen versturen namens jouw domein.
• DKIM (DomainKeys Identified Mail) voegt een cryptografische handtekening toe aan elke uitgaande mail, te verifiëren met een publieke sleutel in DNS.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) koppelt SPF en DKIM aan het zichtbare afzenderdomein en vertelt ontvangende servers wat ze moeten doen als de controle faalt.

Pas door deze drie samen in te zetten weet een ontvangende mailserver met zekerheid dat een bericht echt van jouw domein komt.

Wat is SPF en hoe werkt het?

SPF is vastgelegd in RFC 7208 en bestaat uit één TXT-record in DNS. In dat record som je op welke IP-adressen of hostnames namens jouw domein mail mogen verzenden. Een ontvangende mailserver vergelijkt het IP-adres van de afzendende server met die lijst. Komt het IP niet voor in de lijst, dan is de SPF-check een 'fail' of 'softfail'.

Voorbeeld van een SPF-record

voorbeeld.nl.    IN    TXT    "v=spf1 ip4:198.51.100.10 include:_spf.google.com -all"

De relevante onderdelen:

• v=spf1 geeft de versie aan (er bestaat alleen versie 1).
• ip4: en include: definiëren toegestane verzenders.
• -all (hard fail) instrueert ontvangers om mail van andere bronnen te weigeren. ~all (soft fail) is permissiever en stuurt richting spam.

Beperkingen van SPF

SPF heeft drie bekende zwakheden waarom het op zichzelf niet voldoende is:

1. Maximaal 10 DNS-lookups per evaluatie. Veel include:-statements stapelen veroorzaakt een permerror waardoor de check faalt.
2. SPF beschermt alleen het envelope-from (Return-Path), niet het 'From'-adres dat de gebruiker ziet. Dit gat dicht je pas met DMARC.
3. SPF breekt bij doorsturen. Forwarders veranderen vaak het verzendende IP, waardoor legitieme mail alsnog faalt.

Wat is DKIM en hoe werkt het?

DKIM (vastgelegd in RFC 6376) lost een ander probleem op: het bewijst dat de inhoud van een bericht onderweg niet is gewijzigd en dat het is verzonden door iemand met toegang tot de privésleutel van het domein.

Bij verzending zet de uitgaande mailserver een digitale handtekening over de headers en (een deel van) de body in een DKIM-Signature-header. De ontvanger haalt de bijbehorende publieke sleutel op uit DNS en verifieert de handtekening.

Voorbeeld van een DKIM-record

selector1._domainkey.voorbeeld.nl.    IN    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

De selector (hier selector1) staat ook in de DKIM-Signature-header van de mail. Zo kun je meerdere sleutels parallel publiceren, bijvoorbeeld voor verschillende e-maildiensten.

Best practices voor DKIM in 2026

• Gebruik RSA-sleutels van minimaal 2048 bits. 1024-bits sleutels worden door veel ontvangers (waaronder Google) niet meer als sterk beschouwd.
• Roteer sleutels ten minste één keer per jaar door een nieuwe selector te publiceren en de oude geleidelijk uit te faseren.
• Onderteken altijd de standaardheaders (From, Subject, Date, To) zodat een aanvaller deze niet kan vervangen zonder de handtekening te breken.

Wat is DMARC en welke rol speelt het?

DMARC is gedefinieerd in RFC 7489 en bindt SPF en DKIM aan het domein dat de eindgebruiker in zijn mailclient ziet: het From-adres (RFC 5322). Dat heet alignment. Een bericht slaagt voor DMARC als minstens één van de twee onderliggende checks (SPF of DKIM) slaagt én het gebruikte domein overeenkomt met het zichtbare afzenderdomein.

Voorbeeld van een DMARC-record

_dmarc.voorbeeld.nl.    IN    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@voorbeeld.nl; adkim=s; aspf=s"

De drie DMARC-policies

Met de optionele pct=-tag pas je de policy slechts toe op een percentage van de berichten, bijvoorbeeld pct=25. Zo kun je veilig van quarantine naar reject opschalen.

SPF- en DKIM-alignment

adkim en aspf bepalen hoe streng de alignment is. s (strict) eist dat het domein exact overeenkomt met het From-adres. r (relaxed, de standaard) staat ook subdomeinen toe. Voor maximale bescherming tegen subdomeinmisbruik kiezen veel organisaties voor adkim=s; aspf=s in combinatie met een sp=-policy voor subdomeinen.

Verschil tussen SPF, DKIM en DMARC in één tabel

Strengere eisen van Gmail, Yahoo en Microsoft (2024 tot 2026)

De drie grootste mailbox-providers hebben de teugels in twee jaar tijd aanzienlijk aangetrokken. Wie meer dan 5.000 berichten per dag verstuurt naar gebruikers van Gmail, Yahoo Mail of Outlook.com moet aan alle drie de standaarden voldoen.

Februari 2024: Gmail en Yahoo

Sinds februari 2024 verplichten Gmail en Yahoo voor zogeheten bulk senders (5.000+ berichten per dag naar hun gebruikers):

• Geldige SPF én DKIM.
• Een DMARC-record met minimaal p=none.
• Een spamklachtpercentage onder de 0,3%, idealiter onder 0,1%.
• Een werkende one-click-unsubscribe-header voor commerciële mail.

Mei 2025: Microsoft Outlook

Per 5 mei 2025 stelt Microsoft dezelfde eisen voor afzenders die meer dan 5.000 berichten per dag versturen naar Outlook.com, Hotmail.com en Live.com. Niet-conforme mail werd eerst naar Junk geleid, met verdere afwijzing in latere fases.

November 2025: Gmail schakelt door

Vanaf november 2025 begon Gmail de handhaving aan te scherpen. Mail die niet aan de bulk sender requirements voldoet, ervaart tijdelijke en permanente afwijzingen.

Begin 2026: DMARCbis

DMARCbis is de opvolger van RFC 7489 en wordt naar verwachting begin 2026 als Proposed Standard gepubliceerd. De belangrijkste wijzigingen zijn:

• De specificatie wordt opgesplitst in drie aparte RFC's (kern, aggregate reporting en failure reporting).
• Het bepalen van de organisatie-domein gebeurt voortaan via een DNS Tree Walk in plaats van de Public Suffix List.
• Het verifiëren van externe rapportagedomeinen verandert van SHOULD naar MUST.

Wie vandaag een correct DMARC-record publiceert, hoeft niets aan te passen, maar het is een goed moment om je configuratie te toetsen.

Stappenplan: SPF, DKIM en DMARC implementeren

Een verstandige uitrol verloopt in fases om legitieme mailstromen niet te verstoren.

1. Inventariseer alle verzenders. Denk aan je mailserver, marketingplatform, helpdesk, CRM, facturatieprovider en interne tools die mail versturen namens je domein.
2. Publiceer een SPF-record met al deze bronnen en eindig met -all. Blijf onder 10 DNS-lookups.
3. Schakel DKIM in bij elke verzender. Gebruik per dienst een unieke selector (google._domainkey, mailchimp._domainkey, enzovoort) en RSA 2048-bits sleutels.
4. Publiceer een DMARC-record met p=none en een rua-adres. Verzamel minstens 4 tot 8 weken aan rapporten om alle verzenders te identificeren.
5. Schakel over naar p=quarantine met een lage pct. Verhoog pct geleidelijk van 10 naar 25, 50 en 100 zodra de rapporten stabiel zijn.
6. Stap over naar p=reject zodra alle legitieme bronnen volledig in lijn zijn. Stel ook sp=reject in voor subdomeinen die geen mail mogen verzenden.

Veelgemaakte fouten

• Meerdere SPF-records publiceren. Dit is een hard fail volgens de RFC. Combineer altijd alles in één record.
• Vergeten subdomeinen. Zonder DMARC-record voor mail.voorbeeld.nl kan een aanvaller dat subdomein gebruiken. Dek dit af met een sp=-policy of expliciete subdomein-records.
• Te snel naar p=reject. Zonder rapportageperiode loop je het risico legitieme mail kwijt te raken.
• DKIM-selector niet roteren. Een gelekte privésleutel blijft bruikbaar tot je hem vervangt.
• Geen monitoring van DMARC-rapporten. Aggregate XML-rapporten zijn lastig met de hand te lezen. Gebruik een dashboard of importeer ze in een tool om patronen te herkennen.

Veelgestelde vragen

Heb ik DMARC nodig als ik geen mail verstuur?

Ja. Een ongebruikt domein is juist aantrekkelijk voor spoofing. Publiceer dan een 'null SPF' (v=spf1 -all), eventueel een lege DKIM-policy en een DMARC-record met p=reject.

Wat is het verschil tussen p=quarantine en p=reject?

quarantine levert niet-geautoriseerde mail af in de spamfolder, reject blokkeert het bericht volledig op SMTP-niveau. reject biedt de sterkste bescherming, maar vereist dat je zeker weet dat alle legitieme verzenders correct zijn ingesteld.

Wat is DMARC alignment precies?

Alignment betekent dat het domein dat SPF of DKIM authenticeert overeenkomt met het domein in het From-adres dat de gebruiker ziet. Zonder alignment kan een aanvaller een legitieme SPF/DKIM-check van een ander domein combineren met een vervalst From-adres.

Hoe weet ik of mijn records correct zijn?

Controleer je SPF, DKIM en DMARC met een DNS- en mail-monitoringtool zoals DNSWatcher of een externe parser. Inspecteer ook de DMARC aggregate reports die je via rua ontvangt.

Geldt dit ook voor kleine afzenders?

Ja. De 5.000-berichten-per-dag-grens is een handhavingsdrempel, geen veiligheidsdrempel. Ontvangers wegen SPF, DKIM en DMARC ook voor kleine afzenders mee bij hun spam- en reputatiebeoordeling.

Conclusie

SPF, DKIM en DMARC zijn geen optionele lagen meer, maar de minimale basis om in 2026 nog betrouwbaar e-mail af te leveren. SPF benoemt je verzenders, DKIM ondertekent je berichten en DMARC bindt beide aan het zichtbare afzenderdomein en geeft je rapportage en handhaving. Door de stappen in dit artikel te volgen, voorkom je dat criminelen jouw merk misbruiken én zorg je dat legitieme mail blijft aankomen bij Gmail, Yahoo, Outlook en de rest van de wereld.