Wat is een DMARC-beleid? Geen, quarantaine en weigeren

E-mailfraude is een van de hardnekkigste en schadelijkste cyberdreigingen waarmee organisaties tegenwoordig te maken hebben. Volgens het Verizon Data Breach Investigations Reportblijft phishing een van de belangrijkste oorzaken van datalekken, en beginnen de meeste aanvallen met een vervalst e-maildomein.

Een DMARC-beleid vormt uw eerste verdedigingslinie. Dit is vastgelegd in RFC 7489is DMARC (Domain-based Message Authentication, Reporting, and Conformance) een e-mailverificatieprotocol dat ontvangende mailservers vertelt wat ze moeten doen wanneer een e-mail de verificatiecontroles niet doorstaat. Zonder dit protocol kunnen aanvallers zich vrijelijk voordoen als uw domein om uw klanten, medewerkers en partners te benaderen.

In deze gids wordt uitgelegd wat een DMARC-beleid precies inhoudt, welke drie beleidsopties er zijn, hoe je dit op de juiste manier implementeert en handhaaft, en hoe je de veelvoorkomende valkuilen kunt vermijden waardoor de meeste bedrijven onbeschermd blijven.

Wat is DMARC-beleid?

Een DMARC-beleid is een reeks instructies die in uw DNS worden gepubliceerd en die ontvangende mailservers aangeven hoe ze e-mails moeten behandelen die niet door de DMARC-authenticatie komen. Simpel gezegd is het de handhavingslaag van het DMARC-protocol en bepaalt het het lot van elk niet-geverifieerd bericht dat beweert afkomstig te zijn van uw domein.

Zonder een DMARC-beleid staat uw e-maildomein in feite wijd open. Cybercriminelen kunnen frauduleuze e-mails versturen die afkomstig lijken te zijn van uw organisatie, en uw klanten en medewerkers met phishingaanvallen benaderen.

Hoe werkt een DMARC-beleid?

Een DMARC-beleid zorgt ervoor dat ontvangende mailservers een duidelijk stappenplan krijgen dat ze moeten volgen wanneer een e-mail de DMARC-authenticatie niet doorstaat. Hieronder wordt precies uitgelegd hoe dat proces verloopt, van verzending tot ontvangst in de inbox.

Het authenticatieproces, stap voor stap:

1. Een afzender verstuurt een e-mailbericht waarin wordt beweerd dat het afkomstig is van uw domein.
2. De ontvangende mailserver voert SPF- en DKIM-verificatiecontroles uit op het bericht.
3. Als het bericht beide controles doorstaat en het domein overeenkomt met de From-header, doorstaat het de DMARC-authenticatie en komt het terecht in de inbox van de ontvanger.
4. Als het bericht de DMARC-controles niet doorstaat, leest de server uw DMARC-record uit je DNS-records.
5. Op basis van uw gepubliceerde DMARC-beleid bezorgt de server het niet-geverifieerde bericht, plaatst het in quarantaine of weigert het.
6. De ontvangende server stuurt DMARC-samenvattingsrapporten terug naar het adres dat in uw DMARC-record is opgegeven.

DMARC controleert ook of het geverifieerde domein overeenkomt met het domein in de From-header. Dit wordt ‘identifier alignment’ genoemd en het dicht de maas in de wet waardoor aanvallers een gelijkend domein kunnen gebruiken om de standaardverificatiecontroles voor e-mail te omzeilen.

Zonder afstemming zou een kwaadwillende gebruiker de SPF-verificatie voor één domein kunnen doorstaan, terwijl hij in het ‘Van’-adres dat uw ontvangers daadwerkelijk zien, een heel ander domein vervalst.

Voordat u DMARC configureert

SPF en/of DKIM moeten al minstens 48 uur zijn geïmplementeerd en actief zijn voordat u uw DMARC-record kunt instellen. Als deze niet zijn ingesteld, kan uw DMARC-beleid niets controleren.

Het is ook de moeite waard om te begrijpen hoe DNS werkt voordat u records gaat publiceren, aangezien verkeerd geconfigureerde DNS TXT-records een van de meest voorkomende oorzaken zijn van DMARC-fouten.

Aanbevolen lectuur: Statistieken over e-mailphishing en DMARC: beveiligingstrends voor 2026

De 3 DMARC-beleidsopties

Er zijn drie beleidsopties: p=none, p=quarantine en p=reject. Elk staat voor een ander niveau van DMARC-handhaving. Het kiezen van de juiste optie op het juiste moment is wat organisaties die daadwerkelijk beschermd zijn onderscheidt van organisaties die alleen maar denken dat ze dat zijn.

1. p=geen

p=none is de minst strenge DMARC-beleidsoptie. Hiermee wordt aan ontvangende servers aangegeven dat ze geen actie moeten ondernemen bij e-mails die de DMARC-authenticatie niet doorstaan. Elk bericht, of het nu wel of niet wordt geauthenticeerd, wordt gewoon in de inbox van de ontvanger afgeleverd. Er wordt niets geblokkeerd en niets wordt als verdacht gemarkeerd.

Het enige wat het doet, is DMARC-geaggregeerde rapporten, zodat u kunt zien wie er namens uw domein e-mail verstuurt, hoeveel berichten de authenticatie doorstaan of niet doorstaan, en welke IP-adressen mogelijk uw domein vervalsen.

p=none biedt geen enkele bescherming tegen e-mailspoofing, aangezien:

• Ongeautoriseerde e-mails worden nog steeds afgeleverd
• Er komen nog steeds frauduleuze berichten binnen
• Aanvallers kunnen vrijelijk gebruikmaken van uw domein

Het is het juiste uitgangspunt, maar het is geen einddoel. De meeste bedrijven komen nooit verder dan p=none, waardoor ze volledig onbeschermd blijven. Als uw DMARC-beleid niet is ingeschakeld dan de monitoringmodus, staat je domein nog steeds wijd open.

2. p = quarantaine

p=quarantaine is het tijdelijke handhavingsbeleid. Het zorgt ervoor dat de ontvangende mailserver berichten die de authenticatie niet doorstaan met argwaan behandelt en deze naar de spam- of junkmap van de ontvanger doorstuurt in plaats van naar de inbox.

E-mails die de DMARC-verificatie doorstaan, worden hierdoor helemaal niet beïnvloed. Alleen niet-geverifieerde berichten worden als verdacht beschouwd en uit de inbox verwijderd.

Het quarantainebeleid biedt u actieve handhaving en tegelijkertijd een vangnet. Als een legitieme e-mailbron verkeerd is geconfigureerd en DMARC-controles niet meer doorstaat, komt deze in de spam terecht in plaats van direct te worden geweigerd. U kunt dit opmerken, het probleem oplossen en verstoring van uw e-mailverkeer voorkomen.

U moet pas overgaan naar p=quarantine nadat u uw DMARC-rapporten grondig hebt geanalyseerd en hebt gecontroleerd of alle bekende legitieme afzenders correct zijn geauthenticeerd.

3. p = afwijzen

p=reject is het strengste DMARC-beleid en de gouden standaard voor e-mailbeveiliging. Het geeft ontvangende servers de opdracht om niet-geverifieerde berichten volledig te weigeren. Frauduleuze e-mails komen nooit in de inbox, de spamfolder of ergens anders terecht.

Volledige p=afwijzingen domeinspoofing aanvallen in de kiem, beschermt de reputatie van uw merk en geeft aan mailboxproviders aan dat uw domein betrouwbaar is, wat de plaatsing in de inbox van uw legitieme e-mail kan verbeteren.

P=reject is echter meedogenloos. Alle e-mails van legitieme afzenders die niet correct zijn geauthenticeerd voordat u op dit beleid overschakelt, worden geweigerd. U moet ervoor zorgen dat alle legitieme afzenders op de witte lijst staan en de DMARC-authenticatie doorstaan voordat u deze overstap maakt.

Andere DMARC-beleidslabels die u moet kennen

De p=tag krijgt de meeste aandacht, maar een DMARC-record bevat nog verschillende andere beleidsinstellingen die rechtstreeks van invloed zijn op hoe uw beleid werkt. Het negeren hiervan is een van de redenen waarom organisaties, zelfs na het publiceren van een DMARC-record, nog steeds te maken hebben met hiaten in hun beveiliging.

sp= (Beleid voor subdomeinen)

De sp= tag bepaalt hoe uw DMARC-beleid van toepassing is op subdomeinen. Als u een beleid hebt ingesteld voor uw hoofddomein, maar sp= weg, nemen uw subdomeinen standaard het beleid van het hoofddomein over. In de meeste gevallen is dit prima, maar als u een ander handhavingsniveau wilt toepassen op subdomeinen, moet u dit expliciet instellen.

Als je hoofddomein bijvoorbeeld op p=reject staat, maar een subdomein nog niet klaar is voor volledige handhaving, kun je sp=quarantine instellen om daar een minder streng beleid toe te passen.

pct= (procentuele tag)

De tag `pct=` geeft aan ontvangende servers door op welk percentage van de mislukte berichten uw beleid moet worden toegepast. Als deze tag wordt weggelaten, is de standaardwaarde 100. Deze tag is vooral nuttig tijdens de overgang van `p=quarantine` naar `p=reject`.

In plaats van de schakelaar in één keer voor al het verkeer om te zetten, kunt u beginnen met pct=10 of pct=25 en dit geleidelijk opschalen terwijl u uw rapporten in de gaten houdt.

adkim= en aspf= (uitlijningsmodi)

Deze twee tags bepalen hoe streng DMARC de domeinafstemming controleert voor DKIM en SPF controleert. De twee opties zijn r (relaxed) en s (strict). Bij 'relaxed' alignment is een subdomeinovereenkomst toegestaan, wat betekent dat mail.uwdomein.com zou slagen voor de alignment-controle voor uwdomein.com.

Voor een strikte uitlijning is een exacte overeenkomst vereist. De meeste organisaties zouden een soepele uitlijning moeten gebruiken; dit is de standaardinstelling wanneer deze tags worden weggelaten.

fo= (Opties voor het melden van storingen)

De fo= tag bepaalt wanneer DMARC-forensische rapporten worden gegenereerd. De standaardwaarde is 0, wat betekent dat er alleen een rapport wordt verzonden wanneer zowel SPF als DKIM falen. Als u fo=1 instelt, wordt er een rapport verzonden wanneer SPF of DKIM faalt.

Als u fo=s of fo=d instelt, worden er rapporten gegenereerd die specifiek betrekking hebben op SPF- of DKIM-fouten. Voor een beter inzicht in de probleemoplossing is fo=1 de meest bruikbare instelling.

Vergelijking van DMARC-beleidsregels: p=none versus p=quarantine versus p=reject

De keuze tussen de drie DMARC-beleidsopties is eenvoudiger als je ze naast elkaar kunt bekijken. Gebruik dit als een handig overzicht wanneer je beslist welk beleid het beste past bij de huidige fase van DMARC-implementatie.

De meeste organisaties zouden dit als een stapsgewijs proces moeten zien: begin met p=none, analyseer uw DMARC-rapporten, corrigeer verkeerde instellingen, ga over naar p=quarantine en stap vervolgens over naar p=reject zodra alle legitieme e-mailbronnen zijn geverifieerd.

Hoe je van p=none naar p=reject gaat

De overgang van p=none naar volledige handhaving van het DMARC-beleid is een gefaseerd proces waarbij u in elke fase uw rapporten zorgvuldig moet analyseren. Overhaasting bij deze overgang is de meest voorkomende oorzaak van het blokkeren van legitieme e-mails.

Stap 1: Publiceer een record met p=none en begin met het verzamelen van gegevens

Begin met het publiceren van een DMARC-record met p=none en een geldig rua=-adres. Hiermee schakel je de bewakingsmodus in.

Alle e-mailberichten blijven gewoon doorlopen, maar u ontvangt nu DMARC-overzichtsrapporten waarin wordt weergegeven wie er vanuit uw domein verstuurt, welke berichten de authenticatie doorstaan of niet doorstaan, en welke IP-adressen hierbij betrokken zijn.

Stap 2: Analyseer je DMARC-overzichtsrapporten

Onbewerkte geaggregeerde rapporten worden geleverd als XML-bestanden en zijn niet gemakkelijk handmatig te lezen. Gebruik een DMARC-rapportanalysator om ze te parseren tot leesbare dashboards.

Controleer alle legitieme e-mailbronnen die vanaf uw domein verzenden, IP-adressen die onverwacht niet door de DMARC-controle komen, SPF- en DKIM-afstemmingsfouten bij bekende legitieme afzenders, en ongeautoriseerde afzenders die proberen uw domein te vervalsen.

Houd deze DMARC-authenticatieresultaten minimaal twee tot vier weken in de gaten voordat u beleidswijzigingen doorvoert. Met de geaggregeerde rapportweergaven van PowerDMARC kunt u deze trends in de loop van de tijd eenvoudig volgen.

Stap 3: SPF- en DKIM-afwijkingen verhelpen

Onderzoek voor elke legitieme e-mailbron die niet voldoet aan de DMARC-controles wat de oorzaak is en los deze op. Veelvoorkomende oplossingen zijn onder meer het toevoegen van ontbrekende IP-adressen aan uw SPF-record, het instellen van DKIM-ondertekening voor e-maildiensten van derden en het corrigeren van configuratiefouten in doorgestuurde e-mailstromen.

Door DMARC-rapporten regelmatig te controleren, kunt u deze problemen opsporen voordat ze tot bezorgingsproblemen leiden.

Stap 4: Zet alle legitieme afzenders op de witte lijst

Voordat er een handhavingsbeleid wordt ingevoerd, moet elke legitieme e-mailbron consequent de DMARC-authenticatie doorstaan. Als er in dit stadium ook maar één afzender ontbreekt, kan dit ertoe leiden dat die e-mails worden geweigerd zodra u `p=reject` toepast.

Stap 5: Verplaats naar p=quarantaine bij 10 tot 25 procent

Gebruik de tag `pct=` om uw nieuwe beleid eerst toe te passen op een percentage van de berichten die niet door de controle komen. Begin met `p=quarantine` bij `pct=25` en houd uw rapporten goed in de gaten.

Als legitieme e-mails in de spamfolder terechtkomen, moet je eerst het probleem met de afzender oplossen voordat je verder kunt gaan.

Stap 6: Pas de schaal van p=quarantaine aan naar 100 procent

Zodra u er zeker van bent dat de 25 procent aan mislukte berichten daadwerkelijk ongeautoriseerd is, verhoogt u pct= tot 100 en gaat u door met het monitoren.

Stap 7: Ga naar p=afwijzen

Zodra p=quarantine vlekkeloos op 100 procent draait en er geen legitieme e-mail meer wordt tegengehouden, bent u klaar om over te gaan op volledige handhaving. Alle niet-geverifieerde berichten worden nu vóór aflevering geblokkeerd.

PowerDMARC’s gehoste DMARC-service service kan deze hele overgang voor u beheren, waarbij beleidsupdates worden geautomatiseerd zonder dat er bij elke stap handmatige DNS-wijzigingen nodig zijn.

DMARC-rapportage: geaggregeerde rapporten versus forensische rapporten

Met DMARC-rapporten maakt u van uw beleid een actief hulpmiddel voor informatievergaring. Als u deze rapporten niet leest, krijgt u geen inzicht in wie uw domein gebruikt, wat er misgaat of of uw handhavingsmaatregelen effect sorteren.

Er zijn twee soorten rapporten, die elk een heel ander doel dienen.

Veelvoorkomende fouten in DMARC-beleid en hoe je deze kunt verhelpen

De implementatie van DMARC kan complex zijn, en kleine configuratiefouten kunnen vaak grote gevolgen hebben. Hieronder vindt u de meest voorkomende fouten en hoe u deze snel kunt oplossen.

Ontbrekend of onjuist opgebouwd DMARC TXT-record

Als u onder een verkeerde hostnaam publiceert, de tag v=DMARC1 weglaat of dubbele records aanmaakt, zullen ontvangende servers uw beleid volledig negeren. Een veelvoorkomende fout bij hostnamen is het gebruik van dmarc.uwdomein.com in plaats van _dmarc.uwdomein.com.

Oplossing: Controleer uw record met de DMARC Record Checker van PowerDMARC voor en na elke DNS-wijziging.

SPF en DKIM zijn niet op elkaar afgestemd

Uw SPF en DKIM kunnen beide worden goedgekeurd, terwijl uw berichten toch niet voldoen aan DMARC als het geauthenticeerde domein niet overeenkomt met de From-header. Dit is een van de meest voorkomende misvattingen bij de implementatie van DMARC.

Oplossing: Controleer uw instellingen voor adkim= en aspf= in uw DMARC-record. Een soepele afstemming is voor de meeste organisaties de juiste standaardinstelling en staat overeenkomsten op subdomeinniveau toe zonder dat een exacte domeinovereenkomst vereist is.

Legitieme e-mails worden niet meer afgeleverd na de overgang naar handhaving

Dit betekent vrijwel altijd dat een legitieme afzender tijdens de controlefase over het hoofd is gezien en nu door uw strengere beleid wordt tegengehouden.

Oplossing: Schakel tijdens het onderzoek terug naar p=quarantaine met een lage pct=-waarde. Zoek de afzender die niet voldoet in uw geaggregeerde rapporten, corrigeer de SPF- of DKIM-configuratie, controleer of de berichten nu consistent worden geaccepteerd en schakel vervolgens weer over naar de normale instellingen.

Overschrijding van de limieten voor SPF-DNS-lookups

Er geldt een maximum van 10 SPF-records DNS-lookups. Als u via voldoende platforms van derden verstuurt, overschrijdt u deze limiet, waardoor SPF faalt en dit direct leidt tot DMARC-fouten voor legitieme e-mail.

Oplossing: Controleer uw SPF-record en gebruik geautomatiseerd SPF-beheer om uw record te vereenvoudigen en binnen de opzoeklimieten te blijven.

Er is geen rapportageadres geconfigureerd

Zonder een geldig rua=-adres hebt u wel een beleid geïmplementeerd, maar geen inzicht in of het werkt, wat er misgaat of dat er spoofing plaatsvindt op uw domein.

Oplossing: Zorg ervoor dat u vanaf dag één altijd een geldig rua=-adres opneemt. Als u meerdere domeinen beheert, gebruik dan een gecentraliseerd rapportageplatform om uw DMARC-aggregaterapporten op één plek te consolideren.

Bescherm uw domein met PowerDMARC

Een DMARC-beleid is slechts zo effectief als de uitvoering ervan. De technische stappen zijn eenvoudig. Maar het voortdurende werk van het analyseren van rapporten, het verhelpen van verkeerde configuraties, het op de witte lijst plaatsen van legitieme afzenders en het veilig doorvoeren van handhavingsmaatregelen is waar de meeste organisaties tekortschieten.

PowerDMARC is ontwikkeld om dat hele proces overzichtelijk te maken. Van het aanmaken van uw eerste DMARC-record tot het volledig doorvoeren van de p=reject-regel: het platform regelt elke stap. Het biedt onder meer gehost beleidsbeheer, dashboards met geautomatiseerde rapportages, realtime waarschuwingen voor bedreigingen en SPF- en DKIM-monitoring voor al uw domeinen.

Organisaties die PowerDMARC gebruiken, schakelen sneller over van p=none naar p=reject, met minder verstoringen voor legitieme e-mail en met volledig inzicht in elke afzender die hun domein gebruikt.

Uw domeinnaam is uw merk. Laat deze niet onbeschermd.

Boek een demo en zet vandaag nog uw eerste stap naar volledige e-mailverificatie en handhaving.

FAQs

1. Wat is het standaard DMARC-beleid?

Er is geen standaard DMARC-beleid. Als er geen DMARC-record bestaat, voeren ontvangende servers geen DMARC-controles uit. Wanneer u voor het eerst een DMARC-record aanmaakt, wordt aanbevolen om te beginnen met `p=none` voor controledoeleinden.

2. Kunnen DMARC-beleidsregels invloed hebben op de afleverbaarheid van e-mails?

Ja, DMARC-beleidsregels kunnen de afleverbaarheid met 10 tot 15% verbeteren wanneer ze correct worden geïmplementeerd, aangezien geauthenticeerde domeinen meer vertrouwen genieten bij e-mailproviders. Een onjuiste implementatie kan er echter toe leiden dat legitieme e-mails in quarantaine worden geplaatst of worden geweigerd.

3. Wat is het verschil tussen SPF, DKIM en DMARC?

SPF controleert of de verzendende server geautoriseerd is, DKIM waarborgt de integriteit van berichten door middel van cryptografische handtekeningen, terwijl DMARC zorgt voor de handhaving van het beleid en rapportage door voort te bouwen op de resultaten van zowel SPF als DKIM.

4. Hoe lang moet ik de instelling „p=none“ aanhouden voordat ik overga op strengere regels?

Laat de instelling op `p=none` staan gedurende ten minste 30 dagen om uitgebreide DMARC-rapporten te verzamelen. Voor complexe organisaties met meerdere e-mailbronnen is het raadzaam om 60 tot 90 dagen aan te houden, zodat alle legitieme afzenders worden geïdentificeerd en correct geauthenticeerd.

5. Welk DMARC-beleid is het beste?

p=reject is het strengste beleid, aangezien het voorkomt dat ongeautoriseerde e-mails worden afgeleverd. Dat gezegd hebbende, is het riskant om meteen met p=reject te beginnen. De aanbevolen aanpak is om te beginnen met p=none om uw e-mailverkeer te monitoren, over te stappen op p=quarantine zodra u al uw legitieme afzenders hebt geïdentificeerd, en pas p=reject toe te passen wanneer u er zeker van bent dat alle legitieme berichten correct zijn geauthenticeerd.

6. Hoe pas ik mijn DMARC-beleid aan?

U kunt uw DMARC-beleid bijwerken door uw DMARC TXT-record rechtstreeks in uw DNS-beheerconsole te bewerken en de waarde van de p=-tag te wijzigen. Als u op zoek bent naar een eenvoudigere optie, kunt u met Hosted DMARC van PowerDMARC uw beleid met één muisklik bijwerken.

7. Welk DMARC-beleid zou u hanteren om e-mails te weigeren die niet door de DMARC-controles komen?

Gebruik p=reject. Hiermee geef je ontvangende mailservers de opdracht om berichten die de DMARC-verificatie niet doorstaan, direct te blokkeren. De e-mail komt dan niet terecht in de inbox of de spamfolder van de ontvanger. Als je wilt dat e-mails die de verificatie niet doorstaan in de spamfolder terechtkomen in plaats van volledig te worden geblokkeerd, gebruik dan p=quarantine.

• Over
• Laatste berichten

Maitham Al Lawati

Cyberbeveiligingsexpert, CEO bij PowerDMARC

Maitham is een technisch ondernemer, cyberbeveiligingsexpert, CEO en oprichter van PowerDMARC met meer dan 15 jaar ervaring in de sector. Maitham heeft een Global MBA van de Universiteit van Manchester en diverse professionele certificeringen waaronder CISSP, CISM, CRISC en ISC2 CCSP.

Laatste berichten van Maitham Al Lawati (Bekijk alle berichten)

• E-mailphishing en DMARC-statistieken: trends op het gebied van e-mailbeveiliging in 2026 - 6 januari 2026
• Hoe u 'Geen SPF-record gevonden' kunt oplossen in 2026 - 3 januari 2026
• SPF Permerror: Hoe te veel DNS-lookups te verhelpen - 24 december 2025