DMARC instellen: volledige stapsgewijze configuratiehandleiding (2026)

E-mailproviders beschouwen de implementatie van DMARC niet langer als een ‘nice-to-have’-beveiligingsmaatregel. Nu Gmail, Yahoo en Microsoft strengere authenticatie-eisen hanteren, lopen organisaties die DMARC nog niet hebben geïmplementeerd het risico dat hun berichten permanent worden geweigerd, dat het aantal spoofing-aanvallen toeneemt en dat ze problemen krijgen met de naleving van regelgeving.

In deze handleiding leer je hoe je DMARC helemaal vanaf nul kunt instellen, je SPF- en DKIM-configuratie kunt controleren, een conform DMARC-record kunt publiceren en stapsgewijs kunt overschakelen van de controlemodus naar volledige handhaving. We gaan ook in op de nieuwste updates van RFC 9989, veelvoorkomende configuratiefouten en praktische tips voor het oplossen van problemen, zodat je DMARC met vertrouwen kunt implementeren.

Aan het einde van deze handleiding voor het instellen van DMARC beschik je over een duidelijk stappenplan om je domein te beveiligen tegen spoofing-aanvallen, terwijl je er tegelijkertijd voor zorgt dat legitieme e-mails de inbox blijven bereiken.

Naleving in 2026: handhaving is van kracht

Gmail & Yahoo (nov. 2025): De permanente handhaving van 5xx-afwijzingen is van kracht voor bulkverzenders (5.000+ e-mails per dag). Berichten die niet aan de regels voldoen, worden permanent afgewezen en niet alleen gefilterd.

Microsoft Outlook (mei 2025): SPF, DKIM en DMARC worden actief gehandhaafd. E-mails die niet aan de vereisten voldoen, worden uitgesteld of geweigerd.

PCI DSS v4.0 (maart 2025): Anti-phishingmaatregelen zijn verplicht voor alle organisaties die betaalkaartgegevens verwerken.

• CISA BOD 18-01: Alle Amerikaanse federale instanties moeten DMARC implementeren met een p=reject-beleid.
• Bekijk de volledige vereisten: Wereldwijde en regionale DMARC-vereisten

Wat is DMARC en hoe werkt het?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is een protocol voor e-mailauthenticatie waarmee domeineigenaren ontvangende e-mailservers kunnen aangeven wat er moet gebeuren met berichten die de SPF- en DKIM-authenticatiecontroles niet doorstaan. Simpel gezegd voorkomt het dat anderen zich voordoen als uw domein en geeft het ontvangers aan hoe ze met bedriegers moeten omgaan.

DMARC bouwt voort op twee bestaande protocollen, SPF en DKIM. Samen vormen deze drie de basis van moderne e-mailbeveiliging.

DMARC, SPF en DKIM: hoe ze samenwerken

SPF (Sender Policy Framework) bepaalt welke mailservers e-mail mogen versturen vanuit uw domein. Het is een DNS-record dat aangeeft: „Alleen deze IP-adressen mogen e-mail versturen die afkomstig lijkt te zijn van example.com.”

DKIM (DomainKeys Identified Mail) voorziet je e-mails van een cryptografische handtekening. Deze handtekening bewijst dat het bericht van jou afkomstig is en tijdens het verzenden niet is gewijzigd. De handtekening wordt geverifieerd aan de hand van een openbare sleutel die in je DNS is gepubliceerd.

DMARC brengt deze elementen samen. Het zegt: „Dit is mijn beleid. Als een e-mail beweert afkomstig te zijn van mijn domein, moet deze voldoen aan de SPF- of DKIM-verificatie. Als dat niet het geval is, wil ik dat je het volgende doet: niets (alleen controleren), in quarantaine plaatsen (naar spam sturen) of afwijzen (volledig blokkeren).”

Lees meer over DMARC, SPF en DKIM in onze uitgebreide gids.

Wat gebeurt er als een e-mail niet aan de DMARC-vereisten voldoet?

Wanneer een ontvanger een e-mail ontvangt die zogenaamd afkomstig is van uw domein, wordt deze getoetst aan uw DMARC-beleid. De uitkomst hangt af van uw beleid:

• p=none (monitoring): De e-mail wordt ongeacht het resultaat verzonden. Je ontvangt een rapport waarin staat wat geslaagd is en wat mislukt is.
• p=quarantaine: Afgewezen e-mails worden naar de spam-/junkmap gestuurd. Legitieme e-mails komen nog steeds binnen.
• p=reject: E-mails die niet kunnen worden afgeleverd, worden direct geweigerd. De afzender ontvangt een terugmelding.

Voordat u DMARC instelt: vereisten en overzicht van afzenders

Veel organisaties haasten zich om DMARC in te voeren en stellen de instelling al snel in op ‘p=reject’, om vervolgens te ontdekken dat legitieme afzenders (CRM, ESP, helpdesk, marketingautomatiseringsplatforms) worden geblokkeerd. In dit hoofdstuk wordt het auditproces stap voor stap uitgelegd om die kostbare fout te voorkomen.

Stap 1: Controleer of er een SPF-record voor uw domein is gepubliceerd

Uw domein moet een geldig SPF-record in DNS hebben voordat DMARC kan werken.

1. Gebruik onze SPF-checker om te controleren of je SPF-record bestaat.

2. Controleer of er precies één SPF TXT-record voor uw domein bestaat. Als er twee SPF-records zijn, werkt SPF niet meer, omdat ontvangers beide records zullen negeren.

3. De regel zou er ongeveer zo uit moeten zien: v=spf1 include:sendgrid.net include:mailchimp.com ~all

Als er geen SPF-record is gepubliceerd of als er twee conflicterende records zijn, los dit dan eerst op voordat u verdergaat. Gebruik onze gratis tool om nu uw SPF-record aan te maken.

Stap 2: Controleer de opzoeklimiet van SPF 10

SPF staat maximaal 10 DNS-lookups per berichtbeoordeling toe. Elke externe afzender die je autoriseert (via `include:`) verbruikt 1 tot 3 van deze lookups. Als de limiet wordt overschreden, zal SPF voor sommige afzenders mislukken.

1. Gebruik onze SPF-checker om het aantal opzoekingen van je SPF-record te bekijken

2. Tel het aantal benodigde DNS-opzoekingen. Als je de 10 nadert of overschrijdt, krijg je een foutmelding.

3. Als je de limiet overschrijdt, kun je je record optimaliseren om het aantal zoekopdrachten te verminderen door `include:`-instructies te vervangen door expliciete IP-adressen. Dit is een veelvoorkomend knelpunt bij grote organisaties met veel externe afzenders.

Stap 3: Controleer of DKIM voor alle afzenders is geconfigureerd

DKIM is door Google, Yahoo en Microsoft verplicht gesteld voor bulkverzenders; het is geen optie.

1. Voor je primaire domein: gebruik onze gratis DKIM-checker om te controleren of je DKIM-record is gepubliceerd.

2. Controleer voor elke externe afzender (Salesforce, HubSpot, Klaviyo, enz.) of deze DKIM-ondertekening heeft ingeschakeld en de openbare sleutel als DNS-record heeft gepubliceerd. Hiervoor moet je de leverancier doorgaans vragen om „aangepaste DKIM voor je domein in te schakelen”.

3. Elke afzender moet een unieke DKIM-selector hebben (bijvoorbeeld k1._domainkey.example.com, sendgrid._domainkey.example.com).

Als DKIM ontbreekt, stel dit dan nu in voordat u overgaat op DMARC-handhaving. Gebruik onze gratis tool om een DKIM-record voor uw domein te genereren.

Stap 4: Maak een inventarisatie van alle externe e-mailafzenders

Maak een lijst van alle diensten die e-mail versturen vanuit uw domein:

• ESP’s (SendGrid, Mailchimp, Klaviyo, enz.)
• CRM (Salesforce, HubSpot, Pipedrive, enz.)
• Helpdesk-/ondersteuningssystemen (Zendesk, Freshdesk, enz.)
• Marketingautomatisering (Marketo, Pardot, ActiveCampaign, enz.)
• Platforms voor transactionele e-mail (Auth0, Stripe, AWS SES, enz.)
• Interne servers of applicaties die meldingen versturen
• Verzenddiensten of beheerders van mailinglijsten

Controleer voor elke afzender het volgende:

1. Ze voldoen aan de SPF-afstemming (opgenomen in je SPF-record)
2. Ze voldoen aan de DKIM-vereisten (DKIM-ondertekening is ingeschakeld voor uw domein)
3. Ze zijn zo ingesteld dat ze je domein gebruiken in de From:-header

Gebruik onze DMARC Report Analyzer om te controleren op ongeautoriseerde afzenders.

Stap 5: Controleer of er al een DMARC-record bestaat

Gebruik onze DMARC-checker om te controleren of uw domein al een DMARC-record heeft.

• Als je ‘p=none’ ziet: je domein bevindt zich in de monitoringmodus. Deze handleiding helpt je om veilig over te gaan naar de handhavingsmodus.
• Als je verouderde tags ziet (pct=, rf=, ri=): deze maken geen deel meer uit van de RFC 9989-standaard en moeten worden verwijderd wanneer je het record de volgende keer bewerkt.
• Als er geen gegevens zijn gevonden: je begint helemaal opnieuw. Ga verder naar het volgende gedeelte.

DMARC instellen: stap voor stap

Stap 1: Een DMARC-record aanmaken

Gebruik onze DMARC Generator-tool om uw eerste record aan te maken.

Verplichte velden:

• Domein: Uw domein (bijv. example.com)
• Beleid: Begin met p=none (monitoringmodus, geen handhaving)
• Rapportadres: het e-mailadres waarop u de samengevatte rapporten wilt ontvangen (bijv. [email protected])

Aanbevolen aanvullingen:

• np=reject: Beschermt niet-bestaande subdomeinen tegen spoofing (nieuw in RFC 9989, geen kosten)
• rua-adres: Bestemming van het geaggregeerde rapport (van cruciaal belang voor de monitoring)

Voorbeeld van een startrecord:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

Dit record geeft ontvangers de volgende instructie: „Controleer e-mails van mijn domein en stuur mij dagelijkse rapporten, maar blokkeer voorlopig nog niets.”

Stap 2: Zorg dat je je DMARC-record begrijpt voordat je het publiceert

Een DMARC-record bestaat uit een reeks tag-waardeparen die door puntkomma’s worden gescheiden. Alleen v= en p= zijn verplicht – al het andere is optioneel, maar wordt aanbevolen. Zorg dat je, voordat je het record publiceert, begrijpt wat elke tag doet:

Verplichte tags

Een label	Beschrijving en regels
v= (versie)	• Waarde: Altijd v=DMARC1 • Moet de eerste tag in het record zijn • Er is slechts één geldige waarde
p = (beleid)	• Waarden: none, quarantine, of reject • Geeft ontvangers aan hoe ze moeten omgaan met e-mails die de DMARC-controles niet doorstaan • Zie de onderstaande beleidstabel voor de verschillen

Optionele tags

np= (beleid inzake niet-bestaande subdomeinen)

• Waarden: geen, quarantaine of afwijzen
• Past een beleid toe op subdomeinen die geen DMARC-record hebben
• Biedt bescherming tegen het vervalsen van willekeurige subdomeinen (bijv. random123.example.com)
• Aanbeveling: Stel voor alle domeinen np=reject in. Het kost niets en dicht een lek dat misbruik mogelijk maakt.

rua= (rapportageadres voor geaggregeerde rapporten)

• Formaat: rua=mailto:[email protected]
• Je kunt meerdere adressen opgeven, gescheiden door komma’s: rua=mailto:[email protected],mailto:[email protected]
• Geaggregeerde rapporten zijn XML-overzichten die dagelijks door ontvangers worden verzonden
• Dit is van cruciaal belang voor de monitoring. Zonder dit heb je geen inzicht in je e-mailverkeer.

sp= (beleid voor subdomeinen)

• Waarden: geen, quarantaine of afwijzen
• Past een beleid toe op subdomeinen die een DMARC-record hebben
• Indien niet opgegeven, wordt het hoofdbeleid (p=) toegepast
• Gebruik deze optie als je strengere handhaving wilt voor subdomeinen (bijv. mail.example.com)

fo= (opties voor het melden van storingen)

• Waarden: 0 (standaard), 1, d, s of combinaties daarvan (0:1:d:s)
• Bepaalt wanneer forensische (storings)rapporten worden verzonden
• fo=0: Genereer alleen rapporten als alle authenticatiemechanismen mislukken
• fo=1: Rapporten genereren als een authenticatiemechanisme mislukt (meer gedetailleerd, handig tijdens de installatiefase)
• Wordt meestal gebruikt in combinatie met de tag ruf= (zie hieronder)
• Aanbeveling: Gebruik fo=1 tijdens de eerste installatie om alle fouten op te sporen; schakel over naar fo=0 zodra je zeker bent van je uitlijning

adkim= (DKIM-afstemmingsmodus)

• Waarden: r (soepel, standaard) of s (streng)
• Ontspannen: Het domein en het DKIM-ondertekende domein behoren tot hetzelfde organisatiedomein (bijvoorbeeld: mail.example.com en example.com komen overeen)
• Streng: domeinnamen moeten exact overeenkomen
• Aanbeveling: Begin met adkim=r (soepel). Schakel pas over naar strict als je alle ondertekeningsbronnen onder controle hebt.

aspf= (SPF-uitlijningsmodus)

• Waarden: r (soepel, standaard) of s (streng)
• Ontspannen: Het domein en het SPF Return-Path-domein behoren tot hetzelfde organisatiedomein
• Streng: domeinnamen moeten exact overeenkomen
• Aanbeveling: Begin met aspf=r. Schakel pas over naar „strict“ als je alle verzendbronnen onder controle hebt.

t= (testmodus)

• Waarden: y (testmodus aan) of weggelaten (testmodus uit)
• Wanneer deze is ingesteld op t=y, wordt aan de ontvangers doorgegeven dat jouw beleid één niveau lager moet worden toegepast
• p = quarantaine; t = y gedraagt zich voor ontvangers alsof p = geen
• p = afwijzen; t = y gedraagt zich voor ontvangers alsof p = quarantaine is
• Dit is de vervanging voor de verouderde pct=-tag
• Gebruik dit bij het invoeren van een strenger beleid: publiceer met t=y, houd de rapporten in de gaten en verwijder vervolgens t=y om het beleid af te dwingen

ruf= (adres van het forensisch rapport)

• Formaat: ruf=mailto:[email protected]
• Verzendt realtime kopieën van berichten waarbij de authenticatie is mislukt
• Belangrijke opmerking: Google, Microsoft en Yahoo versturen geen forensische rapporten meer (vanaf RFC 9989). Je kunt deze tag gerust toevoegen, maar er zullen geen rapporten van de grote ontvangers worden gegenereerd.
• Vermeld dit alleen als u over een geautomatiseerd systeem beschikt voor het verwerken van forensische rapporten

Verouderde en verwijderde tags (RFC 9989)

Deze tags maakten deel uit van RFC 7489, maar zijn niet langer onderdeel van de standaard. Voeg ze niet toe aan nieuwe records. Als ze in bestaande records voorkomen, verwijder ze dan bij je volgende DNS-wijziging.

pct=

• Werd gebruikt om het beleid toe te passen op een percentage van de mislukte berichten
• Leverde wisselende resultaten op bij de verschillende ontvangers
• Alternatief: Gebruik in plaats daarvan t=y voor een gefaseerde invoering
• Als het nog in oude records voorkomt, wordt het genegeerd door ontvangers die voldoen aan RFC 9989

rf=

• Was de tag voor het formaat van het storingsrapport (die altijd slechts één waarde had: afrf)
• Verwijderd omdat in de moderne rapportage een ander mechanisme wordt gebruikt

ri=

• Was de tag voor het rapportinterval
• Verwijderd omdat de rapportage-intervallen nu gestandaardiseerd zijn

Stap 2: Log in bij je DNS-provider

Log in op je DNS-beheerconsole (GoDaddy, Cloudflare, Namecheap, cPanel, Route 53, enz.).

Stap 3: Voeg het DMARC-record toe via je DNS-provider

Zoek de optie om een nieuw TXT-record toe te voegen, kopieer en plak de waarde uit de tool en klik op het pictogram ‘Opslaan’.

De procedure is bij alle providers hetzelfde: voeg een nieuw TXT-record toe, stel de naam in op _dmarc, plak je record als waarde en sla het op. De providerspecifieke navigatiepaden en de meest voorkomende valkuilen per provider staan in de onderstaande tabel.

Stap 5: Wacht tot de DNS-wijzigingen zijn doorgevoerd

Het kan tot 48 uur duren voordat DNS-wijzigingen wereldwijd zijn doorgevoerd, maar bij de meeste DNS-providers gebeurt dit binnen 1 à 2 uur. Om de doorvoering in realtime te volgen, kun je onze DNS Propagation Checker gebruiken. Voer gewoon je domein in en zoek naar het _dmarc TXT-record.

Stap 6: Controleer of je DMARC-configuratie actief is

Zodra de DNS-propagatie is voltooid, controleer je je record met behulp van onze DMARC Checker-tool.

1. Voer je domeinnaam in
2. Klik op ‘Opzoeken’
3. Je zou je record moeten zien verschijnen, waarbij alle tags zijn geparseerd
4. Als de checker bij jouw beleid de melding „DMARC-record gevonden“ weergeeft, is je systeem actief

Als u fouten ziet of als het record na 48 uur nog steeds niet is gevonden, controleer dan uw DNS-vermelding op syntaxfouten en configuratiefouten.

DMARC instellen volgens RFC 9989 – Wat is er in 2026 veranderd?

In mei 2026 heeft de IETF RFC 9989 gepubliceerd, waarmee RFC 7489 als officiële DMARC-standaard is vervangen. Uw bestaande v=DMARC1-records blijven volledig geldig, dus er is geen spoedmigratie nodig. Er zijn echter drie wijzigingen die gevolgen hebben voor iedereen die DMARC op dit moment configureert.

Wat RFC 9989 betekent voor uw DMARC-configuratie

1. pct= wordt nu niet meer aanbevolen

De tag `pct=` werd gebruikt om een beleid toe te passen op een percentage van de mislukte berichten. Dit leverde inconsistente resultaten op bij verschillende ontvangers en maakt geen deel meer uit van de standaard.

Actie: Verwijder ‘pct=’ uit alle nieuwe records. Als oudere records dit nog bevatten, verwijder het dan bij je volgende DNS-wijziging. Ontvangers negeren het weliswaar, maar het zorgt voor verwarring.

2. np= is nieuw

Met de tag `np=` (beleid voor niet-bestaande subdomeinen) kun je subdomeinen beschermen die niet bestaan. Aanvallers kunnen willekeurige subdomeinen (bijvoorbeeld `random123.example.com`) nabootsen om DMARC-controles te omzeilen. Door `np=reject` in te stellen, dicht je dit beveiligingslek zonder dat dit iets kost.

Actie: Dit is optioneel, maar je kunt ervoor kiezen om dit aan alle nieuwe records toe te voegen.

3. t=y is de nieuwe manier om beleidswijzigingen door te voeren

De tag `t=y` geeft ontvangers het signaal om je beleid één niveau lager toe te passen dan aangegeven. Zo kun je een strenger beleid testen voordat je het daadwerkelijk gaat handhaven.

• p = quarantaine; t = y gedraagt zich als p = geen (ontvangers plaatsen geen quarantaine; ze bezorgen en melden)
• p = afwijzen; t = y gedraagt zich als p = in quarantaine plaatsen (ontvangers plaatsen het bericht in quarantaine in plaats van het af te wijzen)

Actie: Bij het overschakelen van p=none naar p=quarantine of p=reject, gebruik eerst t=y. Houd de rapporten gedurende 1-2 weken in de gaten. Zodra je er zeker van bent, verwijder je t=y om de instelling door te voeren.

Hoe gebruik je t=y bij een gefaseerde uitrol?

Dit is de exacte werkwijze:

1. Huidige situatie:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

2. Als je klaar bent om de quarantaine te testen, publiceer dan:

v=DMARC1; p=quarantaine; t=y; np=afwijzen; sp=quarantaine; rua=mailto:[email protected]

Ontvangers beschouwen dit als p=none; ze leveren alles af en brengen verslag uit. Je observeert gedurende 1–2 weken.

3. Controleer of er geen legitieme e-mail is aangetast en verwijder vervolgens `t=y` om de wijziging door te voeren:

v=DMARC1; p=quarantaine; np=afwijzen; sp=quarantaine; rua=mailto:[email protected]

4. Nu belandt ongewenste e-mail in de spamfolder, terwijl legitieme e-mail hier geen last van heeft.

5. Zodra je klaar bent om het afwijzingsbeleid te testen, publiceer je het:

v=DMARC1; p=reject; t=y; np=reject; sp=reject; rua=mailto:[email protected]

6. Ontvangers beschouwen dit als p=quarantaine. Je moet de situatie 1–2 weken in de gaten houden.

7. Definitieve uitvoering: Verwijder t=y:

v=DMARC1; p=reject; np=reject; sp=reject; rua=mailto:[email protected]

8. Volledige afwijzing is nu actief.

Als er in een van de stappen iets misgaat: verwijder t=y, ga één beleidsniveau terug, los het probleem met de defecte afzender op en ga vervolgens weer verder.

Hoe u uw DMARC-beleid op een veilige manier kunt uitbreiden

De meeste DMARC-fouten ontstaan doordat organisaties direct naar `p=reject` overschakelen zonder eerst hun e-mailverkeer te controleren. Legitieme e-mails worden geblokkeerd, gebruikers klagen en de domeineigenaar draait in paniek de instellingen terug. In dit hoofdstuk wordt de juiste aanpak uitgelegd: een implementatie in drie fasen waarbij gebruik wordt gemaakt van geaggregeerde rapporten om voor elke stap vertrouwen op te bouwen.

Opmerking: In RFC 9989 wordt expliciet vermeld dat ontvangers bij indirecte e-mailstromen (doorsturen, mailinglijsten) p=reject moeten behandelen als p=quarantine. Voor domeinen waarvan de gebruikers deelnemen aan mailinglijsten, is p=quarantine het veiligere beleid voor permanente handhaving. Voor domeinen die uitsluitend voor transacties of marketingdoeleinden worden gebruikt en geen gebruikersmailboxen hebben, is p=reject geschikt.

Fase 1: Monitor (p = geen)

Duur: minimaal 2-4 weken. Bij complexe verzendomgevingen (10 of meer externe afzenders) duurt het langer.

Hoe je staat:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

Wat te doen:

1. Publiceer het bovenstaande bericht

2. Wacht tot de ontvangers de geaggregeerde rapporten versturen (dit gebeurt doorgaans binnen 24–48 uur)

3. Gebruik onze DMARC Report Analyzer om de dagelijkse rapporten te bekijken

4. Let op:

• Alle bekende verzendbronnen die in rapporten voorkomen
• Slaagpercentages voor SPF en DKIM per afzender
• Onbekende afzenders die je niet herkent
• Status van de afstemming (voldoen uw afzenders aan de afstemmingscriteria of niet?)

Wanneer moet je verdergaan:

• Alle legitieme afzenders voldoen aan de SPF- of DKIM-vereisten
• Geen onbekende bronnen in rapporten
• Je hebt gedurende ten minste 2 weken consistente gegevens verzameld
• Je hebt alle defecte verzenders gerepareerd

Als je nog niet bekend bent met DMARC-rapporten, raadpleeg dan onze handleiding over het lezen van DMARC-rapporten voor een eenvoudige uitleg.

Fase 2: Quarantaine (p = quarantaine)

Duur: 1-2 weken in t=y (testmodus), daarna doorlopend.

Stap A: Test met t=y (proefdraaien)

Publiceren:

v=DMARC1; p=quarantaine; t=y; np=afwijzen; sp=quarantaine; rua=mailto:[email protected]

Als t=y is, passen ontvangers het beleid één niveau lager toe: quarantaine gedraagt zich alsof het niet bestaat. Afgewezen e-mail wordt nog steeds bezorgd; je krijgt alleen rapporten te zien waarin staat wat er in quarantaine zou zijn geplaatst.

Houd dit 1–2 weken in de gaten. Controleer de rapporten en houd je inbox in de gaten. Let op het volgende:

• Er komt nog steeds legitieme e-mail binnen
• Storingsmeldingen waarin wordt aangegeven welke afzenders hierdoor zouden worden getroffen
• Normale percentages van spamklachten

Stap B: Toepassen (verwijder t=y)

Zodra je er zeker van bent, verwijder je t=y:

v=DMARC1; p=quarantaine; np=afwijzen; sp=quarantaine; rua=mailto:[email protected]

Nu belanden ongewenste e-mails in de spamfolder. Legitieme e-mails komen nog steeds gewoon binnen.

Voortdurende monitoring:

• Bekijk de geaggregeerde rapporten wekelijks
• Controleer de spammap op legitieme e-mails
• Als legitieme afzenders fouten gaan vertonen: schakel dan onmiddellijk terug naar p=none, los het uitlijningsprobleem op en ga vervolgens verder

Opmerking over BIMI-geschiktheid: Als u BIMI (Brand Indicators for Message Identification) wilt gebruiken om uw logo in Gmail weer te geven, moet u de instelling p=quarantine of p=reject hebben. p=none komt niet in aanmerking. Dit maakt het des te urgenter om het beleid aan te passen. Hier leest u hoe u BIMI voor uw domein kunt inschakelen.

Fase 3: Afwijzen (p = afwijzen)

Duur: 1-2 weken met t=y, daarna doorlopend.

Stap A: Test met t=y (proefdraaien)

Publiceren:

v=DMARC1; p=reject; t=y; np=reject; sp=reject; rua=mailto:[email protected]

Als t=y is, behandelen ontvangers ‘reject’ als quarantaine. Mislukte e-mails gaan naar de spamfolder en worden niet direct afgewezen. Houd dit 1 à 2 weken in de gaten.

Stap B: Toepassen (verwijder t=y)

v=DMARC1; p=reject; np=reject; sp=reject; rua=mailto:[email protected]

Foutieve e-mails worden nu direct geweigerd. De afzender ontvangt een foutmelding.

Beleidsaanbevelingen:

• Als uw domein e-mailboxen bevat waarvan de gebruikers op mailinglijsten staan (NAR, MLS, verenigingslijsten, enz.), gebruik dan p=quarantine als uw handhavingsbeleid.
• Als je domein uitsluitend voor transacties wordt gebruikt (SaaS, betalingen, fintech, marketingmails zonder gebruikersmailboxen): gebruik dan p=reject.

Problemen bij het instellen van DMARC oplossen: veelvoorkomende problemen en oplossingen

Probleem 1: „Geen DMARC-record gevonden” bij het controleren

Waarom dit gebeurt: de DNS-propagatie is nog niet voltooid, of je hebt de hostnaam verkeerd ingevoerd.

Hoe het te repareren:

1. Wacht 24 tot 72 uur na publicatie
2. Controleer nogmaals of de hostnaam precies _dmarc is (en niet _dmarc.yourdomain.com, zoals bij sommige tools het geval is; raadpleeg hiervoor de instructies van je provider)
3. Gebruik onze DNS-propagatiechecker om de propagatiestatus te controleren
4. Probeer onze DMARC-checker nog eens

Probleem 2: SPF en DKIM zijn niet op elkaar afgestemd

Waarom dit gebeurt: Het domein in de From:-header komt niet overeen met het domein dat via SPF of DKIM is geverifieerd.

Voorbeeld van een fout:

• Van: volgens de header [email protected]
• Het door SPF geverifieerde domein is mail.otherdomain.com
• Het DKIM-ondertekeningsdomein is newsletter.anotherdomain.com
• Resultaat: Geen overeenstemming. DMARC-controle mislukt.

Hoe het te repareren:

1. Begin met een ontspannen uitlijning (adkim=r; aspf=r) in je record. Hierdoor zijn overeenkomsten met subdomeinen mogelijk.

2. Gebruik onze DKIM-checker om het ondertekeningsdomein van elke afzender te controleren

3. Gebruik onze SPF-checker om te controleren of de SPF-record van elke afzender is opgenomen

4. Vraag de leverancier om het domein te configureren voor elke afzender bij wie er een fout optreedt. Bijvoorbeeld:

• “Schakel alstublieft DKIM-ondertekening in voor het domein example.com (geen subdomein)”
• “Gebruik alstublieft example.com als Return-Path/envelope-from-domein”

5. Zodra alle afzenders voldoen aan de versoepelde uitlijningsvereisten, kun je desgewenst overschakelen naar de strikte instelling (adkim=s; aspf=s)

Probleem 3: Afzender van een derde partij slaagt niet in de authenticatie

Waarom dit gebeurt: Een ESP, CRM of marketingplatform verstuurt e-mails vanuit uw domein, maar is niet geconfigureerd in uw SPF-record en/of heeft DKIM niet ingeschakeld.

Hoe het te repareren:

Bij SPF-fouten:

1. Zoek de SPF-include van de afzender op in hun documentatie (bijv. include:sendgrid.net)

2. Voeg dit toe aan je SPF-record: v=spf1 include:sendgrid.net include:mailchimp.com ~all

3. Test het met onze SPF-checker

Bij DKIM-fouten:

1. Vraag de provider om aangepaste DKIM voor uw domein in te schakelen

2. Publiceer de openbare DKIM-sleutel die zij verstrekken (meestal in de vorm: selector._domainkey.yourdomain.com)

3. Test het met onze DKIM-checker

Probleem 4: Meerdere SPF-records of een SPF-limiet van meer dan 10 opzoekingen

1. Meer dan één SPF-record: Als er twee SPF-TXT-records op hetzelfde domein staan, werkt SPF helemaal niet meer en zullen ontvangers beide records negeren.

Oplossing: Voeg je SPF-records samen tot één record, aangezien je per domein slechts één SPF TXT-record mag hebben.

Een voorbeeld:

• Oud record 1: v=spf1 include:sendgrid.net ~all
• Oud record 2: v=spf1 include:mailchimp.com ~all
• Nieuw samengevoegd record: v=spf1 include:sendgrid.net include:mailchimp.com ~all

2. Meer dan 10 DNS-opzoekingen: elke `include:` kan 1 tot 3 DNS-opzoekingen vereisen. Als je het aantal van 10 overschrijdt, mislukt de SPF-controle voor sommige afzenders.

Oplossing: Gebruik onze gehoste SPF om je record dynamisch te optimaliseren. Hierdoor worden `include:`-instructies vervangen door expliciete IP-adressen, waardoor het aantal opzoekacties wordt verminderd.

Een voorbeeld:

• Voorheen (meer dan 10 zoekopdrachten): v=spf1 include:sendgrid.net include:mailchimp.com include:klaviyo.com include:hubspot.com ~all
• Na optimalisatie: v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ip4:9.10.11.12 ~all

Probleem 5: Legitieme e-mail die na p=quarantaine in de spamfolder terechtkomt

Waarom dit gebeurt: Je bent doorgegaan naar p=quarantaine voordat je had gecontroleerd of alle legitieme afzenders de authenticatie hebben doorstaan.

Hoe het te repareren:

1. Ga onmiddellijk terug naar p=none
2. Bekijk je geaggregeerde rapporten om te achterhalen welke afzender problemen veroorzaakt
3. Hun authenticatie corrigeren (SPF- of DKIM-afstemming)
4. Ga terug naar p=quarantaine, maar test met t=y en houd de situatie 1-2 weken in de gaten voordat je de maatregel doorvoert

Probleem 6: Syntaxisfouten in DMARC-records

Waarom dit gebeurt: een typefout in het record, ontbrekende puntkomma’s of tags die niet worden ondersteund

Hoe het te repareren:

1. Controleer dit met onze DMARC-checker, want die zal syntaxfouten aan het licht brengen
2. Gebruik onze DMARC-generator om het record opnieuw aan te maken in plaats van het handmatig te bewerken
3. Kopieer het gegenereerde record en plak het bij je DNS-provider

Laatste woorden

Het correct configureren van DMARC is niet langer optioneel. De permanente afwijzingsmaatregel van Gmail, de vereisten van Yahoo en Microsoft, de aanbevelingen van PCI DSS v4.0 en CISA BOD 18-01 maken DMARC tot een noodzaak om aan de voorschriften te voldoen.

De veilige, betrouwbare aanpak is om het rustig aan te doen, voortdurend te controleren en op verantwoorde wijze handhaving toe te passen. Maar als u op zoek bent naar sneller en eenvoudiger DMARC-beheer met geautomatiseerde rapportverwerking, nalevingscontrole en doorlopende ondersteuning, overweeg dan een gehost DMARC-platform zoals PowerDMARC, dat de installatie, schaalbaarheid en handhaving voor zijn rekening neemt, zodat u zich kunt concentreren op de beveiliging. Start vandaag nog uw gratis proefperiode of boek een demo om uw domein nu te beveiligen.

Veelgestelde Vragen

Hoe lang duurt het om DMARC in te stellen?

Het instellen van de DNS-records duurt slechts enkele minuten. De DNS-propagatie duurt maximaal 72 uur (meestal 1-2 uur). Het volledig van kracht worden van de maatregelen (waarbij met zekerheid p=reject wordt bereikt) duurt doorgaans 4-8 weken, afhankelijk van het aantal verzendende bronnen en hoe snel afstemmingsproblemen worden opgelost.

Heeft de configuratie van DMARC invloed op de afleverbaarheid van e-mail?

Bij p=none heeft dit geen enkele invloed op de afleverbaarheid, aangezien de monitoringmodus geen handhavingsmaatregelen omvat. Bij p=quarantine of p=reject worden alleen niet-geverifieerde en niet-conforme e-mails beïnvloed. Correct geverifieerde e-mails ondervinden geen hinder en zien vaak zelfs een verbeterde afleverbaarheid. DMARC kan de plaatsing in de inbox op lange termijn verbeteren door een domeinreputatie op te bouwen bij inboxproviders.

Hoe stel ik DMARC in voor meerdere domeinen?

Houd er bij het instellen van DMARC voor meerdere domeinen rekening mee dat elk domein zijn eigen DMARC TXT-record nodig heeft op _dmarc.[domein].

Een voorbeeld:

• Domein 1: _dmarc.example.com TXT-record
• Domein 2: _dmarc.example.org TXT-record

Voor organisaties die veel domeinen beheren, biedt een gehost DMARC-platform de mogelijkheid om alle records vanuit één dashboard te beheren, waardoor schaalbaarheid eenvoudig wordt.

Wat is DMARC afstemming?

Overeenstemming houdt in dat het domein in de From:-header moet overeenkomen met het domein dat door SPF of DKIM is geauthenticeerd. Bij ‘relaxed alignment’ (de standaardinstelling, adkim=r; aspf=r) zijn overeenkomsten op organisatieniveau toegestaan, terwijl bij ‘strict alignment’ (adkim=s; aspf=s) exacte overeenkomsten vereist zijn.

• 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)

• DMARC instellen: volledige stapsgewijze configuratiehandleiding (2026) - 20 juni 2026
• Hoe DMARC-rapporten te lezen: een complete gids voor RUA en RUF - 10 juni 2026
• Wat is DMARC? Definitie, hoe het werkt en waarom het belangrijk is - 28 april 2026