English Nederlands Español Italiano 日本語 Français
Log in

DMARC-richtlijnen

DMARC (Domain-based Message Authentication, Reporting & Conformance) is de beleidslaag die bovenop SPF en DKIM zit. Het vertelt ontvangende mailservers wat ze moeten doen als een bericht de authenticatie niet doorstaat, en vraagt hen om daarover te rapporteren.

Zie het als een beleid dat aan de portier wordt meegegeven

DMARC is als een beleid dat aan de portier van een evenement wordt meegegeven: “controleer identiteit via SPF of DKIM; klopt het niet, doe dan dit — toch doorlaten, naar een aparte ruimte sturen, of weigeren — en stuur me hoe dan ook een rapport.” SPF en DKIM doen de controle; DMARC bepaalt wat er daarna gebeurt, en vraagt om de paperassen.

Waarom dit belangrijk is

Vóór DMARC was er geen standaardmanier waarop een domeineigenaar de wereld kon vertellen: “wijs alles af dat zich voordoet als van mij, maar niet klopt.” Ontvangers moesten gokken, met ad-hoc spamfiltering, wat een van de redenen is waarom e-mail van oudsher zo’n veelgebruikt kanaal is voor imitatie en phishing. DMARC geeft domeineigenaren een expliciete, machineleesbare manier om aan te geven wat er met falende mail moet gebeuren, en geeft via de rapportage inzicht in wie er als hun domein verstuurt.

Hoe het werkt

Een DMARC-record wordt gepubliceerd in DNS op _dmarc.jouwdomein.nl. Het benoemt een beleid (none, quarantine of reject) en een adres voor geaggregeerde rapporten. Elk domein zou er één moeten hebben — op zijn minst p=none met een rapportageadres, zodat je al inzicht krijgt in je mailstromen vóórdat je iets afdwingt.

DMARC-beleid wordt standaard overgeërfd door subdomeinen, maar een subdomein dat daadwerkelijk mail verstuurt, doet er goed aan toch een eigen expliciet record te hebben, voor de duidelijkheid en om het overgeërfde beleid indien nodig te overschrijven.

Ik wil meer weten

De uitleg hierboven dekt wat de meeste mensen nodig hebben. De rest van dit artikel is de gedetailleerde naslag: de exacte recordsyntaxis, optionele tags, en aanbevelingen voor handhaving.

Algemeen

  • Elk domein zou een DMARC-record moeten hebben: op zijn minst p=none met een adres voor geaggregeerde rapporten (rua).
  • Een domein mag maar één DMARC-record hebben, gepubliceerd op de host _dmarc.
  • DMARC-records worden in DNS gepubliceerd als TXT-records (of via een CNAME die naar zo’n record wijst).
  • De syntaxis van een DMARC-record is hoofdlettergevoelig en moet vóór publicatie met tooling worden gevalideerd.
  • Houd records overzichtelijk: neem geen tags op met hun impliciete/standaardwaarde (bijvoorbeeld adkim=r of aspf=r zijn beide al de standaard, dus ze expliciet vermelden voegt niets toe).

Configuratie

Het minimaal geldige record heeft een versietag en een beleidstag nodig:

v=DMARC1; p=<beleid>; rua=mailto:<rapportageadres>

  • v=DMARC1; — de versietag, verplicht.
  • p=none|quarantine|reject; — de beleidstag, verplicht.
  • pct= — staat standaard op 100 (het beleid geldt voor 100% van de falende berichten) als je hem weglaat; stel deze alleen expliciet in als je bewust een gedeeltelijke uitrol wilt.
  • aspf=r|s en adkim=r|s — alignmentmodus voor respectievelijk SPF en DKIM (relaxed of strict); dit beïnvloedt alleen hoe alignment met het Header.From-domein wordt beoordeeld, niet of SPF/DKIM zelf slagen.
  • ruf= — adres voor forensische rapporten. Is dit niet ingesteld, dan heeft de bijbehorende fo= tag (forensische opties) niets om op te sturen en kan deze worden weggelaten.
  • Vermijd ri= (rapportage-interval) en rf= (rapportageformaat) — de meeste rapporterende partijen negeren deze tags, dus ze voegen alleen ruis toe zonder effect.
  • Zet sp= niet in het eigen DMARC-record van een subdomein — die tag is bedoeld voor het organisatiedomein om iets over zijn subdomeinen te zeggen, niet voor een subdomein om voor zichzelf in te stellen.
  • Gebruikt je rua– of ruf-adres een ander domein dan het domein dat wordt beschermd, dan moet dat andere domein een expliciet autorisatierecord publiceren, zodat het niet zonder toestemming kan worden gebruikt om rapporten om te leiden: <domein-dat-de-data-verzamelt>._report._dmarc.<beschermde-domein> als TXT-record met waarde v=DMARC1;.

Beveiliging

  • Een beleid van p=none is alleen bedoeld om te monitoren: het stopt misbruik niet uit zichzelf, het geeft alleen inzicht.
  • Ga naar handhaving zodra je rapporten laten zien dat al je legitieme verzenders slagen: minimaal p=quarantine (naar de spammap), bij voorkeur p=reject (volledig geblokkeerd) als einddoel.

Bronnen & verder lezen

  • RFC 7489 – Domain-based Message Authentication, Reporting, and Conformance (DMARC): datatracker.ietf.org/doc/rfc7489. Let op: RFC 7489 is gepubliceerd als Informational, Independent Submission in plaats van op het IETF Standards Track (in tegenstelling tot SPF’s RFC 7208 of DKIM’s RFC 6376) — dat is simpelweg hoe DMARC de RFC-reeks is binnengekomen, en het maakt het document in de praktijk niet minder gezaghebbend: het is nog steeds de specificatie die de hele branche als de DMARC-standaard behandelt.