
In this post:
DMARC, kort voor Domain-based Message Authentication, Reporting and Conformance, is de e-mailregel die ontvangende servers vertelt wat ze moeten doen als een bericht dat van jouw domein lijkt te komen, niet door de authenticatiechecks komt. Het ligt als laag bovenop SPF en DKIM en maakt van die checks een echte policy.
Zonder DMARC levert een mislukte check alleen een schouderophalen op, en beslist de ontvangende server zelf of hij de verdachte mail aflevert. Met DMARC neem je die beslissing vooraf, en vertel je de wereld dat alles wat zakt, moet worden afgeleverd, in quarantaine gezet of geweigerd.
Het doet ook iets wat de andere twee records niet kunnen. DMARC rapporteert aan jou wie er e-mail verstuurt met jouw domein. Zo zie je eindelijk de spoofing en de verkeerde configuraties waar je eerder blind voor was.
TL;DR
DMARC is de policy- en rapportagelaag van e-mailauthenticatie. Het bouwt op SPF en DKIM, bepaalt wat er gebeurt met mail die daarvoor zakt, en stuurt je rapporten over iedereen die e-mail verstuurt namens jouw domein.
De policy kent drie standen: alleen monitoren, quarantaine of weigeren. Het doel is voorzichtig naar weigeren toe te werken, zodat niemand je domein kan spoofen. De rapporten zijn de verborgen prijs, omdat ze je elke afzender laten zien die jouw naam gebruikt, legitiem of niet.
Wat is DMARC, en welk werk doet het dat SPF en DKIM niet kunnen?
DMARC is het ontbrekende stuk dat SPF en DKIM betekenis geeft. Op zichzelf kunnen die twee checks slagen of falen, al vertellen ze een ontvangende server niet wat hij met een mislukte check moet doen, en vertellen ze jou helemaal niets.
DMARC is ontworpen om die twee gaten tegelijk te dichten. Je kunt er een policy mee publiceren: een duidelijke instructie voor hoe ontvangers mail moeten behandelen die zakt voor authenticatie en van jou lijkt te komen. En het zet een rapportagekanaal op, zodat de providers je data sturen over wat er in jouw naam wordt verstuurd.

Daarmee is DMARC de handhavings- en zichtbaarheidslaag van DNS-authenticatie. SPF en DKIM doen de checks, en DMARC bepaalt de gevolgen en laat je het hele plaatje zien. Je hebt ze echt alle drie samen nodig, omdat elk afzonderlijk een gat laat.
Hoe werkt DMARC precies als er een e-mail bij de server binnenkomt?
Het proces duurt een fractie van een seconde, al verdienen de stappen een rustige uitleg. Als er een e-mail binnenkomt die van jouw domein lijkt te komen, haalt de ontvangende server hem door een snelle reeks checks.
Eerst checkt hij SPF, om te bevestigen dat de verzendende server bevoegd is, en DKIM, om te bevestigen dat de handtekening geldig is. Daarna checkt hij alignment: of het domein dat voor SPF of DKIM slaagde, overeenkomt met het domein in het zichtbare afzenderadres.

Als die checks falen of niet aligned zijn, zoekt de server tot slot je DMARC-record op om te zien wat je hem hebt opgedragen.
Daarna levert hij het bericht af, zet hij het in quarantaine of weigert hij het, op basis van je policy, en later stuurt hij je een rapport over wat hij zag. Zo wordt een vaag vermoeden een duidelijke, afgedwongen beslissing.
Wat betekenen de drie DMARC-policystanden echt voor je mail?
DMARC geeft je drie policystanden, en in onze ervaring zit het meeste werk in de keuze daartussen. Elke stand vertelt ontvangers hoe streng ze moeten zijn met mail die zakt.
De eerste is p=none, wat alleen monitoren betekent. Mail die zakt, wordt gewoon afgeleverd, en jij krijgt rapporten. Dit is dus het veilige startpunt waar je meekijkt zonder iets te blokkeren. De tweede is p=quarantine, die ontvangers vertelt mail die zakt als verdacht te behandelen en meestal in de spammap te zetten.
De derde is p=reject, de strengste stand, die ontvangers vertelt mail die zakt direct te blokkeren, zodat die nooit bij iemand aankomt. Reject is het echte doel, omdat het de enige policy is die een gespoofte e-mail echt tegenhoudt. De kunst is er veilig te komen, zonder onderweg je eigen legitieme mail te blokkeren.
Waarom struikelt bijna iedereen over DMARC-alignment?
Alignment is het begrip waar de meeste mensen van in de war raken, dus we nemen er even de tijd voor. Een bericht kan slagen voor SPF of DKIM en toch zakken voor DMARC. DMARC checkt namelijk twee dingen: of het bericht is geauthenticeerd, en of dat is gebeurd onder het juiste domein.
Alignment betekent dat het domein dat voor de check slaagde, overeenkomt met het domein in het afzenderadres dat de ontvanger ziet. Komt je e-mail zichtbaar van jouw domein, terwijl hij alleen voor SPF of DKIM slaagde onder een ander domein, dan telt DMARC dat als een fail, omdat het er voor een mens nog steeds uitziet alsof het van jou komt.
Dit gaat meestal mis als je verstuurt via een externe tool die onder zijn eigen domein authenticeert. De oplossing is DKIM en SPF zo instellen dat ze aligned zijn met jouw domein in plaats van met dat van de tool. Tot ze aligned zijn, blijft je DMARC falen, ook al zien de losse checks er prima uit.
Wat vertellen DMARC-rapporten je, en waarom zijn ze de echte prijs?
Mensen letten vooral op de policy, terwijl de rapporten het punt zijn waar DMARC zich terugbetaalt. Zodra je een DMARC-record publiceert, sturen de mailboxproviders je regelmatig rapporten over elke bron die e-mail verstuurt die van jouw domein lijkt te komen.
Die zichtbaarheid is voor de meeste teams echt nieuw. Voor het eerst zie je alle servers en tools die namens jou versturen, en die vallen direct uiteen in twee nuttige groepen.

Je hebt je legitieme afzenders, zoals je e-mailplatform en je marketingtool, en je hebt de afzenders die je niet herkent. Dat kunnen spoofers zijn of vergeten systemen.
Dit maakt een veilige uitrol mogelijk. Je leest de rapporten, bevestigt dat je echte afzenders geauthenticeerd en aligned zijn, en pas dan scherp je je policy aan. Zonder de rapporten zou de overstap naar reject een gok zijn. Met de rapporten is het een gecontroleerde, geïnformeerde beslissing.
Hoe rol je DMARC veilig uit zonder je eigen e-mail te blokkeren?
Dit is het deel waar elke klant die we onboarden zenuwachtig van wordt, en terecht, omdat een slordige DMARC-uitrol je eigen mail kan blokkeren. De veilige route is geleidelijk, en voor bijna iedereen hetzelfde.
Je begint bij p=none en publiceert het record in monitormodus, zodat er niets wordt geblokkeerd terwijl je rapporten verzamelt. Je leest die rapporten tot je elke legitieme afzender kunt zien en authenticeren, en je herstelt de alignment voor elke tool die dat nodig heeft.

Deze fase kan een paar weken duren, en haast is de belangrijkste manier waarop teams zichzelf schade doen.
Zodra al je echte afzenders slagen en aligned zijn, ga je naar p=quarantine, let je op problemen, en ga je uiteindelijk naar p=reject. Tegen de tijd dat je bij reject bent, weet je al dat je eigen mail veilig is. Het enige wat je dan blokkeert, is de gespoofte en onbevoegde e-mail die je al die tijd wilde tegenhouden.
Waarom is DMARC zo belangrijk om te voorkomen dat mensen je domein spoofen?
De diepste reden voor DMARC is beveiliging, en deliverability liftt mee. E-mail is gebouwd zonder manier om te voorkomen dat iemand het afzenderadres vervalst, en door dat gat was phishing in de naam van een vertrouwd bedrijf zo lang zo effectief.
DMARC op reject sluit die deur voorgoed. Als je het afdwingt, kan een oplichter geen overtuigende e-mail meer sturen die van jouw domein lijkt te komen, omdat ontvangers alles blokkeren wat niet als jou authenticeert.
Dat beschermt je klanten, je partners en je eigen medewerkers tegen mail die jouw naam draagt en ze om de tuin leidt.
Het beschermt ook je merk en je domain reputation. Elke gespoofte phishingmail die in jouw naam wordt verstuurd, kan schaden hoe mensen, en de providers, naar je domein kijken. Door spoofing een halt toe te roepen, voorkomt DMARC dat je goede naam wordt meegesleurd door het misbruik van een ander.
Waarom is DMARC nu een vereiste, en geen nice-to-have meer?
DMARC was vroeger vooral iets voor grote enterprises, en dat is veranderd voor iedereen. De grote mailboxproviders verwachten het nu als basisvoorwaarde om te mogen versturen.
In 2024 voerden Google en Yahoo regels in voor bulkverzenders die SPF, DKIM en een DMARC-record verplichten, samen met makkelijk uitschrijven en een spamklachtpercentage onder de 0,3%. Je hebt minimaal een gepubliceerd DMARC-record nodig, ook als dat om te beginnen alleen op p=none staat.
DMARC is dus van een geavanceerde best practice een basisvereiste geworden. Verstuur je zonder DMARC een serieus volume aan e-mail, dan zak je voor een check die providers verwachten, en dat zet je email deliverability op het spel voordat je ook maar een woord hebt verstuurd.
Een record publiceren is de makkelijke eerste stap, en je krijgt direct rapporten.
Welke veelgemaakte DMARC-fouten richten echte, blijvende schade aan?
DMARC is krachtig, en dat betekent dat een paar fouten echt schade kunnen doen. Als je ze vooraf kent, hoef je het niet op de harde manier te leren.
De schadelijkste is direct naar p=reject springen zonder eerst te monitoren. Dwing je af voordat je hebt bevestigd dat je legitieme afzenders aligned zijn, dan blokkeer je je eigen mail, inclusief dingen als facturen en wachtwoordresets. Dat is een pijnlijke manier om een verkeerd ingestelde tool te ontdekken.

De omgekeerde fout is p=none publiceren en daar nooit meer voorbij komen. Dan krijg je rapporten, zonder echte bescherming tegen spoofing.
Andere veelgemaakte fouten zijn de rapporten helemaal negeren, waardoor je de spoofers of de kapotte afzenders nooit ziet, en vergeten dat elke nieuwe verzendtool die je toevoegt geauthenticeerd en aligned moet worden.
Een DMARC-setup is niet helemaal instellen-en-vergeten, omdat je alignment bij elke wijziging in je verzending kan breken zonder dat je een foutmelding ziet.
Hoe brengt DMARC het hele plaatje van e-mailauthenticatie samen?
DMARC is alleen zinvol als sluitstuk op de andere twee records, dus zo stapelen de drie. SPF en DKIM bewijzen elk iets specifieks, en DMARC maakt van die bewijzen een policy en een feedbackloop.
Daarom horen alle drie bij één sending infrastructure in plaats van drie losse klussen te zijn. SPF zegt welke servers mogen versturen, DKIM ondertekent het bericht, en DMARC bepaalt wat er gebeurt bij falen en rapporteert wie er namens jou verstuurt. Haal er één weg en de andere twee worden zwakker.
Voor cold outreach telt dit dubbel, omdat authenticatie een kernonderdeel is van je cold email infrastructure. Je kunt eindeloos domeinen opwarmen en lijsten opschonen, als niet alle drie de records aligned zijn en worden afgedwongen, verstuur je vanaf een setup die providers niet helemaal vertrouwen, en zo behandelen ze je ook.
Hoe ziet een DMARC-record er precies uit, en wat staat erin?
Het helpt om het record zelf te zien, omdat het minder intimiderend is dan de afkorting doet vermoeden. Een DMARC-record is gewoon één regel tekst in je DNS, opgebouwd uit een paar tags die met puntkomma's van elkaar zijn gescheiden.
De belangrijkste tags zijn makkelijk te lezen. Je hebt de versie, die aangeeft dat het een DMARC-record is, de policy, dat is je stand none, quarantine of reject, en het rapportageadres, waar je de verzamelrapporten naartoe wilt laten sturen.
Met een paar optionele tags kun je dingen fijnafstemmen, zoals een mildere policy voor subdomeinen, of tijdens het testen alleen een percentage van je mail afdwingen.
In de praktijk hoef je dit niet met de hand te schrijven, omdat genoeg tools het record voor je genereren en de rapporten voor je hosten. Als je weet wat de onderdelen betekenen, kun je wel je eigen setup lezen, een verkeerde configuratie spotten en precies begrijpen wat je de wereld opdraagt te doen met mail die zakt.
Hoe lang duurt het echt om DMARC volledig af te dwingen?
Klanten vragen ons DMARC vóór vrijdag af te hebben, terwijl afdwingen een traject is dat je in weken meet, soms in maanden. De tijdlijn hangt af van hoeveel tools e-mail versturen namens je domein en hoe rommelig je huidige setup is.
Een eenvoudige verzender met een of twee e-mailtools haalt reject misschien in een paar weken. Een groter bedrijf met veel systemen die in zijn naam versturen, van facturatie tot support tot marketing, kan maanden nodig hebben om ze allemaal te vinden en te authenticeren.
De tijd gaat zitten in de monitorfase, omdat je pas veilig kunt afdwingen als elke legitieme afzender in beeld is.
Er is geen echte shortcut, en proberen het te haasten is precies hoe je je eigen mail blokkeert. Het goede nieuws is dat de bescherming onderweg toeneemt: zelfs p=none geeft je direct zichtbaarheid, en quarantine houdt al veel spoofing tegen lang voordat je bij volledige reject bent.
Helpt DMARC je deliverability, of gaat het alleen over beveiliging?
Het is makkelijk om DMARC in het vakje beveiliging te stoppen en de deliverability-kant te vergeten, terwijl het allebei doet. De twee hangen sterker samen dan het lijkt.
Aan de beveiligingskant voorkomt DMARC dat mensen je domein spoofen, en dat beschermt je klanten en je merk. Aan de deliverability-kant oogt een domein met goede authenticatie en handhaving betrouwbaarder voor de mailboxproviders, en dat helpt je legitieme mail de inbox te bereiken.
Er is ook een reputatiekant die de twee verbindt. Als spoofers phishing in jouw naam kunnen versturen, kan elk van die berichten je sender reputation omlaag trekken, ook al heb jij ze niet verstuurd.
Door dat misbruik te stoppen, beschermt DMARC de reputatie waar je echte deliverability van afhangt. Het was dus nooit een keuze tussen beveiliging en deliverability, omdat wie het een goed doet, vanzelf ook het ander dient.
Waarom DMARC het slot is dat je eindelijk op je eigen domein kunt dichtdraaien
Voorbij alle afkortingen draait DMARC om controle. Het is het punt waarop je stopt met hopen dat ontvangers je mislukte en vervalste mail verstandig afhandelen, en ze precies gaat vertellen wat ze ermee moeten doen.
Die controle is de zorgvuldige uitrol waard. Zodra je bij handhaving bent, kan niemand meer overtuigend e-mail versturen als jou, is je legitieme mail volledig geauthenticeerd en heb je doorlopend zicht op elke bron die je domein gebruikt. Weinig dingen in deliverability geven je zoveel bescherming met één record.

De eerlijke kanttekening is dat DMARC geduld beloont en haast afstraft. Het werk zit dus in de geleidelijke klim van monitoren naar reject, en minder in de uiteindelijke instelling zelf. Maak die klim goed, houd de rapporten in de gaten, en je hebt een deur op je domein op slot gedaan die altijd al op slot had moeten zitten.
Deel dit bericht
Deliverability
Infrastructure
Begrippenlijst
Gerelateerde begrippen
De basis GTM-concepten begrijpen
Klaar om je pipeline te bouwen











