E-mailbeveiliging met SPF, DKIM en DMARC

Waarom is e-mail zo makkelijk te vervalsen?

Wat je in je mailprogramma ziet als afzender, kan iedereen invullen. Het e-mailprotocol beperkt niet welk adres een verzendende server opgeeft. Daardoor kan een ander de afzender invullen. Dat heet spoofing. Wie mail wil sturen alsof die van je bank, je leverancier of je eigen directie komt, hoeft daarvoor niets te kraken.

In de praktijk kan dit leiden tot phishing en factuurfraude die lijken te komen van een bekende organisatie. Wie wil zien hoe dreigingsinformatie over phishing wordt verzameld en gebruikt, leest threat intelligence uitgelegd.

SPF, DKIM en DMARC veranderen het protocol zelf niet. Ze leggen een laag van controles eroverheen, zodat een ontvanger de herkomst van een bericht kan toetsen.

Wat doet SPF?

SPF (Sender Policy Framework) is beschreven in RFC 7208, een standaard uit april 2014 met de status Proposed Standard. RFC 7208 vervangt RFC 4408. De domeineigenaar publiceert een SPF-record als TXT-record in DNS, met daarin welke servers namens het domein mogen versturen. De ontvangende server haalt dat record op en kijkt of de server die het bericht aanbiedt erop staat. Wie met DNS en mailverkeer werkt, heeft te maken met netwerkbeveiliging.

De controle gaat over twee identiteiten. De eerste is het MAIL FROM-adres, het reverse-path uit het SMTP-protocol. De tweede is de HELO-identiteit, de naam die de verzendende server zich noemt aan het begin van het gesprek. Het adres in de koptekst die de lezer ziet, valt buiten de SPF-controle.

Een SPF-controle levert een van de volgende uitkomsten op:

In een SPF-record staan mechanismen zoals all, include, a, mx, ptr, ip4, ip6 en exists. De RFC zegt dat ptr niet gepubliceerd zou moeten worden. Een SPF-evaluatie mag maximaal 10 termen bevatten die een DNS-opzoeking doen, zoals include, a, mx, ptr, exists en redirect. Overschrijdt een record die grens, dan is het resultaat permerror.

SPF kijkt naar de afzender in de envelop, niet naar het adres dat de lezer ziet. Het NCSC zegt dat SPF op zichzelf nog geen effectieve bescherming tegen e-mailspoofing biedt.

Wat doet DKIM?

DKIM (DomainKeys Identified Mail) is beschreven in RFC 6376 van september 2011 en is een Internet Standard (STD 76). DKIM koppelt een bericht aan het domein van de ondertekenaar. De verifiërende partij controleert een cryptografische handtekening en haalt de bijbehorende publieke sleutel op via het domein van de ondertekenaar. Voor het werken met sleutels en handtekeningen is kennis van cryptografie handig.

De handtekening staat in de header DKIM-Signature. Daarin staan onder meer d= (het ondertekenende domein), s= (de selector), b= (de handtekening, base64), bh= (de hash van de body) en h= (de lijst met ondertekende headervelden). De publieke sleutel staat als TXT-record in de naamruimte _domainkey, onder de naam selector._domainkey.domein. Een lege waarde voor p= betekent dat de sleutel is ingetrokken.

De ontvanger ziet hieruit twee dingen: het bericht hoort bij dat domein, en het is onderweg niet gewijzigd. Verschillende afzenders kunnen elk een eigen selector hebben. Een externe nieuwsbriefdienst kan bijvoorbeeld een eigen selector krijgen, zodat de sleutel voor die dienst los staat van de sleutel voor je eigen mail.

Wat doet DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) bouwt op SPF en DKIM. Het beleid van de domeineigenaar staat in een TXT-record op de naam _dmarc onder het domein. De oorspronkelijke beschrijving stond in RFC 7489 uit maart 2015, met de status Informational. Die RFC is vervangen door RFC 9989, 9990 en 9991. RFC 9989 is gedateerd mei 2026, heeft de status Proposed Standard en vervangt RFC 7489 en RFC 9091.

Het beleid heeft drie vormen:

Een ontvanger kan dit beleid volgen, maar het is een verzoek van de domeineigenaar en geen afdwingbare regel.

Voor DMARC is het niet genoeg dat SPF of DKIM slaagt. Het domein dat slaagt moet ook overeenkomen (alignment) met het domein in de From-header, het domein dat de lezer ziet. Bij relaxed alignment hebben de domeinen hetzelfde organisatiedomein. Bij strict alignment zijn ze identiek. Relaxed is de standaard, en de tags adkim en aspf stellen dit in voor DKIM en SPF.

Met de tag rua geeft de domeineigenaar een adres op voor aggregatierapporten. Die rapporten zijn XML-documenten die ontvangers sturen, beschreven in RFC 9990. Ontbreekt de tag rua, dan mogen ontvangers geen aggregatierapporten maken. RFC 9991 beschrijft de foutrapporten, met details over individuele berichten die niet slaagden.

Rapportage helpt bij het invoeren van een DMARC-beleid. In de aggregatierapporten zie je welke servers mail versturen die zich voordoet als jouw domein. Daar kunnen ook legitieme afzenders tussen zitten die je was vergeten, zoals een marketingtool, een ticketsysteem of een HR-pakket.

Hoe werken SPF, DKIM en DMARC samen? Een voorbeeld

Stel dat een organisatie het domein voorbeeld.nl gebruikt en haar nieuwsbrieven laat versturen door een externe nieuwsbriefdienst. In DNS staat een SPF-record dat die dienst toestaat via include. De dienst voegt daarnaast een DKIM-handtekening toe met d=voorbeeld.nl, onder een eigen selector. De DMARC-policy van voorbeeld.nl staat op reject.

Een aanvaller stuurt vanaf een eigen server een mail met als afzender directie@voorbeeld.nl. De ontvangende server doet dan het volgende:

1. SPF: de server van de aanvaller staat niet in het record van voorbeeld.nl, dus de uitkomst is fail.
2. DKIM: er is geen geldige handtekening van voorbeeld.nl, dus er slaagt geen DKIM-controle met het domein.
3. DMARC: noch SPF noch DKIM slaagt met een overeenkomend domein. De ontvanger kan het reject-beleid toepassen en het bericht weigeren.

De echte nieuwsbrief slaagt wel. De nieuwsbriefdienst staat in het SPF-record, en de DKIM-handtekening met d=voorbeeld.nl komt overeen met het domein in de From-header, dus DMARC is geslaagd. SPF en DKIM zeggen elk iets over een server of een handtekening. DMARC koppelt dat aan het domein dat de lezer ziet.

Technische controles dekken niet alles. Een aanvaller kan een domein registreren dat sterk lijkt op het jouwe, een zogenaamd lookalike-domein, en daar wel correct SPF, DKIM en DMARC voor instellen. Training van medewerkers en procedures voor betalingen blijven daarom nodig. Over het beschermen van accounts lees je meer bij MFA en passkeys.

Wat is verplicht in Nederland?

Het Forum Standaardisatie zet SPF, DKIM en DMARC op de lijst met de status "Verplicht ('Pas toe of leg uit')" voor overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-)publieke sector. Voor SPF geldt dat het moet worden toegepast op alle overheidsdomeinnamen, ook op domeinen waarvan geen e-mail wordt verzonden. DKIM staat sinds het besluit van 15 juni 2012 op de lijst. De status geldt voor overheden en (semi-)publieke instellingen, zie de Forum-pagina's voor SPF, DKIM en DMARC.

Het NCSC schrijft dat het gebruik van SPF, DKIM en DMARC voor overheidsorganisaties verplicht is en voor alle andere organisaties een dringend advies. Dat advies geldt voor alle domeinen, ook voor domeinen waarmee geen mail wordt verzonden. Het NCSC beveelt aan om reject als beleid toe te passen, en het zegt dat SPF op zichzelf nog geen effectieve bescherming tegen e-mailspoofing biedt. Lees het advies op de NCSC-pagina over domeinnamen.

Organisaties die onder de Cyberbeveiligingswet vallen, vinden de wetgeving uitgelegd op NIS2 en de Cyberbeveiligingswet. Wie bij een overheidsorganisatie werkt, vindt het kader voor informatiebeveiliging in de BIO-baseline. Werk bij een overheid vind je onder meer bij de Rijksoverheid en bij gemeenten en provincies.

Hoe voer je SPF, DKIM en DMARC in?

De volgorde verschilt per organisatie en hangt af van het aantal afzenders. Zo kun je te werk gaan:

1. Maak een overzicht van alle systemen die mail versturen namens je domein, ook die van leveranciers. Denk aan de website, het CRM, de nieuwsbriefdienst, het ticketsysteem en het HR-pakket.
2. Publiceer een SPF-record dat precies die afzenders toestaat. Let op de grens van 10 DNS-opzoekingen, want bij overschrijding is het resultaat permerror.
3. Zet DKIM aan bij elk systeem dat mail verstuurt, met een eigen selector per systeem.
4. Publiceer een DMARC-record met het beleid none en een rua-adres, zodat je rapporten ontvangt zonder dat mail wordt geweigerd.
5. Lees de rapporten en repareer legitieme afzenders die falen. Meer over het analyseren van logs lees je bij SIEM uitgelegd.
6. Scherp het beleid aan naar quarantine en daarna naar reject, want het NCSC adviseert reject. Controleer je domein met de e-mailtest op internet.nl.

Let op: een verkeerde instelling van SPF of DKIM kan legitieme mail blokkeren. Begin daarom met rapportage en weiger pas daarna. Ook domeinen waarmee je geen mail verstuurt, kun je beschermen, zodat ze niet gebruikt worden als afzender. De NCSC-pagina over e-mailbeveiligingsstandaarden beschrijft de werking van DKIM en DMARC en is een goede naslag bij de inrichting.

Wie werkt met e-mailbeveiliging?

Meerdere rollen raken aan deze standaarden. Een security engineer voert de DNS-instellingen en de rapportage uit en bewaakt de maildomeinen, zie ook vacatures voor security engineers. Een SOC-analist herkent phishing en kijkt naar afgewezen of verdachte mail. Een network security engineer kan er ook mee te maken krijgen, omdat mailverkeer over het netwerk loopt. Een compliance officer of information security officer stelt het beleid op rond de verplichte standaarden bij de overheid. Het bredere vakgebied staat op de pagina over cybersecurity.