DMARC-policygids: van None naar Reject in 4 stappen

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is de policy-laag die SPF en DKIM aan elkaar knoopt en ontvangende servers vertelt wat ze moeten doen wanneer een bericht de authenticatie niet doorstaat. Zonder DMARC kan een mailboxprovider stilletjes ongeauthenticeerde e-mail doorlaten, in quarantaine plaatsen of weigeren op basis van zijn eigen interne regels. Met DMARC definieer je expliciet hoe e-mail van jouw domein moet worden afgehandeld.

Deze gids loopt het hele DMARC-implementatieproces door, van het publiceren van je eerste monitoring-record tot volledige handhaving met een reject-policy.

Waarom DMARC ertoe doet#

E-mailspoofing is nog steeds een van de meest voorkomende aanvalsvectoren. Een aanvaller kan de "From"-header van een e-mail vervalsen zodat het bericht van jouw domein lijkt te komen. Zonder DMARC hebben ontvangende servers geen betrouwbare manier om te weten wat jouw bedoeling is voor de afhandeling van zulke berichten.

DMARC lost drie problemen op:

• Phishingpreventie: Het stopt aanvallers ervan om e-mails te versturen die eruitzien alsof ze van jouw domein komen.
• Merkbescherming: Het voorkomt dat je domein wordt gebruikt in oplichtingscampagnes die je reputatie schaden.
• Zichtbaarheid: DMARC-rapporten laten je precies zien wie e-mail verstuurt vanaf jouw domein, inclusief legitieme services die je misschien vergeten was en ongeautoriseerde verzenders waarvan je niet wist dat ze bestonden.

Grote mailboxproviders zoals Google, Microsoft en Yahoo verplichten nu DMARC voor bulkverzenders. Sinds 2024 vereist Google dat domeinen die meer dan 5.000 e-mails per dag naar Gmail-adressen sturen een DMARC-policy gepubliceerd hebben.

Hoe DMARC samenwerkt met SPF en DKIM#

DMARC voert geen eigen authenticatiechecks uit. In plaats daarvan evalueert het de resultaten van SPF en DKIM en past een extra vereiste toe die alignment wordt genoemd.

De alignment-vereiste#

Om DMARC te laten slagen, moet ten minste één van de volgende waar zijn:

1. SPF slaagt EN het SPF-geauthenticeerde domein is uitgelijnd met het "From"-headerdomein. SPF controleert de envelope-sender (Return-Path). DMARC vereist dat dit domein matcht met (of een subdomein is van) het domein in de zichtbare "From"-header.

2. DKIM slaagt EN het DKIM-ondertekende domein (d=-tag) is uitgelijnd met het "From"-headerdomein. Het domein in de DKIM-handtekening moet overeenkomen met (of een subdomein zijn van) het "From"-headerdomein.

Alignment kan strict zijn (exacte domeinmatch) of relaxed (subdomeinen toegestaan). Relaxed alignment is de standaard en werkt voor de meeste configuraties.

Waarom alignment ertoe doet#

Zonder alignment zou een aanvaller SPF en DKIM kunnen instellen voor aanvaller.com, een bericht versturen met From: ceo@jouwbedrijf.com, en de e-mail zou de SPF- en DKIM-checks (voor aanvaller.com) doorstaan, terwijl de ontvanger jouw domein ziet. DMARC-alignment dicht dit gat door te eisen dat het geauthenticeerde domein overeenkomt met wat de gebruiker ziet.

DMARC-recordsyntaxis#

Een DMARC-record is een DNS TXT-record gepubliceerd op _dmarc.jouwdomein.com. Hier is een compleet voorbeeld:

v=DMARC1; p=reject; rua=mailto:dmarc-agg@jouwdomein.com; ruf=mailto:dmarc-forensic@jouwdomein.com; pct=100; aspf=r; adkim=r; fo=1;

Tag-referentie#

Tag	Verplicht	Beschrijving	Waarden
v	Ja	Protocolversie	Altijd DMARC1
p	Ja	Policy voor het domein	none, quarantine, reject
rua	Nee*	Ontvangers van aggregaatrapporten	mailto: URI
ruf	Nee	Ontvangers van forensische rapporten	mailto: URI
pct	Nee	Percentage berichten waarop policy van toepassing is	1-100 (standaard: 100)
aspf	Nee	SPF-alignmentmodus	r (relaxed, standaard) of s (strict)
adkim	Nee	DKIM-alignmentmodus	r (relaxed, standaard) of s (strict)
sp	Nee	Subdomeinpolicy	none, quarantine, reject
fo	Nee	Opties voor failure-rapportage	0, 1, d, s

*Hoewel rua technisch optioneel is, moet je hem altijd opnemen. Zonder aggregaatrapporten publiceer je een policy blind, zonder te kunnen zien wat er gebeurt.

Policywaarden uitgelegd#

• none: Alleen monitoren. Berichten die DMARC niet doorstaan worden normaal afgeleverd. Je krijgt rapporten met authenticatieresultaten, maar er wordt geen actie ondernomen. Dit is het startpunt.
• quarantine: Berichten die DMARC niet doorstaan worden als verdacht behandeld. Meestal worden ze in de spam- of junkfolder van de ontvanger geplaatst.
• reject: Berichten die DMARC niet doorstaan worden ronduit geweigerd. De ontvangende server geeft een foutmelding terug en het bericht wordt niet afgeleverd.

Opties voor failure-rapportage (fo-tag)#

• 0 (standaard): Genereer alleen een rapport als zowel SPF als DKIM falen op alignment.
• 1: Genereer een rapport als SPF of DKIM faalt op alignment. Dit is nuttiger voor debuggen en is de aanbevolen instelling.
• d: Genereer een rapport als DKIM faalt, ongeacht alignment.
• s: Genereer een rapport als SPF faalt, ongeacht alignment.

De 4-stappen-progressie naar volledige handhaving#

Direct naar p=reject springen zonder voorbereiding is gevaarlijk. Je zou legitieme e-mail kunnen blokkeren van services waarvan je vergeten was dat je ze gebruikte. De veilige aanpak is een geleidelijke progressie.

Stap 1: Deploy met p=none (monitoren)#

Begin met een monitoring-only-policy om data te verzamelen zonder de mailbezorging te beïnvloeden.

v=DMARC1; p=none; rua=mailto:dmarc-reports@jouwdomein.com; fo=1;

Wat te doen tijdens deze fase:

• Publiceer het record en wacht minimaal 2 tot 4 weken om voldoende rapportagedata te verzamelen.
• Bekijk de aggregaatrapporten om alle legitieme bronnen van e-mail voor je domein te identificeren. Dit omvat je primaire mailserver, marketingplatforms (Mailchimp, SendGrid, HubSpot), transactionele e-mailservices, CRM-systemen, ticketsystemen en alle SaaS-tools die namens jou e-mail versturen.
• Zorg er voor elke legitieme bron voor dat SPF is geconfigureerd (voeg de verzendende IP's van de service toe aan je SPF-record) en dat DKIM is ingesteld (publiceer de DKIM-publieke sleutel van de service in je DNS).
• Onderzoek alle bronnen die je niet herkent. Dat kunnen vergeten legitieme services zijn of ongeautoriseerde verzenders.

Duur: Minimaal 2 tot 4 weken. Langer als je een complexe verzendinfrastructuur hebt.

Stap 2: Ga naar p=quarantine op 25% (zachte handhaving)#

Zodra je vertrouwen hebt dat alle legitieme bronnen DMARC doorstaan, begin je met handhaving op een klein percentage van het verkeer.

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@jouwdomein.com; fo=1;

Dit vertelt ontvangende servers om 25% van de berichten die DMARC niet doorstaan in quarantaine te plaatsen (meestal naar spam te sturen). De andere 75% wordt behandeld alsof de policy none was.

Wat te doen tijdens deze fase:

• Monitor rapporten nauwgezet voor toenames in DMARC-failures van legitieme bronnen.
• Als je een nieuwe legitieme verzender ontdekt waarbij SPF of DKIM ontbreekt, repareer dan de configuratie voordat je verder gaat.
• Let op meldingen dat legitieme e-mail in spamfolders belandt.
• Als alles er na 1 tot 2 weken schoon uitziet, ga dan door naar de volgende stap.

Duur: 1 tot 2 weken.

Stap 3: Verhoog naar p=quarantine op 100% (volledige quarantaine)#

Verwijder de percentagelimiet zodat de quarantaine-policy van toepassing is op alle falende berichten.

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@jouwdomein.com; fo=1;

Of laat de pct-tag simpelweg weg, aangezien 100 de standaardwaarde is:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@jouwdomein.com; fo=1;

Wat te doen tijdens deze fase:

• Blijf rapporten monitoren.
• Verifieer dat geen legitieme e-mail in quarantaine wordt geplaatst.
• Communiceer met je team om te checken of iemand ontbrekende e-mails meldt.
• Na 2 tot 4 weken zonder problemen ben je klaar voor de laatste stap.

Duur: 2 tot 4 weken.

Stap 4: Handhaaf p=reject (volledige bescherming)#

Dit is de eindtoestand. Berichten die DMARC niet doorstaan worden volledig geweigerd.

v=DMARC1; p=reject; rua=mailto:dmarc-reports@jouwdomein.com; ruf=mailto:dmarc-forensic@jouwdomein.com; fo=1;

Op dit punt zal iedereen die probeert e-mail vanaf jouw domein te versturen zonder de juiste authenticatie zijn berichten geweigerd zien worden. Je domein is volledig beschermd tegen spoofing.

Doorlopend onderhoud:

• Blijf aggregaatrapporten minstens maandelijks bekijken.
• Wanneer je een nieuwe e-mailverzendservice toevoegt, configureer dan SPF en DKIM voor het verzenden begint.
• Roteer DKIM-sleutels periodiek en verifieer dat nieuwe sleutels DMARC doorstaan.
• Overweeg ruf toe te voegen voor forensische rapporten als je mailbox het volume aankan.

DMARC-rapporten lezen#

Aggregaatrapporten (rua)#

Aggregaatrapporten zijn XML-bestanden die dagelijks worden verstuurd door ontvangende servers. Ze bevatten:

• De organisatienaam van de rapporterende server.
• De gedekte datumrange.
• Je gepubliceerde DMARC-policy.
• Voor elk bron-IP dat e-mail heeft verzonden via jouw domein: het aantal berichten, SPF/DKIM/DMARC-resultaten en alignment-uitkomsten.

Een vereenvoudigd fragment uit een aggregaatrapport ziet er zo uit:

<record>
  <row>
    <source_ip>198.51.100.10</source_ip>
    <count>1542</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

Ruwe XML is moeilijk te lezen op schaal. De meeste organisaties gebruiken een DMARC-rapportanalyseservice of -tool om de data te parsen en te visualiseren. Diensten zoals Postmark's gratis DMARC-monitoring, dmarcian of EasyDMARC kunnen helpen.

Forensische rapporten (ruf)#

Forensische rapporten bevatten details over individuele berichten die DMARC niet doorstonden, inclusief berichtheaders en soms gedeeltelijke inhoud. Ze zijn nuttig voor het onderzoeken van specifieke spoofing-incidenten, maar genereren grote volumes en kunnen gevoelige informatie bevatten. Veel ontvangers sturen forensische rapporten niet meer vanwege privacyzorgen.

Veelvoorkomende DMARC-valkuilen#

1. p=reject publiceren zonder eerst te monitoren#

Dit is de gevaarlijkste fout. Als een legitieme e-mailservice niet correct is geconfigureerd met SPF en DKIM, worden die berichten geweigerd. Begin altijd met p=none en bekijk de rapporten.

2. Externe verzenders vergeten#

De meest voorkomende oorzaak van DMARC-failures van legitieme bronnen is een vergeten SaaS-tool die e-mail verstuurt via je domein. Veelvoorkomende boosdoeners zijn:

• Marketing-automation-platforms
• Customer-support-ticketsystemen
• CRM-platforms die namens jou e-mail versturen
• Factuur- en boekhoudsoftware
• HR- en recruitmenttools
• Agenda- en planningstools

Audit elke service die met je domein verbonden is voordat je verder gaat dan p=none.

3. SPF-record overschrijdt 10 DNS-lookups#

SPF heeft een harde limiet van 10 DNS-lookup-mechanismen (include, a, mx, redirect, exists). Als je SPF-record deze limiet overschrijdt, geeft SPF-evaluatie een "permerror" terug, wat betekent dat SPF in feite faalt voor alle berichten. Aangezien DMARC vereist dat SPF of DKIM slaagt met alignment, legt een SPF-permerror meer druk op DKIM.

Als je veel verzendservices hebt, overweeg dan je SPF-record te flatten of een subdomeinstrategie te gebruiken waarbij verschillende services vanaf verschillende subdomeinen versturen.

4. rua niet gebruiken#

Zonder aggregaatrapporten heb je geen zicht op hoe de e-mail van je domein wordt geauthenticeerd. Voeg altijd een rua-tag toe, ook bij p=none.

5. Subdomeinen zonder sp=-tag#

Als je de sp-tag niet instelt, erven subdomeinen standaard de policy van het hoofddomein. Als je subdomeinen voor verschillende doeleinden gebruikt (bijv. marketing.jouwdomein.com), overweeg dan een expliciete subdomeinpolicy in te stellen of aparte DMARC-records voor elk subdomein te publiceren.

6. DMARC negeren nadat je reject hebt bereikt#

DMARC is geen "instellen-en-vergeten"-configuratie. Nieuwe verzendservices worden toegevoegd, sleutels verlopen, SPF-records worden gewijzigd. Blijf maandelijks aggregaatrapporten bekijken om regressies te ontdekken.

Je DMARC-configuratie controleren#

Je kunt je huidige DMARC-record controleren door DNS te queryen:

dig TXT _dmarc.jouwdomein.com

Voor een uitgebreide check die je DMARC evalueert naast SPF, DKIM, MX-records en blacklist-status, gebruik je de gratis Email Health Checker van Nova Uptime. De tool geeft je een score uit 100, een lettercijfer (A tot F) en specifieke aanbevelingen om je DMARC-policy te verbeteren.

De tool evalueert de strengheid van je DMARC-policy als onderdeel van de scoring. Een p=reject-policy met aggregaatrapportage scoort het hoogst, terwijl p=none of een ontbrekend DMARC-record leidt tot significante puntenaftrek. Dit geeft je een helder beeld van waar je domein staat en welke stappen je vervolgens moet nemen.

DMARC-implementatietijdlijn#

Hier is een realistische tijdlijn voor een volledige DMARC-deployment:

Week	Actie	DMARC-record
1	Publiceer monitoring-record, zet rapportverwerking op	p=none; rua=mailto:...
2-4	Bekijk rapporten, repareer SPF/DKIM voor alle legitieme verzenders	p=none; rua=mailto:...
5-6	Zachte handhaving op 25%	p=quarantine; pct=25; rua=mailto:...
7-8	Volledige quarantaine	p=quarantine; rua=mailto:...
9-12	Volledige handhaving	p=reject; rua=mailto:...
Doorlopend	Maandelijkse rapportreview, configuraties onderhouden	p=reject; rua=mailto:...

Voor organisaties met een eenvoudige e-mailinfrastructuur (één primaire mailservice, één of twee marketingtools) kan dit worden gecomprimeerd tot 4 tot 6 weken. Voor enterprises met tientallen verzendservices: reken op 3 tot 6 maanden.

Belangrijkste punten#

• DMARC bouwt voort op SPF en DKIM door policyhandhaving en alignment-vereisten toe te voegen.
• Begin altijd met p=none en aggregaatrapportage. Spring nooit direct naar p=reject.
• Gebruik de pct-tag om de handhaving geleidelijk op te voeren.
• Bekijk aggregaatrapporten om alle legitieme e-mailbronnen te identificeren voordat je gaat handhaven.
• p=reject bereiken is het doel, maar het vereist voorbereiding.
• Blijf monitoren na deployment. DMARC vereist doorlopend onderhoud.
• Gebruik de Email Health Checker van Nova Uptime om je DMARC-configuratie te verifiëren en een volledige e-mailauthenticatie-evaluatie te krijgen.

Een correct geïmplementeerde DMARC-policy is een van de sterkste beschermingen die je voor je domein kunt inzetten. Het voorkomt spoofing, bouwt vertrouwen op met mailboxproviders en geeft je helder zicht op wie er namens jou e-mail verstuurt.

Veelgestelde vragen#

Wat is een DMARC-check?#

Een DMARC-check verifieert of je domein een geldig DMARC DNS-record heeft en evalueert de policy-instellingen. Het bevestigt dat de syntaxis van je DMARC-record correct is, dat je policy (none/quarantine/reject) correct is geconfigureerd en dat je rapportageadressen functioneel zijn. Doe een gratis DMARC-check om je huidige configuratie te zien.

Is gratis DMARC-monitoring mogelijk?#

Ja. Nova Uptime biedt DMARC-monitoring als onderdeel van de Email Health Checker. Het controleert je DMARC-record naast SPF, DKIM en blacklist-status op een instelbaar schema en waarschuwt je wanneer er iets verandert. Het gratis plan dekt tot 5 domeinen.

Hoe lang duurt het om p=reject te bereiken?#

Voor de meeste organisaties duurt de progressie van p=none naar p=reject 2-4 maanden. De tijdlijn hangt af van hoeveel legitieme e-mailbronnen je moet identificeren en authenticeren. Naar reject racen zonder DMARC-rapporten te bekijken riskeert je eigen legitieme e-mail te blokkeren.

Wat gebeurt er als ik DMARC op reject zet zonder SPF en DKIM?#

Je e-mails worden geweigerd door ontvangende servers. DMARC-handhaving vereist dat ten minste een van SPF of DKIM slaagt EN uitgelijnd is met je From-domein. Stel eerst SPF en DKIM in en laat DMARC daarna geleidelijk overgaan van none naar reject.

Verder lezen#

• SPF, DKIM & DMARC: complete gids — Hoe alle drie de protocollen samenwerken
• DMARC Test- & Configuratiegids — Geavanceerde DMARC-policyconfiguratie
• Gids voor e-mail-blacklistcheck en -verwijdering — Wat te doen wanneer authenticatieproblemen tot blacklisting leiden
• E-mail-deliverability-checklist — 15 stappen om je inbox-plaatsing te verbeteren
• Gratis Email Health Checker — Check DMARC, SPF, DKIM en blacklists in één scan