In mei 2026 publiceerde de IETF RFC 9989 als de nieuwe Proposed Standard voor DMARC. Deze vervangt RFC 7489 en RFC 9091 en formaliseert belangrijke wijzigingen rond policy discovery, testing, subdomeinen en rapportage. Dit betekent niet dat elke organisatie direct haar DMARC-record moet herschrijven. Het betekent wel dat securityteams, DMARC-platforms en technische documentatie RFC 7489 niet langer als de actuele specificatie moeten behandelen.
Waarom RFC 9989 belangrijk is
RFC 7489 introduceerde DMARC in 2015 als Informational RFC. RFC 9989 brengt het basisprotocol naar de IETF Standards Track als Proposed Standard en verwerkt operationele ervaring uit meer dan tien jaar praktijkgebruik.
De nieuwe specificatie vervangt ook RFC 9091 en wijzigt hoe organisatiedomeinen en policies via de DNS-tree worden gevonden. Daarmee ontstaat een duidelijkere actuele basis voor implementaties, domeineigenaren en assessmenttools.
De pct-tag is verwijderd
RFC 7489 stond een pct-waarde tussen 0 en 100 toe om handhaving slechts op een percentage van falende berichten toe te passen. In de praktijk verwerkten mailboxproviders tussenliggende waarden niet consistent.
RFC 9989 verwijdert pct daarom. Bestaande records met pct kunnen nog door oudere implementaties worden geïnterpreteerd, maar pct maakt geen deel meer uit van de actuele DMARC-basisspecificatie. Nieuwe uitrolplannen moeten niet afhankelijk zijn van percentagegedrag bij ontvangers.
De nieuwe t-tag signaleert testmodus
RFC 9989 introduceert t als testsignaal voor quarantine- of rejectpolicies. De waarde t=y vraagt de ontvanger om tijdens de testfase afhandeling één niveau onder de gepubliceerde policy toe te passen.
De t-tag vervangt een deel van de voormalige pct-functionaliteit, maar is geen percentagecontrol. Een gecontroleerde uitrol blijft afhankelijk van verzenderinventarisatie, alignmentherstel, monitoring en bewuste policybesluiten.
Ondersteuning zal niet overal tegelijk beschikbaar zijn. Een oudere receiver die t niet herkent, hoort de tag te negeren en kan daardoor de gepubliceerde p-policy toepassen zonder de gevraagde verlaging van één niveau. Organisaties moeten ondersteuning bij receivers en platforms daarom valideren voordat zij t=y als productiecontrole voor een uitrol gebruiken.
Policies voor bestaande en niet-bestaande subdomeinen
De specificatie voegt np toe aan het actuele basisprotocol voor beleid op niet-bestaande subdomeinen. De bestaande sp-tag blijft beleid beschrijven voor bestaande subdomeinen wanneer dit afwijkt van het organisatiedomeinbeleid.
Als np ontbreekt, erven niet-bestaande subdomeinen de sp-policy wanneer die aanwezig is, en anders de p-policy. Daardoor is np vooral nuttig wanneer een organisatie bewust een strenger beleid wil voor namen die niet bestaan. Met bijvoorbeeld p=quarantine; sp=quarantine; np=reject blijven bestaande domeinen op quarantine, terwijl voor spoofing via niet-bestaande subdomeinen reject wordt gevraagd.
Door het uitbreidbare DMARC-recordformaat kan deze tag veilig worden toegevoegd: oudere receivers die np niet ondersteunen, negeren de tag en blijven het policygedrag toepassen dat zij via sp of p begrijpen.
- sp: beleid voor bestaande subdomeinen.
- np: beleid voor niet-bestaande subdomeinen, met fallback naar sp en daarna p als de tag ontbreekt.
Policy discovery gebruikt nu een DNS tree walk
RFC 9989 vervangt de Public Suffix List-methode uit RFC 7489 door een begrensde DNS tree walk om de toepasselijke policy en het organisatiedomein te vinden. Hetzelfde mechanisme neemt PSD policy discovery mee en definieert de eerdere experimentele aanpak uit RFC 9091 opnieuw.
De psd-tag helpt de tree walk om domeingrenzen vast te stellen. De waarde psd=y identificeert een Public Suffix Domain, psd=n markeert een domein dat geen public suffix is expliciet als organisatorische grens en psd=u is de standaardwaarde voor een onbekende status. De meeste gewone organisatiedomeinen hoeven psd niet te publiceren, al kan psd=n relevant zijn in complexe of gedecentraliseerde DNS-structuren.
- psd=y: het record is door een Public Suffix Operator gepubliceerd voor een Public Suffix Domain.
- psd=n: het domein vormt expliciet de organisatorische grens voor zichzelf en zijn subdomeinen.
- psd=u: de standaardwaarde; de tree walk bepaalt de toepasselijke organisatorische grens.
Ook de verwerking van records is gewijzigd
RFC 9989 classificeert p als aanbevolen in plaats van onvoorwaardelijk verplicht. Implementaties mogen een gepubliceerd record zonder geldige p-waarde daarom niet automatisch gelijkstellen aan het ontbreken van DMARC. De regels voor policy discovery bepalen of de verwerking doorgaat alsof p=none geldt of dat geen DMARC-verwerking plaatsvindt, waarbij onder meer de aanwezigheid van een syntactisch geldige rua-bestemming relevant is.
Het voormalige groottesuffix op reporting-URI’s, zoals een uitroepteken gevolgd door een maximale rapportgrootte, is nu verouderd. Report generators horen dit suffix te negeren wanneer het nog in een bestaand record voorkomt.
Rapportage heeft nu eigen specificaties
Het DMARC-basisprotocol staat in RFC 9989, terwijl rapportage in twee afzonderlijke documenten is vastgelegd. RFC 9990 specificeert aggregaatrapportage via rua. RFC 9991 specificeert berichtspecifieke failurerapportage via ruf.
De voormalige rf- en ri-tags zijn uit de basisspecificatie verwijderd. Failurerapporten blijven bovendien afhankelijk van ondersteuning door ontvangers, privacyafwegingen en mogelijk aanvullende afspraken.
Wat organisaties nu moeten beoordelen
- Controleer of gepubliceerde DMARC-records nog pct, rf of ri bevatten.
- Controleer of DMARC-tools en interne documentatie RFC 9989 ondersteunen in plaats van uitsluitend RFC 7489.
- Beoordeel hoe policies voor subdomeinen en niet-bestaande domeinen worden verwerkt.
- Controleer of aggregaat- en failurerapportage aansluiten op RFC 9990 en RFC 9991.
- Wijzig handhavingsbeleid niet uitsluitend omdat de specificatie is veranderd; valideer eerst legitieme verzenders en alignment.
Een praktische overgangsaanpak
Begin met een inventarisatie van records, platforms en documentatie. Bepaal welke verouderde tags aanwezig zijn en of operationele processen daar nog van afhankelijk zijn. Test vervolgens hoe ontvangst-, reporting- en monitoringproviders de actuele specificatie toepassen.
RFC 9989 maakt ook expliciet dat p=reject niet automatisch voor ieder domein de juiste eindstatus is. Domeinen voor algemeen gebruikersmailverkeer, vooral wanneer gebruikers deelnemen aan mailinglists, moeten indirecte mailstromen zorgvuldig beoordelen voordat zij reject publiceren. Waar reject passend is, blijft een gefaseerde overgang via monitoring en quarantine essentieel.
Behandel de wijziging als governance- en validatievraagstuk, niet als gehaaste DNS-wijziging. Het doel blijft hetzelfde: houd legitieme mail aligned, maak ongeautoriseerd exact-domain gebruik zichtbaar en ga pas richting handhaving wanneer het verzenderlandschap duidelijk is.
Bronnen en vervolgstappen
Sluit uw DMARC-inrichting nog aan op de actuele standaard?
Sender Integrity helpt uw records, verzenderlandschap, alignment en veilige route naar handhaving te beoordelen aan de hand van de actuele DMARC-specificatie.
Start met Sender Integrity Scan