DMARC uitrollen: van none naar reject

Module 4: Afleverbaarheid: SPF, DKIM en DMARC in de praktijk · Leestijd: 12 minuten

Leerdoel: Na deze les kun je uitleggen hoe uitlijning werkt, een DMARC-uitrol in fasen plannen van p=none naar p=reject, de juiste tags kiezen (rua, sp, np, t) en de bekende valkuilen bij doorsturen en mailinglijsten opvangen.

Kernbegrippen: DMARC (RFC 9989), Author Domain (het domein in Van), uitlijning (alignment), relaxed en strict (adkim, aspf), organisatiedomein, DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (testmodus), vervallen tags pct, rf, ri, mailinglijsten, From herschrijven, ARC

Wat DMARC precies controleert

DMARC beantwoordt één vraag voor elke binnenkomende mail: is SPF of DKIM geslaagd voor een domein dat bij het Van-adres hoort? Het domein in het Van-adres heet in de standaard het Author Domain. De basis van het record staat in de DNS-cursus, les 4.5. In mei 2026 is de herziene standaard verschenen: RFC 9989, met RFC 9990 voor de verzamelrapporten en RFC 9991 voor de foutrapporten. Bestaande records met v=DMARC1 blijven gewoon geldig.

Uitlijning in de praktijk

"Hoort bij" heet uitlijning (alignment). Er zijn twee standen:

• relaxed (standaard): de domeinen hebben hetzelfde organisatiedomein. nieuws.example.com en example.com zijn uitgelijnd; example.com en example.net niet.
• strict (adkim=s of aspf=s): de domeinen moeten precies gelijk zijn.

Voor SPF vergelijkt DMARC het domein van het Return-Path met het Van-domein. Voor DKIM het d=-domein van een geldige handtekening. Een paar voorbeelden voor een mail met Van: info@example.com:

Laat adkim en aspf dus op relaxed staan, tenzij je een goede reden hebt.

Hoe weet een ontvanger wat het organisatiedomein is? Vroeger met de Public Suffix List, een lijst met domeinen als .nl, .co.uk en github.io. RFC 9989 vervangt dat door een DNS tree walk: de ontvanger zoekt _dmarc-records op van het domein en de bovenliggende domeinen. Voor een gewone gebruiker verandert er niets; je merkt het alleen als je met records op subdomeinen werkt.

De uitrol in vier fasen

Het doel is p=reject: dan weigeren ontvangers mail die zich als jou voordoet, en dat is de beste bescherming tegen nepfacturen en phishing uit jouw naam. Maar wie meteen op reject gaat zonder zijn verzenders te kennen, weigert straks zijn eigen facturen. Daarom deze volgorde (de advieslijn van deze cursus):

Fase 0: voorbereiden

• Maak de inventaris van al je verzenders (les 4.2).
• Zorg dat elke verzender SPF of DKIM uitgelijnd heeft; liefst DKIM, want dat overleeft doorsturen.
• Maak een apart adres voor rapporten, bijvoorbeeld dmarc@example.com, of gebruik een rapportdienst. Je krijgt al snel een paar rapporten per dag.

Fase 1: meten met p=none

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

p=none doet niets met de mail zelf. Ontvangers leveren alles af zoals altijd, maar sturen je dagelijks een verzamelrapport (aggregate report) met elke server die namens je domein mailde en of SPF, DKIM en DMARC slaagden. Daarmee voldoe je ook aan de minimale eis van Gmail, Yahoo en Microsoft voor bulkverzenders (les 5.3).

Laat dit minstens twee tot vier weken staan, en langer als je diensten hebt die maar af en toe mailen (een jaarlijkse herinnering, een kwartaalfactuur). Lees de rapporten (les 4.5) en repareer elke eigen bron die faalt.

Fase 2: p=quarantine

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Mail die niet door DMARC komt, gaat bij de ontvanger naar de spammap. Vergeet je toch een bron, dan is die mail niet weg, maar wel lastig te vinden. Wil je voorzichtig zijn, voeg dan eerst t=y toe (testmodus): ontvangers passen dan een stap milder beleid toe (bij quarantine dus none), maar je ziet in de rapporten wat er zou gebeuren. Dit is in RFC 9989 de vervanger van de oude tag pct=.

Kijk weer een paar weken naar de rapporten.

Fase 3: p=reject

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Mail die niet door DMARC komt, wordt geweigerd. De afzender krijgt een bounce, bij Microsoft bijvoorbeeld met de code 5.7.509 en bij Gmail met een verwijzing naar het DMARC-beleid (module 6). Houd de rapporten aan: nieuwe diensten komen er altijd bij.

Wanneer mag het sneller?

Gaat al je mail via één aanbieder die SPF en DKIM voor je regelt, en verstuurt verder niets namens je domein? Dan kan een streng beleid meteen. Sommige hostingbedrijven zetten daarom standaard p=reject. Ga je daarna toch een nieuwsbriefdienst of boekhoudprogramma gebruiken, zet het dan eerst tijdelijk terug op p=none met een rapportadres, tot die dienst goed staat.

De andere tags

Een rapportadres op een ander domein (bijvoorbeeld een rapportdienst) werkt alleen als dat domein toestemming geeft met een record als example.com._report._dmarc.rapportdienst.example. De dienst regelt dat meestal zelf (RFC 9990, hoofdstuk 4).

Valkuilen

Mailinglijsten

Een klassieke mailinglijst stuurt jouw mail door naar alle leden, vanaf zijn eigen server, en voegt vaak [lijst] aan het onderwerp of een voettekst toe. Dan faalt SPF (andere server) en DKIM (mail veranderd). Met p=reject weigeren de ontvangers jouw bericht aan de lijst. Moderne lijstsoftware lost dat op door het Van-adres te herschrijven naar het lijstadres ("Jan via Leden"), of door de mail ongewijzigd door te sturen. Gebruik je een lijst die dat niet doet, dan zie je het terug in je rapporten.

Doorsturen

Zie les 3.3: SPF breekt, DKIM overleeft meestal. Een ontvanger kan met ARC besluiten een bekende doorstuurder te vertrouwen. In de rapporten herken je dit als mail van een onbekende server met DKIM pass en SPF fail; dat is geen reden om je beleid te versoepelen.

Twee records of een tikfout

Twee DMARC-records op _dmarc maken het beleid ongeldig, en een tikfout in p= ook (p=rejected bestaat niet). Controleer na elke wijziging.

In de praktijk: zo ziet het eruit in een paneel

Bij een hostingpakket van WebOké staat standaard v=DMARC1;p=reject, zonder rapportadres. Dat is veilig als al je mail via die servers loopt. Mail je ook via andere diensten, zet het dan op p=none met een rua-adres en werk de fasen af. In DirectAdmin doe je dat in DNS Beheer met het potlood achter het _dmarc-record (velden Domein beleid Type en Geaggregeerde e-mail (RUA)); in Mijn WebOké met de DMARC-hulp op het tabblad DNS. Bij andere aanbieders maak je een TXT-record op de naam _dmarc en typ je de tekst zelf; het resultaat is hetzelfde.

Samenvatting

• DMARC slaagt als SPF of DKIM slaagt voor een domein dat uitgelijnd is met het Van-domein; relaxed uitlijning accepteert subdomeinen.
• Uitrol: inventaris, p=none met rua en rapporten lezen, p=quarantine (eventueel met t=y), en dan p=reject.
• Gebruik np=reject voor niet-bestaande subdomeinen zodra het hoofdbeleid streng is. pct, rf en ri zijn vervallen.
• Mailinglijsten en doorsturen geven verwachte fouten; DKIM en ARC vangen een deel op.
• Precies één record op _dmarc, zonder tikfouten.

Quiz

Opdracht

Opdracht Z4.4: DMARC van je domein controleren en de volgende stap kiezen. Vul je eigen domein in (of internet.nl). Vul het DMARC-record in zoals je het vond, de waarde van p= en of er een rua-adres in staat. Kies daarna welke fase van de uitrol volgens jou de volgende stap is, en waarom. Het programma vraagt het record live op, controleert de syntax volgens RFC 9989 (één record, geldige p, bekende tags, vervallen tags als waarschuwing), en zet jouw antwoorden ernaast.

Verder lezen

De stappen in deze artikelen gelden voor de panelen van WebOké; bij andere aanbieders werkt het vergelijkbaar.

• Gratis DNS-cursus 4.5: DMARC: wat ontvangers moeten doen met nepmail
• DirectAdmin handleiding 5.9: DMARC instellen
• Wat is DMARC? Uitleg in gewone taal
• DMARC-record aanmaken in DirectAdmin
• RFC 9989 (DMARC), met name 4.7 (tags) en bijlage C (wijzigingen sinds RFC 7489)