DMARC-vragen,
beantwoord

DMARC (Domain-based Message Authentication, Reporting & Conformance) is een e-mailauthenticatieprotocol dat ontvangende mailservers vertelt wat ze moeten doen wanneer SPF- of DKIM-controles mislukken. Het voorkomt dat aanvallers e-mail versturen die van uw domein lijkt te komen, en beschermt zo uw merk en uw ontvangers tegen phishing en spoofing. DMARC is gedefinieerd in RFC 7489.

Ja. Als uw domein e-mail verstuurt - of zelfs als dat niet zo is - heeft u DMARC nodig. Zonder DMARC kan iedereen e-mail versturen die zich voordoet als uw domein. Google en Yahoo vereisen nu ten minste p=none voor domeinen die meer dan 5.000 berichten per dag versturen. PCI DSS v4.0 vereist DMARC voor domeinen die met klanten communiceren. Domeinen die geen e-mail versturen, zouden p=reject moeten publiceren om imitatie te voorkomen.

Zorg er eerst voor dat SPF en DKIM voor uw domein zijn geconfigureerd. Publiceer vervolgens een DNS TXT-record op _dmarc.uwdomein.com met p=none en een rua=-rapportageadres. Monitor aggregatierapporten gedurende ten minste 90 dagen, corrigeer de authenticatie voor alle legitieme verzenders en ga daarna geleidelijk over naar p=quarantine en uiteindelijk p=reject. Gebruik onze DMARC Checker om uw record te valideren.

Het publiceren van een DMARC-record op p=none duurt enkele minuten. Volledige handhaving op p=reject bereiken duurt doorgaans 9 tot 18 maanden. Elke fase (none, quarantine, reject) vereist minimaal 90 dagen monitoring om alle legitieme verzendbronnen te identificeren en hun authenticatie te corrigeren. Organisaties met minder externe verzenders kunnen sneller vooruitgaan.

Een DMARC-record is een DNS TXT-record dat wordt gepubliceerd op _dmarc.uwdomein.com. Een typisch record ziet er zo uit: v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=r; aspf=r. De tags v= en p= zijn verplicht; alle andere zijn optioneel maar aanbevolen. Bekijk onze pagina Wat is DMARC voor een volledige uitleg van elke tag.

SPF verifieert dat de verzendende server is geautoriseerd door het DNS-record van het domein - het controleert de envelopafzender (Return-Path). DKIM voegt een cryptografische handtekening toe om te bewijzen dat het bericht onderweg niet is gewijzigd. DMARC koppelt ze samen: het vereist dat SPF of DKIM slaagt EN uitgelijnd is met het zichtbare From-headerdomein, en vertelt ontvangers vervolgens wat ze moeten doen wanneer authenticatie mislukt. Gebruik onze SPF Checker en DKIM Lookup om uw records te testen.

Nee. Een domein moet precies één DMARC TXT-record hebben op _dmarc.domein.com. Meerdere DMARC-records veroorzaken een PermError en ontvangers negeren ze allemaal. Als u rapporten naar meerdere adressen moet sturen, vermeld ze dan door komma's gescheiden in de rua=-tag: rua=mailto:dmarc@example.com,mailto:reports@example.com.

DMARC-uitlijning betekent dat het domein in de zichtbare From-header moet overeenkomen met het domein dat SPF of DKIM heeft doorstaan. Relaxed-uitlijning (standaard) staat overeenkomst op subdomeinniveau toe - mail.example.com is uitgelijnd met example.com. Strikte uitlijning vereist een exacte domeinovereenkomst. Uitlijning voorkomt dat aanvallers SPF halen met hun eigen domein terwijl ze het uwe in de From-header vervalsen.

Het beleid p=none instrueert ontvangende servers om geen handhavingsmaatregel te nemen tegen berichten die DMARC niet doorstaan. Berichten worden normaal afgeleverd, ongeacht de authenticatieresultaten. Het doel is monitoring: ontvangers sturen nog steeds aggregatierapporten, wat de domeineigenaar inzicht geeft in alle verzendbronnen. Begin altijd met p=none voordat u naar handhaving overgaat.

Het beleid p=quarantine instrueert ontvangende servers om berichten die de controle niet doorstaan naar de spam- of ongewenste-berichtenmap te routeren. Het bericht bestaat nog steeds - ontvangers kunnen het vinden - maar het is als verdacht gemarkeerd. Dit is de tussenliggende handhavingsstap tussen p=none (monitoring) en p=reject (volledige blokkering). Zie onze gids DMARC-beleid voor de volledige progressie.

Het beleid p=reject instrueert ontvangende servers om berichten die de controle niet doorstaan op SMTP-niveau te weigeren. De ontvanger ziet het bericht nooit en de verzendende server ontvangt een bounce. Dit is de sterkste DMARC-bescherming en het uiteindelijke doel voor elk domein. Om p=reject te bereiken is eerst grondige monitoring via de fasen p=none en p=quarantine nodig.

De pct=-tag bepaalt welk percentage van de mislukte berichten de handhavingsmaatregel ondergaat. Bij pct=25 wordt slechts 25% van de mislukte berichten in quarantaine geplaatst of geweigerd - de rest wordt behandeld als p=none. Dit maakt een geleidelijke uitrol van handhaving mogelijk. Begin bij pct=10, verhoog naar 25, 50 en dan 100 over enkele weken. Als pct= wordt weggelaten, is de standaardwaarde 100.

Een aggregatierapport (RUA) is een XML-bestand dat dagelijks door ontvangende mailservers wordt verzonden en dat de authenticatieresultaten samenvat voor alle berichten die beweren van uw domein afkomstig te zijn. Het toont welke IP-adressen e-mail hebben verzonden, of SPF en DKIM zijn geslaagd en welk beleid is toegepast. Aggregatierapporten vormen de basis van DMARC-monitoring - ze leveren de gegevens die nodig zijn om handhavingsbeslissingen te nemen. DMARC Report zet deze XML-bestanden om in visuele dashboards.

Een forensisch rapport (RUF) biedt foutdetails per bericht - de specifieke e-mail die de authenticatie niet doorstond, het afzender-IP, de From/Return-Path-mismatch en welk mechanisme faalde. Forensische rapporten zijn nuttig om actieve spoofingpogingen te onderzoeken, maar worden minder vaak ondersteund door ontvangers dan aggregatierapporten. Sommige ontvangers versturen helemaal geen RUF-rapporten vanwege privacyoverwegingen.

Ruwe DMARC-aggregatierapporten zijn XML-bestanden die handmatig moeilijk te lezen zijn. Gebruik een DMARC-rapportanalyzer zoals DMARC Report om XML om te zetten in visuele dashboards die de authenticatiestatus van verzenders, uitlijningsresultaten en beleidsacties tonen. De tool classificeert verzenders automatisch per leverancier (Google Workspace, Microsoft 365, SendGrid, enz.) en markeert fouten die aandacht vereisen.

Veelvoorkomende redenen: uw DMARC-record bevat geen rua=-tag, het rua=-e-mailadres bevat een typefout, of er is niet genoeg e-mailvolume verzonden om rapporten te activeren (ontvangers bundelen rapporten doorgaans dagelijks). Als rua= naar een ander domein verwijst dan het domein dat wordt geauthenticeerd, heeft u een extern verificatie-DNS-record nodig. Reken op 24 tot 72 uur na het publiceren van uw DMARC-record voordat de rapporten binnenkomen. Gebruik onze DMARC Checker om de syntaxis van uw record te valideren.

De meeste ontvangers versturen aggregatierapporten eens per 24 uur, doorgaans om middernacht UTC. Sommige grote ontvangers zoals Google en Microsoft kunnen meerdere rapporten per dag versturen. Het aantal rapporten dat u ontvangt, hangt af van hoeveel verschillende ontvangers e-mail van uw domein verwerken. Populaire domeinen kunnen dagelijks honderden rapporten van tientallen ontvangers ontvangen.

De weg van p=none naar p=reject duurt doorgaans 9 tot 18 maanden. Elke fase vereist minimaal 90 dagen: p=none voor monitoring en verzenderidentificatie, p=quarantine voor tussentijdse handhaving en p=reject voor volledige bescherming. Organisaties met minder externe verzenders en een eenvoudigere e-mailinfrastructuur kunnen sneller vooruitgaan, maar het overhaasten van handhaving zorgt ervoor dat legitieme e-mail wordt geblokkeerd.

Als een legitieme verzender DMARC niet doorstaat bij p=quarantine, belandt hun e-mail in de spam. Bij p=reject wordt deze volledig geblokkeerd. Om dit op te lossen: controleer de aggregatierapporten om de mislukte verzender te identificeren, configureer diens SPF-include of DKIM-ondertekening en verifieer dat de uitlijning slaagt. Het gebruik van de pct=-tag om handhaving geleidelijk uit te rollen, helpt deze problemen op te sporen voordat ze alle e-mail treffen.

Quarantaine biedt betekenisvolle bescherming - vervalste berichten verlaten het postvak IN. Toch is p=reject het aanbevolen doel, omdat het aflevering volledig voorkomt. Sommige nalevingskaders (PCI DSS v4.0, CISA BOD 18-01 voor federale instanties) vereisen specifiek p=reject. Bovendien is p=reject vereist om in aanmerking te komen voor BIMI, dat uw merklogo weergeeft in ondersteunende e-mailclients.

Ja. Traditionele e-maildoorsturing kan de SPF-uitlijning verbreken, omdat het IP van de doorstuurserver niet in het SPF-record van het oorspronkelijke domein staat. DKIM overleeft doorsturing doorgaans, omdat de handtekening aan het bericht zelf is gekoppeld. Daarom is DKIM-uitlijning bijzonder belangrijk voor domeinen waarvan de ontvangers e-mail doorsturen. ARC (Authenticated Received Chain) is een nieuwer protocol dat is ontworpen om dit aan te pakken, maar de adoptie groeit nog steeds.

DMARC wordt vereist door een groeiend aantal standaarden en organisaties. Google en Yahoo vereisen ten minste p=none voor bulkverzenders (5.000+ berichten/dag). PCI DSS v4.0 vereist DMARC voor domeinen die worden gebruikt bij communicatie met klanten (van kracht sinds maart 2025). CISA BOD 18-01 verplicht p=reject voor Amerikaanse federale instanties. Veel cyberverzekeringspolissen en inkoopprocessen vereisen nu DMARC-handhaving.

Sinds februari 2024 vereisen Google en Yahoo van alle bulkverzenders (5.000+ berichten/dag naar Gmail-/Yahoo-gebruikers) een DMARC-beleid van ten minste p=none met een geldig rua=-adres. Bovendien moeten verzenders correct geconfigureerde SPF en DKIM hebben, uitschrijfheaders met één klik opnemen in marketing-e-mail en een spamklachtenpercentage onder 0,3% aanhouden. Niet-conforme verzenders ondervinden vertraagde aflevering en weigeringen.

Ja. PCI DSS v4.0 (van kracht sinds maart 2025) vereist dat organisaties die kaarthoudergegevens verwerken DMARC implementeren op domeinen die worden gebruikt in communicatie met klanten. Specifiek stelt vereiste 5.4.1 dat anti-phishingmechanismen domeingebaseerde authenticatie (DMARC, SPF, DKIM) moeten omvatten. De meeste PCI-beoordelaars verwachten p=reject of p=quarantine voor naleving.

Binding Operational Directive 18-01, uitgevaardigd door de Cybersecurity and Infrastructure Security Agency (CISA), vereist dat alle Amerikaanse federale uitvoerende instanties DMARC implementeren op p=reject. Deze richtlijn heeft de adoptie van DMARC in de overheidssector aanzienlijk vergroot en wordt vaak aangehaald als benchmark voor best practices door andere organisaties en sectoren.

DMARC ondersteunt HIPAA-naleving door e-mailspoofing van domeinnamen in de gezondheidszorg te voorkomen, waardoor het risico op phishingaanvallen die kunnen leiden tot blootstelling van beschermde gezondheidsinformatie (PHI) wordt verkleind. Hoewel HIPAA DMARC niet expliciet noemt, vereist de Security Rule waarborgen ter bescherming van elektronische PHI, en e-mailauthenticatie wordt beschouwd als een redelijke en passende maatregel. Let op: forensische rapporten (RUF) kunnen berichtinhoud bevatten, dus organisaties in de gezondheidszorg zouden uitsluitend aggregatierapporten (RUA) moeten gebruiken of ervoor moeten zorgen dat forensische rapporten conform HIPAA worden verwerkt.