Zo leest u een DMARC-aggregaatrapport (rua) en wat u ermee doet

Een DMARC-aggregaatrapport is een dagelijkse samenvatting die grote mailboxproviders sturen naar het adres in de rua-tag van uw DMARC-record. Het somt elk IP-adres op dat mail verstuurde met uw domein in de From-veld, hoeveel berichten elk adres verstuurde, en of SPF en DKIM slaagden en overeenkwamen met uw domein (alignment). Het bevat geen berichtinhoud, onderwerpen of adressen van ontvangers.

Door deze rapporten te lezen, ontdekt u wie er werkelijk namens u verstuurt: uw eigen mailservers, het CRM, de facturatietool, het nieuwsbriefplatform, en iedereen die uw domein gewoon in de From-veld zet. Die lijst hebt u nodig voordat u uw beleid van p=none naar handhaving brengt.

Sinds mei 2026 is het formaat vastgelegd in RFC 9990, die samen met RFC 9989 (het DMARC-mechanisme zelf) de oudere RFC 7489 heeft vervangen. Wilt u de 3 records nog eens opfrissen, begin dan met SPF, DKIM en DMARC uitgelegd.

Hoe de rapporten bij u komen

U vraagt rapporten aan met de rua-tag in uw DMARC-record:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Elke deelnemende provider mailt u vervolgens een XML-bestand, meestal gecomprimeerd. Volgens RFC 9990 hoort de XML met GZIP gecomprimeerd te zijn (SHOULD), met de extensie .xml.gz, en de bestandsnaam volgt een vast patroon:

mail.receiver.example!example.com!1013662812!1013749130.xml.gz

Dat zijn de rapporterende organisatie, uw domein, en het begin en einde van de periode als Unix-tijdstempels. De rapportageperiode beslaat doorgaans 1 UTC-dag.

Moeten de rapporten naar een mailbox op een ander domein (bijvoorbeeld een rapportagedienst op reports.example.net), dan moet dat domein bevestigen dat het ze aanvaardt. Ontvangers zoeken een TXT-record zoals example.com._report._dmarc.reports.example.net met v=DMARC1, en als dat ontbreekt, negeren ze het rua-adres. Een ontbrekend bevestigingsrecord is een veelvoorkomende reden waarom rapporten nooit aankomen.

De opbouw van een rapport

Elk rapport heeft dezelfde 3 delen. Hieronder een ingekort voorbeeld op basis van het voorbeeld in RFC 9990:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <report_metadata>
    <org_name>Sample Reporter</org_name>
    <date_range><begin>302832000</begin><end>302918399</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>quarantine</p>
    <testing>n</testing>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.123</source_ip>
      <count>123</count>
      <policy_evaluated>
        <disposition>pass</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>example.com</envelope_from>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><result>pass</result><selector>abc123</selector></dkim>
      <spf><domain>example.com</domain><result>fail</result></spf>
    </auth_results>
  </record>
</feedback>

• report_metadata: wie het rapport verstuurde en welke periode het beslaat.
• policy_published: het DMARC-record dat de ontvanger zag. Vergelijk het met wat u denkt te hebben gepubliceerd.
• record: 1 blok per combinatie van verzendend IP-adres en resultaten. Een druk domein krijgt er veel.

Een record lezen, veld voor veld

source_ip en count. De server die verbinding maakte met de ontvanger en hoeveel berichten hij in die periode afleverde. Hier identificeert u de afzenders: een reverse DNS-opvraging (dig -x 192.0.2.123 +short) of de eigenaar van het IP-adres vertelt u vaak of het bij uw mailprovider, uw CRM of een onbekende hoort.

policy_evaluated. Het DMARC-oordeel. Hier zijn dkim en spf niet de ruwe resultaten maar de alignmentresultaten: slaagde de controle voor een domein dat overeenkomt met uw From-domein. DMARC slaagt als ten minste 1 ervan pass is. disposition toont wat de ontvanger deed: none, pass, quarantine of reject. Wijkt dat af van uw beleid, dan legt een reason-element uit waarom, bijvoorbeeld een uitzondering voor doorsturen of een mailinglijst.

identifiers. header_from is het domein dat uw ontvangers zagen. envelope_from is het domein dat de SPF-controle gebruikte, vaak een subdomein van uw verzenddienst in plaats van het uwe.

auth_results. De ruwe SPF- en DKIM-resultaten met de domeinen waarvoor ze zijn gecontroleerd. RFC 9990 vereist nu de DKIM-selector, zodat u kunt zien welke dienst het bericht heeft ondertekend.

In het voorbeeld hierboven slaagde DKIM en was het aligned, faalde SPF, en slaagde het bericht toch voor DMARC. Dat is een typisch beeld bij een dienst die met uw domein ondertekent maar vanaf zijn eigen envelopdomein verstuurt.

Afzenders indelen in 3 groepen

Na een paar weken rapporten past elk bron-IP in een van deze groepen:

1. Bekend en geslaagd. Uw mailprovider en correct ingestelde diensten. Niets te doen.
2. Bekend maar falend. Een legitieme tool (helpdesk, facturatie, nieuwsbrief) die verstuurt zonder aligned DKIM, of die ontbreekt in SPF. Schakel in die tool DKIM met uw domein in, of voeg hem toe aan SPF en let daarbij op de grens van 10 opvragingen.
3. Onbekend en falend. Servers die u aan niets kunt koppelen wat u gebruikt. Sommige zijn doorstuurdiensten en mailinglijsten; andere zijn van iemand die uw domein in de From-veld zet. Juist die berichten zou een beleid p=quarantine of p=reject tegenhouden, dezelfde soort mail die wordt gebruikt bij fraude met valse facturen.

Voordat u gaat handhaven, telt vooral groep 2. Schakelt u over naar p=quarantine terwijl een legitieme tool nog faalt, dan belandt de mail van die tool in spam.

Praktische tips

• Gebruik een aparte mailbox of een tool die rapporten verwerkt. Ruwe XML van meerdere providers per dag is met de hand moeilijk te lezen.
• Let op de waarde testing. RFC 9989 heeft de oude pct-tag vervangen door een testmodustag t; t=y vraagt ontvangers een mildere actie toe te passen dan uw beleid.
• Kijk naar volume, niet alleen naar fouten. Een plotseling nieuwe bron met een hoge count verdient aandacht, ook als hij slaagt.
• Bewaar rapporten een paar maanden, zodat u de situatie voor en na een wijziging kunt vergelijken.
• Houd er rekening mee dat mailboxproviders steeds vaker DMARC verwachten van afzenders met grote volumes, zoals beschreven in de afzendervereisten van Gmail en Yahoo.

Korte checklist

• DMARC-record met een rua-adres dat iemand echt leest.
• Externe rapportbestemmingen bevestigd met een _report._dmarc-record.
• Elk bron-IP gekoppeld aan een dienst die u kent.
• Aligned DKIM ingeschakeld voor elke legitieme afzender.
• Onbekende falende bronnen beoordeeld, daarna het beleid naar p=quarantine en later naar p=reject.

De rol van Guarding

DMARC-rapporten tonen wat ontvangers zagen. Wij bewaken dagelijks de andere kant van buitenaf: uw SPF-, DKIM- en DMARC-records, lookalike-domeinen en de rest van uw externe blootstelling. Wordt een record afgezwakt of verdwijnt een selector, dan beoordeelt een mens dat en krijgt u de precieze wijziging die u moet doorvoeren, zoals beschreven bij wat er gebeurt als we iets vinden. Hoe dat eruitziet, ziet u in het voorbeelddashboard.