Gratis DMARC-record- controle

Wat is DMARC en waarom is het in 2026 belangrijk?

DMARC — Domain-based Message Authentication, Reporting & Conformance — is de policylaag die SPF en DKIM aan elkaar bindt. SPF vertelt ontvangende servers welke IP's namens jouw domein mogen versturen. DKIM ondertekent elk bericht cryptografisch zodat ontvangers kunnen verifiëren dat er niets mee is geknoeid. DMARC is de gebruiksaanwijzing: het vertelt Gmail, Outlook, Yahoo en elke andere inboxprovider wat te doen wanneer een bericht dat zogenaamd van jouw domein komt op een of beide checks faalt. Zonder DMARC kunnen aanvallers je From-adres spoofen en op jouw reputatie meerijden, recht de inbox van je klanten in.

In 2026 is dit niet langer optioneel. Sinds februari 2024 — en steeds strenger door 2025 en 2026 heen — vereisen Gmail en Yahoo dat elke afzender met meer dan 5.000 berichten per dag een geldig DMARC-record heeft. Microsoft 365 volgde met eigen handhaving voor afzenders met hoog volume. Domeinen zonder DMARC zien bulkmail bouncen of direct in spam belanden, en het aantal phishingaanvallen waarbij een merk wordt nagebootst verdubbelt ruwweg wanneer DMARC ontbreekt.

Anatomie van een DMARC-record

Een DMARC-record is één enkel TXT-record gepubliceerd op _dmarc.jouwdomein.com. Het is een lijst tags gescheiden door puntkomma's. Hier is een typisch record en wat elk onderdeel doet:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; aspf=r; adkim=r;

• v=DMARC1 — Verplichte versietag. Moet exact DMARC1 zijn (hoofdlettergevoelig) anders wordt het hele record genegeerd.
• p= — Het beleid zelf. p=none betekent alleen monitoren — fouten worden nog steeds afgeleverd. p=quarantine stuurt falende mail naar de spamfolder. p=reject blokkeert het direct aan de SMTP-grens.
• rua= — Mailbox voor aggregaatrapporten. Ontvangers sturen hier dagelijks XML-rapporten naartoe met een samenvatting van welke IP's mail verstuurden namens jouw domein en hoeveel berichten slaagden of faalden. Formaat: rua=mailto:dmarc-reports@jouwdomein.com.
• ruf= — Mailbox voor forensische (failure) rapporten. Per-bericht failure samples met headers en soms een geredacteerde body. De meeste providers sturen deze niet meer om privacyredenen, dus rua is in de praktijk veel nuttiger.
• pct= — Percentage falende mail waarop de policy van toepassing is (1–100). Hiermee kun je gefaseerd uitrollen: pct=25 met p=quarantine quarantineert een kwart van de fouten en levert 75% af.
• aspf= / adkim= — Alignment-modus. aspf=s/r en adkim=s/r bepalen of het matchen van SPF/DKIM-domeinen strict (exact) of relaxed (subdomein toegestaan) is. Standaard is relaxed — wat bijna iedereen wil.

5 veelvoorkomende DMARC-fouten en hoe je ze oplost

Fout: geen DMARC-record gevonden

De meest voorkomende failure mode. Voer dig TXT _dmarc.jouwdomein.com uit — krijg je niets terug, dan ontbreekt het record. Check drie dingen: (1) je hebt het TXT-record gepubliceerd op _dmarc als subdomein, niet op het rootdomein; (2) het hostveld is exact _dmarc met een leidende underscore (sommige DNS-UI's strippen die); (3) je hebt op propagatie gewacht. TTL is meestal 300–3600 seconden, maar Cloudflare en Route53 zijn meestal binnen een minuut live. Vermijd hoofdletters _DMARC — DNS-labels zijn hoofdletterongevoelig, maar sommige validators zijn streng.

Fout: meerdere DMARC-records

Als er twee of meer TXT-records bestaan op _dmarc, vereist RFC 7489 dat ontvangers ze allemaal negeren — je domein valt dan terug op géén beleid. Dit gebeurt vaak wanneer een marketingtool of migratiescript een tweede record publiceert zonder de eerste te verwijderen. Voer dig +short TXT _dmarc.jouwdomein.com uit — zie je meer dan één v=DMARC1-regel, verwijder dan de oudere of zwakkere. Consolideer alles in één enkel record met alle tags die je nodig hebt (p, rua, ruf, pct, aspf, adkim).

Fout: ongeldige syntax

DMARC-parsers zijn streng. De vijf meest voorkomende syntaxfouten: (1) ontbrekende puntkomma's tussen tags — elk tagpaar moet eindigen met ;; (2) =-tekens in mailto-URI's gebruiken zonder correcte encoding; (3) smart quotes uit een Word-doc geplakt in plaats van rechte ASCII-aanhalingstekens; (4) typo's zoals p=quarentine of p=rejct; (5) het hele record extra tussen aanhalingstekens zetten terwijl de DNS-UI dat al doet. Valideer met onze checker hierboven — die parst tag voor tag en vertelt je precies welke token faalde.

Fout: SPF/DKIM-alignmentproblemen

DMARC slaagt alleen wanneer ten minste een van SPF of DKIM zowel authenticeert als uitlijnt met het From-domein. Een veelvoorkomende valkuil: je ESP (bijv. Mailchimp) authenticeert met zijn eigen return-path zoals bounces.mcsv.net, dus SPF slaagt maar lijnt niet uit met jouwdomein.com. Los dit op door DKIM-signing met jouw eigen domein in te schakelen op de ESP — DKIM-alignment is gemakkelijker dan SPF-alignment omdat de d=-tag in de DKIM-handtekening met je rootdomein kan matchen. Voor subdomeinen, zet aspf=r en adkim=r (relaxed, de standaard) zodat subdomein-mail uitlijnt met de root.

DMARC-setup in 5 stappen

1. Audit je huidige authenticatie — Voordat je DMARC publiceert, fix eerst SPF en DKIM. Run onze SPF Checker en DKIM Checker op elk verzendend domein en subdomein. Bevestig dat SPF onder de limiet van 10 DNS-lookups blijft en eindigt op -all of ~all. Bevestig dat DKIM tekent met een 2048-bits sleutel en uitlijnt met je From-domein.
2. Publiceer een monitoringrecord (p=none) — Voeg dit TXT-record toe op host _dmarc: v=DMARC1; p=none; rua=mailto:dmarc@jouwdomein.com; pct=100; aspf=r; adkim=r. p=none betekent géén impact op mailflow — ontvangers sturen je aggregaatrapporten zonder te quarantaineren of te weigeren. Dit is je dataverzamelingsfase. Gebruik een aparte mailbox of een DMARC-analyser, want ruwe XML is op schaal onleesbaar.
3. Verzamel aggregaatrapporten — Binnen 24 uur zou je dagelijkse XML-rapporten moeten ontvangen van grote ontvangers. Parse ze om elk IP en platform te identificeren dat als jouw domein verstuurt. Verwachte afzenders (Google Workspace, Mailchimp, SendGrid) moeten slagen. Onverwachte zijn ofwel shadow IT ofwel spoofers — onderzoek voordat je het beleid aanscherpt.
4. Schakel over naar quarantine met pct=25 — Zodra 95%+ van legitieme mail zowel SPF als DKIM met alignment passeert, scherp aan tot v=DMARC1; p=quarantine; pct=25; rua=...;. Nu gaat 25% van de falende mail naar spam. Houd rapporten en helpdesktickets in de gaten op false positives. Na twee schone weken, verhoog pct naar 50, dan 100.
5. Bereik p=reject — Eindstatus: v=DMARC1; p=reject; rua=mailto:dmarc@jouwdomein.com; pct=100;. Falende mail wordt aan de SMTP-grens geweigerd — phishers kunnen je domein niet meer spoofen. Dit is de enige configuratie die je merk volledig beschermt. De meeste domeinen bereiken reject binnen 8 weken na de start op p=none.

DMARC-uitrolfases (4 tot 8 weken)

Een veilige DMARC-uitrol volgt een procentuele ramp zodat je misconfiguraties opvangt voordat ze deliverability schaden. Het minimaal werkbare tijdspad is vier weken; acht is veiliger voor organisaties met veel verzendplatforms.

• Week 1-2: monitoren (p=none) — Publiceer p=none met rua=-rapportage. Verzamel aggregaatrapporten, identificeer elke legitieme afzender en dicht SPF/DKIM-gaten. Verwacht ten minste één shadow ESP te ontdekken waarvan IT niet wist.
• Week 3-4: quarantine pct=25 — Schakel over naar p=quarantine; pct=25. Een kwart van niet-geauthenticeerde mail belandt nu in spam. Houd rapporten dagelijks in de gaten op onverwachte uitval van legitieme mail. Als een afzender breekt, draai terug naar p=none, fix het, probeer opnieuw.
• Week 5-6: quarantine pct=100 — Verhoog naar p=quarantine; pct=100. Alle falende mail gaat naar spam. Op dit punt zouden je rapporten 99%+ slagingspercentages moeten tonen van bekende afzenders. Spoofed mail die je domein probeert te misbruiken is nu in de inbox van de ontvanger geneutraliseerd.
• Week 7-8: reject — Schakel over naar p=reject; pct=100. Falende mail wordt bij de SMTP-transactie geweigerd — bereikt nooit de ontvanger. Dit is de eindstatus. Houd rapportage aan (rua=) zodat je regressies opmerkt wanneer een nieuwe ESP wordt toegevoegd.

Gmail- en Yahoo-vereisten in 2026

Verstuur je meer dan 5.000 berichten per dag naar Gmail- of Yahoo-adressen, dan is DMARC verplicht. Het minimaal aanvaardbare record is p=none — maar Google's eigen richtlijnen raden inmiddels p=quarantine of strikter aan. Zonder een geldig DMARC-record zien bulkverzenders berichten bouncen met 5.7.26 'unauthenticated email is not accepted' of direct in spam belanden, ongeacht de inhoud. De andere vereisten van 2026 stapelen daarbovenop: one-click unsubscribe in headers, spamklachten onder 0,3%, en TLS voor SMTP. DMARC is hiervan het goedkoopst om te implementeren — typisch één TXT-record en 30 minuten werk — en het is de allerbelangrijkste deliverability-hefboom voor transactionele en marketingmail.