DMARC-rapporten lezen

Module 4: Afleverbaarheid: SPF, DKIM en DMARC in de praktijk · Leestijd: 12 minuten

Leerdoel: Na deze les kun je een DMARC-verzamelrapport openen en lezen, per rij bepalen welke bron het is en waarom die slaagt of faalt, en beslissen wat je repareert, wat je mag negeren en wanneer je je beleid kunt aanscherpen.

Kernbegrippen: verzamelrapport (aggregate report, RFC 9990), rua, XML, gzip of zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selector, foutrapport (ruf, RFC 9991), rapportdienst, privacy

Wat je binnenkrijgt

Heb je in je DMARC-record een rua-adres gezet (les 4.4), dan sturen grote ontvangers zoals Google, Microsoft en Yahoo je ongeveer elke dag een verzamelrapport. Het is een mail met een bijlage, meestal een gezipt XML-bestand met een naam als:

receiver.example!example.com!1793923200!1794009599.xml.gz

Dat betekent: van ontvanger receiver.example, over jouw domein example.com, over de periode tussen de twee tijdstempels (seconden sinds 1970; hier 6 november 2026, de hele dag in UTC).

Een rapport bevat geen inhoud van mail, geen onderwerpen en meestal geen adressen van ontvangers. Het bevat per verzendende server het aantal berichten en de uitkomst van SPF, DKIM en DMARC. Daardoor is het een betrouwbaar overzicht van wie er namens je domein mailt, ook van bronnen die je zelf vergeten was, en van oplichters.

De opbouw van een rapport

Een rapport heeft drie delen. Hieronder de belangrijkste stukken uit het voorbeeldbestand bij deze les (dmarc-rapport-1.xml).

1. Wie rapporteert, over welke periode

<report_metadata>
  <org_name>receiver.example</org_name>
  <email>noreply-dmarc@receiver.example</email>
  <report_id>receiver.example-20261106-7f3c2a91</report_id>
  <date_range>
    <begin>1793923200</begin>
    <end>1794009599</end>
  </date_range>
</report_metadata>

2. Welk beleid de ontvanger bij jou vond

<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <sp>none</sp>
  <np>none</np>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

Controleer dit altijd: staat hier niet wat je denkt dat er in je DNS staat, dan las de ontvanger een ander (of oud) record.

3. Per bron: een record

Elke record gaat over één verzendend IP-adres met één combinatie van uitkomsten:

<record>
  <row>
    <source_ip>198.51.100.40</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounce.mailer.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example</domain>
      <selector>k1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Het belangrijkste verschil: auth_results tegenover policy_evaluated

Hier zit de kern van het lezen. In het voorbeeld hierboven staat in auth_results twee keer pass: DKIM slaagde voor mailer.example en SPF slaagde voor bounce.mailer.example. Toch staat in policy_evaluated twee keer fail. Dat is geen tegenspraak: policy_evaluated telt alleen een geslaagde controle die uitgelijnd is met header_from. Geen van beide domeinen hoort bij example.com, dus faalt DMARC.

Zo lees je elke rij:

1. Kijk naar policy_evaluated. Staat er bij dkim of spf een pass? Dan slaagt DMARC en is deze bron in orde.
2. Faalt alles? Kijk in auth_results naar de domeinen. Is het een dienst van jou die wel slaagt, maar voor zijn eigen domein? Dan moet je bij die dienst DKIM met je eigen domein aanzetten (les 4.3).
3. Faalt het ook in auth_results, of ontbreekt DKIM helemaal? Zoek uit wie het IP-adres is (reverse DNS, les 5.1, of een whois-opzoeking). Is het een van jouw systemen: repareren. Is het onbekend en gaat het om verdachte aantallen: waarschijnlijk vervalsing.

Patronen die je steeds ziet

Let ook op IPv6: een eigen server die soms over IPv6 verstuurt, terwijl je SPF alleen het IPv4-adres noemt, geeft een softfail op die rijen. Met een DKIM-handtekening slaagt DMARC dan nog, maar het is een teken dat je SPF onvolledig is.

Van rapport naar besluit

Je bent klaar om je beleid aan te scherpen (van none naar quarantine, daarna naar reject) als:

• elke bron die van jou is, in policy_evaluated minstens één pass heeft;
• dat al een paar weken zo is, bij alle grote ontvangers;
• wat nog faalt, alleen doorgestuurde mail met een geldige DKIM-handtekening is (die slaagt dan toch) of duidelijk vervalsing.

Faalt een grote eigen bron, zoals in het voorbeeld de nieuwsbriefdienst met 1250 berichten, dan is het te vroeg. Met p=reject zou de ontvanger die 1250 nieuwsbrieven weigeren.

Rapporten leesbaar maken

Eén rapport in een teksteditor is te doen. Twintig per dag niet. Er zijn drie manieren:

• Een rapportdienst (er zijn er veel, ook met een gratis variant). Je zet hun adres in rua en zij maken er grafieken en lijsten van. Let op: dan geef je die dienst inzicht in welke servers namens je mailen, en het rapportadres staat op hun domein (zie de toestemming via _report._dmarc in les 4.4). Kies een dienst die je vertrouwt en die de AVG naleeft.
• Een eigen hulpmiddel: er bestaan open-sourceprogramma's die rapporten uit een mailbox halen en in een overzicht zetten.
• Zelf lezen met een XML-viewer of een browser, voor af en toe.

Foutrapporten (ruf, RFC 9991) zijn anders: per mislukte mail, soms met stukken van de mail erin. Bijna geen grote ontvanger stuurt ze, juist vanwege de privacy. Je hebt ze niet nodig om DMARC goed in te voeren.

In de praktijk: zo ziet het eruit

Bij WebOké kun je het rapportadres invullen in de DMARC-hulp in DirectAdmin of Mijn WebOké (zie les 4.4), en kies je zelf een mailbox waar de rapporten binnenkomen; een apart adres zoals dmarc@ met een eigen map voorkomt dat je gewone mail ondersneeuwt. Lezen doe je met een rapportdienst of programma naar keuze. Dat werkt bij elke aanbieder hetzelfde: het rapport is een standaardformaat.

Samenvatting

• Een verzamelrapport is een dagelijks XML-bestand (vaak gezipt) per ontvanger, met per verzendend IP het aantal berichten en de uitkomsten.
• auth_results geeft de ruwe SPF- en DKIM-uitkomst; policy_evaluated alleen wat uitgelijnd slaagde. Een pass in auth_results kan een fail in DMARC zijn.
• Doorgestuurde mail herken je aan DKIM pass met SPF fail; vervalsing aan alles fail van een onbekend IP.
• Scherp je beleid pas aan als al je eigen bronnen een paar weken slagen.
• Foutrapporten (ruf) zijn zeldzaam en niet nodig.

Quiz

Opdracht

Opdracht Z4.5: Een DMARC-rapport lezen. Open het voorbeeldbestand dmarc-rapport-1.xml (een verzamelrapport over example.com, met verzonnen gegevens). Beantwoord de vragen: welk beleid vond de ontvanger, hoeveel berichten staan er in totaal in het rapport, hoeveel daarvan faalden DMARC, welke rij is de nieuwsbriefdienst en wat moet daar gebeuren, welke rij is doorgestuurde mail, welke rij is waarschijnlijk vervalsing, wat moet er aan het SPF-record veranderen volgens rij 6, welke rij slaagt alleen dankzij DKIM bij een dienst met een eigen Return-Path, en mag het domein nu naar p=quarantine? Het programma kijkt je antwoorden na met een vaste sleutel en legt per vraag uit welke regel van het rapport het antwoord geeft.

Verder lezen

De stappen in deze artikelen gelden voor de panelen van WebOké; bij andere aanbieders werkt het vergelijkbaar.

• Wat is DMARC? Uitleg in gewone taal
• DirectAdmin handleiding 5.9: DMARC instellen
• Gratis DNS-cursus 4.5: DMARC: wat ontvangers moeten doen met nepmail
• RFC 9990 (DMARC Aggregate Reporting), met het voorbeeldrapport in bijlage B; RFC 9991 (Failure Reporting)