Hoe je het DMARC-beleid van een bedrijf in tien seconden leest (en wat het je niet vertelt)

Eén DNS-query vertelt je wat een bedrijf de mailservers van de wereld heeft gevraagd te doen met vervalste mail in haar naam. Het record is openbaar, en het commando is één regel: dig +short TXT _dmarc.example.com. Wat terugkomt is een korte tekenreeks met instellingen, en erin zit één instructie — p=none, p=quarantine of p=reject — die de voorkeur van de domeinbeheerder aangeeft wanneer een bericht met dat domein authenticatie niet doorstaat.

De huidige specificatie, RFC 9989, gepubliceerd in mei 2026 als een IETF Standards Track-document, verving de oudere RFC 7489. De drie waarden worden bijna tersluiks gedefinieerd:

• p=none — "De domeineigenaar drukt geen voorkeur uit."
• p=quarantine — "De domeineigenaar beschouwt dergelijke mail als verdacht. Het is mogelijk dat de mail geldig is, hoewel het authenticatiedefault een significant bezwaar oplevert."
• p=reject — "De domeineigenaar beschouwt alle dergelijke defects als duidelijk bewijs dat het gebruik van de domeinnaam niet geldig is."

Lees die woorden opnieuw, want ze zijn zwakker dan de meeste uitleg over DMARC togeeft. Een beleid is een voorkeur, gepubliceerd door de afzender voor ontvangers om in overweging te nemen. Het is geen instructie die een ontvanger verplicht moet uitvoeren. RFC 9989 zegt dit in één zin: "De uiteindelijke verwerking van elk bericht is altijd een zaak van lokaal beleid en wordt aan het oordeel van de Mailontvanger overgelaten." Dezelfde sectie voegt beide helften van het gevolg toe — ontvangers "MOGEN een bericht weigeren of in quarantaine plaatsen, zelfs als het de DMARC-validatiecontrole doorstaat," en ze "MOGEN GEEN berichten weigeren louter vanwege een gepubliceerd beleid van 'reject'," precies zodat legitieme mail die op manieren is verzonden die DMARC niet kan beschrijven, en mailinglijsten, niet worden vernietigd in het proces.

Wat geeft p=none dus eigenlijk toe? Minder dan het meestal van wordt beschuldigd. In de termen van de spec is het Monitoring Mode: de domeineigenaar verzamelt geaggregeerde rapporten en "drukt geen verwerkingsvoorkeur uit voor berichten die DMARC-validatie niet doorstaan," terwijl een ontvanger die DMARC inzet het gebruik van het domein nog steeds "kan" valideren. Wat het niet doet is iets aan de ontvangende kant uitschakelen. De spamfiltering, reputatiescore, URL-controles en attachmentanalyse van je provider zijn afzonderlijke mechanismen die ongeacht wat de afzender heeft gepubliceerd draaien. Een vervalst bericht dat bij een p=none-domein aankomt, wordt niet door het record naar je inbox gepromoveerd; het wordt eenvoudigweg zonder uitgesproken voorkeur aan de ontvanger overhandigd, en de ontvanger beslist.

De andere helft van het misverstand loopt de andere kant uit. DMARC leest het gevaarlijke deel van een phishing-email niet. De eigen specificatie geeft aan wat opzettelijk buiten bereik valt, en "contentanalyse" staat op die lijst, in die woorden. Het stelt ook dat DMARC "het gebruik van visueel vergelijkbare domeinnamen of misbruik van de RFC5322.From voor mensen leesbare weergavenaam niet behandelt" — de twee trucs die het meeste merk-imitatieverkeer dragen. En over de waarde van een pass: "een DMARC-pass op zich garandeert niet dat bezorging in de inbox van de ontvanger veilig of wenselijk zou zijn." Een correct geverifieerd bericht van een wegwerp-domein doorstaat DMARC schoon. DMARC antwoordt wie gemachtigd was om het domein in de From:-header te gebruiken. Niets meer.

Dit is waar de bulkafzenderregels van 2024 routinematig verkeerd worden gerapporteerd, inclusief in de eerste versie van dit artikel. De richtlijnen van Google voor afzenders van 5.000 of meer berichten per dag naar Gmail-accounts vereisen dat afzenders "DMARC-e-mailauthenticatie voor uw verzenddomein instellen," en zeggen dan, in dezelfde adem: "Uw DMARC-handhavingsbeleid kan op none worden ingesteld." De eigen Sender Hub van Yahoo, die apart moet worden gelezen in plaats van ervan uit te gaan dat deze Google kopieert, stelt de vereiste als "Publiceer een geldig DMARC-beleid met ten minste p=none - DMARC moet doorstaan," en publiceert helemaal geen numerieke volumedrempel. Beide reeksen vereisten traden in februari 2024 in werking. Geen van beide dwingt iemand weg van p=none. Wat beide eigenlijk afdwingen is authenticatie die aansluit: Google vereist dat "het domein in de From:-header van de afzender aansluit bij het SPF-domein of het DKIM-domein," en Yahoo zegt dat ontspannen uitlijning aanvaardbaar is. Uitlijning, niet ernst, is de drempel.

Dit laat de werkelijke reden achter waarom domeinen op monitoring blijven hangen, en die is operationeel in plaats van laffe. Overgaan naar quarantine of reject betekent eerst elke service vinden die in jouw naam mail verzendt — lonen, ticketing, marketing, een helpdesk waarvan niemand wist dat deze bestond — en elk ervan verifiëren zodat deze aansluit. De standaard zelf erkent de gevaren die dit langzaam maken: aanbieders van derden worden door DMARC noch ingeleid noch uitgesloten, doorsturen en mailinglijsten kunnen uitlijning breken zonder schuld van de afzender, en de spec verwijst ontvangers naar RFC 7960 voor exact die foutmodi. Een organisatie die p=none publiceert en haar rapporten leest, doet het werk in de volgorde die de spec beschrijft. Eentje die p=none publiceert en de rapporten negeert, doet dit niet. Van buiten af kan het record alleen niet vertellen welke van de twee je bekijkt.

Je hebt geen terminal nodig om ernaar te kijken. Gratis opzoekhulpmiddelen — dmarcian's domain checker, MXToolbox's DMARC check — halen het record op en drukken het beleid voor je af. Doe dit voor je bank, je salarisprovider, de luchtvaartmaatschappij waarmee je vliegt. Lees het antwoord gewoon voor wat het is: een intentieverkklaring van de domeinbeheerder, één input onder veel anderen in een beslissing die je mailprovider op eigen initiatief neemt, over één specifiek soort vervalsing. Dat is een werkelijk nuttig iets om in tien seconden te kunnen lezen. Het is geen oordeel over of het volgende bericht dat zegt afkomstig te zijn van dat merk veilig is.

Correctie, 20 oktober 2026. Een eerdere versie van dit artikel beschreef p=none als het afleveren van vervalsingen in de inbox en p=reject als de enige instelling die een vervalst bericht blokkeert, zei dat de bulkafzenderregels van Google en Yahoo van 2024 afzenders van p=none wegduwden, en citeerde een cijfer van ongeveer één op de drie domeinen bij handhaving. De beleidsbeschrijvingen zijn gecorrigeerd aan de hand van RFC 9989; zowel Google als Yahoo accepteren in feite p=none, hierboven aangehaald uit hun eigen documentatie; en het handhavingscijfer is verwijderd omdat het onderliggende rapport zijn steekproef of noemer niet publiceert. Het artikel geeft nu ook aan wat DMARC niet onderzoekt.