Belangrijkste Conclusies
- Een DMARC-record is een DNS TXT-record dat wordt gepubliceerd op _dmarc.jouwdomein.com. Het geeft e-mailservers aan wat ze moeten doen met e-mails die de SPF- of DKIM-controles niet doorstaan.
- Je moet SPF of DKIM hebben ingesteld voordat je DMARC kunt toepassen. Controle met p=none werkt prima zonder deze protocollen, maar quarantaine of afwijzing werkt pas als ten minste één ervan slaagt.
- Om een DMARC-record te publiceren, voeg je bij je DNS-provider een TXT-record toe met de naam _dmarc. Het kan tot 48 uur duren voordat het record is doorgevoerd – controleer of het record actief is met behulp van een DMARC-checker of via dig/nslookup.
- De meeste DMARC-fouten komen neer op een paar simpele vergissingen: ontbrekende puntkomma’s, een verkeerd recordtype, publicatie op het hoofddomein in plaats van op _dmarc.yourdomain.com, of het hebben van twee records terwijl er maar één zou moeten zijn.
- Gmail, Yahoo en Microsoft eisen dat bulkverzenders DMARC naleven. Als u kaartbetalingen verwerkt, schrijft PCI DSS v4.0 bovendien anti-phishingmaatregelen voor.
Een DMARC-record is een DNS-TXT-record dat ontvangende mailservers aangeeft hoe ze e-mails moeten behandelen die de authenticatiecontroles niet doorstaan. In deze handleiding wordt stap voor stap uitgelegd hoe u uw DMARC-record aanmaakt, dit in de DNS van uw domein publiceert, controleert of het werkt en inzicht krijgt in de norm voor 2026 (RFC 9989) die nu het protocol regelt.
Of u nu voor het eerst e-mailverificatie instelt of uw DMARC-record bijwerkt om te voldoen aan de nalevingsvereisten voor 2025/2026, u kunt binnen 10 minuten een werkend DMARC-record genereren en publiceren. Deze handleiding is bedoeld voor IT-professionals, domeinbeheerders, MSP’s en compliance-managers.
Opmerking: DMARC is in mei 2026 bijgewerkt (RFC 9989). Alle voorbeelden van records in deze handleiding zijn in overeenstemming met de bijgewerkte norm.
Wat is een DMARC-record?
Een DMARC-record is een DNS TXT-record dat wordt gepubliceerd op _dmarc.uwdomein.com en dat ontvangende mailservers instrueert hoe ze moeten omgaan met e-mails die beweren afkomstig te zijn van uw domein, maar die de authenticatiecontroles niet doorstaan.
DMARC bouwt voort op twee bestaande protocollen voor e-mailverificatie:
- SPF (Sender Policy Framework): geeft bepaalde IP-adressen toestemming om e-mail te versturen vanuit uw domein
- DKIM (DomainKeys Identified Mail): ondertekent e-mails cryptografisch om aan te tonen dat ze afkomstig zijn van uw domein
Zonder DMARC is er geen beleid dat ontvangers voorschrijft wat ze moeten doen als SPF of DKIM faalt. Ze nemen dan zelf een beslissing, waardoor vervalste e-mails vaak toch worden doorgelaten.
De rol van DMARC bij e-mailauthenticatie
- SPF controleert het verzendende IP-adres door na te gaan of de server die deze e-mail verstuurt, is geautoriseerd door het SPF-record van het domein.
- DKIM controleert de handtekening door na te gaan of de digitale handtekening van de e-mail overeenkomt met de gepubliceerde DKIM-sleutel van het domein.
- DMARC bepaalt welke actie er wordt ondernomen als SPF en/of DKIM niet kloppen. Uw DMARC-beleid (en afstemmingsregels) geven de ontvanger de opdracht om de e-mail te weigeren, in quarantaine te plaatsen of toe te laten.
Voordat u het DMARC-record publiceert
Voor DMARC-records is het vereist dat ten minste SPF of DKIM is gepubliceerd en afgestemd is op uw verzenddomein. U kunt een DMARC-record met p=none (monitoring) publiceren zonder deze protocollen, maar voor handhaving (p=quarantine of p=reject) moet ten minste één protocol de controle doorstaan.
Snelle controles:
Anatomie van een DMARC-record
Een DMARC-record is een reeks tag-waardeparen die door puntkomma’s worden gescheiden. Er zijn slechts twee tags verplicht; al het overige is optioneel, maar wordt wel aanbevolen.
Actieve tags
| Een label | Doel | Toegestane waarden | Een Voorbeeld | Vereiste |
|---|---|---|---|---|
| v | DMARC-versie | DMARC1 | v=DMARC1 | Vereist |
| p | DMARC-beleid | geen, quarantaine, afwijzen | p=geen | Vereist |
| sp | Beleid inzake subdomeinen | geen, quarantaine, afwijzen | sp=afwijzen | Optioneel |
| np | Beleid inzake niet-bestaande subdomeinen | geen, quarantaine, afwijzen | np=afwijzen | Optioneel |
| rua | Samenvattend rapport per e-mail | Geldig e-mailadres | rua=mailto:[email protected] | Aanbevolen |
| ruf | E-mail met storingsmelding | Geldig e-mailadres | ruf=mailto:[email protected] | Optioneel |
| psd | Vlag voor domeinen met een openbaar achtervoegsel | y (ja)/n (nee)/u (onbekend) | psd=y | Optioneel |
| t | Testmodus | y (ja) | t = y | Optioneel |
| adkim | DKIM afstemmingsmodus | r (soepel)/s (streng) | adkim=r | Optioneel |
| aspf | SPF uitlijnmodus | r (soepel)/s (streng) | aspf=s | Optioneel |
| fo | Opties voor storingsmeldingen | 0, 1, d, s | fo=1 | Optioneel |
Opmerking over psd=: Deze tag is in de eerste plaats bedoeld voor Public Suffix Operators (PSO’s), zoals registries van landcode-domeinen of gTLD-beheerders. De meeste gewone domeineigenaren kunnen deze tag beter helemaal weglaten. Hij is alleen relevant als uw domein een openbaar achtervoegsel is, zoals .gov.uk of .bank.
Opmerking over ruf= De belangrijkste ontvangers (Google, Microsoft, Yahoo) sturen geen foutmeldingen meer.
Verouderde tags
In RFC 9989 zijn drie tags afgeschaft of verwijderd die tot inconsistenties in de implementatie leidden:
| Een label | Wat het was | Waarom verouderd | Actie |
|---|---|---|---|
| pct | Percentage e-mails waarop het beleid van toepassing is | Wordt niet consistent geïmplementeerd in de verschillende ontvangers, wat leidt tot onvoorspelbare resultaten | Verwijder dit uit nieuwe records. Gebruik in plaats daarvan t=y om de testmodus aan te geven. |
| ri | Rapportformaat | Er is maar één waarde (afrf) ooit gebruikt; overbodig | Bij het bewerken uit bestaande records verwijderen. |
| rf | Rapportinterval (in seconden) | De receivers negeerden het tijdens de training | Bij het bewerken uit bestaande records verwijderen. |
Opmerking: Als je bestaande records deze tags bevatten, werken ze nog steeds, aangezien ontvangers ze gewoon negeren. Maar wanneer je je record de volgende keer bewerkt, kun je ze verwijderen om aan RFC 9989 te voldoen, en neem ze niet op bij het publiceren van nieuwe records.
Vergelijking van DMARC-beleidsregels
| Beleid | Werking van de ontvanger | Beveiligingsniveau | Vereisten voor ESP-bulkverzenders | Wanneer te gebruiken |
|---|---|---|---|---|
| geen | Alleen controleren; geen afkeuring | Geen | Aanvaardbaar | Eerste implementatie; verkeersmonitoring |
| quarantaine | Naar de spam-/junkmap verplaatsen | Matig | Voldoet aan de vereisten | Voor een geleidelijke invoering |
| weiger | Volledig blokkeren en weigeren | Hoog | Voldoet aan de vereisten | Zodra men er zeker van is dat de volledige handhaving kan worden ingezet. |
Voorbeelden van DMARC-records
Alle onderstaande voorbeelden zijn in overeenstemming met RFC 9989, aangezien verouderde tags zijn weggelaten en waar van toepassing nieuwe tags zijn opgenomen.
Voorbeeld 1: Bewakingsmodus (begin hier)
v=DMARC1; p=none; rua=mailto:[email protected]
Gebruiksscenario: Eerste DMARC-configuratie. Geen handhaving. Dagelijks worden geaggregeerde rapporten verzonden om de authenticatieresultaten bij te houden.
Wat elke tag doet:
- v=DMARC1 Geeft aan dat dit een DMARC-record is
- p=geen Geen actie ondernemen; alleen in de gaten houden
- rua= mailto:[email protected] Stuur dagelijkse rapporten naar dit e-mailadres
Voorbeeld 2: Gedeeltelijke tenuitvoerlegging (overgangsregeling)
v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:[email protected]
Toepassingsvoorbeeld: Op weg naar handhaving. E-mails die niet binnenkomen in quarantaine plaatsen. Strenger beleid voor niet-bestaande subdomeinen.
Wat is er nieuw:
- sp=quarantaine Subdomeinen nemen het quarantainebeleid over
- np=reject Niet-bestaande subdomeinen worden afgewezen (RFC 9989-beveiliging)
Voorbeeld 3: Volledige handhaving
v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]
Gebruiksscenario: Volledige handhaving in de productieomgeving. Alle e-mails die niet aan de eisen voldoen, worden afgewezen. Het domein biedt geen ruimte aan mailinglijsten.
Voorbeeld 4: Domein dat geen e-mail verstuurt / geparkeerd domein
v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s
Toepassingsgeval: een domein dat geen e-mail verstuurt, maar wel bescherming nodig heeft tegen spoofing.
Wat is er anders:
- adkim=s; aspf=s Strikte uitlijning (geen ‘relaxed’-modus nodig)
- No rua= Geen rapporten (domein verstuurt geen rapporten)
- np=reject Zelfs niet-bestaande subdomeinen wijzen vervalste e-mails af
Zelfs inactieve domeinen moeten worden beveiligd, aangezien aanvallers ongebruikte domeinen kunnen misbruiken in phishingcampagnes.
Voorbeeld 5: Subdomein met strengere regels
Hoofddomein: v=DMARC1; p=quarantine; rua=mailto:[email protected]
Subdomein (marketing.yourdomain.com): v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]
Gebruiksscenario: Het hoofddomein staat quarantaine toe (heeft e-mail doorgestuurd). Het marketing-subdomein is een speciale afzender; pas p=reject toe.
Voorbeeld 6: Microsoft 365 / Google Workspace
v=DMARC1; p=reject; rua=mailto:[email protected]
Opmerking: Voor Microsoft 365 of Google Workspace is geen specifieke DMARC-syntaxis vereist. Het record wordt net als bij elke andere DMARC-implementatie in DNS gepubliceerd. Controleer, voordat u de regels gaat handhaven, de SPF- en DKIM-configuratie voor alle verzendbronnen.
Voor een uitgebreide handleiding kun je onze handleidingen voor het instellen van DMARC in Microsoft 365 en Google Workspace raadplegen.
Hoe maak je een DMARC-record aan?
Methode 1: De gratis generator van PowerDMARC gebruiken
1. Ga naar de DMARC Record Generator
2. Selecteer het gewenste handhavingsniveau (Geen / Controle, Quarantaine, Weigeren)
3. Voer je domeinnaam en het e-mailadres voor rapportages in
4. Schakel het subdomeinbeleid in en bescherm desgewenst niet-bestaande subdomeinen (optioneel)
5. Klik op ‘Genereren’
6. DMARC-record aangemaakt
Methode 2: Handmatig aanmaken
Open een teksteditor en typ het record met de hand in:
v=DMARC1; p=none; rua=mailto:[email protected]
Begin met p=none (monitoring). Je kunt het beleid later aanpassen zodra je inzicht hebt in je e-mailverkeer.
Vereist:
- v=DMARC1 (altijd)
- p= (uw beleid: geen, in quarantaine plaatsen of weigeren)
- rua= (je e-mailadres voor rapportage)
Hoe publiceer je een DMARC-record – stap voor stap via je DNS-provider
De DNS-instellingen van je domein worden beheerd door je domeinregistrar (GoDaddy, Namecheap, enz.), je webhostingprovider (cPanel) of je CDN (Cloudflare). Log daar in en volg de onderstaande stappen voor jouw provider.
Algemene stappen (als uw zorgverlener niet in de lijst staat):
1. Zoek de DNS-beheerconsole
2. Klik op het domein waarvoor u DMARC wilt configureren
3. Maak een nieuw TXT-record aan
4. Naam van het record: _dmarc (of _dmarc.jouwdomein.com als in het formulier de volledige hostnaam moet worden opgegeven)
5. Recordwaarde: plak de tekst van je DMARC-record
6. Sla op en wacht tot de wijzigingen zijn doorgevoerd (24-48 uur)
7. Gebruik de DMARC-checker om te controleren
DMARC-record publiceren op GoDaddy
1. Log in op je GoDaddy-domeinportfolio
2. Klik op ‘DNS’ naast je domein
3. Blader naar DNS-records
4. Klik op ‘Nieuw record toevoegen’
5. Type: TXT
6. Naam: _dmarc
7. Waarde: plak je DMARC-record
8. Klik op ‘Opslaan’
DMARC-record publiceren op Cloudflare
1. Log in op je Cloudflare-dashboard
2. Kies je domein
3. Ga naar DNS > Records
4. Klik op ‘Record toevoegen’
5. Type: TXT
6. Naam: _dmarc
7. Inhoud: plak je DMARC-record
8. TTL: Auto (of 3600)
9. Proxy-status: alleen DNS (geen proxy)
10. Klik op ‘Opslaan’
Opmerking: Stel de proxystatus in op „Alleen DNS“ (grijze wolk), niet op oranje. DMARC moet rechtstreeks bij de DNS worden opgevraagd, niet via Cloudflare.
DMARC-record publiceren in cPanel / WHM
1. Log in op je cPanel-account
2. Ga naar de Zone-editor (onder ‘Domeinen’)
3. Klik op ‘Beheren’ naast je domein
4. Klik op + Nieuw record toevoegen
5. Type: TXT
6. Naam: _dmarc.uwdomein.com
7. Waarde (TXT-gegevens): plak je DMARC-record
8. Klik op ‘Een record toevoegen’
DMARC-record publiceren op Namecheap
1. Log in op je Namecheap-account
2. Ga naar Dashboard > Domeinlijst
3. Klik op ‘Beheren’ naast je domein
4. Ga naar Geavanceerde DNS
5. Klik op ‘Nieuw record toevoegen’
6. Type: TXT-record
7. Gastheer: _dmarc
8. Waarde: plak je DMARC-record
9. TTL: Automatisch (3600)
10. Klik op het vinkje om op te slaan
DMARC-record publiceren op Amazon Route 53
1. Log in op de AWS Management Console > Route 53
2. Ga naar ‘Hosted zones’ en selecteer je domein
3. Klik op ‘Record aanmaken’
4. Naam van het record: _dmarc
5. Recordtype: TXT
6. Waarde: plak je DMARC-record tussen dubbele aanhalingstekens
- Voorbeeld: „v=DMARC1; p=none; rua=mailto:[email protected]”
- In Route 53 zijn aanhalingstekens vereist; zonder deze worden de gegevens niet opgeslagen
7. TTL: 300 (of 3600)
8. Klik op ‘Records aanmaken’
Opmerking: Bij Route 53 moeten de waarden van TXT-records tussen dubbele aanhalingstekens worden geplaatst. Kopieer en plak je record precies zoals het is, en plaats het vervolgens tussen “…”.
DMARC-record publiceren op Microsoft 365 / Azure DNS
Als uw DNS wordt beheerd in Azure DNS:
1. Meld je aan bij de Azure Portal > DNS-zones
2. Kies je domein
3. Klik op + Recordset
4. Naam: _dmarc
5. Type: TXT
6. TTL: 3600
7. Waarde: plak je DMARC-record
8. Klik op OK
Als je DNS bij een domeinregistrar staat (GoDaddy, Namecheap, enz.):
- Volg de bovenstaande stappen van de registrar
Hoe lang duurt het voordat een DMARC-record is doorgevoerd?
DNS-wijzigingen worden geregeld door een instelling die TTL (Time To Live) heet; deze geeft aan hoe lang servers een DNS-record in de cache moeten bewaren voordat ze controleren of er updates zijn. De meeste DNS-providers stellen de TTL standaard in op 3600 seconden (1 uur).
Gebruikelijke tijdsduur:
- Op de meeste locaties wordt de DNS-wijziging binnen 1–2 uur doorgevoerd
- In zeldzame gevallen kan het tot 48 uur duren voordat de wijziging wereldwijd is doorgevoerd
- Raak niet in paniek als je DMARC-checker in het eerste uur ‘geen record’ aangeeft; wacht minstens 30-60 minuten en probeer het dan opnieuw
Controleer de verspreiding wereldwijd: gebruik onze DNS Propagation Checker om te controleren of je record op meerdere wereldwijde DNS-servers actief is.
Hoe controleer je of je DMARC-record werkt?
Methode 1: PowerDMARC DMARC Checker-tool
1. Ga naar de DMARC Record Checker
2. Voer je domeinnaam in
3. Klik op ‘Controleren’
4. Uit de resultaten blijkt:
- Geldig: het record is correct opgemaakt en gepubliceerd
- Ongeldig: Syntaxisfout; controleer je gegevens
- Geen record gevonden: Controleer de DNS-propagatie of ga na of het record in de DNS is opgeslagen
Methode 2: Opdrachtregel (nslookup of dig)
In Windows (opdrachtprompt):
nslookup -type=TXT _dmarc.jouwdomein.com
Op Mac/Linux (Terminal):
dig TXT _dmarc.jouwdomein.com
Succesvolle uitvoer:
_dmarc.jouwdomein.com. 3600 IN TXT “v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]”
Als je geen resultaten ziet, is de DNS-wijziging nog niet doorgevoerd of is het record niet correct opgeslagen.
Methode 3: Controleer de e-mailheader (Authentication-Results)
Stuur een test-e-mail en controleer de headers.
Stappen:
1. Stuur jezelf een testmail vanaf je domein (of vraag iemand van een ander bedrijf om je een e-mail te sturen)
2. In Gmail:
- Open de e-mail
- Klik op het menu met de drie puntjes (⋮) > Origineel weergeven
- Zoeken naar authenticatieresultaten
3. In Outlook:
- Open de e-mail
- Klik op Bestand > Eigenschappen > Internetkoppen
- Zoeken naar authenticatieresultaten
Waar je op moet letten:
✅ DMARC-test geslaagd:
Authenticatieresultaten: mx.google.com;
dmarc=geslaagd (p=REJECT sp=REJECT np=REJECT dis=NONE) header.from=yourdomain.com
❌ DMARC-fout:
Authenticatieresultaten: mx.google.com;
dmarc=fail (p=REJECT sp=REJECT) header.from=yourdomain.com reden=”SPF komt niet overeen”
Wat ‘geslaagd’ betekent: je SPF- of DKIM-handtekening komt overeen met het domein in de ‘From’-header en je DMARC-beleid is toegepast.
Wat ‘fail’ betekent: SPF of DKIM is mislukt of kwam niet overeen. Controleer je SPF-record en DKIM-configuratie.
Wanneer kunt u uw eerste DMARC-rapport verwachten?
De geaggregeerde rapporten worden binnen 24 tot 72 uur na publicatie van uw gegevens verzonden.
Wat het rapport bevat:
- Dagelijks overzicht van alle e-mails die vanaf uw domein zijn verzonden
- Verificatieresultaten (SPF geslaagd/mislukt, DKIM geslaagd/mislukt, DMARC geslaagd/mislukt)
- Het verzenden van IP-adressen en het aantal daarvan
- Herkomstlanden
- Maatregelen ter handhaving van het beleid die door curatoren zijn genomen
Wat is er veranderd in RFC 9989 met betrekking tot DMARC-records?
In mei 2026 heeft RFC 9989 RFC 7489 vervangen als de officiële DMARC-standaard. Uw bestaande record werkt nog steeds. Dit zijn de belangrijkste wijzigingen voor nieuwe records:
Drie nieuwe tags toegevoegd:
- np= (beleid voor niet-bestaande subdomeinen): Voeg np=reject of np=quarantine toe om niet-bestaande subdomeinen te beveiligen. Vóór RFC 9989 konden aanvallers willekeurige subdomeinen zonder DMARC-records vervalsen. Nu kun je hiervoor op het niveau van het bovenliggende domein een beleid instellen. De meeste domeineigenaren zouden dit moeten toevoegen.
- t= (vlag voor testmodus): Gebruik t=y om aan te geven dat je beleid zich in de testmodus bevindt. Ontvangers behandelen p=reject; t=y als p=quarantine (één stap minder streng), waardoor een veilige gefaseerde uitrol mogelijk is. Vervangt de oude pct=-tag.
- psd= (vlag voor domeinen met een openbaar achtervoegsel): Geeft aan of een domein een openbaar achtervoegsel is (zoals .gov.uk of .bank). Dit is alleen relevant voor beheerders van openbare achtervoegsels en complexe domeinhiërarchieën. De meeste domeineigenaren kunnen dit negeren.
Verouderde/verwijderde tags:
- pct= wordt niet meer aanbevolen. Ontvangers hebben dit op inconsistente wijze geïmplementeerd. Gebruik in plaats daarvan t=y voor gefaseerde uitrol.
- rf= en ri= zijn verwijderd. Verwijder ze als ze in uw bestaande records voorkomen. Ontvangers negeren ze toch al.
Raadpleeg onze DMARC RFC 9989 -gids voor meer informatie over de wijzigingen in RFC 9989.
Momenteel geldende nalevingsvereisten
| Vereiste | Status | Deadline | Actie |
|---|---|---|---|
| Permanente afwijzing door Gmail | Actief | feb 2024 | DMARC-publicatie is verplicht; p=none is aanvaardbaar als uitgangspunt, met de verwachting dat dit voor bulkverzenders (5.000+ berichten/dag) wordt aangepast naar p=quarantine of p=reject |
| Definitieve afwijzing door Yahoo | Actief | feb 2024 | DMARC-publicatie is verplicht; p=none is aanvaardbaar als uitgangspunt, met de verwachting dat dit voor bulkverzenders (5.000+ berichten/dag) wordt aangepast naar p=quarantine of p=reject |
| Handhaving van Microsoft Outlook | Actief | Mei 2025 | DMARC-handhaving in combinatie met SPF en DKIM is verplicht voor bulkverzenders naar Outlook.com, Hotmail.com en Live.com |
| PCI-DSS versie 4.0 | Actief | Maart 2025 | Alle entiteiten die gegevens van kaarthouders verwerken, moeten anti-phishingmaatregelen treffen. |
Lees meer over lokale en wereldwijde vereisten in onze uitgebreide gids over DMARC-vereisten.
Veel voorkomende DMARC recordfouten
1. Er is geen DMARC-record gevonden
Oorzaak: Je hebt geen DMARC-record voor je domein gepubliceerd, het is verkeerd geconfigureerd of de DNS-propagatietijd is nog niet voltooid
Oplossing: Zodra u hebt gecontroleerd dat er geen record in uw DNS staat, logt u in op uw DNS-beheerconsole om een nieuw record aan te maken. Als er al een record bestaat, bewerk dan het bestaande record om fouten of verkeerde instellingen te verwijderen. Als de propagatietijd van 48 uur nog niet is verstreken, wacht dan even voordat u het opnieuw controleert.
2. Syntaxfouten
Veelgemaakte fouten:
- Ontbrekende puntkomma’s: Elke tag moet worden gevolgd door een puntkomma.
- Extra spaties: Vermijd spaties na puntkomma’s of rondom
- Onjuiste versie: moet v=DMARC1 zijn, niet v=DMARC2 of version=1
- Ongeldige tag-namen: typefouten zoals po=reject in plaats van p=reject
Dubbele DMARC-records
Oorzaak: Je mag slechts één DMARC TXT-record per domein hebben. Als je meerdere records hebt, lezen ontvangers alleen het eerste record dat ze tegenkomen. Dit kan leiden tot onverwacht gedrag van het beleid.
Oplossing: Zorg ervoor dat je dubbele records onder hetzelfde domein verwijdert, of voeg records indien nodig samen.
Gebruik het commando: nslookup -type=TXT _dmarc.yourdomain.com of gebruik een DMARC-controleprogramma. Als u twee of meer DMARC-records ziet, verwijder dan onmiddellijk de dubbele records.
Onjuiste naam of type van DNS-record
Oorzaak: De naam of het type van je DNS-record is ongeldig; er is bijvoorbeeld een MX-record geconfigureerd in plaats van een TXT-record voor DMARC.
Oplossing:
- Recordtype: TXT (niet A, CNAME, MX, enz.)
- Naam van het record: _dmarc (sommige DNS-providers voegen je domeinnaam automatisch toe; bij andere moet je _dmarc.jouwdomein.com opgeven)
Veelgemaakte fouten:
- Een DMARC-record toevoegen als A- of CNAME-record
- Publiceren op het hoofddomein (jouwdomein.com) in plaats van op _dmarc.jouwdomein.com
- Typefouten zoals _dmrc of dmarc (ontbrekende onderstreping)
Controleer je DNS-beheerprogramma om de exacte naam en het type te verifiëren.
Heb je meer hulp nodig? Volledige handleiding voor het oplossen van problemen
Voor problemen met SPF/DKIM-afstemmingsfouten, fouten bij externe afzenders of legitieme e-mails die in de spamfolder terechtkomen, raadpleeg je de volledige DMARC-oplossingsgids.
DMARC-records voor domeinen die geen e-mail verzenden en geparkeerde domeinen
Zelfs als uw domein geen e-mail verstuurt, kunnen aanvallers het domein vervalsen om phishingberichten naar uw klanten te sturen. Bescherm inactieve en geparkeerde domeinen met een restrictief DMARC-record.
Aanbevolen record voor een domein dat geen e-mails verstuurt
v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s
Wat dit doet:
- p=afwijzen; sp=afwijzen; np=afwijzen: alle ongeautoriseerde e-mails afwijzen
- adkim=s; aspf=s: Strikte afstemming vereist (geen soepele afstemming)
- No rua=: Rapporten worden niet gecontroleerd (domein verstuurt geen rapporten)
Waarom domeinen die geen e-mails versturen het doelwit zijn
Aanvallers kunnen domeinen registreren die op uw domeinen lijken, of inactieve domeinen in uw portfolio misbruiken. Een geparkeerd domein zonder DMARC-record lijkt een gemakkelijk doelwit voor spoofing. Door overal p=reject in te stellen, voorkomt u:
- Phishing-e-mails die zijn verzonden vanaf uw „company.old“- of „company.test“-domeinen
- Reputatieschade
- Onopgemerkt misbruik (als er geen aangifte wordt gedaan, zou je nooit weten dat het is gebeurd)
Volgende stappen na het publiceren van DMARC
De instelling ‘p=none’ (monitoringmodus) biedt geen bescherming en dient uitsluitend voor het verzamelen van gegevens. Om uw domein te beschermen tegen spoofing en phishing, moet u stapsgewijs overgaan op handhaving.
Driefasige aanpak:
- Monitoren (p=geen): Bekijk de DMARC-rapporten gedurende 1-2 weken. Breng alle legitieme afzenders en derde partijen in kaart die namens u berichten versturen (SaaS-tools, marketingplatforms, ticketsystemen).
- Overgangsfase (p = quarantaine): Verplaats verdacht verkeer naar de spamfolder. Houd deze fase 1 tot 4 weken aan en houd daarbij het aantal meldingen in de gaten. Als legitieme e-mail in quarantaine terechtkomt, heb je een afzender gevonden die een SPF- of DKIM-configuratie nodig heeft.
- Afdwingen (p=afwijzen): Ongeautoriseerde e-mails volledig afwijzen. Ga hier pas toe over nadat is gecontroleerd of alle legitieme afzenders in orde zijn.
DMARC op grote schaal beheren voor meerdere domeinen
Als u meerdere domeinen beheert, is het één voor één bewerken van DNS-records tijdrovend en foutgevoelig. De Hosted DMARC-oplossing van PowerDMARC automatiseert het beheer van records voor uw gehele domeinportfolio.
Voordelen:
- Beheer een onbeperkt aantal domeinen vanuit één dashboard
- Bulk-beleidsupdates (p=reject in één keer doorvoeren voor 50 domeinen)
- AI-gestuurde dreigingsinformatie detecteert pogingen tot spoofing
- Een zorgvuldige onboarding en deskundige ondersteuning
Lees meer over Hosted DMARC.
Veelgestelde Vragen
1. Heb ik DMARC nodig als ik al SPF en DKIM heb?
Ja. SPF en DKIM zijn afzonderlijke authenticatiemechanismen, maar zonder DMARC is er geen beleid dat ontvangers voorschrijft wat ze moeten doen als die controles mislukken. DMARC maakt bovendien geaggregeerde rapportage mogelijk; zonder DMARC heb je geen inzicht in wie er e-mail verstuurt vanuit jouw domein.
2. Wat gebeurt er als ik geen DMARC-record heb?
Zonder DMARC nemen ontvangende servers zelf beslissingen over niet-geverifieerde e-mail, waardoor uw domein kwetsbaarder wordt voor spoofing en phishing. Verschillende e-maildienstverleners (ESP’s) eisen DMARC voor bulkverzenders, en het ontbreken hiervan kan de afleverbaarheid aanzienlijk schaden.
3. Is DMARC automatisch van toepassing op subdomeinen?
Subdomeinen nemen het DMARC-beleid van het bovenliggende domein over, tenzij dit wordt overschreven. Gebruik de sp=-tag om een ander beleid in te stellen voor bestaande subdomeinen, en de np=-tag (nieuw in RFC 9989) om het beleid in te stellen voor nog niet-bestaande subdomeinen. Het instellen van sp=reject terwijl p=quarantine behouden blijft, is een veelvoorkomend patroon voor strengere bescherming van subdomeinen.
4. Is DMARC vereist voor naleving van PCI DSS v4.0?
PCI DSS v4.0, dat in 2025 volledig van kracht is geworden, schrijft anti-phishingmaatregelen voor aan organisaties die betaalkaartgegevens verwerken. Hoewel DMARC niet expliciet vereist is om aan de voorschriften te voldoen, kan de implementatie ervan u helpen om aan de vereisten te voldoen.

