Terug naar kennisbank

SPF, DKIM en DMARC uitgelegd: waarom ook domeinen zonder e-mail deze records nodig hebben

Gepubliceerd op 17 juli 2026

Een phishingmail versturen die van uw domein lijkt te komen, kost een aanvaller niets. Het From-veld van een e-mail is een vrij tekstveld, net als de afzender op een envelop: iedereen kan er alles inzetten. Het e-mailprotocol SMTP stamt uit 1982 en controleert zelf niets. Alles wat e-mail vandaag enigszins betrouwbaar maakt, is er later bovenop gebouwd, en het staat in uw DNS: SPF, DKIM en DMARC.

Dit artikel legt die drie records uit met concrete voorbeelden, plus de blinde vlek die vrijwel elke uitleg overslaat: domeinen die helemaal geen e-mail versturen. Juist die worden graag misbruikt, en juist die zijn met drie kleine records volledig dicht te zetten.

Hoe een ontvangende mailserver beslist

Als een mailserver een bericht binnenkrijgt dat beweert van uwdomein.nl te komen, zoekt hij in de DNS van dat domein op wat de eigenaar daarover heeft vastgelegd. Mag deze verzendende server dat? Klopt de handtekening? En wat wil de eigenaar dat ik doe als het niet klopt? De drie kernrecords beantwoorden precies die drie vragen. Staan de records er niet, dan heeft de ontvanger geen grond om iets te weigeren, en belandt een vervalsing verrassend vaak gewoon in de inbox.

SPF: wie mag namens uw domein versturen

Een SPF-record (Sender Policy Framework) is een TXT-record op het domein zelf, met daarin de lijst van servers die namens het domein mogen versturen:

uwdomein.nl.  TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.10 -all"

Twee dingen die vaak misgaan. Ten eerste mag een SPF-controle maximaal 10 DNS-opzoekingen kosten; wie te veel include-regels stapelt (elke SaaS-dienst wil erin), overschrijdt die grens en dan faalt SPF geruisloos. Ten tweede controleert SPF het envelop-afzenderadres, niet het From-adres dat de ontvanger in beeld krijgt. Een aanvaller kan dus SPF laten slagen op een eigen domein terwijl het zichtbare From-veld uw domein toont. Dat gat dicht pas DMARC.

DKIM: de cryptografische handtekening

DKIM (DomainKeys Identified Mail) laat de verzendende server elk bericht ondertekenen met een privésleutel. De bijbehorende publieke sleutel staat in de DNS, onder een zogeheten selector:

selector1._domainkey.uwdomein.nl.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."

De ontvanger haalt de publieke sleutel op en controleert de handtekening over de belangrijkste headers en de berichtinhoud. Klopt die, dan staat vast dat het bericht via een geautoriseerde server is verstuurd en onderweg niet is aangepast. Anders dan SPF overleeft DKIM ook het doorsturen van mail, omdat de handtekening in het bericht zelf meereist.

De selector (hier selector1) bepaalt uw mailprovider; elke dienst die namens u mailt krijgt een eigen selector en sleutelpaar. In de praktijk is DKIM instellen meestal een kwestie van de records overnemen die uw provider klaarzet.

DMARC: beleid, rapportage en de koppeling met het From-adres

DMARC (Domain-based Message Authentication, Reporting and Conformance) is het sluitstuk. Het staat als TXT-record op het subdomein _dmarc:

_dmarc.uwdomein.nl.  TXT  "v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc-rapporten@uwdomein.nl"

DMARC doet drie dingen die SPF en DKIM los van elkaar niet doen.

Het bindt de controles aan het zichtbare afzenderadres. Een bericht doorstaat DMARC alleen als SPF of DKIM slaagt én het gecontroleerde domein overeenkomt met het domein in het From-veld. Dat heet alignment. Daarmee is de truc van hierboven (SPF laten slagen op een ander domein) van tafel.

Het geeft de ontvanger een beleid mee. Het veld p= kent drie standen, en dat is bewust een groeipad:

  1. p=none: alleen rapporteren, niets tegenhouden. De juiste startstand om eerst te zien wie er allemaal namens uw domein verstuurt.
  2. p=quarantine: berichten die falen gaan naar de spammap.
  3. p=reject: berichten die falen worden geweigerd. Dit is het einddoel.

Een record dat jarenlang op p=none blijft staan, is een meetinstrument, geen slot. Plan de stap naar quarantine en daarna reject zodra de rapportages laten zien dat uw legitieme mailstromen kloppen.

Het levert rapportage. Via rua= ontvangt u dagelijks geaggregeerde XML-rapporten van grote mailproviders: welke servers verstuurden namens uw domein, en wat was het resultaat van de controles. Die rapporten zijn onmisbaar om veilig naar reject te groeien, en leesbaarder via een van de vele (ook gratis) DMARC-rapportagetools dan met de hand.

Twee verdiepingspunten die de meeste uitlegpagina's overslaan. Het veld sp= bepaalt het beleid voor subdomeinen; zonder sp= erven subdomeinen het beleid van p=. Wie expliciet sp=reject zet, sluit ook factuur.uwdomein.nl en elk ander verzonnen subdomein af, een geliefde route voor phishers. En met adkim=s en aspf=s zet u de alignment op strikt: dan moet het domein exact overeenkomen in plaats van dat een subdomein ook telt. Strikt is veiliger, maar controleer eerst in de rapportages of geen legitieme stroom erdoor breekt.

De blinde vlek: domeinen die nooit mailen

Nu het deel waar de meeste organisaties nooit aan denken. Vrijwel elke organisatie heeft domeinen die geen e-mail versturen: defensieve registraties van de merknaam met andere extensies, het domein van een oude campagne of een gestopte productlijn, de holding-bv, het domein dat ooit voor een project is vastgelegd. De redenering is dan al snel: geen mail, dus geen mailrecords nodig.

Die redenering klopt niet, want de aanvaller vraagt uw domein geen toestemming. Phishing uit naam van oudecampagne.nl werkt technisch precies even goed als phishing uit naam van uw hoofddomein, en het merk erachter is hetzelfde. Sterker nog: juist het domein zónder records is aantrekkelijk, omdat de ontvangende server dan niets heeft om de vervalsing op te weigeren. Uw hoofddomein met strak DMARC-beleid is dicht; het vergeten zusje ernaast staat wagenwijd open.

Een domein dat nooit mailt, is gelukkig ook het makkelijkst te beveiligen. Drie records, eenmalig instellen, klaar:

1. Een SPF-record dat niemand toestaat:

uwdomein.nl.  TXT  "v=spf1 -all"

Geen enkele server mag namens dit domein versturen. Elke poging faalt de SPF-controle hard.

2. Een null MX-record (RFC 7505):

uwdomein.nl.  MX  0 .

Een MX-record met prioriteit 0 en als bestemming een enkele punt is de gestandaardiseerde manier om te zeggen: dit domein ontvangt geen e-mail. Verzendende servers breken de poging direct af in plaats van dagen te blijven aankloppen, en het domein is als antwoordadres in phishing meteen ongeloofwaardig.

3. Een DMARC-record dat alles weigert, ook op subdomeinen:

_dmarc.uwdomein.nl.  TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-rapporten@uwbedrijf.nl"

Omdat er geen legitieme mail bestaat, hoeft hier geen groeipad: direct reject, strikt, inclusief subdomeinen. De rua= mag naar een postbus op uw hoofddomein wijzen en is ook hier zinvol: elke binnenkomende rapportregel is per definitie een misbruikpoging, en dat wilt u weten.

Wie het helemaal af wil maken, voegt een leeg wildcard-DKIM-record toe (*._domainkey.uwdomein.nl. TXT "v=DKIM1; p="), dat elke denkbare DKIM-selector expliciet ongeldig verklaart.

Dit rijtje geldt voor élk geregistreerd domein, niet alleen de domeinen die u dagelijks in beeld heeft. In de praktijk is de inventarisatie het echte werk: welke domeinen bezit de organisatie eigenlijk allemaal? Vergeten registraties zijn een klassiek stuk schaduw-IT in uw externe aanvalsoppervlak, en wat u niet in beeld heeft, kunt u ook niet dichtzetten.

Moderne aanvullingen: transport, logo en certificaten

SPF, DKIM en DMARC regelen wie er mag versturen. Een tweede generatie standaarden beveiligt het transport en de presentatie. Eerlijk over de prioriteit: zolang de drie kernrecords niet op orde zijn, hebben deze aanvullingen weinig zin. Daarna zijn ze wel degelijk de moeite waard.

MTA-STS en TLS-RPT: TLS afdwingen tussen mailservers. E-mail tussen servers wordt meestal wel versleuteld (STARTTLS), maar die versleuteling is standaard vrijblijvend: een aanvaller die het verkeer kan manipuleren, kan de opwaardering naar TLS eruit strippen. MTA-STS laat u publiceren dat uw domein alléén mail over geverifieerd TLS accepteert. Het bestaat uit een TXT-record plus een beleidsbestand op een vast HTTPS-adres:

_mta-sts.uwdomein.nl.  TXT  "v=STSv1; id=20260717000000"

met op https://mta-sts.uwdomein.nl/.well-known/mta-sts.txt een bestand dat onder meer mode: enforce en uw mailservers bevat. De bijbehorende rapportagestandaard TLS-RPT meldt u wanneer bezorging aan die eis niet voldeed:

_smtp._tls.uwdomein.nl.  TXT  "v=TLSRPTv1; rua=mailto:tls-rapporten@uwdomein.nl"

DANE: TLS verankerd in DNSSEC. DANE bereikt hetzelfde doel als MTA-STS, maar dan via een TLSA-record in de DNS zelf, cryptografisch beschermd door DNSSEC in plaats van door een HTTPS-bestand. Een voorbeeld voor een mailserver:

_25._tcp.mail.uwdomein.nl.  TLSA  3 1 1 8bd1c...

DANE vereist werkende DNSSEC op het domein en is daarmee de robuustere maar veeleisender variant. In Nederland is dit geen exotische standaard: STARTTLS en DANE staan, net als SPF, DKIM, DMARC en DNSSEC, op de pas-toe-of-leg-uit-lijst van Forum Standaardisatie voor de overheid, en internet.nl test er standaard op. Grote Nederlandse ontvangers ondersteunen het al jaren.

BIMI: uw logo bij geauthenticeerde mail. BIMI toont uw merklogo naast uw berichten in onder meer Gmail, Yahoo en Apple Mail (Outlook doet niet mee). Het vereist DMARC op afdwingniveau (p=quarantine met pct=100, of p=reject), een logo in het SVG Tiny PS-formaat en voor de meeste providers een certificaat: een VMC (op basis van een geregistreerd merk) of sinds kort een CMC (op basis van aantoonbaar langdurig logogebruik). BIMI is de kers op de taart: het beloont goede authenticatie met zichtbaarheid, maar het beveiligt zelf niets.

CAA: welke uitgevers certificaten mogen leveren. Geen mailrecord, maar hetzelfde principe van vastleggen wie iets namens uw domein mag:

uwdomein.nl.  CAA  0 issue "letsencrypt.org"

Hiermee mag alleen de genoemde certificaatuitgever certificaten voor uw domein uitgeven, wat het risico op ten onrechte uitgegeven certificaten verkleint.

DNSSEC als fundament. Alle records hierboven staan in de DNS, en zonder DNSSEC zijn DNS-antwoorden te vervalsen. DNSSEC ondertekent uw DNS-zone, zodat een ontvanger zeker weet dat het SPF- of TLSA-record dat hij ophaalt echt van u komt. Voor DANE is het een harde vereiste, voor al het overige een verstandig fundament. Bij de meeste Nederlandse registrars is het een vinkje.

Zelf controleren, en daarna bijhouden

U hoeft dit niet op gezag aan te nemen: internet.nl, een gratis dienst van de Nederlandse overheid, test uw domein op vrijwel alles uit dit artikel, van SPF en DMARC tot STARTTLS, DANE en DNSSEC. Doe die test voor al uw geregistreerde domeinen, niet alleen het hoofddomein. Waarom die gratis check en doorlopende monitoring elkaar aanvullen, leest u in internet.nl is gratis, wanneer heeft u Exposentry nodig.

Bedenk daarbij dat deze records ook voor een aanvaller zichtbaar zijn: DNS is openbaar, en ontbrekende mailrecords staan in elke verkenning van uw domein pijnlijk duidelijk aangegeven. Wat er verder allemaal van buitenaf zichtbaar is, beschreven we in wat ziet een aanvaller van je domein.

De scans van Exposentry controleren deze records mee: ontbreekt SPF, DKIM of DMARC op een domein, dan staat dat als bevinding in uw rapportage, met verwijzing naar dit artikel. Het instellen zelf doet u (of uw IT-partner) bij uw DNS-beheerder, dat is eenmalig werk. De waarde van monitoring zit in het bijhouden: records die per ongeluk sneuvelen bij een DNS-migratie, een nieuw domein dat zonder records live gaat, een DMARC-beleid dat op p=none is blijven hangen. Precies het soort stille achteruitgang dat een maandelijkse rapportage wél opmerkt en een eenmalige check niet.

Geschreven door Edward Hasekamp, oprichter van Exposentry en core-maintainer van het open-source OpenKAT-project. Zie het project op GitHub en het profiel op github.com/hasecon. Exposentry levert EU-soevereine, forensisch onderbouwde vulnerability monitoring op basis van OpenKAT. Meer artikelen in de Kennisbank.