In this post:
DNS-authenticatie is de set records die je in de DNS van je domein publiceert, zodat ontvangende mailservers kunnen nagaan of een e-mail die in jouw naam is verstuurd echt van jou komt en onderweg niet is aangepast. In de praktijk gaat het om drie records die als team werken, SPF, DKIM en DMARC, met een paar buren (MX, reverse DNS en BIMI) die dezelfde vraag raken.
Er bestaat geen losse schakelaar die DNS-authenticatie heet. Elk record beantwoordt een eigen vraag, en een ontvanger vertrouwt de uitkomst pas als die antwoorden wijzen naar het domein in de From-regel die je ontvanger echt ziet. Die laatste voorwaarde heet alignment, en daar gaan de meeste setups onderuit. Elk record ziet er los bekeken goed uit, en toch meldt DMARC een fail.
De fouten maken ook geen lawaai. Een facturatietool die vorig voorjaar zonder DKIM-sleutel is gekoppeld, blijft versturen, ontvangers blijven zijn mail filteren, en het eerste teken dat iemand opvalt, is een klant die vraagt waarom zijn factuur in spam belandde.
TL;DR
SPF somt de servers op die voor je domein mogen versturen, DKIM ondertekent elk bericht met een sleutel die in je DNS staat, en DMARC checkt of minstens een van de twee is geslaagd voor het domein in het zichtbare From-adres. Daarna vertelt DMARC ontvangers wat ze moeten doen als geen van beide slaagde.
Alignment is waar het om draait. Een tool die onder zijn eigen domein slaagt voor SPF en DKIM, levert jouw domein niets op, en DMARC laat het bericht zakken.
DMARC begon als RFC 7489, een informatief document uit 2015. De herziening van de IETF is nu RFC 9989, een Proposed Standard van mei 2026, die de oude pct-tag vervangt door een eenvoudige testvlag.
Richt de records in een vaste volgorde in: inventariseer je afzenders, dan MX, SPF, DKIM voor elke tool, een testbericht, DMARC op p=none met rapporten, en daarna quarantine en reject. Google raadt minstens een week op none aan voordat je aanscherpt. BIMI komt als laatste, omdat het enforcement nodig heeft.
Elk domein voor cold outreach heeft een eigen complete set nodig voordat de warmup begint, en DMARC op je hoofddomein doet niets tegen lookalike-domeinen.
De gebruikelijke fouten zijn onzichtbaar: een tool die ontbreekt in SPF, DKIM op maar een deel van de platforms, DMARC dat jarenlang op none blijft staan, en passes onder het verkeerde domein. In de aggregaatrapporten komen ze boven.
Een pass bewijst wie de mail heeft verstuurd. Of hij in de inbox belandt, hangt nog steeds af van reputatie, de lijst en hoe ontvangers reageren.
Wat DNS-authenticatie omvat, record voor record
Als mensen het over het authenticeren van e-mail hebben, komen er zes soorten DNS-records langs. Drie doen het authenticeren, en drie staan eromheen.
SPF. Een TXT-record met de servers en diensten die voor je domein mogen versturen. Het wordt gecheckt tegen het verborgen retouradres voor bounces, en naar de From-regel kijkt het niet. Het SPF-artikel behandelt de syntax en de limiet van 10 lookups.
DKIM. Een public key in je DNS waarmee ontvangers een handtekening kunnen verifiëren die je verzendplatform aan elk bericht toevoegt. Elke tool krijgt een eigen sleutel onder een eigen selector, en het DKIM-artikel behandelt sleutels, selectors en rotatie.
DMARC. Een TXT-record op _dmarc.yourdomain dat SPF en DKIM koppelt aan het zichtbare From-domein, een beleid voor fouten vastlegt en ontvangers vraagt je rapporten te sturen. DMARC is het record dat de andere twee omzet in bescherming.
MX. Zegt waar mail voor je domein moet worden afgeleverd. Het authenticeert niets, maar een verzenddomein zonder MX-record kan geen replies of bouncemeldingen ontvangen, en lijsttools gebruiken het voor MX-validatie van de adressen die je mailt.
PTR, oftewel reverse DNS. Koppelt het IP-adres van een verzendende server terug aan een hostnaam. De afzenderrichtlijnen van Google eisen geldige forward en reverse DNS voor verzendende IP's. Verstuur je via Google Workspace of Microsoft 365, dan zijn die IP's en hun PTR-records van het platform.
BIMI. Een optioneel record waarmee mailapps die het ondersteunen je logo naast geauthenticeerde mail tonen. Het werkt pas als DMARC op enforcement staat.
Waarom moest authenticatie later aan e-mail worden toegevoegd?
Met het protocol dat mail tussen servers verplaatst, kan de afzender elk adres in het From-veld zetten, en decennialang checkte niets dat. Uit dat gat zijn phishing en spoofing gegroeid: een bericht kon er precies uitzien alsof het van je bank of je financieel directeur kwam, en de ontvangende server had geen test om uit te voeren.
Elk record dichtte een deel van dat gat. Met SPF kon een domein zijn afzenders noemen, met DKIM kon het zijn berichten ondertekenen, en DMARC koppelde die twee eindelijk aan het adres dat een mens leest. Mail die slaagt, is zeer waarschijnlijk echt, en mail die faalt, kun je met argwaan behandelen in plaats van te gokken. Precies die scheiding wilden de providers hebben voordat ze het gingen afdwingen.
Hoe SPF, DKIM en DMARC een bericht aan elkaar doorgeven
De makkelijkste manier om te zien hoe de drie in elkaar passen, is één bericht van een Nederlands bedrijf, yourcompany.nl, door drie situaties te volgen.
Mail vanuit Google Workspace. Anna verstuurt vanaf anna@yourcompany.nl. Het return path staat op yourcompany.nl, dus SPF slaagt voor yourcompany.nl. Google ondertekent met d=yourcompany.nl, dus DKIM slaagt voor hetzelfde domein. Beide zijn aligned met het From-adres, en DMARC slaagt.
Mail vanuit een webinartool die niemand goed heeft gekoppeld. De tool verstuurt uitnodigingen als anna@yourcompany.nl, maar zijn return path staat op het eigen bouncedomein van de tool en hij ondertekent met d=webinartool.example. SPF slaagt, voor het domein van de tool. DKIM slaagt, voor het domein van de tool. Geen van beide komt overeen met yourcompany.nl, dus DMARC faalt, en onder een reject-beleid komt de uitnodiging nooit aan.
Dezelfde tool na de fix. Iemand publiceert de DKIM-sleutel van de tool onder yourcompany.nl, en de tool ondertekent nu met d=yourcompany.nl. SPF slaagt nog steeds alleen voor het domein van de tool, maar DMARC heeft genoeg aan één aligned pass, dus het bericht slaagt.
Alignment komt in twee sterktes. Relaxed, de standaard, accepteert een subdomein, dus een handtekening van mail.yourcompany.nl telt mee voor yourcompany.nl. Strict wil een exacte match. Voor de meeste domeinen is relaxed prima.
De tweede situatie komen we het vaakst tegen. De oplossing zit bijna altijd in de instellingen van de tool. Daar staat een pagina om de records van de tool aan je DNS toe te voegen, en die heeft niemand ooit geopend. Een aligned DKIM-handtekening is de moeite waard, ook als SPF al aligned is, want SPF breekt als mail wordt doorgestuurd en een handtekening in het bericht overleeft dat meestal.
DMARC-beleid, rapporten en de standaard van 2026
Een DMARC-record bevat een beleid en een rapportageadres. Het beleid, ingesteld met de p-tag, heeft drie waarden. Met none spreekt de domeineigenaar geen voorkeur uit en behandelen ontvangers fouten zoals ze dat normaal doen. Met quarantine wordt falende mail als verdacht behandeld, en dat betekent meestal de spammap. Met reject wordt falende mail meteen geweigerd.
De rua-tag vertelt ontvangers waar ze aggregaatrapporten naartoe moeten sturen. Dat zijn dagelijkse samenvattingen van elke provider die rapporteert, met de IP-adressen die mail als jouw domein verstuurden, hoeveel berichten elk adres verstuurde en of die slaagden voor SPF, DKIM en alignment. Ze zijn in XML en rauw onprettig om te lezen, dus de meeste teams halen ze door een rapportviewer. Het is ook de enige plek waar je elke dienst ziet die in jouw naam verstuurt.
De standaard zelf is net veranderd. DMARC werd in maart 2015 voor het eerst gepubliceerd als RFC 7489, een informatief document uit de Independent Submission-stream en dus geen IETF-standaard. De herziening van de IETF, bekend als DMARCbis, staat in de IETF-datatracker als RFC 9989, een Proposed Standard van mei 2026, die RFC 7489 vervangt.
Voor de meeste domeineigenaren ziet het record er hetzelfde uit als voorheen. De zichtbare verandering is de pct-tag, waarmee je een beleid op een percentage van de falende mail kon toepassen. RFC 9989 merkt op dat ontvangers die tag zelden nauwkeurig toepasten, tenzij de waarde 0 of 100 was, en vervangt hem door een t-tag die de testmodus gewoon aan- of uitzet.
De volgorde waarin je DNS-authenticatie op een nieuw domein inricht
Elk record leunt op de records ervoor, dus de volgorde telt zwaarder dan de snelheid. Dit is de volgorde die we aanhouden voor elk domein dat mail gaat versturen:
Zet elke afzender op een lijst. Het mailboxplatform, CRM, marketingtool, supportdesk, facturatiesysteem, webinartool en elke tool voor cold email. Een afzender die je hier mist, is de bron van de meeste latere fouten.
Publiceer MX als het domein mail moet ontvangen. Dat geldt voor elk domein dat cold email verstuurt, want replies en bounces moeten ergens heen kunnen.
Publiceer één SPF-record dat elke afzender noemt, en tel de DNS-lookups voordat je publiceert.
Zet DKIM aan in elke tool en publiceer elke sleutel onder een eigen selector, zodat elke tool als jouw domein ondertekent.
Stuur een test naar een mailbox bij een andere provider (een privé-Gmailaccount werkt prima) en bekijk de ruwe headers. De Authentication-Results-header hoort spf=pass en dkim=pass te tonen, met bij allebei je eigen domein.
Voeg DMARC toe op p=none met een rua-adres. De aanbevolen uitrol van DMARC van Google zegt dat je SPF en DKIM minstens 48 uur eerder instelt, een week op none begint en de rapporten dagelijks bekijkt.
Scherp aan naar quarantine en daarna reject, zodra de rapporten laten zien dat elke legitieme bron slaagt en aligned is. De handleiding van Google beschrijft nog steeds hoe je quarantine per percentage opvoert. Volg je die, onthoud dan dat de pct-tag in de nieuwe standaard niet meer bestaat.
Voeg BIMI toe als je dat wilt. De setuppagina voor BIMI van Google vereist een DMARC-beleid van quarantine of reject op 100%, een Verified Mark Certificate of Common Mark Certificate van een externe certificaatautoriteit, en een logo in SVG.
Een eenvoudig domein met een of twee afzenders kan binnen een paar weken op reject staan. Een bedrijfsdomein met tien jaar aan tools achter zich duurt langer, omdat de rapporten steeds afzenders opleveren die niemand zich nog herinnerde.
Wat er verandert voor domeinen voor cold outreach
Elk secundair domein in je infrastructuur voor cold email is een volwaardig domein. Het heeft een eigen SPF nodig, een eigen DKIM-sleutel in het verzendplatform, een eigen DMARC-record en een MX-record, allemaal gepubliceerd en getest voordat de warmup begint. Een domein opwarmen dat zijn checks niet haalt, betekent weken geschiedenis opbouwen op mail die ontvangers niet aan jou konden toeschrijven.
Sinds februari 2024 eisen Gmail en Yahoo SPF, DKIM en DMARC van bulkverzenders, en hun overige regels staan onder e-mail deliverability. Cold domeinen zitten ruim onder de grens voor bulk, maar een domein zonder geschiedenis heeft verder niets wat voor hem instaat, dus ontvangers leunen zwaarder op de records.
Cold domeinen hebben ook een voordeel: ze versturen meestal vanaf één mailboxplatform en één verzendtool, dus er zijn maar twee bronnen om aligned te krijgen. Daardoor breng je ze snel naar enforcement zodra de eerste rapporten schoon terugkomen.
Eén beperking is goed om te kennen. DMARC op reject voor yourcompany.nl houdt iedereen tegen die verstuurt als precies yourcompany.nl. Tegen yourcompany-mail.nl of een andere lookalike doet het niets, en dat is precies wat cold verzenddomeinen zijn. Houd een lijst bij van elke lookalike die je bezit, stuur de website van elk ervan door naar je hoofdsite, en geef domeinen die je bezit maar nooit gebruikt om te versturen een SPF-record van v=spf1 -all en een DMARC-beleid van reject, zodat niemand ze kan lenen.
Waar een setup die af lijkt toch lekt
Een kapot record geeft nooit een foutmelding in je verzendtool. Dit zijn de fouten die steeds weer opduiken in audits, meestal een paar tegelijk:
Een afzender die ontbreekt in SPF. De mail van één tool faalt terwijl al het andere slaagt, dus de gemengde cijfers bewegen nauwelijks.
DKIM op een deel van de platforms. Elke tool die later wordt toegevoegd, opent een nieuw gat tot iemand zijn sleutel publiceert.
DMARC dat onbeperkt op p=none blijft staan. Je verzamelt rapporten en krijgt geen bescherming. We vinden regelmatig domeinen die al jaren op none staan omdat niemand eigenaar was van de volgende stap.
Passes onder het verkeerde domein. SPF en DKIM slagen allebei, voor het domein van een leverancier, dus DMARC faalt. Dit is de webinartool van hierboven.
Een SPF-record boven de lookuplimiet. Tien DNS-lookups is het plafond, en geneste includes tellen mee, dus een record kan voor elk bericht breken als een leverancier zijn eigen record aanpast.
Dat deze fouten blijven hangen, komt deels doordat DNS meestal bij IT ligt, terwijl de deliverability-pijn bij sales en marketing zit. Daardoor is niemand eigenaar van de lijst met afzenders. Maak de DNS-records van een nieuwe tool onderdeel van het aanzetten ervan, en het grootste deel van het gat is dicht.
Lees na enforcement de aggregaatrapporten minstens maandelijks en na elke wijziging in de stack, en neem authenticatie mee in elke outbound deliverability audit. Een bron die ineens begint te falen, is een tool die iemand zonder overleg heeft toegevoegd, of iemand die als jou verstuurt en dat niet hoort te doen. In beide gevallen zie je het als eerste in het rapport.
Wat levert slagen voor DNS-authenticatie je echt op?
Het stelt je identiteit vast, en verder niets. Zodra een ontvanger weet dat de mail echt van yourcompany.nl komt, beoordeelt hij dat domein op zijn staat van dienst: klachten, bounces, engagement en hoe gelijkmatig het verstuurt. Dat is domeinreputatie en de bredere sender reputation, en authenticatie is wat een provider überhaupt in staat stelt om die geschiedenis aan jou te koppelen.
Een volledig geauthenticeerd domein dat een gescrapete lijst mailt, belandt dus nog steeds in spam, en dat hebben we maandenlang zien gebeuren. De records beschermen je inbox placement rate zonder die te bepalen. Ze beschermen ook iets wat placementcijfers niet laten zien: zonder DMARC op enforcement kan iedereen phishing versturen als jouw exacte domein, en ontvangers geven je merk daar de schuld van.
De kern
DNS-authenticatie beantwoordt de eerste vraag die elke ontvangende server stelt: komt deze mail echt van wie hij zegt? SPF, DKIM en DMARC beantwoorden elk een deel daarvan, en het antwoord telt pas als het wijst naar het domein in de From-regel. Zit de alignment goed, dan is de rest onderhoud.
De setup zelf is een paar dagen werk, verspreid over een paar weken, en de meeste tijd wacht je op rapporten. Bij het onderhoud glippen teams uit: elke nieuwe tool heeft zijn records nodig, elk rapport verdient een blik, en iemand moet eigenaar zijn van de lijst van wie er als jou verstuurt. Zonder die eigenaar zakt een correcte setup binnen een jaar terug tot een lekkende.
Als Nebor de verzendinfrastructuur van een klant inricht, komen de records in de DNS van de klant, voor het hoofddomein en elk verzenddomein, met een kort register van elke afzender, zijn selector en zijn DMARC-status. Dat register blijft bij de klant, zodat wie de volgende tool toevoegt kan zien wat er al staat en wat die tool nodig heeft.
Veelgestelde vragen
Wat is het verschil tussen DNS-authenticatie en versleuteling zoals TLS?
Ze doen elk een ander werk. TLS versleutelt de verbinding tussen twee mailservers, zodat niemand het bericht onderweg kan lezen. DNS-authenticatie verbergt niets. Het bewijst welk domein het bericht heeft verstuurd en dat de ondertekende delen niet zijn veranderd. De afzenderrichtlijnen van Google vragen om allebei, een TLS-verbinding voor het verzenden van mail en SPF, DKIM en DMARC voor de identiteit, en het een vervangt het ander niet.
IT beheert onze DNS, maar sales voelt de deliverability-pijn. Wie hoort de records te beheren?
Verdeel het bewust. Eén persoon, vaak in RevOps of marketing operations, is eigenaar van de lijst met elke tool die als het bedrijf verstuurt en bepaalt wat elke tool nodig heeft. IT publiceert en onderhoudt de records in DNS. Maak het toevoegen van de SPF- en DKIM-records van een tool onderdeel van het aanzetten van die tool, en laat beide kanten eens per maand samen naar de DMARC-rapporten kijken.
Hoe snel na het publiceren gaan SPF, DKIM en DMARC werken?
Meestal binnen een paar uur, maar reken op maximaal twee dagen. Volgens Google kan het tot 48 uur duren voordat SPF werkt, en de uitrolhandleiding voor DMARC van Google vraagt je om SPF en DKIM minstens 48 uur voor DMARC in te stellen. Stuur na het publiceren een testbericht naar een externe inbox en lees de Authentication-Results-header, in plaats van te vertrouwen op het groene vinkje in een beheerconsole.
Hebben subdomeinen eigen SPF-, DKIM- en DMARC-records nodig?
Voor SPF wel. Google en Microsoft zeggen allebei dat elk subdomein dat mail verstuurt een eigen SPF-record nodig heeft, omdat het record van het hoofddomein het niet dekt. DKIM-sleutels stel je per ondertekenend domein in, in elke tool. DMARC werkt anders: Microsoft merkt op dat subdomeinen de DMARC-instellingen van het bovenliggende domein erven, tenzij je die overschrijft. Eén beleid op het hoofddomein dekt dus ook subdomeinen die niemand heeft ingericht.
Wat is BIMI, en is het de moeite waard om in te stellen?
Met BIMI tonen mailapps die het ondersteunen je logo naast berichten die slagen voor DMARC. Google vereist een DMARC-beleid van quarantine of reject dat op alle mail van toepassing is, een Verified Mark Certificate of Common Mark Certificate van een externe autoriteit, en een logo in SVG. Voor merken die veel klantmail versturen, is het de moeite waard. Voor domeinen voor cold outreach kost het geld zonder dat de placement verandert.
Doet reverse DNS ertoe als je via Google Workspace of Microsoft 365 verstuurt?
Niet als taak voor jou. De afzenderrichtlijnen van Google eisen dat verzendende IP-adressen geldige forward en reverse DNS hebben, dus een PTR-record dat verwijst naar een hostnaam die bij het IP past. Verlaat je mail de servers van Google of Microsoft, dan zijn die IP's en hun PTR-records van het platform. Reverse DNS wordt pas jouw taak als je een eigen mailserver draait.
Wat is het verschil tussen p=quarantine en p=reject?
Allebei zijn het enforcementbeleid voor mail die faalt voor DMARC. Quarantine vraagt ontvangers om falende mail als verdacht te behandelen, en in de praktijk betekent dat meestal de spammap. Reject vraagt ze om de mail tijdens de aflevering te weigeren, zodat hij de ontvanger helemaal niet bereikt. De meeste domeinen gaan eerst door quarantine, houden in de rapporten in de gaten of er legitieme mail wordt tegengehouden, en stappen over op reject zodra dat niet meer gebeurt.
Kan een streng DMARC-beleid mail van onze eigen tools blokkeren?
Ja, en dat is het grootste risico als je te snel gaat. Verstuurt een tool als jouw domein zonder aligned pass voor SPF of DKIM, dan vertelt een reject-beleid ontvangers dat ze die mail moeten weigeren, of het nu facturen, wachtwoordresets of uitnodigingen voor webinars zijn. Lees eerst de aggregaatrapporten, los elke legitieme bron op die faalt, en scherp pas daarna het beleid aan.
Hoe check je de authenticatieresultaten van een bericht in Gmail?
Open het bericht, kies "Origineel weergeven" in het menu, en Gmail toont een overzicht waarin SPF, DKIM en DMARC elk als pass of fail zijn gemarkeerd. Kijk verderop in de Authentication-Results-header voor welk domein elke check slaagde. Een DKIM-pass voor het domein van een leverancier in plaats van het jouwe betekent dat de tool niet als jou ondertekent, ook al staat het woord pass erbij.
Deel dit bericht
Deliverability
Infrastructure
Begrippenlijst
Gerelateerde begrippen
De basis GTM-concepten begrijpen
Automatisering
SPF (Sender Policy Framework)
SPF (Sender Policy Framework) is een DNS-record met de mailservers en IP-adressen die e-mail mogen versturen voor je domein, zodat ontvangende servers kunnen controleren of een bericht legitiem is.
Automatisering
DKIM (DomainKeys Identified Mail)
DKIM (DomainKeys Identified Mail) is een methode voor e-mailauthenticatie die een digitale handtekening aan elk bericht toevoegt. Zo kunnen ontvangende servers bevestigen dat het bericht van jouw domein komt en onderweg niet is aangepast.
Automatisering
DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance) is een e-mailrecord dat ontvangende servers vertelt om mail van jouw domein die zakt voor SPF en DKIM af te leveren, in quarantaine te zetten of te weigeren, en dat rapporteert wie er namens jou verstuurt.
Automatisering
E-mail deliverability
E-mail deliverability is of je e-mails in de inbox komen in plaats van in spam te belanden of geblokkeerd te worden. Het hangt af van je authenticatie, je sender reputation, de kwaliteit van je lijst en hoe mensen op je mail reageren.
Klaar om je pipeline te bouwen
