Hoe DMARC-rapporten te lezen: een complete gids voor RUA en RUF

Je hebt een DMARC-record gepubliceerd, `rua=` ingesteld op je e-mailadres, en nu komen er rapporten als gecomprimeerde XML-bestanden in je inbox terecht. Ze zijn moeilijk te lezen, ze zijn afkomstig van bedrijven waar je nog nooit van hebt gehoord, en het is niet meteen duidelijk wat je ermee moet doen, als er al iets mee te doen is.

Deze handleiding biedt uitkomst. Hierin wordt uitgelegd wat DMARC-rapporten bevatten, hoe je de XML veld voor veld kunt lezen, wat RUA en RUF precies betekenen, en – het allerbelangrijkste – welke maatregelen je moet nemen wanneer een afzender de controle doorstaat, niet doorstaat of onverwacht opduikt. Als je nu je eerste rapport in handen hebt, begin dan bovenaan en werk naar beneden toe.

In deze blog wordt ervan uitgegaan dat je al een record hebt ingesteld. Als dat niet het geval is, publiceer dan eerst een DMARC-record en kom daarna terug om de rapporten die hierdoor worden gegenereerd te interpreteren.

Wat zijn DMARC-rapporten?

DMARC-rapporten zijn dagelijkse overzichten die door ontvangende mailservers worden verzonden naar het adres in uw `rua=`-tag. In elk rapport wordt een lijst weergegeven van alle IP-adressen die tijdens een rapportageperiode een e-mail hebben verzonden die beweerde afkomstig te zijn van uw domein, en of SPF en DKIM voor elke bron geslaagd of gefaald zijn. Ze vormen het belangrijkste hulpmiddel om de e-mailauthenticatie van uw domein te controleren. Ze bieden u het enige echte inzicht in wie er e-mail verstuurt onder uw naam, of dit nu legitiem is of niet.

Wie verstuurt DMARC-rapporten?

Elke mailserver die e-mail van uw domein ontvangt, stuurt een rapport als u rua= hebt geconfigureerd. Daaronder vallen uiteraard Google, Microsoft en Yahoo. Ook vallen hier kleinere e-maildienstverleners (ESP’s), e-mailgateways van bedrijven, universitaire systemen en internationale providers die uw ontvangers toevallig gebruiken. 

Het ontvangen van berichten van organisaties die je niet herkent is normaal en te verwachten. Het kan simpelweg betekenen dat een server ergens een bericht heeft verwerkt dat afkomstig leek te zijn van uw domein. Houd er echter rekening mee dat een groot aantal e-mails in die rapporten afkomstig van een IP-adres waarover u geen controle hebt, toch nader onderzoek vereist, aangezien dat een teken van spoofing.

Het aantal rapporten dat je per dag ontvangt, hangt af van het aantal verschillende mailservers die je e-mail hebben ontvangen. Als je slechts naar een handvol ontvangers verstuurt, krijg je misschien twee of drie rapporten per dag. Verzenders die grote hoeveelheden e-mail versturen, kunnen er honderden ontvangen. Op zich duidt dit nog niet op een probleem. Het aantal rapporten geeft de spreiding van je ontvangers weer, niet de gezondheid van je domein.

Wanneer worden de rapporten bezorgd?

De meeste aanbieders sturen eens per 24 uur één samengevat rapport, en de rapporten komen doorgaans binnen 24 tot 48 uur na de e-mailactiviteit waarover ze verslag doen binnen. Je ontvangt van elke rapporterende organisatie een apart rapport (Google en Microsoft sturen elk afzonderlijk hun eigen rapport), dus de e-mailverkeer van één dag naar verschillende ontvangers levert meerdere rapporten op die dezelfde periode bestrijken.

Rapporten worden als gecomprimeerde bijlagen in .zip- of .gz-formaat verzonden door geautomatiseerde afzenders. Sommige e-mailprogramma’s markeren deze als verdacht, dus als je rapporten verwacht maar geen ontvangt, controleer dan eerst je spam- of ongewenste e-mailmap voordat je ervan uitgaat dat er iets niet goed werkt.

Soorten DMARC-rapporten: RUA versus RUF

Er zijn twee soorten DMARC-rapporten. Voor vrijwel alle domeinen hoef je eigenlijk alleen maar rekening te houden met de eerste.

Geaggregeerde rapporten (RUA): De norm

DMARC-geaggregeerde rapporten zijn een 24-uursoverzicht van al het e-mailverkeer van uw domein dat door een bepaalde mailserver is verwerkt. Ze worden geleverd als gecomprimeerde XML en tonen u de verzendende IP-adressen, het aantal berichten, SPF-goedkeuring/afwijzing, DKIM-goedkeuring/afwijzing en de DMARC-disposition (de actie die de ontvanger heeft ondernomen). Belangrijk is dat ze geen e-mailinhoud en geen persoonlijk identificeerbare informatie bevatten, alleen authenticatiemetadata, waardoor ze in elke regio veilig kunnen worden ontvangen en opgeslagen. Dit is het rapport waarop deze handleiding zich richt. 

Foutmeldingen (RUF): Fouten per bericht

DMARC-foutmeldingen (voorheen forensische rapporten genoemd) zijn bijna realtime meldingen dat een specifiek bericht de authenticatie niet heeft doorstaan. RFC 9991 (mei 2026) heeft dit rapporttype formeel gestandaardiseerd. Omdat een foutmelding berichtkoppen en soms ook de inhoud van het bericht (gegevens die mogelijk PII bevatten) kan bevatten, versturen grote providers, waaronder Google, Microsoft en Yahoo, deze helemaal niet. Schakel ruf= alleen in als u over een speciale processor voor de gegevens beschikt, en verwacht in ieder geval geen rapporten van de grote e-mailproviders. 

RUA tegen RUF 

Wat staat er in een DMARC-rapport: veld voor veld

Een DMARC-geaggregeerd rapport is een XML-bestand dat is onderverdeeld in drie hoofddelen: metadata van het rapport (wie het heeft verzonden en wanneer), gepubliceerd beleid (uw DMARC-record zoals de ontvanger het heeft gezien) en records, één rij per afzender. Begrijp deze drie onderdelen, en de rest is bijzaak.

Section 1: Report Metadata (<report_metadata>)

In dit blok staat vermeld wie het rapport heeft ingediend en welke periode het beslaat.

• org_name: de rapporterende organisatie (bijv. google.com).
• e-mail: het contactadres van de afzender van het rapport.
• report_id: een unieke identificatiecode voor dit specifieke rapport.
• date_range (begin + einde): de rapportageperiode, weergegeven als epoch-tijdstempels; je moet deze omzetten naar een voor mensen leesbare datum.

Wat u hier moet controleren: controleer of het rapport de periode omvat die u verwacht.

Section 2: Policy Published (<policy_published>)

Hier wordt je DMARC-record weergegeven precies zoals de ontvanger het op het moment van verwerking heeft beoordeeld.

• domein: het domein waarop het beleid van toepassing is.
• adkim / aspf: DKIM- en SPF-afstemmingsmodi (soepel of strikt).
• p: uw beleid (geen, quarantaine of weigeren).
• sp: je subdomeinbeleid, indien ingesteld.
• pct: een verouderd percentageveld. Let op: pct is verwijderd op grond van RFC 9989 (mei 2026); het kan nog steeds voorkomen in oudere rapporten, maar in nieuwe records mag het niet meer worden gebruikt.

Wat u hier moet controleren: ga na of het gepubliceerde beleid overeenkomt met wat u van plan was. Als dat niet het geval is, is uw DNS mogelijk nog niet volledig doorgevoerd.

Section 3: Records (<record>): The Important Part

Each <record> represents all the emails from one source IP during the reporting period. This is where you spend most of your time.

• source_ip: het IP-adres van de afzender. Zoek dit op om te achterhalen wie de e-mail heeft verzonden.
• aantal: hoeveel berichten er vanaf dat IP-adres zijn binnengekomen.
• policy_evaluated/disposition: de ondernomen actie (geen actie, quarantaine of afwijzen).
• policy_evaluated/dkim en policy_evaluated/spf: het DMARC-conforme resultaat (geslaagd/mislukt) voor elk van beide.
• identifiers/header_from: het zichtbare „From:”-domein, dat door DMARC wordt beschermd.
• auth_results/spf: het SPF-domein en het resultaat.
• auth_results/dkim: het DKIM-domein, de selector en het resultaat.

Wat u hier moet controleren: voldoet elk IP-adres dat u herkent aan de DMARC-vereisten, en zijn er IP-adressen die u niet herkent?

Voorbeeld van een DMARC XML-rapport

Hier volgt een realistisch, geanonimiseerd geaggregeerd rapport met drie verzendbronnen: één legitieme afzender die aan de criteria voldoet, één legitieme afzender die niet aan de criteria voldoet, en één onbekend IP-adres. Elk veld is voorzien van een toelichting in gewoon Engels. 

<?xml version="1.0" encoding="UTF-8"?>
<feedback>

  <!-- ===== SECTION 1: WHO SENT THIS REPORT AND WHEN ===== -->
  <report_metadata>
    <org_name>google.com</org_name>             <!-- The provider that generated this report -->
    <email>[email protected]</email>  <!-- Where the report came from -->
    <report_id>1234567890123456789</report_id>  <!-- Unique ID for this report -->
    <date_range>
      <begin>1718928000</begin>                 <!-- Start of window (epoch) = 2024-06-21 00:00 UTC -->
      <end>1719014400</end>                      <!-- End of window (epoch)   = 2024-06-22 00:00 UTC -->
    </date_range>
  </report_metadata>

  <!-- ===== SECTION 2: YOUR POLICY AS THE RECEIVER SAW IT ===== -->
  <policy_published>
    <domain>example.com</domain>                <!-- The domain this report is about -->
    <adkim>r</adkim>                             <!-- DKIM alignment: r = relaxed -->
    <aspf>r</aspf>                               <!-- SPF alignment:  r = relaxed -->
    <p>none</p>                                  <!-- Your policy: monitoring only -->
    <sp>none</sp>                                <!-- Subdomain policy -->
  </policy_published>

  <!-- ===== SECTION 3: ONE RECORD PER SENDING SOURCE ===== -->

  <!-- RECORD 1: Legitimate sender (Google). All passing, no action needed. -->
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>      <!-- A Google sending IP -->
      <count>150</count>                         <!-- 150 messages from this IP -->
      <policy_evaluated>
        <disposition>none</disposition>          <!-- No action taken -->
        <dkim>pass</dkim>                         <!-- DKIM aligned & passed -->
        <spf>pass</spf>                           <!-- SPF aligned & passed -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Visible From: domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>google</selector>
        <result>pass</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 2: Known ESP. SPF passes but DKIM is not configured.
       Action: ask the provider to enable DKIM signing for your domain. -->
  <record>
    <row>
      <source_ip>198.51.100.42</source_ip>      <!-- Your email service provider -->
      <count>45</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>                         <!-- DKIM not aligned / not signed -->
        <spf>pass</spf>                           <!-- SPF passes -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>esp-vendor.example.org</domain>  <!-- Signed by vendor domain, not yours -->
        <selector>s1</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 3: Unknown sender. Both DKIM and SPF fail.
       Low volume here = monitor. High volume would signal active spoofing. -->
  <record>
    <row>
      <source_ip>203.0.113.17</source_ip>       <!-- Unrecognized IP -->
      <count>8</count>
      <policy_evaluated>
        <disposition>none</disposition>          <!-- Not blocked yet (p=none) -->
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Claiming to be your domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>unknown</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

</feedback>

Hoe u uw DMARC-rapporten kunt lezen: stap voor stap

Stap 1: Open het rapport en pak het uit

De rapporten worden als bijlage bij een e-mail verzonden met een onderwerpregel als bijvoorbeeld: Rapport domein: yourdomain.com Indiener: google.com Rapport-ID: …. Sla de bijlage op, pak deze uit (de ingebouwde uitpakprogramma’s van je besturingssysteem kunnen .zip- en .gz-bestanden prima verwerken) en open het resulterende .xml-bestand in een willekeurige teksteditor. 

Als je meer wilt doen dan alleen even snel kijken, upload het dan naar onze DMARC Report Analyzer in plaats van de ruwe XML te lezen, zodat u de gegevens grondig kunt analyseren in een voor mensen leesbaar formaat.

Stap 2: Bepaal welke organisatie de rapportage moet opstellen

Check <org_name> in the metadata so you know whose view you are looking at. Google’s report covers your Gmail recipients; Microsoft’s covers Outlook and Hotmail. You will get separate reports from each, so never assume one report is the whole picture.

Stap 3: Controleer je gepubliceerde beleid

Confirm <p>, <sp>, <adkim>, and <aspf> match what you intended to publish. If they do not, your record may have been propagated incorrectly or edited. Verify the live record with our DMARC Checker.

Stap 4: Controleer elk record (verzendbron)

For each <record>: look up the <source_ip> with a reverse DNS or IP lookup to identify the service (for example, 209.85.220.41 resolves to Google). Check the <count>. High volume from an IP you do not recognize is a red flag. Then check the disposition and the DKIM/SPF results. A legitimate sender should show both dkim=pass and spf=pass; a failure on either for a sender you recognize means something needs fixing.

Stap 5: Deel elke bron in een categorie in

Deel elke bron in een van de volgende drie categorieën in:

1. Geoorloofd en in orde: geen actie nodig.
2. Correct, maar niet goed: moet worden aangepast (zie het actiekader hieronder).
3. Onbekend en verzending: mogelijke spoofing; houd het volume in de gaten en overweeg uw beleid aan te scherpen als het hoog is.

DMARC-rapporten op grote schaal lezen: hulpmiddelen en automatisering

Zodra er dagelijks rapporten binnenkomen van meerdere aanbieders, wordt het handmatig doorlezen van XML-bestanden onpraktisch. Een domein dat rapporten verstuurt naar gebruikers van Gmail, Outlook en Yahoo ontvangt elke dag minstens drie rapporten, en het is onmogelijk om die allemaal met de hand door te nemen na de eerste week. Geautomatiseerde analyse is niet voor niets de industriestandaard.

Voor een snelle eenmalige controle kun je met gratis tools zoals de DMARC Report Analyzer van PowerDMARC een onbewerkt XML-bestand uploaden en de inhoud ervan in een voor mensen leesbare indeling bekijken, zonder dat je daarvoor een teksteditor hoeft te openen.

Voor doorlopende monitoring op grote schaal zorgt een speciaal platform ervoor dat alles automatisch wordt afgehandeld: rapporten van alle providers worden gestandaardiseerd en in één overzicht weergegeven, u krijgt een melding wanneer er een onbekende afzender opduikt, de geschiedenis wordt bewaard en er worden exportbestanden gegenereerd die klaar zijn voor audits. 

Voor PowerDMARC-gebruikers regelt ons rapportagedashboard dit alles, zowel in omgevingen met één domein als met meerdere domeinen, zodat de analyse continu plaatsvindt en niet alleen wanneer u eraan denkt om te controleren.

• Al uw rapporten op één plek: In plaats van tientallen afzonderlijke XML-bestanden die verspreid liggen in een inbox, wordt elk rapport van elke aanbieder samengevoegd tot één overzicht.
• Dekking voor elk domein: Voor teams die meer dan één domein beheren, strekt die consolidatie zich uit over de gehele portfolio, zodat één enkel dashboard alle domeinen omvat waarvoor u verantwoordelijk bent.
• Historische gegevens, niet alleen momentopnames: Dankzij de bewaarde geschiedenis kunt u uw slagingspercentage van week tot week volgen, controleren of een oplossing voor een defecte afzender daadwerkelijk heeft gewerkt, en een langzame toename van verdachte activiteiten opmerken voordat deze tot een incident leidt.
• Filteren en zoeken: Zoek een specifieke verzendbron of een specifiek type storing, in plaats van elk record handmatig te doorzoeken.
• Waarschuwingen bij nieuwe afzenders: Ontvang een melding wanneer er een nieuwe, niet-geautoriseerde afzender opduikt, zodat u niet hoeft te wachten op de volgende handmatige controle om dit op te merken.
• Export klaar voor audit: Maak exporteerbare rapporten voor nalevingscontroles en rapportage aan belanghebbenden.

Wat te doen met je DMARC-rapporten

Het rapport lezen is de eerste stap. Pas door actie te ondernemen bescherm je je domein daadwerkelijk. Doorloop de volgende stappen in deze volgorde telkens wanneer je een nieuwe reeks rapporten doorneemt.

Problemen met legitieme afzenders oplossen

Als een afzender die je herkent (je ESP, CRM, helpdesk of nieuwsbriefplatform) de melding dkim=fail of spf=fail weergeeft:

1. Bij SPF-fouten: voeg het IP-bereik van de afzender toe of neem het mechanisme ‘include:’ op in je SPF-record, en controleer het vervolgens opnieuw met onze SPF-checker.
2. Bij DKIM-fouten: vraag de provider om aangepaste DKIM-ondertekening voor je domein in te schakelen en de sleutel die je van hen krijgt te publiceren; controleer vervolgens met onze DKIM-checker.

Onbekende afzenders identificeren en in de gaten houden

Een IP-adres dat u niet herkent en dat e-mail namens uw domein verstuurt, kan een tool zijn die een team in gebruik heeft genomen zonder iemand daarvan op de hoogte te stellen, een legitieme doorstuurservice of een actieve poging tot spoofing. Een laag e-mailvolume vanaf een onbekend IP-adres komt vaak voor en houdt weinig risico in. Een hoog e-mailvolume vanaf een onbekend IP-adres is een duidelijk teken van spoofing, en in dat geval kunt u het misbruik actief tegengaan door uw beleid aan te scherpen en de e-mails in quarantaine te plaatsen of te weigeren.

Houd je slagingspercentage in de loop van de tijd bij

Uw DMARC-slaagpercentage is het percentage e-mails dat de DMARC-authenticatie doorstaat. Bij p=none heeft dit geen invloed op de bezorging, maar het geeft wel aan in hoeverre u klaar bent om het beleid af te dwingen. Streef naar een slaagpercentage van meer dan 95% voor alle legitieme afzenders, op een constante basis, voordat u uw beleid aanscherpt. Houd dit gedurende ten minste twee tot vier weken wekelijks in de gaten, in plaats van te reageren op de resultaten van één enkele dag.

Bepaal wanneer u uw polis wilt verlengen

Ga over naar p=quarantaine wanneer aan alle drie de gereedheidscontroles is voldaan:

1. Alle bekende legitieme afzenders voldoen aan de DMARC-norm.
2. Er verschijnen geen onverwachte afzenders met grote verzendvolumes in uw rapporten.
3. Het slagingspercentage is consequent boven de 95% gebleven.

Schakel over naar p=reject wanneer diezelfde omstandigheden gedurende één tot twee weken in quarantaine gelden zonder dat er zich onverwachte situaties voordoen. Het volledige verloop van het beleid wordt behandeld in onze DMARC-installatiehandleiding.

PowerDMARC automatiseert deze hele analyse. Ons platform houdt de doorlaatpercentages bij, identificeert afzenders op naam in plaats van op IP-adres en waarschuwt u zodra er een nieuwe, niet-geautoriseerde afzender opduikt, zodat de beslissing over de toelating voor u wordt genomen in plaats van dat u deze zelf moet afleiden uit onbewerkte XML-gegevens.

Waarom ontvang ik geen DMARC-rapporten?

Als je een record hebt gepubliceerd waarbij rua= is ingesteld, maar er zijn nog geen rapporten binnengekomen, ligt dit vrijwel altijd aan een van deze zes oorzaken.

Probleem 1: Er ontbreekt een rua=-tag in uw DMARC-record. Dit is de meest voorkomende oorzaak. Zonder rua= hebt u zich expliciet afgemeld voor het ontvangen van rapporten. Oplossing: voeg rua=mailto:[email protected] toe aan uw record en controleer dit met onze DMARC Checker.

Probleem 2: Verkeerd of ongeldig e-mailadres. Een typefout, een niet-bestaande inbox of een volle mailbox zorgt ervoor dat rapporten ongemerkt worden genegeerd. Oplossing: controleer of het rua=-adres daadwerkelijk e-mail kan ontvangen door er een testbericht naartoe te sturen.

Probleem 3: Externe rapportagebestemming niet geautoriseerd. Als uw rua= verwijst naar een adres op een ander domein dan uw DMARC-record (uw domein is company.com maar rua= verwijst naar [email protected]), moet het externe domein een autorisatierecord publiceren op _report._dmarc.reportingservice.com met daarin v=DMARC1. Zonder dit record worden rapporten genegeerd. De meeste DMARC-platforms regelen dit automatisch voor u.

Probleem 4: U hebt een nieuw record gepubliceerd, maar de DNS is nog niet doorgevoerd. Rapporten beginnen binnen 24 tot 48 uur nadat uw record wereldwijd live is gegaan binnen te komen. Om dit te verhelpen, kunt u de doorvoering controleren met onze DNS-propagatiechecker.

Probleem 5: Meldingen komen in de spamfolder terecht. Meldingen worden als gecomprimeerde bijlagen verzonden door geautomatiseerde afzenders en worden vaak gefilterd. Om dit te verhelpen, controleert u uw spamfolder en voegt u de afzenders van de meldingen toe aan de witte lijst ([email protected], [email protected]).

Nummer 6: Er is nog geen e-mail verzonden. Rapporten worden alleen gegenereerd wanneer uw domein daadwerkelijk e-mail heeft verzonden die bij een provider is aangekomen. Als er sinds het publiceren van het record nog niets is verzonden, is er nog niets te rapporteren.

RFC 9990: De norm voor het geaggregeerde rapport van 2026

Met ingang van mei 2026, regelt RFC 9990 regelt het formaat en de verzending van DMARC-geaggregeerde rapporten en neemt daarmee de rapportagefunctie over die voorheen in RFC 7489 was vastgelegd. Het XML-schema is achterwaarts compatibel (bestaande parsers en de rapporten die u al ontvangt, blijven werken), en de belangrijkste wijziging is de formele standaardisatie van het rapportageformaat en de dagelijkse frequentie. 

Voor een volledig overzicht van de laatste updates kun je onze DMARC RFC 9989/9990/9991 gids. 

Veelgestelde Vragen

Wat is een DMARC-rapport?

Een DMARC-rapport is een dagelijks XML-bestand dat door ontvangende e-mailservers wordt verzonden naar het adres in uw `rua=`-tag. Hierin wordt een overzicht gegeven van alle IP-adressen die e-mail vanaf uw domein hebben verzonden, en of SPF en DKIM voor elk adres zijn geslaagd of mislukt. Providers zoals Google, Microsoft en Yahoo genereren deze rapporten telkens wanneer ze e-mail ontvangen die beweert afkomstig te zijn van uw domein. Ze vormen het belangrijkste hulpmiddel om de authenticatiestatus van de e-mail van uw domein te controleren.

Wat is het verschil tussen RUA en RUF in DMARC?

RUA-rapporten (geaggregeerd) zijn dagelijkse XML-overzichten van alle e-mailactiviteit vanuit uw domein. RUF-rapporten (foutmeldingen) zijn foutmeldingen per bericht die individuele e-mailheadergegevens kunnen bevatten. De meeste grote providers, waaronder Google, Microsoft en Yahoo, versturen vanwege privacybeperkingen geen foutmeldingen meer, waardoor geaggregeerde rapporten gebruikelijker zijn en wereldwijd worden ondersteund.

Hoe vaak worden DMARC-rapporten verzonden?

De meeste providers versturen één samengevat rapport per 24 uur. Aangezien elke ontvangende mailserver zijn eigen rapport verstuurt, ontvang je er één van elke provider waarvan de gebruikers jouw e-mail hebben ontvangen. Een domein dat e-mails verstuurt naar gebruikers van Gmail, Outlook en Yahoo kan dus rekenen op ten minste drie rapporten per dag.

Hoe lees ik een DMARC XML-rapport?

Een DMARC XML-rapport bestaat uit drie hoofddelen: report_metadata (wie het heeft verzonden en de periode), policy_published (uw DMARC-record zoals beoordeeld) en records (één vermelding per verzendend IP-adres met de bijbehorende SPF- en DKIM-resultaten). Voor een praktische uitleg kunt u het XML-voorbeeld verderop in deze handleiding raadplegen. De meeste IT-teams maken echter gebruik van een geautomatiseerde analysetool die afzenders op naam identificeert, in plaats van de ruwe XML-code te lezen.

Waarom krijg ik DMARC-rapporten van organisaties die ik niet ken?

Elke mailserver die e-mail ontvangt die afkomstig lijkt te zijn van uw domein, stuurt een rapport als u rua= hebt geconfigureerd. Dit geldt ook voor kleine internetproviders, e-mailgateways van bedrijven en internationale providers waarvan uw ontvangers gebruikmaken, niet alleen voor Google en Microsoft. Het is normaal om rapporten te ontvangen van onbekende organisaties; dit betekent simpelweg dat die servers e-mail hebben verwerkt die afkomstig leek te zijn van uw domein.

• 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