Waarom werkt DMARC niet? Oorzaken, oplossingen en hoe je dit kunt controleren

Waarom mislukt DMARC op uw domein? In bijna alle gevallen komt het neer op een van de volgende twee zaken: SPF of DKIM komt niet overeen met uw zichtbare ‘Van’-adres, of een externe afzender is nog niet geautoriseerd. In deze handleiding worden beide situaties behandeld, en wordt bovendien uitgelegd hoe u kunt vaststellen of recente wijzigingen in het handhavingsbeleid van Google, Yahoo of Microsoft de werkelijke oorzaak zijn van uw DMARC-fouten, en hoe u een fout zelf kunt controleren voordat u wijzigingen doorvoert.

Waarom werkt DMARC niet? Het korte antwoord

DMARC mislukt wanneer noch SPF noch DKIM het bericht verifieert en overeenkomt met het zichtbare „From“-domein. Om te slagen, vereist DMARC dat ofwel SPF ofwel DKIM voldoet aan de domeinovereenstemming. Wanneer geen van beide overeenkomt, leidt dit automatisch tot een DMARC-fout. In sommige gevallen, wanneer een domein is geconfigureerd met alleen SPF of DKIM in combinatie met DMARC (en niet beide), zal DMARC mislukken wanneer de SPF/DKIM-overeenstemming voor dat bericht niet klopt, zelfs als de verificatie wel slaagt.

Wat betekent een DMARC-fout?

Er is sprake van een DMARC-fout wanneer een e-mail de DMARC-controle zelf niet doorstaat. Dit gebeurt wanneer noch SPF, noch DKIM op een afgestemde manier kan verifiëren dat de e-mail daadwerkelijk vanaf uw domein is verzonden. ‘Verifiëren’ en ‘afstemmen’ zijn hier twee verschillende taken, en het door elkaar halen ervan is de bron van de meeste verwarring.

SPF kan slagen en DMARC kan toch mislukken – hier is waarom

Stel dat je marketingplatform e-mails verstuurt via zijn eigen ‘return-path’-domein, mail.esp-provider.com. SPF controleert dat domein en keurt het goed; het verzendende IP-adres is geautoriseerd om namens mail.esp-provider.com te verzenden. Maar je zichtbare ‘Van’-adres is yourdomain.com. DMARC controleert niet alleen of SPF ergens is geslaagd, maar ook of het domein dat de SPF-controle heeft doorstaan, overeenkomt met het zichtbare ‘Van’-domein. mail.esp-provider.com komt niet overeen met yourdomain.com. Dus SPF is geslaagd, maar DMARC mislukt nog steeds.

Dezelfde logica geldt voor DKIM. Een bericht kan een geldige, cryptografisch geverifieerde DKIM-handtekening bevatten, maar als het d=domein in die handtekening (het ondertekenende domein) niet overeenkomt met uw zichtbare ‘Van’-domein, behandelt DMARC het als niet-afgestemd en mislukt de controle, ook al is de handtekening zelf volkomen geldig. Dit is de meest voorkomende oorzaak van de verwarring rond ‘SPF en DKIM geven beide een positieve uitslag’, en daarom is afstemming, en niet alleen authenticatie, het eerste wat u moet controleren.

Veelvoorkomende oorzaken van DMARC-fouten

De meeste DMARC-fouten zijn te wijten aan een verkeerde configuratie ergens in uw verzendinfrastructuur, en niet aan een daadwerkelijke aanval. Hieronder volgt een overzicht van hoe SPF- en DKIM-fouten van invloed zijn op DMARC:

1. SPF-fout

SPF faalt om een aantal specifieke, goed gedocumenteerde redenen:

• Overschrijding van de limiet van 10 DNS-lookups: SPF staat maximaal 10 DNS-lookups per controle toe. Zodra een domein via meerdere platforms verstuurt (bijvoorbeeld een CRM-systeem, een e-mailmarketingtool en interne e-mailservers), die elk hun eigen opname-mechanisme hebben, wordt die limiet al snel bereikt. Wanneer deze limiet wordt overschreden, mislukt SPF volledig, vaak zonder duidelijke waarschuwing totdat e-mails worden teruggestuurd.
• Een ontbrekende SPF-verwijzing voor een verzenddienst: als je een nieuw verzendplatform toevoegt en vergeet de bijbehorende SPF-verwijzing toe te voegen, zal e-mail van dat platform telkens de SPF-controle niet doorstaan.
• Meerdere SPF-records op één domein: DNS staat slechts één SPF-record per domein toe. Als er twee zijn, kunnen de meeste ontvangende servers niet bepalen welke ze moeten vertrouwen en zal de controle mislukken.
• Syntaxfouten: extra spaties, onjuist opgebouwde constructies of een record in de verkeerde volgorde kunnen het geheel ongeldig maken.

Lees meer over waarom SPF faalt.

2. DKIM-fout

DKIM-fouten zijn meestal terug te voeren op een van de volgende drie oorzaken:

• Verlopen of vernieuwde sleutels die nooit in het DNS zijn bijgewerkt: DKIM-sleutels zijn niet permanent. Als een sleutel aan de verzendende kant wordt vernieuwd, maar de nieuwe openbare sleutel niet in het DNS wordt gepubliceerd, wordt elke handtekening tegen de verkeerde sleutel gecontroleerd en mislukt de validatie.
• Een ontbrekende of onjuiste selector: De selector geeft aan ontvangende servers door welk DNS-record de openbare sleutel voor een bepaalde handtekening bevat. Als je de selector verkeerd invoert, mislukt de DKIM-verificatie, zelfs als de sleutel zelf in orde is.
• Handtekeningen worden ongeldig verklaard als het bericht na het ondertekenen wordt gewijzigd: DKIM ondertekent specifieke headers en de inhoud van de body. Als er na het ondertekenen iets verandert dat onder die handtekening valt, wordt de handtekening ongeldig.

Raadpleeg onze handleiding over het instellen van DKIM en onze uitgebreide uitleg over de oorzaken van DKIM-fouten om specifieke scenario’s en fouten met betrekking tot DKIM op te lossen.

3. Niet-geautoriseerde externe afzenders (CRM-systemen, e-maildienstverleners, helpdesks)

Veel bedrijven versturen e-mails via marketingautomatiseringstools, CRM-systemen, helpdesksoftware en diensten voor transactionele e-mail. Als die platforms niet correct zijn geautoriseerd om namens uw domein te verzenden, kan elk bericht dat ze versturen een DMARC-fout veroorzaken.

Google Workspace en Microsoft 365 ondertekenen bijvoorbeeld beide uitgaande e-mail met hun eigen standaard DKIM-selector, tenzij je een aangepaste selector configureert. Dat betekent dat e-mail die via deze diensten wordt verzonden, bij ontvangers kan verschijnen met de vermelding „via provider.com“. Deze berichten kunnen de afstemming niet doorstaan, omdat het ondertekenende domein niet overeenkomt met je zichtbare „Van“-domein, tenzij je binnen dat platform expliciet aangepaste DKIM-ondertekening voor je eigen domein hebt ingesteld.

4. E-maildoorsturing en mailinglijsten

Wanneer een e-mail wordt doorgestuurd, staat het IP-adres van de doorstuurserver niet in het SPF-record van de oorspronkelijke afzender, waardoor de SPF-afstemming wordt verstoord. Ook het „envelope from“-adres of de headers kunnen tijdens dit proces worden gewijzigd.

Mailinglijsten zijn verwant, maar niet hetzelfde. Ze wijzigen vaak de berichttekst of de headers rechtstreeks, door een afmeldingsvoettekst toe te voegen of de onderwerpregel te herschrijven, waardoor de DKIM-handtekening wordt verbroken, zelfs in situaties waarin het doorsturen op zich dat niet zou doen. ARC (Authenticated Received Chain) is specifiek bedoeld om dit te ondervangen door tussenliggende servers een verifieerbaar verslag van de oorspronkelijke authenticatieresultaten te laten toevoegen. Het systeem wordt echter mogelijk binnenkort afgeschaft, waarbij de mogelijkheden ervan worden geïntegreerd in de aanstaande DKIM2-specificatie.

5. Verkeerde toewijzing van subdomeinen

Als uw DMARC-beleid van toepassing is op uwdomein.com, maar er e-mails worden verzonden vanaf mail.uwdomein.com zonder eigen afstemming, kunnen die e-mails de DMARC-controles niet doorstaan. Organisaties die e-mailverkeer via meerdere subdomeinen afhandelen, hebben behoefte aan consistente authenticatie voor al deze subdomeinen, niet alleen voor het hoofddomein.

6. Vertragingen bij DNS-propagatie (periodieke storingen)

Als een DNS-record net is gewijzigd, kan het zijn dat sommige ontvangende servers nog steeds de oude, in de cache opgeslagen versie gebruiken, terwijl andere de nieuwe versie al hebben overgenomen. Door die discrepantie slaagt DMARC bij sommige ontvangers en faalt het bij anderen op precies hetzelfde moment, wat een erg verwarrend patroon is als je niet weet dat de vertraging bij de verspreiding hiervan de oorzaak is. Als je onlangs een SPF-, DKIM- of DMARC-record hebt aangepast en de fouten niet overal maar slechts op sommige plaatsen voorkomen, wacht dan even (vaak tot 24-48 uur, afhankelijk van de TTL van het record) voordat je aanneemt dat er iets anders mis is.

Controleer de DNS-propagatie in realtime via https://powerdmarc.com/dns-propagation-checker/

7. Domeinspoofing (DMARC werkt zoals bedoeld)

Als iemand zich voordoet als uw domein om phishing- of spammails te versturen, zullen die berichten uiteraard niet door de DMARC-controle komen, aangezien de ongeautoriseerde afzender niet voldoet aan de SPF- of DKIM-controles die voor uw domein zijn ingesteld. Dit is de enige oorzaak op deze lijst die geen gevolg is van een verkeerde configuratie. DMARC doet hiermee precies waarvoor het is ontworpen, en het is een teken dat uw domein actief het doelwit is; het loont dan ook de moeite om dit nauwlettend in de gaten te houden in uw DMARC-rapporten.

8. Krijg je een specifieke foutmelding of foutcode te zien?

Als je hier terecht bent gekomen omdat je op zoek was naar een specifieke foutmelding, dan zijn alle onderstaande meldingen gewoon DMARC- of synchronisatiefouten die in de taal van het betreffende platform worden weergegeven. De onderliggende oorzaken en oplossingen zijn allemaal hierboven behandeld.

Mimecast: „DNS-authenticatie: DMARC-fout”

Dit is de manier waarop Mimecast aangeeft dat een inkomend of uitgaand bericht de DMARC-controle niet heeft doorstaan, meestal om dezelfde redenen met betrekking tot de SPF/DKIM-afstemming die hierboven zijn beschreven.

Bezorgfouten bij SendGrid

Fouten die betrekking hebben op DMARC duiden er meestal op dat het eigen verzenddomein van SendGrid, of het ‘Van’-domein van een klant dat via SendGrid wordt verzonden, niet correct is geconfigureerd, vaak omdat de aangepaste DKIM/SPF-configuratie voor het verzenddomein nog niet is voltooid.

De SMTP-codes van Gmail

421-4.7.26 is een tijdelijke foutmelding, wat betekent dat het bericht niet geauthenticeerd is (geen overeenkomende SPF- of DKIM-verificatie), en Gmail escaleert deze sinds eind 2025 steeds vaker naar permanente 550-5.7.26 -afwijzingen bij aanhoudende niet-naleving. Een verwante foutcode, 550-5.7.1, betekent specifiek dat het bericht niet voldeed aan het eigen, gepubliceerde DMARC-beleid van het verzendende domein.

Microsoft 550 5.7.515

Dit is een harde afwijzing die Microsoft heeft ingevoerd voor verzenders met een hoog verzendvolume (5.000+ e-mails per dag naar Outlook-, Hotmail- of Live.com-adressen) die niet voldoen aan de authenticatie-eisen van Microsoft, met ingang van 5 mei 2025.

Waarom begon DMARC plotseling te falen?

Als je domein voorheen aan de DMARC-vereisten voldeed en sinds kort niet meer voldoet, loop dan eerst deze lijst door voordat je ervan uitgaat dat er iets niet goed werkt:

• Er is een nieuwe marketingtool, een CRM-systeem of een helpdeskplatform toegevoegd zonder dat uw SPF- of DKIM-instellingen zijn bijgewerkt.
• Er is onlangs een DNS-record gewijzigd en dit bevat nu een syntaxfout of een per ongeluk dubbel SPF-record.
• Een DKIM-sleutel is vernieuwd of is verlopen zonder dat de nieuwe sleutel in het DNS is gepubliceerd.
• Een subdomein is begonnen met het verzenden van e-mail zonder dat de SPF-, DKIM- of DMARC-instellingen zijn afgestemd.
• Google, Yahoo en Microsoft hebben de handhaving aan hun kant aangescherpt.

Google, Yahoo en Microsoft handhaven DMARC strenger dan ooit

De vereisten van Google en Yahoo voor bulkverzenders werden eind 2023 bekendgemaakt en traden in februari 2024 in werking voor verzenders met grote volumes, waarna de volledige handhaving in april 2024 volgde. Sindsdien is Gmail steeds strenger geworden in de manier waarop tijdelijke uitstelmaatregelen worden omgezet in definitieve afwijzingen voor domeinen die niet aan de vereisten voldoen, een trend die tot eind 2025 merkbaar strenger is geworden.

Microsoft volgde met zijn eigen vereisten voor Outlook-, Hotmail- en Live.com-adressen. De handhaving ging op 5 mei 2025 van start: bulkmail die niet aan de vereisten voldoet (5.000+ e-mails per dag) wordt nu direct geweigerd met foutcode 550 5.7.515, in plaats van alleen maar naar de spamfolder te worden doorgestuurd.

Als uw domein dagelijks 5.000 of meer e-mails verstuurt naar een van deze providers en DMARC de laatste tijd vaker fouten vertoont, dan is deze strengere handhaving wellicht de reden hiervoor. De oplossing is in beide gevallen hetzelfde: breng alle verzendbronnen in kaart, zorg ervoor dat SPF en DKIM correct zijn afgestemd en controleer of uw DMARC-record correct is. Raadpleeg onze gids met vereisten voor verzenders van bulk-e-mails voor de volledige vereisten per provider.

Hoe controleer je of er een DMARC-fout is opgetreden?

Controleer, voordat je wijzigingen aanbrengt, wat er daadwerkelijk gebeurt:

1. Stuur een testbericht naar Gmail, Outlook en Yahoo en open vervolgens de header ‘Authentication-Results’.

Open in Gmail het bericht en selecteer ‘Origineel weergeven’. Gebruik in Outlook de optie ‘Berichtdetails weergeven’. Zoek naar de vermeldingen spf=, dkim= en dmarc= en controleer of het domein dat de controle doorstaat overeenkomt met het zichtbare ‘Van’-adres.

2. Vergelijk het IP-adres van de bron die de controle niet doorstaat met je DMARC-aggregatierapporten (RUA).

Deze rapporten geven een overzicht van alle IP-adressen die e-mail namens uw domein versturen en of ze zijn geslaagd of gefaald; dit is doorgaans de snelste manier om een ongeautoriseerde of verkeerd geconfigureerde bron op te sporen. Als u niet bekend bent met het ruwe XML-formaat, kunt u onze handleiding raadplegen over het interpreteren van DMARC-rapporten.

3. Controleer het domein met een gratis DMARC-checker

Controleer de huidige status van uw records, want een record dat bij publicatie correct leek, kan na verloop van tijd syntactische fouten, duplicaten of hiaten in de doorsturing vertonen. Onze DMARC-recordchecker controleert dit allemaal in één keer.

Wat gebeurt er als DMARC faalt?

Het resultaat hangt volledig af van het DMARC-beleid dat voor uw domein is ingesteld. Uw beleid bepaalt hoe ontvangende mailservers moeten omgaan met e-mails die de authenticatie niet doorstaan, en elk niveau heeft andere gevolgen.

p=none: Alleen monitoring

Als het DMARC-beleid is ingesteld op p=none, worden e-mails die niet aan de DMARC-vereisten voldoen nog steeds afgeleverd, maar komen ze vaak in de spamfolder terecht in plaats van in de inbox. Dit beleid is bedoeld voor monitoring. Hiermee kunt u DMARC-rapporten verzamelen en authenticatieproblemen opsporen zonder uw e-mailverkeer te verstoren. Hoewel dit een veilig uitgangspunt is, blijft uw domein kwetsbaar als u p=none op de lange termijn handhaaft, aangezien het onbevoegde afzenders niet actief blokkeert.

p=quarantaine: naar spam verzonden

Bij een DMARC-beleid met de instelling p=quarantine worden e-mails die niet worden afgeleverd, naar de spamfolder van de ontvanger gestuurd. Dit vermindert de zichtbaarheid en de betrokkenheid van gebruikers, omdat uw legitieme e-mails tussen de ongewenste e-mails terecht kunnen komen. Hoewel dit beleid meer bescherming biedt dan p=none, kan het uw bedrijf toch schaden als legitieme e-mails niet worden afgeleverd vanwege verkeerde configuraties in plaats van daadwerkelijke spoofing.

p=afwijzen: Volledig geblokkeerd

Een DMARC-beleid met de instelling p=reject zorgt ervoor dat ontvangende servers de e-mail volledig blokkeren, waardoor deze de ontvanger helemaal niet bereikt. Dit is het strengste en veiligste beleid. Het snijdt pogingen tot phishing en spoofing in de kiem af. Als uw SPF en DKIM echter niet correct zijn geconfigureerd, zal een p=reject-beleid ook uw eigen legitieme e-mails blokkeren, wat de zakelijke communicatie ernstig kan verstoren.

De impact van DMARC-fouten op uw bedrijf

DMARC-fouten vormen een grote uitdaging voor bedrijven die voor hun communicatie afhankelijk zijn van e-mail. Hieronder leest u welke gevolgen een DMARC-fout kan hebben voor uw organisatie.

Verminderde e-mailbezorgbaarheid

DMARC-fouten kunnen ertoe leiden dat legitieme e-mails door e-mailproviders worden geblokkeerd of geweigerd, wat gevolgen heeft voor de zakelijke communicatie. Of je e-mails nu in de spamfolder terechtkomen of helemaal worden geweigerd, het resultaat is hetzelfde: je berichten bereiken niet de mensen die ze moeten zien. Voor bedrijven die voor verkoop, marketing, klantenondersteuning of transactionele communicatie afhankelijk zijn van e-mail, betekent dit direct gemiste kansen.

Beschadigde reputatie van afzender

Herhaaldelijke DMARC-fouten kunnen de afzenderreputatie van uw domein schaden, waardoor het zelfs voor geauthenticeerde e-mails moeilijker wordt om de inbox te bereiken. E-mailproviders zoals Google en Microsoft houden de authenticatiegeschiedenis van uw domein bij. Wanneer zij een patroon van DMARC-fouten waarnemen, gaan zij uw domein als minder betrouwbaar beschouwen, wat betekent dat zelfs correct geconfigureerde e-mails na verloop van tijd problemen met de afleverbaarheid kunnen ondervinden.

Lagere open rates en klantbetrokkenheid

DMARC-fouten kunnen ertoe leiden dat e-mails in de spamfolder terechtkomen, waardoor het openingspercentage en de klantbetrokkenheid dalen. Als uw marketingcampagnes, facturen, orderbevestigingen of belangrijke zakelijke updates steevast in de spamfolder belanden, zal uw doelgroep ze simpelweg niet zien, wat leidt tot gederfde inkomsten en gefrustreerde klanten.

Verhoogd risico op phishing en spoofing

Een hoog percentage mislukte DMARC-controles verhoogt het risico op phishingaanvallen en domeinspoofing, waardoor het vertrouwen van klanten wordt aangetast. Als uw domein wordt gespoofd, zullen ongeautoriseerde bronnen de DMARC-controles niet doorstaan, maar zonder een strikt handhavingsbeleid kunnen die gespoofde e-mails toch bij de ontvangers terechtkomen, waardoor uw klanten, partners en medewerkers het risico lopen te trappen in frauduleuze berichten die onder de naam van uw merk worden verzonden.

Langdurige schade aan de leverbaarheid

DMARC-fouten kunnen voor e-mailproviders een teken zijn dat een domein niet betrouwbaar is, wat op lange termijn gevolgen kan hebben voor de afleverbaarheid van e-mail. Het herstellen van een beschadigde afzenderreputatie kost veel tijd en moeite. Zodra de authenticatie weer in orde is, is het geleidelijk herstellen van het vertrouwen van de inbox – door middel van een gestructureerde IP-warm-up, het dagelijks stapsgewijs verhogen van het uitgaande volume en het genereren van positieve betrokkenheidssignalen van echte ontvangers – vaak bepalend voor hoe snel de afleverbaarheid daadwerkelijk herstelt.

Hoe een DMARC-fout te verhelpen

Om een DMARC-fout te verhelpen, moet u eerst begrijpen waarom de fout is opgetreden en vervolgens de juiste aanpassingen doorvoeren in uw e-mailverificatie-instellingen.

Stap 1: Begin met een soepel DMARC-beleid (p=none)

Met een ‘none’-beleid kunt u beginnen met het monitoren van uw domein via DMARC (RUA) Aggregate Reports en het nauwlettend in de gaten houden van inkomende en uitgaande e-mail. Zo kunt u reageren op bezorgingsproblemen voordat deze escaleren.
Hierdoor blijven legitieme berichten de ontvangers bereiken, zelfs als DMARC voor deze berichten faalt. Dit maakt u echter wel kwetsbaar voor phishing en spoofing.

Stap 2: Zorg voor de juiste SPF- en DKIM-uitlijning

Controleer je DNS-record op fouten en zorg ervoor dat het domein dat de SPF- of DKIM-controle doorstaat, daadwerkelijk overeenkomt met je zichtbare ‘Van’-adres, precies zoals eerder in deze handleiding is uitgelegd. Onze gratis DMARC-checker kan fouten in je DMARC-syntaxis of de opmaak van je DNS-record opsporen, waaronder extra spaties en spelfouten.

Het gecombineerde gebruik van DKIM en SPF zorgt voor een gelaagde aanpak: DKIM controleert of het bericht niet is gemanipuleerd, terwijl SPF de identiteit van de verzendende server verifieert. Samen dragen ze bij aan het opbouwen van vertrouwen in de afzender van de e-mail en verminderen ze het risico op spoofing en ongeoorloofde e-mailactiviteiten.

Stap 3: Versterk je verdediging met handhaving

Zodra legitieme afzenders zijn geverifieerd en gekoppeld, schakelt u over op een strikt beleid (p = quarantaine, vervolgens p = afwijzen) om daadwerkelijke bescherming te bieden tegen domeinspoofing en phishingaanvallen.

Stap 4: Beschermen met AI-gestuurde bedreigingsdetectie

Blokkeer kwaadaardige IP-adressen en meld deze rechtstreeks vanuit je DMARC-platform om toekomstige pogingen tot identiteitsfraude te voorkomen, waarbij je waar mogelijk gebruikmaakt van tools voor dreigingsinformatie.

Stap 5: Blijf continu optimaliseren aan de hand van foutmeldingen

Schakel DMARC (RUF)-foutmeldingen in om gedetailleerde informatie te krijgen over specifieke gevallen waarin e-mails niet aan de DMARC-vereisten voldeden, zodat u de oorzaak van het probleem kunt achterhalen en het sneller kunt oplossen.

DMARC-fout verhelpen met PowerDMARC

Het omgaan met DMARC-fouten kan complex zijn, vooral wanneer u meerdere verzendservices, platforms van derden en een steeds veranderende e-mailinfrastructuur beheert. PowerDMARC vereenvoudigt het hele proces, van de eerste installatie tot voortdurende monitoring en detectie van bedreigingen.

Wij helpen organisaties bij het correct implementeren van DMARC door stapsgewijze begeleiding en automatiseringstools te bieden die ervoor zorgen dat uw DMARC-records, SPF- en DKIM-authenticatie vanaf dag één correct zijn geconfigureerd en op elkaar zijn afgestemd. Dit vermindert het risico op verkeerde configuraties die leiden tot DMARC-storingen en zorgt ervoor dat uw domein sneller volledig wordt geëffectueerd.

Zodra DMARC is geïnstalleerd, controleert PowerDMARC continu uw e-mailverkeer en genereert het realtime rapporten en waarschuwingen wanneer een DMARC-fout wordt gedetecteerd.

Dit is wat ons uniek maakt:

• AI-gestuurde dreigingsinformatie en geautomatiseerde waarschuwingen die pogingen tot phishing en spoofing in realtime identificeren
• Stapsgewijze ondersteuning bij onboarding en implementatie om DMARC, SPF en DKIM vanaf dag één correct te gebruiken
• Voor mensen leesbare, bruikbare rapportages die complexe XML-gegevens vervangen door duidelijke inzichten
• Vertrouwd door meer dan 5.000 organisaties wereldwijd om DMARC-fouten te verhelpen en te voorkomen

Veelgestelde Vragen

1. Waar staat DMARC voor?

DMARC staat voor Domain-Based Message Authentication, Reporting, and Conformance. Het is een e-mailverificatieprotocol dat domeinen helpt beschermen tegen e-mailspoofing, phishing en andere cyberaanvallen door te controleren of e-mails legitiem zijn verzonden vanuit geautoriseerde bronnen.

2. Hoe slaag je voor DMARC-authenticatie?

Om de DMARC-authenticatie te doorstaan, moeten uw e-mails voldoen aan de SPF- of DKIM-vereisten en overeenkomen met het domein dat in het „Van”-adres wordt weergegeven. Om dit te bereiken, moet u ervoor zorgen dat uw verzendende IP-adressen in SPF zijn geautoriseerd, dat DKIM correct is ondertekend en dat uw DMARC-record correct in DNS is gepubliceerd.

3. Hoe DMARC-beveiliging herstellen?

Om het gebrek aan DMARC-beveiliging te verhelpen, moet u een DMARC-record in de DNS van uw domein publiceren. Begin met een monitoringbeleid (p=none) om rapporten te verzamelen, en schakel vervolgens geleidelijk over naar strengere handhaving (p=quarantine of p=reject) zodra u hebt gecontroleerd of alle legitieme e-mailbronnen zijn geauthenticeerd.

4. Hoe kan ik de DMARC-foutmelding oplossen?

Om de DMARC-fout te verhelpen, moet u eerst nagaan waarom het bericht de authenticatie niet heeft doorstaan. Zorg ervoor dat SPF en DKIM correct zijn ingesteld en overeenkomen met het verzendende domein. Controleer vervolgens of het DMARC-beleid van uw domein correct in DNS is gepubliceerd en overeenkomt met de manier waarop uw e-mails daadwerkelijk worden verzonden. Zodra alles op orde is, kunt u de DMARC-rapporten in de gaten houden om te controleren of het probleem is opgelost.

5. Wat is een DMARC-overtreding?

Een DMARC-overtreding is een andere manier om een bericht te omschrijven dat niet door de DMARC-controle komt, hetzij omdat het ongeautoriseerd is (iemand die uw domein vervalst), hetzij omdat een legitieme afzender niet correct is gekoppeld. Wat er vervolgens gebeurt, hangt af van uw beleid: p=none registreert het, p=quarantine stuurt het naar de spamfolder en p=reject blokkeert het direct.

6. Kan DMARC afkeuren, zelfs als SPF en DKIM beide worden goedgekeurd?

Ja, en dit is een van de meest voorkomende bronnen van verwarring. SPF en DKIM kunnen technisch gezien allebei hun eigen controles doorstaan, terwijl DMARC toch faalt, als het domein dat bij de controle wordt goedgekeurd niet overeenkomt met je zichtbare „Van”-adres. Een bericht van mail.esp-provider.com kan de SPF-controle zonder problemen doorstaan en toch niet voldoen aan DMARC als je zichtbare „Van”-domein yourdomain.com is, aangezien DMARC niet alleen de authenticatie controleert, maar ook de overeenstemming.

• 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)

• Wat is een DMARC-beleid? Geen, Quarantaine en Weigeren - 27 juli 2026
• Naleving van Dmarc: wat het is, waarom het belangrijk is en hoe je dit kunt controleren - 21 juli 2026
• DMARC instellen: volledige stapsgewijze configuratiehandleiding (2026) - 20 juni 2026