Wat is DMARC? Uitlijning, Beleidslijnen en RFC 9989

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.

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 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 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.

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:

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

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

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

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

5. 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 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.

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.