Wat is DMARC? Definitie, hoe het werkt en waarom het belangrijk is

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is een protocol voor e-mailauthenticatie waarmee domeineigenaren kunnen bepalen wat er gebeurt met e-mails die de SPF- en DKIM-controles niet doorstaan. Het beschermt uw domein tegen phishing, spoofing en Business Email Compromise door ontvangende e-mailservers te instrueren om niet-geverifieerde e-mails te controleren, in quarantaine te plaatsen of te weigeren.

DMARC valt nu onder RFC 9989 (mei 2026), die de oorspronkelijke RFC 7489 heeft vervangen. Het is belangrijk om op te merken dat bestaande records die vóór de RFC-update correct waren geconfigureerd, nog steeds geldig blijven; er hoeft dus niets te worden gemigreerd.

Waar staat DMARC voor? Volledige betekenis

DMARC staat voor Domain-based Message Authentication, Reporting, and Conformance. Elk onderdeel van de naam verwijst naar een functie die het protocol daadwerkelijk vervult:

• Op domeinbasis: DMARC werkt op domeinniveau, niet per afzonderlijk bericht. Je publiceert één DNS-beleid dat van toepassing is op alle e-mails die beweren afkomstig te zijn van jouw domein.
• Verificatie van berichten: Hierbij wordt gecontroleerd of een e-mail daadwerkelijk afkomstig is van uw domein, door de SPF- en DKIM-resultaten te verifiëren en na te gaan of deze overeenkomen met het zichtbare „Van:”-adres.
• Rapportage: Ontvangende servers sturen u rapporten waarin wordt weergegeven wie er e-mail verstuurt via uw domein en hoe dit is verlopen wat betreft de authenticatie.
• Naleving: Je publiceert een beleid (geen actie, in quarantaine plaatsen of afwijzen) waarin je ontvangers aangeeft hoe ze moeten omgaan met e-mail die niet door de controle komt, en zij houden zich daaraan.

Hoe werkt DMARC?

DMARC controleert of een inkomende e-mail voldoet aan SPF of DKIM, en verifieert of het resultaat overeenkomt met het domein dat in het veld „Van:” wordt weergegeven. Vervolgens past het het beleid toe dat je in DNS hebt gepubliceerd. Het bouwt voort op SPF en DKIM en vult de twee aspecten aan die deze methoden afzonderlijk missen.

Wanneer er een e-mail binnenkomt die beweert afkomstig te zijn van uw domein, voert de ontvangende server beide controles uit, gaat na of een van beide overeenkomt met uw ‘From:’-domein en past vervolgens het beleid toe dat u in DNS hebt gepubliceerd. Ten slotte ontvangt u een rapport, zodat u precies kunt zien wat er is gebeurd.

Het authenticatieproces voor e-mail: SPF, DKIM en DMARC

Hier volgt het volledige proces, vanaf het moment dat een e-mail wordt verzonden tot het moment dat het rapport weer in je inbox terechtkomt:

1. E-mail wordt verzonden: een server verstuurt een bericht waarbij je domein in het ‘Van:’-adres wordt gebruikt.
2. SPF-controle: De ontvangende server controleert of het IP-adres van de afzender is geautoriseerd in het SPF-record van uw domein.
3. DKIM-controle: De ontvanger controleert de DKIM-handtekening van het bericht aan de hand van de openbare sleutel die in uw DNS is gepubliceerd, om te bevestigen dat het bericht tijdens de verzending niet is gewijzigd.
4. DMARC-beoordeling en overeenstemming: DMARC beoordeelt zowel de resultaten als of het domein dat via SPF of DKIM is geauthenticeerd, overeenkomt met het domein in de zichtbare From:-header. Ten minste één van beide moet slagen en overeenkomen.
5. Het beleid wordt toegepast: op basis van uw gepubliceerde beleid wordt het bericht door de ontvanger normaal afgeleverd (geen actie), naar de spamfolder gestuurd (quarantaine) of geblokkeerd (afgewezen).
6. Het rapport is verzonden: De ontvanger stuurt je, doorgaans binnen 24 uur, een samenvattend rapport terug met een overzicht van wat er is waargenomen.

Wat is DMARC-afstemming?

Afstemming is het mechanisme dat een geslaagde SPF- of DKIM-controle koppelt aan het domein dat de ontvanger daadwerkelijk in het veld „Van:” ziet. Een bericht kan de SPF- of DKIM-controle voor een bepaald domein doorstaan, terwijl in de „Van:”-header toch uw domein wordt weergegeven. Afstemming dicht deze kloof door te eisen dat het geauthenticeerde domein overeenkomt met het „Van:”-domein.

Er zijn twee uitlijningsmodi:

• Bij ‘Relaxed alignment’ (de standaardinstelling) wordt een overeenkomst op het niveau van het organisatiedomein geaccepteerd, zodat mail.example.com overeenkomt met example.com.
• Voor een strikte uitlijning is een exacte overeenkomst vereist.

Zonder afstemming zou een aanvaller de SPF-controle kunnen omzeilen door een domein te gebruiken waarover hij de controle heeft, en toch uw „From:”-adres kunnen vervalsen. Dat is precies de maas in de wet die met DMARC moest worden gedicht.

Lees meer over de twee soorten afstemming, wat je moet configureren en wanneer, in onze DMARC-afstemmingsgids.

DMARC, SPF en DKIM: hoe ze samenwerken

DMARC is geen vervanging voor SPF en DKIM; het is juist afhankelijk van deze protocollen. De drie protocollen pakken elk een ander aspect van het authenticatieprobleem aan, en DMARC brengt ze met elkaar in verband.

Lees meer over de afzonderlijke protocollen in onze handleiding over DMARC, SPF en DKIM.

Wat SPF doet

SPF (Sender Policy Framework) bepaalt welke IP-adressen en servers bevoegd zijn om e-mail namens uw domein te verzenden. De ontvangende server vergelijkt het ‘envelope-from’-adres (Return-Path) met uw gepubliceerde SPF-record. De beperking hiervan is dat SPF geen bescherming biedt voor de zichtbare ‘From:’-header die ontvangers daadwerkelijk lezen; een bericht kan dus door de SPF-controle komen terwijl er toch een vervalst ‘From:’-domein wordt weergegeven.

Wat DKIM doet

DKIM (DomainKeys Identified Mail) voegt aan elk bericht een cryptografische handtekening toe. Ontvangers verifiëren die handtekening aan de hand van een openbare sleutel in je DNS, waarmee ze bevestigen dat het bericht tijdens het verzenden niet is gemanipuleerd en het domein identificeren dat de handtekening heeft geplaatst. De beperking ervan: net als SPF kan DKIM een domein goedkeuren dat afwijkt van het domein dat in de From:-header wordt weergegeven, dus het voorkomt op zichzelf geen From:-spoofing.

Waarom DMARC zo belangrijk is

SPF en DKIM zijn afzonderlijke authenticatiemechanismen, maar geen van beide geeft de ontvanger aan wat hij moet doen als een controle mislukt, en geen van beide koppelt het resultaat aan het zichtbare From:-domein. DMARC vult de ontbrekende stukjes aan: het koppelt SPF en DKIM aan elkaar, vereist afstemming met het From:-domein, publiceert een handhavingsbeleid en schakelt rapportage in. Zonder DMARC kan spoofing nog steeds slagen, zelfs als zowel SPF als DKIM zijn geïmplementeerd.

Vergelijkingstabel: SPF vs DKIM vs DMARC

DMARC-beleidsregels: Geen, Quarantaine en Weigeren

Uw DMARC-beleid geeft ontvangende servers aan wat ze moeten doen met e-mail die niet voldoet aan de authenticatie- en afstemmingscriteria. Er zijn drie DMARC-beleidsniveaus, waarbij elk niveau een strengere handhaving inhoudt dan het vorige.

p=geen (Monitor)

Er worden geen handhavingsmaatregelen genomen; onbestelbare post wordt nog steeds bezorgd en er worden rapporten verstuurd, zodat u kunt zien wie er namens u post verstuurt. Dit is de juiste eerste stap bij elke nieuwe implementatie.

Opmerking inzake naleving: p=none voldoet niet aan de vereisten voor bulkverzenders van Gmail en Yahoo, noch aan de anti-phishingvereisten van PCI DSS v4.0, waarvan naleving wordt verwacht.

p = quarantaine (softe handhaving)

E-mail die niet wordt geaccepteerd, wordt naar de spam- of junkmap doorgestuurd in plaats van naar de inbox. Legitieme, geverifieerde e-mail ondervindt hier geen hinder van. Opmerking inzake naleving: de quarantaine voldoet aan de handhavingsverwachtingen van Gmail, Yahoo, Microsoft en PCI DSS v4.0.

p = afwijzen (volledige handhaving)

E-mail die niet wordt geaccepteerd, wordt direct geweigerd en komt nooit in de inbox of de spamfolder terecht. Dit is het hoogste beveiligingsniveau. Opmerking inzake naleving: ‘reject’ voldoet aan alle huidige vereisten. Eén kanttekening uit RFC 9989: voor domeinen waarvan de gebruikers berichten op mailinglijsten plaatsen, kan ‘p=quarantine’ een veiliger permanent beleid zijn, omdat mailinglijsten de authenticatie vaak op een zodanige manier verstoren dat legitieme e-mail wordt geweigerd.

Wat zijn DMARC-rapporten?

DMARC is het enige e-mailverificatieprotocol dat je inzichtgegevens verstrekt. Die rapporten zijn precies de reden waarom je DMARC op p=none moet instellen voordat je overgaat tot handhaving: ze laten je alle afzenders zien die e-mail versturen onder jouw domeinnaam, zodat je kunt controleren of al je legitieme afzenders de controle doorstaan voordat je iets gaat blokkeren.

Geaggregeerde rapporten (RUA)

Geaggregeerde rapporten zijn dagelijkse XML-overzichten die worden verzonden door elke ontvangende mailserver die e-mail van uw domein heeft verwerkt. Elk rapport bevat een overzicht van de verzendende IP-adressen, het aantal berichten, of SPF is geslaagd of mislukt, of DKIM is geslaagd of mislukt, het algemene DMARC-resultaat en de toegepaste afhandeling. Deze rapporten zijn van groot belang omdat u uw beleid niet veilig kunt aanpassen zonder deze informatie: u moet eerst controleren of elke legitieme afzender de controle doorstaat voordat u overgaat tot quarantaine of afwijzing. Het handmatig doorlezen van onbewerkte XML-bestanden is niet schaalbaar, dus gebruiken de meeste teams onze DMARC Report Analyzer om rapporten om te zetten in overzichtelijke dashboards.

Als je nog niet bekend bent met rapportage, bekijk dan onze stapsgewijze handleiding over het lezen van DMARC-rapporten voor een eenvoudig overzicht.

Storingsmeldingen (RUF)

Foutmeldingen (voorheen ‘forensische rapporten’ genoemd) zijn meldingen per bericht die worden verzonden wanneer een individuele e-mail niet voldoet aan de DMARC-vereisten. Ze zijn gedetailleerder dan geaggregeerde rapporten. Opmerking over privacy: Google, Microsoft en Yahoo versturen geen foutmeldingen meer; als uw domein er toch nog ontvangt, zijn deze afkomstig van kleinere providers. Neem de ruf=-tag alleen op in uw record als u een processor hebt ingesteld om deze te verwerken.

Waartegen biedt DMARC bescherming?

De belangrijkste taak van DMARC is om te voorkomen dat aanvallers e-mails versturen die lijken te zijn afkomstig van precies uw domein. Dit biedt bescherming tegen drie van de meest schadelijke soorten e-mailaanvallen.

E-mail spoofing

Bij een spoofing-aanval verstuurt iemand een e-mail die lijkt afkomstig te zijn van precies hetzelfde domein als het uwe, bijvoorbeeld [email protected]. DMARC met de instelling p=reject blokkeert deze berichten voordat ze een inbox bereiken, omdat ze de authenticatie- en afstemmingscontrole voor uw domein niet doorstaan.

Phishing-aanvallen

Phishing-e-mails doen zich voor als uw merk om klanten of medewerkers ertoe te verleiden hun inloggegevens of geld af te staan. Als DMARC wordt afgedwongen, kunnen aanvallers uw domein niet als afzender gebruiken, waardoor de meest overtuigende vorm van een phishing-e-mail wordt uitgeschakeld: een e-mail die echt lijkt te zijn afkomstig van u.

Compromittering van zakelijke e-mails (BEC)

Bij BEC-aanvallen doet de aanvaller zich voor als een CEO, CFO of vertrouwde leverancier om overschrijvingen of gevoelige gegevens te vragen. DMARC voorkomt BEC-aanvallen waarbij het exacte domein wordt misbruikt, waarbij de aanvaller uw echte domein nabootst. Let wel: het vervalsen van de weergavenaam, waarbij de zichtbare naam ‘Naam CEO’ luidt maar het onderliggende domein daar geen verband mee houdt, wordt niet door DMARC tegengehouden, omdat de aanvaller uw domein helemaal niet gebruikt.

Voordelen van de implementatie van DMARC

1. Voorkomt phishing en spoofing met exacte domeinnamen: het zich voordoen als een ander domein wordt geblokkeerd voordat de berichten de ontvangers bereiken, waardoor de meest overtuigende aanvallen op uw klanten en medewerkers worden uitgeschakeld.
2. Beschermt de reputatie van uw merk: klanten ontvangen geen frauduleuze e-mails meer die afkomstig lijken te zijn van uw bedrijf, waardoor het vertrouwen in uw merk behouden blijft.
3. Verbetert de afleverbaarheid van e-mails: geauthenticeerde e-mails worden door ontvangers als betrouwbaar beschouwd en komen vaker in de inbox terecht, terwijl niet-geauthenticeerde e-mails als ongewenst worden gemarkeerd.
4. Biedt volledig inzicht: in de geaggregeerde rapporten worden alle bronnen weergegeven die e-mail versturen vanuit uw domein, inclusief vergeten diensten en ongeautoriseerde afzenders.
5. BIMI inschakelen: Een beleid met p=quarantine of p=reject is een voorwaarde om uw BIMI-merklogo naast uw berichten weer te geven in ondersteunde inboxen.
6. Voldoet aan de nalevingsvereisten: DMARC op handhavingsniveau draagt bij aan de naleving van PCI DSS v4.0, de regels voor bulkverzenders van Google/Yahoo en Microsoft, en CISA BOD 18-01.

DMARC-nalevingsvereisten in 2026

Naleving is de belangrijkste reden geworden waarom organisaties DMARC implementeren. In de afgelopen twee jaar hebben de grote e-mailproviders en diverse toezichthouders DMARC van een ‘best practice’ tot een vereiste gemaakt. Cruciaal is dat `p=none` aan geen van de onderstaande vereisten voldoet, en dat handhaving (in quarantaine plaatsen of afwijzen) is wat zij verwachten.

Gmail en Yahoo (sinds februari 2024)

Sinds februari 2024 verplichten Gmail en Yahoo bulkverzenders – dat wil zeggen verzenders die 5.000 of meer berichten per dag versturen – om gebruik te maken van SPF, DKIM en een gepubliceerd DMARC-record. In november 2025 is Gmail overgegaan op het permanent weigeren van e-mail die niet aan deze eisen voldoet. Een p=none-record voldoet aan het absolute minimum om een DMARC-record te hebben gepubliceerd, maar pas de handhaving (quarantaine of weigering) biedt daadwerkelijke bescherming.

Microsoft Outlook (sinds mei 2025)

Microsoft is op 5 mei 2025 begonnen met het handhaven van authenticatievereisten voor bulkverzenders. E-mail met een hoog verzendvolume die de authenticatie niet doorstaat, wordt nu direct op SMTP-niveau geweigerd in plaats van naar de spamfolder te worden doorgestuurd. DMARC maakt deel uit van de authenticatievereisten van Microsoft voor verzenders van meer dan 5.000 berichten per dag.

PCI DSS v4.0 (vanaf maart 2025)

Vereiste 5.4.1 van PCI DSS v4.0.1 schrijft geautomatiseerde anti-phishingmechanismen voor, waaronder DMARC naast SPF en DKIM, voor organisaties die betaalkaartgegevens verwerken. Dit is op 31 maart 2025 verplicht geworden. Een p=none-record dat uitsluitend voor monitoring dient, voldoet hier niet aan; auditors verwachten een handhavingsbeleid.

CISA BOD 18-01 (Amerikaanse federale domeinen)

De Binding Operational Directive 18-01 (CISA BOD 18-01) van het Amerikaanse Cybersecurity and Infrastructure Security Agency (CISA) schrijft voor dat alle domeinen van de federale uitvoerende macht DMARC moeten implementeren met de instelling p=reject. Dit was het eerste overheidsvoorschrift dat een beleid op handhavingsniveau verplicht stelde, in plaats van louter de invoering ervan.

Raadpleeg onze uitgebreide handleiding over DMARC-nalevingsvereisten voor meer informatie over wereldwijde nalevingsvereisten en aanbevelingen.

De invoering van DMARC in 2026: belangrijke statistieken

Uit de statistieken van PowerDMARC over e-mailphishing en DMARC voor 2026 komt een duidelijk wereldwijd patroon naar voren: phishing blijft toenemen, het gebruik van DMARC groeit maar is nog lang niet algemeen ingeburgerd, en de meeste domeinen die DMARC wel toepassen, bereiken nooit het handhavingsniveau dat spoofing daadwerkelijk blokkeert.

• Slechts ongeveer 18% van de 10 miljoen meest bezochte domeinen ter wereld publiceert een geldig DMARC-record, en slechts zo’n 4% past een afwijzingsbeleid volledig toe (analyse uit het tweede kwartaal van 2025), waardoor de overgrote meerderheid van de domeinen kwetsbaar blijft voor spoofing en merkmisbruik.
• Van de domeinen die wel DMARC publiceren, gaan de meeste niet zo ver om dit daadwerkelijk af te dwingen: 68,2% gebruikt p=none, 12,1% gebruikt p=quarantine en slechts 19,6% hanteert een strikt p=reject-beleid.
• Ook de bereidheid tot handhaving is gering: slechts 25,5% van de afzenders met p=none is van plan om hun beleid binnen een jaar aan te scherpen, terwijl 61% aangeeft dat ze hun beleid alleen zullen aanpassen als een regelgeving of zakelijke noodzaak hen daartoe dwingt.
• De authenticatieverplichtingen hebben effect waar ze het meest nodig zijn: nadat Google en Yahoo eisen voor bulkverzenders hadden ingevoerd, meldde Google een daling van 65% in het aantal niet-geauthenticeerde berichten dat Gmail bereikte, met alleen al in 2024 265 miljard minder niet-geauthenticeerde berichten.
• Er staat veel op het spel: een gemiddeld datalek als gevolg van phishing kost ongeveer 4,88 miljoen dollar, en door „Business Email Compromise“ (BEC) zijn naar schatting 2,9 miljard dollar aan verliezen gemeld.

RFC 9989: De update van de DMARC-standaard voor 2026

In mei 2026 heeft RFC 9989 RFC 7489 vervangen als de DMARC-standaard; dit is de eerste grote update sinds de oorspronkelijke specificatie uit 2015. Aangezien bestaande records geldig blijven, is er geen migratie nodig. Domeineigenaren die verouderde tags gebruiken, kunnen echter overwegen hun records bij te werken om rekening te houden met de nieuwe aanpassingen.

Er is een aantal kleine praktische aanpassingen doorgevoerd aan de tags die je in een record kunt publiceren. Hieronder volgen enkele van de belangrijkste wijzigingen:

• pct= wordt niet meer ondersteund. De oude procentuele tag, waarmee ontvangers de opdracht kregen om je beleid slechts op een deel van de mislukte e-mails toe te passen, is verwijderd omdat deze zich bij verschillende providers onvoorspelbaar gedroeg.
• np= is toegevoegd om een apart beleid in te stellen voor niet-bestaande subdomeinen, die helemaal geen legitieme e-mail versturen. Hierdoor kun je e-mail van subdomeinen die aanvallers zouden kunnen verzinnen, weigeren zonder dat dit gevolgen heeft voor je actieve verzendende subdomeinen.
• t= is toegevoegd om aan te geven dat het om een test of een gefaseerde uitrol gaat, waardoor je op een overzichtelijkere, gestandaardiseerde manier naar volledige implementatie kunt toewerken dan met de verouderde pct=-tag het geval was.

Voor een volledig overzicht van de wijzigingen kun je onze handleiding over DMARC RFC 9989 raadplegen.

Beperkingen van DMARC: waartegen het geen bescherming biedt

DMARC is zeer effectief tegen spoofing waarbij het exacte domein wordt gebruikt, maar het is geen volledige oplossing tegen fraude, en het is goed om duidelijk te zijn over wat het niet dekt:

• Het biedt geen bescherming tegen aanvallen met op uw domein lijkende domeinnamen, waarbij een aanvaller een domein registreert dat er vergelijkbaar uitziet, zoals paypa1.com of paypal-secure.com, omdat DMARC op uw domein geen zeggenschap heeft over een ander domein.
• Dit voorkomt echter geen misbruik van de weergavenaam, waarbij de zichtbare naam van de afzender lijkt op die van uw merk, maar het onderliggende e-maildomein daar geen verband mee houdt.
• Het biedt geen oplossing voor gehackte legitieme accounts, omdat e-mail die vanaf een echt, gekaapt account wordt verzonden, correct wordt geauthenticeerd.

Voor bedreigingen die buiten het toepassingsgebied van DMARC vallen, kunt u onze Lookalike Domain Checker gebruiken om een onderzoek te starten naar lookalike-domeinen, typosquatting en homoglyph-aanvallen.

Aan de slag met DMARC

Je hoeft niets ingewikkelds in te stellen om aan de slag te gaan. Met de volgende stappen kun je meteen aan de slag:

1. Controleer uw SPF-, DKIM- en DMARC-records: Zoals eerder uitgelegd, moet voor DMARC ofwel SPF ofwel DKIM zijn geconfigureerd om te kunnen functioneren (bij voorkeur beide). Voordat u aan de slag gaat, moet u dus controleren of deze records aanwezig zijn. Voer uw domein in onze Domain Analyzer in om in één keer te controleren of u over bestaande SPF-, DKIM- en DMARC-records beschikt en wat uw huidige recordbeleid is.

2. Maak een record aan als je er nog geen hebt: gebruik onze DMARC Generator-tool om een geldige syntaxis te genereren en publiceer het record in je DNS om het protocol te activeren. Stel je beleid in het begin altijd in op „none“ en schakel pas geleidelijk over naar handhaving zodra je zeker bent van je afleverbaarheid.

3. Voeg een record toe aan je DNS: Open je DNS-beheerconsole en publiceer het DMARC-record onder _dmarc.jouwdomein.com als een TXT-record.

4. Controleer met de DMARC-checker: Controleer ten slotte, na 24 uur, uw domein via onze DMARC-checker om na te gaan of uw gepubliceerde record geldig en foutloos is.

Voor een volledige handleiding over het instellen van DMARC kun je de blog via de link raadplegen voor een gedetailleerde stapsgewijze uitleg.

Laatste woorden

DMARC is uitgegroeid van een beveiligingsaanbeveling tot een basisvereiste. Het laat de wereld zien dat e-mail met uw domeinnaam daadwerkelijk van u afkomstig is, en het wordt steeds vaker verplicht gesteld door de e-mailproviders en toezichthouders waaraan uw bedrijf al verantwoording aflegt. Het protocol zelf is niet ingewikkeld: publiceer een record, bekijk uw rapporten en scherp uw beleid aan naarmate uw legitieme afzenders zich hierachter scharen. Het echte werk zit hem in de overstap van monitoring naar handhaving.

PowerDMARC is een full-stack DMARC-beheerplatform dat het hele proces van monitoring en handhaving voor u regelt, ruwe rapporten omzet in begrijpelijke inzichten en u helpt de status ‘p=reject’ te bereiken zonder legitieme e-mail te blokkeren.

Veelgestelde Vragen

Wat is DMARC?

Een DMARC-record is een DNS TXT-record dat wordt gepubliceerd op _dmarc.uwdomein.com. Het bevat uw DMARC-beleid en de e-mailadressen waarnaar rapporten moeten worden verzonden. Het aanmaken en publiceren van een DMARC-record is de eerste stap bij het implementeren van DMARC voor uw domein.

Is DMARC in 2026 verplicht?

Ja, voor bulkverzenders. Gmail en Yahoo stellen sinds februari 2024 DMARC verplicht voor domeinen die 5.000 of meer e-mails per dag versturen, en Microsoft is in mei 2025 begonnen met de handhaving hiervan. PCI DSS v4.0 schrijft sinds maart 2025 DMARC voor aan verwerkers van betaalkaartgegevens. Zelfs voor niet-bulkverzenders wordt DMARC sterk aanbevolen om uw domein tegen spoofing te beschermen.

Wat is het verschil tussen DMARC, SPF en DKIM?

SPF controleert welke IP-adressen e-mail mogen verzenden namens een domein. DKIM controleert de integriteit van berichten aan de hand van een cryptografische handtekening. DMARC koppelt beide aan elkaar, stemt ze af op het zichtbare „From:”-domein, voegt een handhavingsbeleid toe en maakt rapportage mogelijk. Alle drie zijn nodig voor volledige e-mailauthenticatie.

Wat voorkomt DMARC?

DMARC voorkomt e-mailspoofing met exact dezelfde domeinnaam, waarbij een aanvaller e-mails verstuurt die lijken afkomstig te zijn van uw domein. Dit omvat phishing-e-mails, het zich voordoen als een merk en Business Email Compromise (BEC). Het biedt geen bescherming tegen aanvallen met een op uw domein lijkend domein of tegen het vervalsen van de weergavenaam, waarbij een ander domein wordt gebruikt.

Wat gebeurt er als ik geen DMARC heb?

Zonder DMARC beschikken ontvangende servers niet over beleidsrichtlijnen voor e-mailberichten van uw domein die niet voldoen aan SPF en DKIM, waardoor uw domein vrijelijk kan worden misbruikt bij phishingaanvallen. Sinds 2024 heeft het ontbreken van DMARC ook gevolgen voor de afleverbaarheid van bulkverzenders, omdat Gmail en Yahoo uw legitieme e-mailberichten kunnen weigeren of lager rangschikken.

Voorkomt DMARC alle phishingaanvallen?

Nee. DMARC voorkomt phishing waarbij uw exacte domein wordt nagebootst, maar biedt geen bescherming tegen domeinen die op het uwe lijken, misbruik van de weergavenaam of aanvallen vanuit gehackte legitieme accounts. DMARC moet een onderdeel zijn van een bredere e-mailbeveiligingsstrategie en mag niet de enige maatregel zijn.

• Over
• Laatste berichten

Maitham Al Lawati

Cyberbeveiligingsexpert, CEO bij PowerDMARC

Maitham is een technisch ondernemer, cyberbeveiligingsexpert, CEO en oprichter van PowerDMARC met meer dan 15 jaar ervaring in de sector. Maitham heeft een Global MBA van de Universiteit van Manchester en diverse professionele certificeringen waaronder CISSP, CISM, CRISC en ISC2 CCSP.

Laatste berichten van Maitham Al Lawati (Bekijk alle berichten)

• DMARC instellen: volledige stapsgewijze configuratiehandleiding (2026) - 20 juni 2026
• Hoe DMARC-rapporten te lezen: een complete gids voor RUA en RUF - 10 juni 2026
• Wat is DMARC? Definitie, hoe het werkt en waarom het belangrijk is - 28 april 2026