DMARC RFC 9989, 9990 en 9991 vervangen RFC 7489

Na jarenlang werk binnen de IETF DMARC-werkgroep is de langverwachte update van de DMARC-standaard gepubliceerd. Drie nieuwe documenten, RFC 9989, RFC 9990 en RFC 9991, vervangen nu officieel de oorspronkelijke RFC 7489 uit 2015. Hoewel het geen officiële term is, stonden de RFC's in de gemeenschap gezamenlijk bekend als DMARCbis en zijn ze nu gepubliceerd als de bijgewerkte DMARC-specificatie met hetzelfde versienummer.

De nieuwe specificaties werden in mei 2026 gepubliceerd, waardoor DMARC binnen het IETF Standards Track van de eerdere status ‘Informational’ naar ‘Proposed Standard’ is overgegaan. Dit is een belangrijke stap voorwaarts, aangezien DMARC hierdoor een stevigere en meer formele positie krijgt binnen de reeks internetstandaarden.

Wat er in elke RFC wordt behandeld

De DMARC-specificatie is opgesplitst in drie gerichte documenten in plaats van één groot bestand. RFC 9989 bevat het kernprotocol, inclusief beleidsevaluatie, afstemmingsregels en de verwerking van records. RFC 9990 definieert het rapportageformaat voor geaggregeerde gegevens (RUA). RFC 9991 behandelt foutmeldingen, ook wel forensische rapporten genoemd.

Uw bestaande DMARC-record werkt nog steeds

Een van de belangrijkste punten voor domeineigenaren is dat dit geen ingrijpende wijziging is. De protocol-ID blijft hetzelfde, dus records beginnen nog steeds met v=DMARC1. U hoeft uw configuratie niet van de ene op de andere dag aan te passen of al uw records opnieuw te publiceren.

Als je even wilt opfrissen hoe records zijn opgebouwd, kun je in onze handleiding over DMARC-tags een overzicht vinden van alle velden.

Belangrijkste technische wijzigingen

Er zijn een paar updates die in het oog springen, en van een paar daarvan is het de moeite waard om ze grondig te begrijpen voordat je je bestand aanraakt.

Lijst met openbare achtervoegsels vervangen door DNS Tree Walk

Ontvangers zijn niet langer afhankelijk van de extern bijgehouden Public Suffix List om het organisatiedomein te achterhalen. In plaats daarvan doorlopen ze de DNS-hiërarchie en zoeken ze op elk niveau naar _dmarc-records. In de praktijk begint een ontvanger bij het betreffende domein en voert hij achtereenvolgens zoekopdrachten uit op steeds hogere labels, tot maximaal acht zoekopdrachten, totdat hij een gepubliceerd DMARC-record vindt. Hierdoor wordt de afhankelijkheid van derden weggenomen en wordt de nauwkeurigheid bij complexe domeinstructuren verbeterd.

Er is een praktische implicatie die het vermelden waard is. Omdat de Tree Walk het organisatorische domein anders verwerkt dan de oude Public Suffix List-methode, kan een ontvanger die RFC 9989 hanteert in sommige gevallen tot een ander organisatorisch domein komen dan een ontvanger die nog steeds RFC 7489 gebruikt. Als u een complexe subdomeinhierarchie hanteert of gedelegeerde domeinen gebruikt, is de veiligste aanpak om een expliciet DMARC-record te publiceren op elk domein en subdomein van waaruit u daadwerkelijk e-mail verstuurt. Dat neemt elke onduidelijkheid weg over welk beleid van toepassing is, ongeacht welke versie een bepaalde ontvanger gebruikt.

Nieuwe tags: np, psd en t

RFC 9989 introduceert drie nieuwe tags. Hieronder wordt uitgelegd wat elke tag doet en wanneer je deze daadwerkelijk zou gebruiken.

np (beleid inzake niet-bestaande subdomeinen)

Met de sp-tag kun je al een beleid instellen voor subdomeinen, maar np gaat nog een stap verder door het beleid te scheiden voor subdomeinen die helemaal niet bestaan, wat betekent dat DNS een NXDOMAIN-foutmelding retourneert. Dit dicht een reëel beveiligingslek met betrekking tot subdomein-spoofing, aangezien aanvallers vaak e-mail vervalsen vanuit subdomeinen die nooit zijn geregistreerd. Een record van bijvoorbeeld v=DMARC1; p=none; np=reject; past geen beleid toe op het hoofddomein en de legitieme subdomeinen daarvan, maar weigert wel e-mail van niet-bestaande subdomeinen. Als uw domein al is ingesteld op p=reject of sp=reject, wordt het strikte beleid automatisch overgenomen, dus np=reject voegt niets toe en er is geen wijziging nodig. Als u een minder streng beleid hanteert maar gerichte bescherming tegen deze specifieke aanval wilt, is het zeker de moeite waard om np=reject toe te voegen.

t (testmodus)

Dit is de tag die het vaakst verkeerd wordt geïnterpreteerd. Als je t=y instelt, wordt je beleid niet uitgeschakeld. In plaats daarvan wordt van ontvangers gevraagd het op één na minst strenge beleid toe te passen ten opzichte van het beleid dat je hebt gepubliceerd: een ‘reject’-beleid wordt behandeld als ‘quarantine’, een ‘quarantine’-beleid als ‘none’, en ‘none’ blijft ongewijzigd. Dit is veel nauwkeuriger dan het oude pct-gedrag dat hiermee in feite wordt vervangen. Een belangrijke kanttekening: nog niet elke ontvanger ondersteunt RFC 9989, dus sommige zullen t=y simpelweg negeren. Tijdens de overgangsperiode is het veiliger om zowel pct als t samen te gebruiken, zodat zowel oudere als nieuwere ontvangers je bedoeling begrijpen. Een gefaseerd record zou er als volgt uit kunnen zien: v=DMARC1; p=reject; pct=50; t=y;. Je kunt meer lezen over deze verandering in onze eerdere notitie over waarom t pct vervangt.

psd (domein met openbaar achtervoegsel)

Deze tag helpt ontvangers bij het bepalen van het organisatiedomein tijdens de DNS-boomdoorloop. De meeste gewone domeineigenaren kunnen deze tag gewoon weglaten. Hij is alleen relevant in twee situaties: wanneer een organisatie bewust een grens voor het organisatiedomein wil aangeven op een subdomein (stel daar psd=n in), of wanneer een beheerder van een Public Suffix-domein zoals .bank of .gov (stel psd=y in). Houd er rekening mee dat ontvangers die nog steeds RFC 7489 gebruiken deze tag volledig zullen negeren, dus het is geen vervanging voor een degelijk recordontwerp.

Drie tags verwijderd: pct, rf en ri

RFC 9989 schrapt drie tags. Geen van deze schrappingen zal bestaande records onbruikbaar maken, maar het is de moeite waard om te begrijpen wat elke tag deed en hoe hiermee om te gaan. Zie het betreffende gedeelte hieronder.

Duidelijkere richtlijnen voor mailinglijsten en het doorsturen van e-mails

Indirecte e-mailstromen verstoren nog steeds de afstemming tussen SPF en DKIM, en de nieuwe specificatie erkent dit openlijk. Er wordt afgeraden om een agressief ‘p=reject’-beleid te hanteren wanneer er veel verkeer via mailinglijsten plaatsvindt, wat aansluit bij hoe e-mail zich in de praktijk gedraagt.

Een beter omschreven conformiteit

In de nieuwe tekst wordt duidelijk uiteengezet wat „volledige DMARC-deelname” inhoudt voor zowel afzenders als ontvangers, wat een einde zou moeten maken aan de fragmentarische implementaties die al jaren een probleem vormen.

Beperking op de grootte van rapport-URI’s opgeheven

Een kleine wijziging die gemakkelijk over het hoofd wordt gezien: in RFC 9989 is de mogelijkheid geschrapt om een maximale rapportgrootte op te geven in de rapportage-URI. Records waarin een groottesuffix werd gebruikt, zoals rua=mailto:[email protected]!10m, hebben geen betekenis meer, en ontvangers moeten nu elke groottelimiet die aan een rua- of ruf-adres is gekoppeld, negeren. Als uw rapportage-URI’s deze syntaxis bevatten, kunt u het gedeelte met de groottelimiet gerust verwijderen.

Uitleg over de verwijderde tags

Als je huidige bestand gebruikmaakt van pct, rf of ri, lees hier precies wat elk van deze afkortingen betekende en wat je nu moet doen.

pct (percentage)

Deze tag is ontworpen om je in staat te stellen een beleid geleidelijk in te voeren door het toe te passen op een gekozen percentage van de e-mail. In de praktijk werd deze tag niet consistent geïmplementeerd bij de verschillende ontvangers, wat tot onvoorspelbare resultaten leidde, en is hij vervangen door de overzichtelijkere t-tag. Als je nog steeds gebruikmaakt van pct, vertrouw er dan voortaan niet meer uitsluitend op. Tijdens de overgang is het verstandig om pct en t=y samen te gebruiken, zodat zowel oudere ontvangers als RFC 9989-ontvangers begrijpen dat u stapsgewijs naar volledige handhaving toewerkt.

rf (rapportformaat)

Deze tag bepaalde de indeling voor foutmeldingen, maar de enige geldige waarde was altijd ‘afrf’, waardoor de tag in de praktijk overbodig was. Deze tag kan zonder problemen worden verwijderd uit elk record waarin hij voorkomt.

ri (rapportage-interval)

Deze tag bepaalde het gewenste interval tussen geaggregeerde rapporten, uitgedrukt in seconden. De meeste ontvangers negeerden deze tag en gebruikten standaard een dagelijks rapport, en RFC 9989 legt dit nu vast door te vereisen dat ontvangers ten minste één keer per dag geaggregeerde rapporten versturen. Het kan geen kwaad om de tag te laten staan, maar hij wordt steeds minder relevant en men moet er niet op vertrouwen.

Hoe werk je het DMARC-record bij volgens RFC 9989?

De publicatie van RFC 9989 heeft geen invloed op wat je al hebt. Je record staat nog steeds op dezelfde plek – een DNS TXT-record op _dmarc.jouwdomein.com – en de versietag is nog steeds v=DMARC1.

Waarom zou je dan überhaupt een update uitvoeren? Omdat RFC 9989 weergeeft hoe e-mail in de praktijk werkt na tien jaar daadwerkelijke toepassing, en het de moeite loont om een aantal van de wijzigingen nu al in je systeem op te nemen in plaats van er later pas achter te komen.

Dit is wat domeineigenaren moeten doen

Domeineigenaren kunnen de onderstaande checklist doorlopen om hun gegevens dynamisch bij te werken:

Verwijder de tags rf en ri. Beide zijn verouderd en kunnen veilig worden verwijderd.
Replace pct with t: use t=y for testing (in place of any pct<100), or drop the tag for full enforcement (t=n is the default)
Overweeg om `np=reject` toe te voegen als je spoofing vanuit niet-bestaande subdomeinen wilt blokkeren zonder je hoofdbeleid te wijzigen.
Verwijder het achtervoegsel voor de maximale grootte van de rapportage-URI als je rua- of ruf-records zo’n achtervoegsel bevatten.
Laat `psd` weg, tenzij je bewust een grens voor een organisatiedomein wilt aangeven of een domein met een openbaar achtervoegsel beheert.
Publiceer expliciete DMARC-records voor elk domein en subdomein waarvan u e-mail verstuurt, om onduidelijkheden bij de DNS Tree Walk tussen ontvangers die RFC 9989 en RFC 7489 hanteren te voorkomen.

Voor een uitgebreider overzicht van de wijzigingen en hoe u uw gegevens hierop kunt voorbereiden, raadpleegt u onze volledige handleiding over DMARCbis.

Een gemoderniseerd record volgens RFC 9989 ziet er als volgt uit:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s

Let op wat er ontbreekt: geen pct. Om dit veilig in te voeren, voeg je t=y toe, laat je de geaggregeerde rapporten zich opstapelen en verwijder je het vervolgens wanneer je klaar bent voor volledige handhaving.

Je zult ook merken dat twee geldige RFC 9989-tags in dit record ontbreken – t en psd – en dat is bewust gedaan, omdat beide tags eerder situationeel dan standaard zijn.

De t-tag staat voor de tijdelijke testmodus: je voegt deze alleen toe tijdens de aanloop naar de daadwerkelijke handhaving, aangezien deze de ontvangers opdraagt het beleid toe te passen dat één niveau lager ligt dan het door jou gepubliceerde beleid. De psd-tag is daarentegen een vlag waarmee een domein wordt aangemerkt als een openbaar suffix. Beheerders van openbare suffixen moeten psd=y instellen, maar voor een gewone domeineigenaar is de standaardinstelling (u) precies goed, en kun je de tag gewoon weglaten.

Zorg ervoor dat uw DMARC-platform klaar is

Nog niet alle tools op de markt voldoen aan de nieuwe normen, en die achterstand is van belang. Als uw platform de nieuwe tags niet kan lezen of rapporten in het bijgewerkte formaat niet kan verwerken, verliest u juist op het moment dat het protocol zich verder ontwikkelt het overzicht.

PowerDMARC voldoet al aan de nieuwe specificaties en ondersteunt:

Genereren van records die compatibel zijn met RFC 9989, 9990 en 9991
Het parseren van de nieuwe tags np, psd en t
RFC 9990: verwerking en rapportage van geaggregeerde rapporten
Verwerking van domeinen op basis van DNS-boomnavigatie
Aangepast verwerkingsgedrag dat aansluit bij de nieuwe conformiteitsregels

Als je wilt weten hoe je huidige instellingen het doen ten opzichte van de nieuwe standaard, voer ze dan in onze gratis DMARC-checker in en bekijk wat er moet worden aangepast.

Laatste woorden

De bijgewerkte RFC’s vormen geen nieuw protocol. Het gaat om hetzelfde DMARC, maar dan duidelijker geformuleerd en opgewaardeerd tot de status van standaard. Na meer dan tien jaar praktijkervaring weerspiegelt de specificatie nu hoe e-mail in de praktijk werkt, inclusief de minder overzichtelijke aspecten zoals doorsturen en mailinglijsten.

Voor iedereen die verantwoordelijk is voor domeinbeveiliging is de publicatie van RFC’s 9989, 9990 en 9991 een goede aanleiding om uw records te controleren en ervoor te zorgen dat uw tools klaar zijn voor de nieuwe tags en de DNS Tree Walk-methode.

Over
Laatste berichten

Ahona Rudra

Expert domein- en e-mailbeveiliging bij PowerDMARC

Ahona is marketingmanager bij PowerDMARC en heeft meer dan vijf jaar ervaring met het schrijven over cybersecurity, gespecialiseerd in domein- en e-mailbeveiliging. Ahona heeft een masterdiploma in journalistiek en communicatie, en heeft sinds 2019 haar carrière in de beveiligingssector verder uitgebouwd.

Laatste berichten van Ahona Rudra (Bekijk alle berichten)