Terug naar kennisbank

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

Gepubliceerd op 17 juli 2026 · Bijgewerkt op 26 oktober 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.

Wat deze records bijzonder maakt: ze zijn extern meetbaar. Anders dan een beleidsdocument of een ingevulde vragenlijst toont u SPF, DKIM en DMARC niet op papier aan: ze staan in de openbare DNS, en iedereen die uw domein bevraagt, ook een aanvaller, leest ze zo uit. Wat er staat, geldt; wat ontbreekt, valt in elke verkenning meteen op.

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"

• include: verwijst naar de SPF-lijst van een dienst die voor u verstuurt, zoals Google Workspace of Microsoft 365.
• ip4: (of ip6:) staat een specifiek IP-adres toe, bijvoorbeeld uw eigen mailserver of een applicatie die facturen mailt.
• -all aan het einde zegt: al het overige is niet toegestaan. De zachtere variant ~all ("softfail") markeert overtreders slechts als verdacht; kies waar mogelijk voor -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 eenvoudig doorsturen vaak wél, omdat de handtekening in het bericht zelf meereist, al kan een mailinglijst of forwarder die de inhoud onderweg aanpast de handtekening alsnog breken.

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 doorgaans 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.

Deze records bepalen ook of uw eigen mail aankomt

SPF, DKIM en DMARC houden niet alleen misbruikers buiten de deur, ze bepalen ook of uw eigen legitieme post aankomt. Correct ingestelde records verbeteren de kans dat uw nieuwsbrieven, facturen en offertes in de inbox belanden in plaats van in de spammap. Ontbreken ze of staan ze fout, dan worden diezelfde berichten sneller als verdacht weggezet. Sinds februari 2024 maken Gmail en Yahoo dit expliciet: wie grotere volumes verstuurt (bij Gmail vanaf 5.000 berichten per dag naar Gmail-adressen) moet aantoonbaar SPF, DKIM én een DMARC-record hebben, anders wordt de mail geweigerd of als spam behandeld. Authenticatie is daarmee niet langer alleen een beveiligingsmaatregel tegen vervalsing, maar een harde voorwaarde voor bezorging van uw eigen mail.

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 die de standaard volgen, 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 bij ondersteunende ontvangers elke DKIM-selector 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. Meerdere grote Nederlandse ontvangers ondersteunen het.

BIMI: uw logo bij geauthenticeerde mail. BIMI toont uw merklogo naast uw berichten in onder meer Gmail, Yahoo en Apple Mail; Outlook toont deze logo's vooralsnog niet, dus controleer de actuele status bij Microsoft. 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 het Platform Internetstandaarden (een publiek-privaat samenwerkingsverband dat mede door de overheid wordt ondersteund), 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. Wilt u alleen de mailrecords zien, met per record de uitleg, dan doet de DMARC-check dat direct op het scherm voor het domein van uw zakelijke e-mailadres. 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.

Deze mail- en DNS-records worden gecontroleerd door de boefjes van OpenKAT, de open-source scanner van de Nederlandse overheid waar Exposentry op draait; Edward Hasekamp, oprichter van Hasecon, draagt als collaborator bij aan het OpenKAT-project. 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 collaborator op 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.