E-mailbeveiliging uitgelegd: SPF, DKIM, DMARC, DNSSEC en DANE

Een e-mail met als afzender [email protected] kan van iedereen komen. Het protocol waarmee mail wordt verstuurd stamt uit 1982 en controleert niet wie er achter de afzender zit. Criminelen weten dat: bij CEO-fraude en factuurfraude sturen ze precies zo’n mail, met uw naam erboven. Vijf standaarden lossen dat op. Ze zijn niet nieuw en niet duur, maar wel precies in de volgorde waarin u ze invoert.

Twee vragen, vijf standaarden

Het helpt om ze in twee groepen te zien. SPF, DKIM en DMARC beantwoorden de vraag: mag deze mail namens dit domein verstuurd worden? Dat beschermt de ontvangers van uw mail tegen vervalsing. DNSSEC en DANE beantwoorden een andere vraag: komt mail voor mij bij de juiste server aan, over een verbinding die niemand kan afluisteren? Dat beschermt de mail die u ontvangt.

Een vergelijking met gewone post maakt het concreet. SPF is de lijst met postkantoren die uw brieven mogen versturen. DKIM is het lakzegel op de envelop. DMARC is de instructie aan de voordeur van de ontvanger: klopt het zegel niet, gooi de brief dan weg, en laat me weten wie het probeerde. DNSSEC is een telefoonboek met een notarisstempel, zodat niemand een vals adres kan invullen. En DANE zet in dat telefoonboek ook welk slot er op de deur zit, zodat niemand er ongemerkt een nepdeur tussen zet.

Waarom nu

Er zijn drie redenen om dit niet langer te laten liggen. De eerste is fraude: zonder DMARC op p=reject kan iedereen uw domein gebruiken in phishing, en die mail komt vaak gewoon aan. De tweede is bezorging: Gmail en Yahoo eisen sinds 2024 SPF, DKIM en DMARC van partijen die veel mail sturen, en Microsoft doet dat sinds mei 2025 ook voor Outlook.com, Hotmail en Live.com bij meer dan 5.000 berichten per dag. Mail die niet voldoet, wordt geweigerd. De derde geldt voor de overheid: SPF, DKIM, DMARC, DNSSEC en STARTTLS met DANE staan op de lijst ‘pas toe of leg uit’ van het Forum Standaardisatie. Voor ministeries, gemeenten, provincies en waterschappen is het dus geen keuze.

Waar staat u nu? Test het hieronder: u ziet per standaard hoe uw domein ervoor staat en hoe u het oplost.

SPF: wie mag er namens u mailen?

Met SPF (Sender Policy Framework) publiceert u in DNS een lijst van servers die mail voor uw domein mogen versturen. Voor een organisatie die alleen Microsoft 365 gebruikt, is dat één regel: v=spf1 include:spf.protection.outlook.com -all. De -all aan het eind betekent: alles wat niet op de lijst staat, hoort er niet bij.

SPF heeft twee zwakke plekken. Het controleert het technische afzenderadres op de envelop, niet het adres dat de ontvanger in zijn mailprogramma ziet. En het breekt bij doorsturen, omdat de doorstuurserver niet op uw lijst staat. Daarnaast mag een SPF-record maximaal tien DNS-opzoekingen veroorzaken. Wie elke nieuwsbriefdienst en elk CRM-pakket met een include: toevoegt, zit daar snel boven, en dan faalt SPF voor álle mail.

DKIM: een handtekening op elk bericht

DKIM (DomainKeys Identified Mail) zet een digitale handtekening op elke uitgaande mail. De bijbehorende publieke sleutel staat in uw DNS. De ontvanger controleert daarmee twee dingen: dat de mail echt van uw domein komt, en dat er onderweg niets aan is veranderd. Omdat de handtekening in het bericht zelf zit, overleeft DKIM doorsturen meestal wel.

In Microsoft 365 zet u DKIM aan per domein, met twee CNAME-records in DNS. Kies dan meteen voor 2048-bits sleutels en vernieuw de sleutels af en toe. Vergeet de andere diensten niet: ook uw nieuwsbrieftool en factuursysteem moeten met úw domein ondertekenen, niet met dat van de leverancier.

DMARC: het sluitstuk

SPF en DKIM zeggen iets over een domein, maar niet per se over het domein dat de ontvanger als afzender ziet. DMARC (Domain-based Message Authentication, Reporting and Conformance) legt die koppeling: een mail slaagt alleen als SPF of DKIM klopt voor hetzelfde domein als het zichtbare afzenderadres. Dat heet alignment, en het is precies wat phishing met uw domein tegenhoudt.

Sinds mei 2026 geldt RFC 9989 (DMARCbis), samen met RFC 9990 en 9991 voor de rapporten. Twee dingen zijn nieuw en meteen bruikbaar. np=reject weigert mail van subdomeinen die niet bestaan, zoals facturen.uwgemeente.nl. Dat mag vanaf de eerste dag, ook zolang het hoofddomein nog op p=none staat. En t=y is de teststand: ontvangers passen het beleid één stap lichter toe, dus quarantine werkt als none en reject als quarantine. Het oude pct-percentage is uit de standaard en hoort niet meer in een nieuw record.

DMARC doet nog twee dingen. U bepaalt wat de ontvanger doet met mail die niet klopt: niets (p=none), naar spam (p=quarantine) of weigeren (p=reject). En u krijgt rapporten: elke grote mailprovider stuurt dagelijks een overzicht van alle mail die met uw domein als afzender bij hen binnenkwam. Daarin ziet u ook die vergeten nieuwsbriefdienst, en de fraudeur in een ander land.

Die rapporten komen als XML-bestanden binnen, tientallen per dag. Niemand leest die met de hand. In onze ervaring is DMARC Advisor de beste tool om ze te verwerken: een Nederlands platform dat de rapporten omzet in overzichten per bron, waarschuwt bij afwijkingen en u stap voor stap naar p=reject helpt. Het wordt gebruikt door bedrijven en overheden in Europa.

Vergeet de domeinen die niet mailen

Bijna elke organisatie heeft domeinen die nooit mailen: de .com naast de .nl, een oude merknaam, een campagnesite. Die zijn favoriet bij fraudeurs, juist omdat niemand erop let. De oplossing is eenvoudig. Zet er drie records op: v=spf1 -all (niemand mag mailen), een DMARC-record met p=reject; sp=reject, en een zogenaamd null-MX-record (0 .) dat zegt dat dit domein geen mail ontvangt.

DNSSEC en DANE: de weg naar uw mailbox

Mailservers versleutelen hun verbinding met STARTTLS, maar alleen als het lukt. Een aanvaller die tussen twee servers zit, kan de versleuteling onderdrukken of zich voordoen als uw mailserver, en de verzender merkt daar niets van. DNS zelf is ook niet te vertrouwen: zonder bescherming kan iemand een vals antwoord geven op de vraag welke server uw mail ontvangt.

DNSSEC zet een digitale handtekening op de antwoorden van uw DNS, zodat een verzender kan controleren dat het adres van uw mailserver echt is. DANE bouwt daarop voort: het publiceert in die ondertekende DNS welk certificaat uw mailserver gebruikt. Een verzender die DANE ondersteunt, weigert dan af te leveren bij een server met een ander certificaat, en valt ook niet terug op een onversleutelde verbinding. DANE zonder DNSSEC bestaat dus niet.

Voor Exchange Online is uitgaande DANE al jaren standaard aan. Voor inkomende mail moet u eerst uw eigen domein met DNSSEC ondertekenen en daarna uw MX-record verhuizen naar Microsofts ondertekende mailservers. Hoe dat precies gaat, staat in onze guide DNSSEC en DANE voor Exchange Online. Een alternatief voor DANE is MTA-STS, dat Gmail gebruikt; veel organisaties zetten beide aan.

De volgorde die werkt

1. Inventariseer wie er namens u mailt. Microsoft 365, maar ook de nieuwsbrief, het CRM, het zaaksysteem, de factuursoftware, de printer die scans mailt en het contactformulier op de website.
2. Zet SPF goed, in één record, onder de tien opzoekingen.
3. Zet DKIM aan voor Microsoft 365 en voor elke andere dienst.
4. Publiceer DMARC met p=none en np=reject en lees twee tot vier weken de rapporten, bijvoorbeeld in DMARC Advisor.
5. Ga via p=quarantine naar p=reject, en test elke stap eerst een week met t=y (RFC 9989). Gebruik geen pct meer.
6. Beveilig de domeinen die niet mailen met de drie records hierboven.
7. Onderteken uw zone met DNSSEC en zet daarna DANE aan.
8. Controleer het resultaat met onze e-mailbeveiligingscheck, en blijf de DMARC-rapporten volgen.

De stappen met alle DNS-records, PowerShell-opdrachten en controles voor Microsoft 365 staan in de guide SPF, DKIM en DMARC voor Microsoft 365.

Fouten die wij vaak zien

• Twee SPF-records op één domein. Dan is SPF ongeldig. Voeg ze samen tot één regel.
• DKIM alleen op het onmicrosoft.com-domein. Microsoft ondertekent dan wel, maar met het verkeerde domein, en DMARC-alignment faalt.
• Rapporten die niemand leest. Een DMARC-record zonder opvolging is een vinkje, geen beveiliging.
• Te snel naar reject. En dan een maand later ontdekken dat de salarisstroken niet meer aankomen.
• DNSSEC op de registrar vergeten. Zonder DS-record bij de registrar telt de ondertekening niet, en werkt DANE niet.

Tot slot

E-mailbeveiliging is geen project van een jaar. Voor de meeste organisaties is het in een paar weken rond, waarvan de meeste tijd opgaat aan wachten op DMARC-rapporten. Het resultaat is concreet: fraudeurs kunnen uw domein niet meer gebruiken, uw mail komt beter aan, en u voldoet aan wat de overheid en de grote mailproviders vragen. Wilt u weten waar u staat, of hulp bij de overstap naar p=reject? Neem gerust contact met ons op.