Hero background

dns authentication

DNS-authenticatie

DNS-authenticatie

In this post:
No headings found on page

DNS-authenticatie is de set records die je in de DNS van je domein publiceert om te bewijzen dat je e-mail echt van jou is. Het is de verzamelnaam voor de drie controles die mailboxproviders op elk bericht loslaten: SPF, DKIM en DMARC, die samen één geheel vormen.

Als die records er staan en op elkaar zijn afgestemd, kunnen ontvangende servers bevestigen dat een e-mail van jou komt en niet is vervalst of aangepast. Ontbreken ze, dan ziet je mail er verdacht uit, en een groot deel ervan komt nooit in de inbox.

Voor elke vorm van e-mail op volume, en zeker voor cold outreach, is DNS-authenticatie het fundament waar al het andere op rust. Je kunt perfecte copy en een schone lijst hebben, maar zonder authenticatie verstuur je vanaf een domein dat de providers niet vertrouwen.

TL;DR

DNS-authenticatie is hoe je met records in je DNS bewijst dat je e-mail legitiem is. Het bestaat uit drie delen, SPF, DKIM en DMARC, en elk deel heeft een eigen taak.

SPF zegt welke servers namens jou mogen versturen, DKIM ondertekent je berichten zodat niemand ze kan vervalsen of aanpassen, en DMARC bepaalt wat er gebeurt als die controles falen en rapporteert wie er namens jou verstuurt. Samen vertellen ze de mailboxproviders dat je mail echt is.

Sinds 2024 eisen Google en Yahoo alle drie van bulkverzenders, dus de volledige set is nu verplicht voordat de grote providers je volume accepteren. Je zet het één keer op, en daarna beschermt het op de achtergrond je deliverability zolang je verstuurt.

Wat betekent DNS-authenticatie nu echt voor je e-mail?

DNS-authenticatie is het bewijzen van de echtheid van je e-mail via de DNS van je domein, hetzelfde systeem dat je domein naar je website laat verwijzen. Je publiceert daar een paar speciale records, en de mailboxproviders lezen die uit om je mail te verifiëren.

Alles in deze hoek van e-mail draait om vertrouwen. De oorspronkelijke e-mailprotocollen gaven ontvangers geen ingebouwde manier om de identiteit van een afzender te controleren, dus decennialang kon iedereen een afzenderadres vervalsen.

DNS-authenticatie is de laag die de sector er later bovenop heeft gezet om dat op te lossen. Ontvangers kunnen daarmee controleren of een bericht echt komt van wie het zegt te zijn.

Als mensen het hebben over het authenticeren van je domein, bedoelen ze dus dit. Het is geen losse instelling. Het is een klein systeem van records waarmee een ontvangende server je e-mail kan vertrouwen in plaats van te moeten gokken.

Waarom moest authenticatie überhaupt achteraf aan e-mail worden toegevoegd?

Het probleem dat authenticatie oplost, verklaart waarom de providers er zoveel belang aan hechten. E-mail had vanaf het begin een flagrante zwakte: iedereen kon elk adres in het afzenderveld zetten en mail versturen als iemand anders.

Die zwakte is de wortel van phishing en spoofing. Een oplichter kon een e-mail sturen die er precies uitzag alsof hij van je bank, je baas of je favoriete merk kwam, en niets in het systeem hield hem tegen. Mailboxproviders moesten maar raden welke mail echt was en welke vervalst.

DNS-authenticatie dicht dat gat door afzenders records te laten publiceren die hun identiteit bewijzen, en dat geeft ontvangers een betrouwbare test. Mail die slaagt, is veel waarschijnlijker echt, en mail die faalt, kan met argwaan worden behandeld. Precies die heldere scheiding wilden de providers bereiken.

Welke drie DNS-records vormen samen e-mailauthenticatie?

DNS-authenticatie vraagt om drie aparte records, en elk record regelt een ander stukje van de puzzel. Pas als ze alle drie samenwerken, heb je het volledige plaatje.

De eerste is SPF, het Sender Policy Framework, dat de servers opsomt die namens je domein e-mail mogen versturen. De tweede is DKIM, dat een cryptografische handtekening toevoegt zodat ontvangers kunnen bevestigen dat een bericht echt en onveranderd is.

Drie records die bewijzen dat je mail van jou is.

De derde is DMARC, dat bovenop de andere twee werkt, ontvangers vertelt wat ze moeten doen als een bericht faalt, en aan jou rapporteert wie er e-mail verstuurt uit naam van je domein. Elk record dicht een gat dat de andere openlaten, en daarom verwachten de providers de volledige set te zien in plaats van maar één record.

Hoe verdelen SPF, DKIM en DMARC het werk onderling?

De duidelijkste manier om DNS-authenticatie te begrijpen, is kijken hoe de drie records het werk verdelen. Er zit geen overlap tussen, omdat elk record zijn eigen vraag beantwoordt.

SPF beantwoordt waar de mail vandaan kwam, door te bevestigen dat de verzendende server op je goedgekeurde lijst staat. DKIM beantwoordt of het bericht echt en onaangeroerd is, door een handtekening te controleren die alleen jouw domein kan hebben gemaakt. Geen van beide vertelt een ontvanger op zichzelf wat hij moet doen als de controle faalt.

Decennialang kon iedereen mailen als wie dan ook.

Die derde vraag beantwoordt DMARC. Het bepaalt wat er bij een fout moet gebeuren, en het koppelt de andere twee aan het domein dat iemand in de afzenderregel ziet. Dat concept heet alignment.

Samen vormen ze een keten waarin SPF en DKIM je identiteit bewijzen en DMARC die afdwingt. Haal je één schakel weg, dan verzwakt de hele keten.

Wat gebeurt er met je e-mail als je DNS-authenticatie helemaal overslaat?

Authenticatie overslaan kost je meer dan een klein nadeel, omdat de providers ontbrekende records op zichzelf al als alarmsignaal zien. Niet-geauthenticeerde mail is voor een ontvangende server precies hoe spam en phishing eruitzien, dus zo wordt hij ook behandeld.

In de praktijk komt mail van een niet-geauthenticeerd domein veel vaker in spam terecht, wordt hij afgeknepen of zelfs direct geweigerd. De providers kunnen je legitieme e-mail niet onderscheiden van een vervalsing, dus ze kiezen de veilige kant en filteren hem. Je beste campagne sterft in spammappen die niemand ooit bekijkt.

Niet-geauthenticeerd is hoe spam eruitziet.

Er zit ook een beveiligingsrisico in. Zonder authenticatie, en vooral zonder DMARC op enforcement, kan iedereen je domein spoofen en phishing uit jouw naam versturen. Dat beschadigt je domeinreputatie en je merk. Overslaan schaadt dus tegelijk je deliverability en je bescherming.

Waarom is DNS-authenticatie nu verplicht voor iedereen die op volume verstuurt?

Authenticatie was vroeger een best practice voor zorgvuldige verzenders, en is inmiddels een harde eis geworden. De grote mailboxproviders verwachten het nu van iedereen die op volume verstuurt.

In 2024 voerden Google en Yahoo regels in voor bulkverzenders die SPF, DKIM en DMARC samen vereisen, plus een makkelijke afmeldoptie en een spamklachtpercentage onder 0,3%. Een verzender die dit mist, heeft meer dan een nadeel: zijn mail kan worden geweigerd in plaats van alleen gefilterd.

DNS-authenticatie is dus het toegangskaartje tot de inbox geworden. Verstuur je echt volume zonder de volledige set, dan loop je tegen een filter aan dat de providers nu op iedereen toepassen, en dat zet je e-mail deliverability op het spel voordat je bericht zelfs maar gelezen is.

Het goede nieuws: je zet het één keer op, en het levert onevenredig veel op.

Hoe zet je DNS-authenticatie vanaf nul op zonder een stap te missen?

De volledige stack opzetten is een afgebakend project, en het meeste werk bestaat uit records publiceren die je e-mailplatform je aanreikt. Bij elke klantbuild volgen we dezelfde volgorde, omdat de drie records op elkaar voortbouwen.

Je begint met SPF: je publiceert een record met elke dienst die namens je domein mag versturen, en het precieze werk zit in het opsporen van al je echte verzenders. Daarna stel je DKIM in op elk verzendplatform en publiceer je de sleutels die ze genereren, zodat je mail ondertekend wordt.

Drie vragen, nooit dubbel.

Staan die twee er allebei en slagen ze, dan voeg je DMARC toe. Je begint in monitormodus, zodat je kunt meekijken zonder iets te blokkeren.

Vanaf daar lees je je DMARC-rapporten, controleer je of elke legitieme verzender geauthenticeerd en aligned is, en scherp je je DMARC-beleid geleidelijk aan richting enforcement. Voor een eenvoudige setup duurt het geheel een paar weken, en langer als je via veel tools verstuurt, maar elke stap voegt meteen bescherming toe.

Waarom telt DNS-authenticatie extra zwaar bij cold outreach?

Bij cold email weegt authenticatie nog zwaarder dan normaal, omdat cold verzenders zonder enig voordeel van de twijfel beginnen. Een nieuw outreach-domein heeft geen geschiedenis, dus de providers leunen zwaar op de authenticatie om te bepalen of ze het überhaupt vertrouwen.

Daarom is DNS-authenticatie een kernonderdeel van elke serieuze infrastructuur voor cold email. De aparte verzenddomeinen die je voor outreach gebruikt, hebben elk hun eigen SPF, DKIM en DMARC nodig, correct ingesteld en aligned, voordat je er ook maar één campagne vanaf verstuurt.

Het werkt samen met de rest van de setup en vervangt er niets van. Een opgewarmd domein, een schone lijst en volledige authenticatie versterken elkaar, en de providers beoordelen je op de combinatie. Klopt de authenticatie niet, dan levert al het opwarmen en alle lijsthygiëne van de wereld je nog steeds geen inbox op.

Welke veelgemaakte fouten met DNS-authenticatie blijven je parten spelen?

Een kapot record geeft nooit een foutmelding die je ziet, dus een paar veelgemaakte fouten kunnen je maandenlang schaden zonder duidelijk symptoom. Hetzelfde handjevol duikt op in bijna elke setup die we auditen, dus hier zijn ze.

De fout die we het vaakst herstellen, is een onvolledig SPF-record dat een van je verzendtools mist. De mail van die tool faalt dan voor authenticatie, ook al slaagt al het andere. Een andere fout is DKIM op sommige platforms instellen en op andere niet, waardoor er een gat ontstaat telkens als je een nieuwe tool toevoegt.

Het faalt zonder symptoom.

Een derde is DMARC publiceren en het daarna nooit voorbij monitormodus brengen, zodat je wel rapporten krijgt en geen echte bescherming.

De subtielste is misalignment: SPF of DKIM slaagt technisch gezien wel, alleen onder het verkeerde domein, dus DMARC faalt alsnog. Al deze fouten verstoppen zich in het volle zicht, en daarom loont het om je setup te testen en je DMARC-rapporten te volgen. Een setup waarvan je aanneemt dat hij werkt, kan al die tijd vertrouwen lekken.

Garandeert DNS-authenticatie dat je e-mail in de inbox komt?

Laten we eerlijk zijn over de verwachtingen, want authenticatie is noodzakelijk en toch maar een deel van het verhaal. Slagen voor SPF, DKIM en DMARC doorstaat de identiteitscheck, maar belooft op zichzelf geen inbox.

Authenticatie beantwoordt de vraag wie je bent, en meer niet. Zodra de providers weten dat je mail echt van jou is, hangt de plek waar hij landt nog steeds af van je gedrag, je sender reputation en hoe mensen reageren op wat je verstuurt.

We hebben volledig geauthenticeerde domeinen maandenlang in spam zien belanden omdat de lijst eronder rommel was.

Zie authenticatie dus als de grond waarop je bouwt, en niet als de finish. Je zet het één keer op zodat de identiteitsvraag voorgoed verdwijnt, en vanaf daar win je de inbox met schone lijsten, echte engagement en regelmatig versturen.

Je ziet het het duidelijkst terug in je inbox placement rate, die authenticatie beschermt zonder hem in zijn eentje te bepalen.

Hoe verschilt DNS-authenticatie van encryptie zoals TLS?

Mensen gooien authenticatie soms op één hoop met e-mailencryptie, terwijl het aparte dingen zijn met aparte taken. Ze zijn makkelijk te verwarren en handig om uit elkaar te houden.

Encryptie, meestal TLS, beschermt de inhoud van een e-mail terwijl hij tussen servers reist, zodat niemand hem onderweg kan lezen. DNS-authenticatie probeert niets te verbergen. Het bewijst wie het bericht heeft verstuurd en dat niemand het heeft aangepast. Dat is een kwestie van identiteit en niet van geheimhouding.

Je wilt ze allebei, en ze vervangen elkaar niet. TLS houdt het gesprek privé, en authenticatie houdt het eerlijk. Als mensen het over het authenticeren van je domein hebben, bedoelen ze bijna altijd de identiteitskant, dus SPF, DKIM en DMARC, met de encryptielaag die er los onder werkt.

Wie is eigenaar van DNS-authenticatie als IT en marketing er allebei aan zitten?

Dit zorgt voor echte wrijving binnen bedrijven, omdat de records op een plek staan waar marketing meestal niet bij kan. DNS wordt vaak beheerd door IT of een technisch team, terwijl de mensen die de pijn van slechte deliverability voelen bij marketing en sales zitten.

Precies die splitsing is de reden dat authenticatie wordt verwaarloosd, en we hebben dat bij klanten vaker zien gebeuren dan we kunnen tellen.

Marketing ziet dat de mail de inbox niet haalt en kan de records zelf niet publiceren. IT kan ze wel publiceren, alleen voelt het daar niet altijd de urgentie. De mail blijft steken in het gat tussen die twee.

De oplossing is het als gedeelde taak te behandelen, met duidelijke afstemming. Wie eigenaar is van deliverability, bepaalt de eisen, en wie de DNS beheert, publiceert en onderhoudt de records. Samen houden ze de DMARC-rapporten in de gaten. Die overdracht expliciet benoemen bespaart je later een hoop naar elkaar wijzen.

Hoe houd je je DNS-authenticatie gezond als je manier van versturen verandert?

Authenticatie is nooit helemaal af, omdat je verzendsetup blijft veranderen en elke wijziging er invloed op kan hebben. Een record dat vorig jaar perfect was, kan verouderen naarmate je tools toevoegt, zonder één foutmelding die je waarschuwt.

De hoofdregel: elke nieuwe verzendtool moet aan je authenticatie worden toegevoegd. Een nieuw marketingplatform of een nieuwe outreach-tool moet in SPF worden opgenomen en een eigen DKIM krijgen, anders faalt de mail ervan.

Er speelt ook een technische grens, want SPF staat maar een vast aantal DNS-lookups toe, en als je er te veel diensten in propt, kan het record helemaal breken.

De gewoonte is dus om je authenticatie te controleren telkens als je verzendsetup verandert, en je DMARC-rapporten te blijven lezen op alles wat faalt of niet aligned is. We bouwen die controle in elke verzendinfrastructuur in die we opleveren, omdat een kleine afwijking die je vroeg ziet nooit uitgroeit tot een echt deliverability-probleem.

Waarom DNS-authenticatie het fundament is onder al je andere deliverability-werk

Als je uitzoomt, is DNS-authenticatie gewoon de manier waarop de server van een vreemde leert je te vertrouwen. Het is het systeem dat de meest basale vraag van een ontvanger beantwoordt: komt deze mail echt van wie hij zegt?

Tot je die vraag helder kunt beantwoorden, telt niets anders wat je voor deliverability doet volledig mee. Warmup, reputatie en schone lijsten gaan er allemaal van uit dat de providers je identiteit al vertrouwen, en authenticatie is wat dat vertrouwen oplevert. Het is het eerste wat je goed moet regelen en het laatste wat je fout wilt hebben.

De vloer waar al het andere op staat.

Het geruststellende is dat het een afgebakend fundament is dat je één keer legt. Heb je de drie records gepubliceerd, ze aligned, DMARC naar enforcement gebracht en de rapporten in de gaten gehouden, dan heb je de basislaag gebouwd waar elk ander deel van je verzending op leunt.

Niets van dit werk is glamoureus, en niets ervan komt ooit in een campagnerapport terecht. Toch begint elke reactie die je ooit krijgt bij een ontvangende server die besluit dat je mail de inbox verdiende, en bij deze drie records begint die beslissing.

Deel dit bericht

Deliverability

Email

Infrastructure

Revenue tips, Weekly

Workflows, automation strategies, and GTM insights delivered straight

Klaar om je te bouwen
GTM-engine

Laten we praten over je salesuitdagingen en hoe we je kunnen helpen schalen

Nebor brand chevron in purple, section accent
Nebor brand chevron in orange and purple, section accent
Revenue tips, Weekly

Workflows, automation strategies, and GTM insights delivered straight

Klaar om je te bouwen
GTM-engine

Laten we praten over je salesuitdagingen en hoe we je kunnen helpen schalen

Nebor brand chevron in purple, section accent
Nebor brand chevron in orange and purple, section accent

Begrippenlijst

Gerelateerde begrippen

De basis GTM-concepten begrijpen

Klaar om je pipeline te bouwen

Laten we bespreken hoe je leadgeneratie implementeert in je GTM-strategie

Laten we bespreken hoe je leadgeneratie implementeert in je GTM-strategie

Boek een call met ons team om te bespreken hoe deze workflow past binnen je salesproces en tijdlijn.

Diensten

Case studies

Resources

Over ons

Diensten

Case studies

Resources

Over ons

Nebor logo, a go-to-market and RevOps agency based in Amsterdam

Diensten

Case studies

Resources

Over ons

Nebor logo, a go-to-market and RevOps agency based in Amsterdam