# Wat is DMARC? Uitlijning, Beleidslijnen en RFC 9989

URL: https://notificationharbor.com/nl/journal/wat-is-dmarc
Type: blog
Locale: nl
Published: 2026-09-29
Updated: 2026-09-29

---

> DMARC vertelt ontvangers wat te doen wanneer mail uitlijning niet haalt. Hier ziet u hoe het record, beleidslijnen en rapporten werken, en wat in 2026 veranderde.

Wat is DMARC? Het is een DNS-record dat ontvangende mailservers vertelt wat ze moeten doen wanneer een bericht jouw domein claimt in de From-header, maar de authenticatie faalt. Daarbij geeft het ook aan waar rapportage naartoe moet gaan. DMARC verifieert niet zelf. Het checkt dat SPF of DKIM is geslaagd en dat het domein dat zij hebben geverifieerd aansluit op het domein dat de lezer ziet.

Die overeenkomst heet alignment, en het is het punt waar meeste teams het verkeerd aanpakken. Een bericht kan SPF doorstaan, DKIM doorstaan en DMARC alsnog falen.

## DMARC is een beleidstandaard bovenop SPF en DKIM

SPF somt de IP-adressen op die namens jouw domein mail mogen sturen. DKIM ondertekent het bericht zodat een ontvanger kan controleren dat het niet is gewijzigd en dat het ondertekende domein akkoord is gegaan. Geen van beide kijkt naar het From-adres dat een mens ziet.

DMARC vult die kloof. Het stelt één vraag: sluit het domein in de zichtbare From-header aan op het domein dat SPF of DKIM heeft geverifieerd? Ja, het bericht slaagt. Nee, de ontvanger past jouw beleid toe.

![Engineer reviewing DNS records in a terminal on a laptop at a desk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f76a50-inline1.webp)

Het record staat op `_dmarc.jouwdomein.nl` als een TXT-record. Een minimaal, geldig record ziet er zo uit:

`_dmarc.voorbeeld.nl.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rapporten@voorbeeld.nl"`Drie tags doen het echte werk. `p` is het beleid, `rua` is waar de aggregatierapporten heen gaan, en `adkim` / `aspf` bepalen hoe strikt alignment moet zijn. Alles andere is optioneel.

## Alignment is waar goed ingestelde systemen falen

SPF verifieert de envelopsender, het Return-Path-domein. DKIM verifieert het domein in de `d=`-tag van de handtekening. DMARC heeft nodig dat tenminste één ervan aansluit op het From-domein, hetzij exact (streng) hetzij op organisatiedomein-niveau (ontspannen, de standaard).

Hier is het falen dat we het vaakst zien in traces. Een team stuurt via een derde partij, die partij ondertekent met haar eigen domein (`d=provider-mail.nl`) en gebruikt haar eigen bounce-domein. SPF slaagt, DKIM slaagt, en DMARC faalt omdat geen van beide domeinen `voorbeeld.nl` matchen.

De oplossing is een aangepast verzenddomein: een DKIM-sleutel gepubliceerd onder jouw domein, en bij voorkeur een aangepast return-path op een subdomein. Elke serieuze provider ondersteunt dat. Bijna niemand zet het standaard aan.

## De drie beleidslijnen: none, quarantine, reject

De `p`-tag heeft drie waarden, en het zijn niet drie trappen die je op schema klimt.

- 
**`p=none`**: de ontvanger bezorgt normaal en stuurt je rapporten. Gebruik dit de eerste 2 tot 4 weken, terwijl je je verzenders inventariseert.

- 
**`p=quarantine`**: de ontvanger routeert fouten naar spam of ongewenst. Gebruik dit wanneer rapporten tonen dat alle legitieme bronnen alignment hebben.

- 
**`p=reject`**: de ontvanger weigert fouten op het SMTP-moment. Gebruik dit wanneer quarantine gedurende een volledige verzendcyclus schoon is geweest.

`p=none` is monitoring, geen bescherming. Een domein dat twee jaar op `none` staat heeft een compliance-vink en geen bescherming tegen spoofing. Sla de verleiding over om het daar te laten omdat "niets brak".

`p=reject` is de bestemming voor elk domein dat alleen mail verzendt die je bestuurt. Domeinen met zware mailinglijstverkeer of erfenis-forwarders hebben meer zorg nodig, omdat forwarding vaak SPF breekt en DKIM kan breken als de tussenpersoon de body aanpast.

## Waarom de Gmail en Yahoo-regels dit urgent maakten

Sinds februari 2024 vereisen [Googles richtlijnen voor verzenders](https://support.google.com/mail/answer/81126?hl=nl) dat iedereen die meer dan 5.000 berichten per dag naar Gmail-rekeningen stuurt een DMARC-record publiceert, met SPF en DKIM op orde. Het beleid mag `none` zijn. Google vraagt bulk-verzenders ook om de door gebruikers gerapporteerde spamratio in Postmaster Tools onder de 0,30% te houden, en adviseert onder de 0,10% te blijven.

[Yahoos Sender Hub](https://senders.yahooinc.com/best-practices/) stelt dezelfde kerneisen: een gepubliceerd DMARC-beleid van tenminste `p=none`, met het From-domein op lijn met het SPF- of DKIM-domein. Ontspannen alignment is aanvaardbaar.

Let op wat wel en niet in die regels staat. De eis is een gepubliceerd record en slagende alignment, niet handhaving. Dat is een vloer. Het is geen eindpunt.

![Lowered customs barrier at a harbor container yard at dusk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/4a2947-inline3.webp)

## Aggregatierapporten zijn het product, het beleid is de schakelaar

Het `rua`-adres ontvangt dagelijks XML-rapporten van elke ontvanger die DMARC naleeft. Elk rapport somt bron-IP's, berichtenaantallen, SPF- en DKIM-resultaten en of alignment standhield. Zo vind je de vergeten verzender: de oude CRM-export, het factureringshulpmiddel dat een aannemer in 2022 heeft ingesteld, het formulier op een subdomein van niemand.

Ruw XML is onleesbaar op schaal. Stuur `rua` naar een mailbox waar een parser er in kan kijken, of naar een gehoste DMARC-rapportageservice, en bekijk de data gegroepeerd per bron. Wat je wilt zien, is elke legitieme bron met 100% alignment, en al het andere duidelijk onbekend.

Een praktische uitrol gaat in deze volgorde:

- 
Publiceer `p=none` met een `rua`-adres.

- 
Verzamel twee tot vier weken rapporten. Bouw de verzender-inventaris.

- 
Repareer elke legitieme onuitgelijnde bron met een aangepast DKIM-domein of return-path.

- 
Ga naar `p=quarantine`. Kijk uit voor supporttickets over ontbrekende mail.

- 
Ga naar `p=reject` wanneer quarantine geen legitieme fouten meer toont.

Zet elke stap afzonderlijk uit. Het beleid veranderen en een nieuwe verzendprovider toevoegen in dezelfde week maakt elke regressie onmogelijk om toe te schrijven.

## DMARCbis verandert de tags, niet je record

In 2026 publiceerde de IETF RFC 9989, RFC 9990 en RFC 9991, die RFC 7489 vervangen. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989) is de kern-DMARC-spec. Verzameling en foutrapportage zijn naar eigen documenten verhuisd.

De praktische veranderingen voor een record-eigenaar zijn klein:

- 
`pct`, `rf` en `ri` zijn verwijderd.

- 
`t` (testmodus) vervangt `pct` als alles-of-niets-schakelaar: `t=y` rapporteert zonder af te dwingen.

- 
`np` stelt een beleid in voor niet-bestaande subdomeinen, wat spoofing van adressen zoals `abc123.voorbeeld.nl` blokkeert.

- 
`psd` markeert domeinen met publieke achtervoegsels, en een DNS-boomwandeling vervangt de oude Public Suffix List opzoeken.

Bestaande `v=DMARC1`-records blijven geldig. Niets breekt als je vandaag niets verandert. Provider-ondersteuning voor de nieuwe tags rolt ongelijk uit, dus een nieuwe tag die niets lijkt te doen betekent meestal dat de ontvanger het nog niet heeft geïmplementeerd.

De `np`-tag is echt het moeite waard om vroeg aan te nemen. Als `np=reject` wordt ingesteld terwijl `p` nog `none` is, sluit je het valse-subdomein-misvormgebruik af zonder de rest van je mail aan handhaving vast te leggen.

## Subdomeinen en waarom de standaard erft

Een DMARC-record op het organisatiedomein is van toepassing op subdomeinen, tenzij je het overschrijft met `sp`. Die erfenis is nuttig en ook een val.

Als marketing mailt van `nieuws.voorbeeld.nl` via een aparte provider, erft het het ouderbeleid. Verplaats het ouder naar `p=reject` voordat die provider de DKIM van de nieuwsbrief heeft uitgelijnd en de brief gaat door de vloer. Publiceer een apart `_dmarc.nieuws.voorbeeld.nl`-record wanneer een subdomein zijn eigen verzenderfloot en zijn eigen uitrol-ritme heeft.

Een schonere architectuur scheidt reeksen per subdomein vanaf het begin. Transactionele mail op één, levenscyclusmail op een ander, menselijke mail op de root. Elk krijgt zijn eigen DKIM-sleutels, zijn eigen reputatie en zijn eigen DMARC-record.

## Lees de Authentication-Results-header voordat je gist

Wanneer een bericht faalt, noteert de ontvangende server waarom. In Gmail geeft "Origineel weergeven" de `Authentication-Results`-header bloot, en die vertelt meer dan elk dashboard.

`Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=bounce.provider-mail.nl;
  dkim=pass header.d=provider-mail.nl;
  dmarc=fail (p=NONE) header.from=voorbeeld.nl`Lees het van links naar rechts. SPF slaagde voor `bounce.provider-mail.nl`. DKIM slaagde voor `provider-mail.nl`. DMARC faalde omdat de From-header `voorbeeld.nl` zegt en geen van de geslaagde domeinen matchen eraan.

De notatie `(p=NONE)` toont het beleid dat de ontvanger zag. Op `none` werd dit bericht toch bezorgd. Op `reject` zou het zijn teruggestuurd met een 5.7.x-fout, en zou de verzender van een klant ervan horen.

Twee checks vangen de meeste van deze gevallen. Bevestig dat de `header.d`-waarde in het DKIM-resultaat jouw domein is. Bevestig daarna dat het `smtp.mailfrom`-domein jouw domein is of een subdomein ervan.

## SPF heeft een opzoeklimiet die DMARC blootlegt

SPF staat tien DNS-opzoekingen per evaluatie toe. Elk `include:` voor een provider geeft ervan uit, en geneste includes geven meer uit. Over de tien en SPF geeft een permanente fout terug, wat als een faal telt.

Teams met vijf of zes verzendtools raken dit zonder het op te merken, omdat SPF-fouten onzichtbaar waren voor DMARC-rapportage. Zodra `rua`-rapporten arriveren, is het patroon duidelijk: één bron faalt plotseling aan SPF over alle ontvangers op de dag waarop iemand een ander `include:` toevoegde.

Dit is nog een reden om DKIM-alignment als het primaire pad te gebruiken. DKIM overleeft de meeste forwarding, heeft geen opzoekbudget en is gekoppeld aan het bericht in plaats van aan het verbindende IP. Houd SPF geldig, maar bouw je DMARC-pass er niet alleen op.

## Wat DMARC niet doet

DMARC voorkomt spoofing van exact-domein. Het stopt lookalike-domeinen (`voorbo1d.nl`) niet, het beoordeelt inhoud niet en het reparatuur geen slechte afzender-reputatie. Een perfect uitgelijd domein dat naar aangeschafte lijsten stuurt, belandt toch in spam.

Het vervangt ook monitoring niet. Alignment kan in stilte breken: een DNS-verandering verwijdert een DKIM-selector, een provider roteert sleutels, een nieuw hulpmiddel begint zonder jouw weten te sturen. Rapporten zijn hoe je ervan hoort voordat jouw gebruikers het doen.

Behandel het DMARC-record zoals elk ander productiemonfigstuk. Het hoort in versiebeheer, veranderingen gaan door review en de `rua`-mailbox heeft een eigenaar nodig.

![Cream envelope being sealed with a red wax stamp](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f3aca9-inline2.webp)

## Voor je het record publiceert

Loop dit eenmaal door. Het kost minder dan een uur voor één domein.

- 
Inventariseer elk systeem dat als jouw domein mail verzendt: product, facturering, support, CRM, marketing, agendauitnodigingen.

- 
Bevestig dat elk met jouw domein DKIM ondertekent, niet met die van de leverancier.

- 
Stel een aangepast return-path in waar de provider het toestaat.

- 
Kies een `rua`-bestemming die iemand leest.

- 
Begin op `p=none` en zet op de agenda wanneer je van plan bent het te controleren.

- 
Controleer spamratio in Google Postmaster Tools wekelijks tijdens de uitrol.

## Waar je heen kunt

Als je je rapporten nooit hebt bekeken, publiceer vandaag `p=none` met een `rua`-adres en lees wat over twee weken binnenkomt. Het eerste rapport noemt bijna altijd minstens één verzender die niemand zich herinnerde. De volgende concrete stap is beslissen welke je behoudt.

## FAQ

### Is DMARC vereist?

Voor bulk-verzenders in feite wel. Google vereist een DMARC-record voor verzenders van meer dan 5.000 berichten per dag naar Gmail, en Yahoo vereist een geldig beleid van tenminste p=none. Handhaving is niet vereist, maar het record en de alignment wel.

### Wat betekent p=none in DMARC?

Het betekent alleen monitoren. Ontvangers bezorgen falende mail normaal en sturen je rapporten. Het voldoet aan het Gmail- en Yahoo-minimum, maar biedt geen bescherming tegen spoofing.

### Kan een e-mail SPF en DKIM doorstaan en DMARC alsnog mislopen?

Ja. DMARC vereist dat het domein dat door SPF of DKIM is geverifieerd aansluit op het From-header-domein. Mail verzonden via een provider die met zijn eigen domein ondertekent, haalt beide checks en faalt toch alignment.

### Hoe lang moet ik op p=none blijven?

Meestal twee tot vier weken rapporten, lang genoeg om elke legitieme verzender te zien, inclusief lage-volume-typen. Stap over als elke legitieme bron alignment toont.

### Beïnvloedt DMARC de bezorgbaarheid?

Indirect. Een gepubliceerd, uitgelijn record is een basisvereiste bij Gmail en Yahoo, en uitlijning mislopen kan mail naar spam sturen of weigering activeren onder een handhavingsbeleid. Het reparatuur geen slechte zender-reputatie of hoge klachtratio.

### Wat veranderde met DMARCbis en RFC 9989?

RFC 9989 vervangt RFC 7489. Het verwijdert pct, rf en ri, voegt t, np en psd toe, en vervangt Public Suffix List opzoeken door een DNS-boomwandeling. Bestaande v=DMARC1-records blijven geldig.