DMARC instellen: stap voor stap van p=none naar reject

DMARC instellen lijkt een klus van vijf minuten: één TXT-record in je DNS en klaar. Het gaat meestal mis bij de stap daarna. Wie meteen p=reject zet, merkt pas aan de reacties dat de nieuwsbrief of het factuursysteem niet meer aankomt. Wie op p=none blijft staan, heeft een record dat geen enkele vervalste mail tegenhoudt.

Hieronder loop ik het hele traject door zoals de nieuwe standaard het beschrijft: RFC 9989 van mei 2026, met RFC 9990 voor de rapporten. Wat er in het record staat, hoe een ontvanger het vindt, wat de rapporten laten zien en wanneer je strenger kunt worden. Onderweg kijk ik naar de echte DMARC-records van 22 bekende domeinen. Hoe SPF, DKIM en DMARC samenwerken staat in De reis van een e-mail, de klikroute voor Microsoft 365 in DKIM en DMARC instellen in Microsoft 365.

Eerst: je eigen mail moet al slagen

DMARC controleert zelf niets nieuws. Het kijkt of SPF of DKIM slaagt voor het domein dat in de zichtbare From: staat. Dat heet alignment. Standaard is die relaxed: hetzelfde organisatiedomein is genoeg, dus een DKIM-handtekening van mail.example.nl telt voor info@example.nl.

RFC 9989 raadt aan om allebei te gebruiken. Wil je later naar p=reject, dan is DKIM verplicht: bij doorsturen komt de mail van het IP-adres van de doorstuurder en faalt SPF, terwijl een DKIM-handtekening dat meestal overleeft. Controleer dus voor elke dienst die namens je domein mailt (een nieuwsbriefdienst, je webshop) of die met jouw domein ondertekent en niet met dat van de leverancier.

DMARC instellen: het record

Het beleid staat in een TXT-record op _dmarc. plus je domein. Een goed begin:

_dmarc.example.nl.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.nl"

v=DMARC1 moet als eerste tag staan. Staat hij er niet, of niet vooraan, dan negeert de ontvanger het hele record. Ontbreekt p, dan behandelt de ontvanger het record als p=none zolang er een geldige rua in staat; anders past hij DMARC helemaal niet toe. En zonder rua mag een ontvanger je geen rapporten sturen. Een record met alleen v=DMARC1; p=none doet dus vrijwel niets.

Tag	Betekenis	Standaard
p	beleid: none, quarantine of reject	none
sp	beleid voor bestaande subdomeinen	gelijk aan p
np	beleid voor niet-bestaande subdomeinen	sp, anders p
rua	adres(sen) voor overzichtsrapporten	geen
ruf	adres(sen) voor rapporten per mislukte mail	geen
adkim, aspf	alignment r (relaxed) of s (strict)	r
t	testmodus y of n	n

Publiceer er precies één. Vindt de ontvanger twee DMARC-records op dezelfde naam, dan worden ze allebei weggegooid.

Hoe een ontvanger je record vindt

De ontvanger vraagt eerst _dmarc op voor het exacte domein uit From:. Staat daar niets, dan volgt een tree walk: hij haalt telkens het meest linkse label weg en vraagt opnieuw, tot hij een record vindt. Dat vervangt de Public Suffix List waarmee de oude RFC 7489 het organisatiedomein bepaalde. Heeft het domein meer dan acht labels, dan worden de tussenliggende stappen overgeslagen.

Vanaf een Nederlandse verbinding, op 20 oktober 2026: _dmarc.www.google.com geeft NXDOMAIN, één niveau hoger staat v=DMARC1; p=reject. Voor een subdomein telt dan sp, of np als het subdomein niet bestaat. Gmail laat het verschil zien: p=none; sp=quarantine. Het hoofddomein staat op monitoren, subdomeinen op quarantaine.

Bij de Belastingdienst gebeurt iets aardigs. Een vraag naar _dmarc.mail.belastingdienst.nl levert v=spf1 redirect=_spf.belastingdienst.nl op, omdat er een wildcard-TXT op het domein staat. Dat antwoord begint niet met v=DMARC1, dus de ontvanger negeert het en loopt door naar belastingdienst.nl, waar p=reject en sp=reject staan.

Zes van de 22 domeinen die ik bekeek, zetten geen TXT op _dmarc maar een CNAME naar een centraal beheerd record. _dmarc.rijksoverheid.nl wijst naar _dmarc.reject.ssonet.nl. Voor DMARC maakt dat niet uit: de resolver volgt de CNAME en de ontvanger ziet gewoon de TXT.

Wat de rapporten je vertellen

Met rua vraag je om overzichtsrapporten. Volgens RFC 9990 zijn dat XML-bestanden, bij voorkeur met gzip ingepakt, die meestal één UTC-dag beslaan. De bestandsnaam volgt een vast patroon, zoals mail.receiver.example!example.com!1013662812!1013749130.xml.gz: ontvanger, jouw domein, begin en eind in Unix-seconden. Het hart van zo'n rapport is per verzendend IP-adres een blok als dit (ingekort, uit het voorbeeld in RFC 9990):

<row>
  <source_ip>192.0.2.123</source_ip>
  <count>123</count>
  <policy_evaluated>
    <disposition>pass</disposition>
    <dkim>pass</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>

Hier kwamen 123 berichten van één adres. SPF faalde, DKIM slaagde aligned, dus DMARC slaagde. Zo lees je de rapporten: zie je een IP-adres van een van je eigen diensten waarbij DMARC faalt, dan repareer je dat voordat je strenger wordt. De RFC raadt aan de rapporten door software te laten verwerken in plaats van ze zelf te lezen.

Laat je de rapporten naar een ander domein sturen, bijvoorbeeld een DMARC-dienst, dan moet dat domein zelf toestemming geven. De ontvanger vraagt <jouwdomein>._report._dmarc.<rapportdomein> op en verwacht een TXT met v=DMARC1. Zonder dat record negeert hij het adres. Bij 17 van de 22 domeinen gaan de rapporten naar een ander domein. De twee diensten die ik testte gebruiken een wildcard: ook bestaatniet-xyz.nl._report._dmarc.vali.email geeft gewoon "v=DMARC1;" terug.

Van none naar quarantine naar reject

RFC 9989 is streng over de volgorde. Begin met p=none en een werkende rua. Legitieme stromen die nog niet slagen, moeten gerepareerd zijn voordat je naar quarantine of reject gaat. De RFC waarschuwt dat het bij onregelmatig verzonden mail maanden kan duren voordat je zeker weet dat alles klopt. Voor domeinen met gewone gebruikers die op mailinglijsten posten is het advies: minstens een maand p=none, dan even lang p=quarantine, en daarna de uitkomsten vergelijken.

In oudere handleidingen zie je de overgang met pct=10, pct=25 en verder. Die tag is in RFC 9989 historisch. Volgens de RFC werden waarden anders dan 0 en 100 in de praktijk meestal niet nauwkeurig toegepast, en verschilde dat ook nog per ontvanger. Wat overbleef is t=y: de ontvanger past dan één niveau lager toe, dus reject met t=y wordt behandeld als quarantine, en quarantine als none. De rapporten lopen gewoon door. Ook ri (rapportinterval) en rf zijn vervallen. Acht van de 22 records bevatten nog pct, allemaal pct=100, wat altijd al de standaard was.

Ook p=reject blijft een verzoek. De RFC zegt dat een ontvanger een mail nooit alleen op basis van p=reject mag weigeren; zonder verdere analyse moet hij hem als quarantine behandelen.

De stand bij de 22 domeinen:

Beleid (p)	Aantal	Voorbeelden
reject	15	belastingdienst.nl, ing.nl, google.com, microsoft.com, kpn.com
quarantine	4	bol.com, nos.nl, digid.nl, politie.nl
none	3	gmail.com, outlook.com, tweakers.net

Zelf proberen

Je eigen record en dat van anderen:

$ dig +short TXT _dmarc.gmail.com
"v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"

$ dig +short TXT _dmarc.rijksoverheid.nl
_dmarc.reject.ssonet.nl.
"v=DMARC1; p=reject; adkim=r; aspf=r; pct=100; fo=1; rf=afrf; ri=86400; ..."

De tree walk naspelen: eerst het subdomein, dan het hoofddomein.

$ dig TXT _dmarc.www.google.com | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: ...
$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

En de toestemming voor externe rapporten:

$ dig +short TXT rabobank.nl._report._dmarc.ag.eu.dmarcadvisor.com
"v=DMARC1;"

Werkt alles, dan zie je in de headers van een testmail aan een adres bij een andere provider dmarc=pass staan in Authentication-Results.

Tot slot

Wat me verraste: de twee grote consumentenmaildiensten in mijn lijstje, Gmail en Outlook.com, staan op hun eigen hoofddomein op p=none, terwijl alle drie de banken reject hebben. Na het lezen van de RFC snap ik het beter. Wie gebruikers heeft die op mailinglijsten posten, kan met reject vooral zijn eigen mensen schade doen. Het record maak je in vijf minuten, maar of je naar reject kunt hangt af van wat er in een maand rapporten staat.