Wat is ARF? Formaat voor het melden van misbruik en DMARC-foutmeldingen (RFC 5965)

Wat is ARF (Abuse Reporting Format)?

ARF staat voor Abuse Reporting Format. Het is een gestandaardiseerd, machinaal leesbaar formaat om afzenders te melden dat een e-mail een probleem heeft veroorzaakt. Het werd in 2010 gedefinieerd in RFC 5965, in een tijd waarin meldingen van misbruik meestal inconsistente e-mails in platte tekst waren die e-mailbeheerders met de hand moesten doorlezen. Dat werkte prima toen het volume nog laag was, maar het systeem stortte in zodra providers iets wilden automatiseren. ARF bood ontvangers, internetproviders en mailboxaanbieders een gemeenschappelijke structuur, zodat misbruikgebeurtenissen aan domeineigenaren en afzenders konden worden gemeld in een formaat dat scripts en parsers gemakkelijk konden verwerken.

Tegenwoordig komt ARF op vier belangrijke plaatsen voor:

• DMARC-foutmeldingen – wanneer een bericht de DMARC-authenticatie niet doorstaat, kan een ontvanger een ARF-rapport versturen waarin precies wordt beschreven wat er mis is gegaan.
• Feedbacklussen van internetproviders – wanneer een ontvanger op ‘dit is spam’ klikt, sturen sommige providers die klacht in ARF-formaat terug naar de afzender.
• Klachten bij de meldpuntdienst – handmatig ingediende meldingen van misbruik die via geautomatiseerde systemen voor de afhandeling van misbruik worden doorgestuurd.
• Meldingen van phishing en fraude – meldingen waarbij een bericht als frauduleus wordt aangemerkt, en niet alleen als ongewenst.

Even voor de duidelijkheid: deze afkorting ARF heeft niets te maken met andere afkortingen waar je misschien aan denkt. In de e-mailwereld staat ARF altijd voor „Abuse Reporting Format”.

Hoe een ARF-rapport is opgebouwd (de drie delen)

RFC 5965 definieert ARF als een MIME-bericht van het type „multipart/report“, wat simpelweg betekent dat het een e-mail is die bestaat uit drie afzonderlijke onderdelen die aan elkaar zijn gekoppeld. Elk onderdeel is bedoeld voor een andere ontvanger: één is voor een mens, één is voor een machine en één dient als bewijsstuk.

Deel 1: Voor mensen leesbare samenvatting (text/plain)

Het eerste deel is een blok met platte tekst dat bedoeld is voor iemand die zijn inbox doorbladert. Het bevat meestal een samenvatting van één of twee regels over wat er is gebeurd, zodat iemand die het rapport vluchtig doorneemt, de machinaal leesbare velden niet hoeft te ontcijferen om de kern van het verhaal te begrijpen.

Deel 2: Machinaal leesbaar rapport (message/feedback-report)

Dit is de kern van het rapport en het gedeelte dat door geautomatiseerde systemen daadwerkelijk wordt geanalyseerd. Het bestaat uit een reeks sleutel-waarde-velden, zoals Feedback-Type, Version, User-Agent, Source-IP en Arrival-Date, naast authenticatiespecifieke velden zoals Auth-Failure. Hierin ligt de diagnostische waarde van het rapport.

Deel 3: Het oorspronkelijke bericht (message/rfc822 of text/rfc822-headers)

Het laatste deel bevat ofwel het volledige oorspronkelijke bericht, ofwel alleen de kopteksten ervan, afhankelijk van hoe de afzender de instellingen heeft geconfigureerd en hoeveel details de ontvanger bereid is te delen. Aangezien de inhoud van het bericht persoonlijke gegevens kan bevatten, beperken veel ontvangers dit tot alleen de kopteksten, of maken ze delen ervan onleesbaar, voordat ze het rapport doorsturen.

Soorten feedback binnen het ARF

Het veld ‘Feedbacktype’ geeft aan om wat voor soort rapport het gaat:

Voor DMARC-doeleinden zul je hier altijd slechts één waarde zien: auth-failure. Er kunnen aanvullende feedbacktypes bij IANA worden geregistreerd als er zich een nieuwe gebruikssituatie voordoet, maar voor DMARC is het altijd bij auth-failure gebleven, vanaf het allereerste begin.

ARF, AFRF, RUF, forensische rapporten: de terminologie ontrafeld

Als je je hebt verdiept in DMARC-rapportage en hebt gemerkt dat de termen ARF, AFRF, RUF en ‘forensisch rapport’ bijna door elkaar worden gebruikt, dan verbeeld je je dat niet. Deze termen overlappen elkaar inderdaad, en hieronder leg ik uit hoe ze precies met elkaar verband houden:

• ARF is het basisbestandsformaat dat in RFC 5965 is gedefinieerd. Het is een algemeen formaat en is nooit specifiek voor DMARC geweest.
• AFRF (Authentication Failure Reporting Format) is de in RFC 6591 gedefinieerde uitbreiding waarmee ARF specifiek is aangepast voor het rapporteren van authenticatiefouten bij SPF, DKIM en DMARC.
• RUF is de DMARC-tag (ruf=) die je in je DNS-record opneemt om aan te geven dat er per bericht foutmeldingen naar een bepaalde bestemming moeten worden verzonden.
• 'Forensic report' is de oudere benaming voor ditzelfde artefact, overgenomen uit de oorspronkelijke DMARC-specificatie, RFC 7489. In de huidige reeks RFC’s wordt het in plaats daarvan een ‘failure report’ genoemd.

Dus als iemand vraagt naar een „voorbeeld van een forensisch rapport“ en iemand anders het een „DMARC-foutrapport“ noemt, hebben ze het over hetzelfde. De benaming is veranderd met de standaard, niet het onderliggende mechanisme.

ARF en DMARC: uitleg over foutmeldingen

Wanneer je een ruf=-tag toevoegt aan je DMARC-DNS-record, vraag je ontvangende mailservers om je een rapport te sturen telkens wanneer een bericht dat beweert afkomstig te zijn van jouw domein, niet voldoet aan de DMARC-regels. In tegenstelling tot geaggregeerde rapporten, die het verkeer van een hele dag bundelen in één XML-overzicht, zijn foutmeldingen bedoeld om kort na het moment van de fout te worden gegenereerd en hebben ze betrekking op één enkel bericht.

Een DMARC-foutmelding geeft je informatie die een geaggregeerd rapport niet kan bieden: de authenticatieresultaten voor dat specifieke bericht, details over welk mechanisme precies heeft gefaald, informatie over de afzender en ofwel het volledige bericht of de headers ervan, zodat je kunt achterhalen waar het daadwerkelijk vandaan kwam. Juist dat detailniveau maakt foutmeldingen zo nuttig om een spoofingpoging vrijwel in realtime op te sporen – ervan uitgaande dat je er daadwerkelijk een ontvangt, wat ons bij de volgende paragraaf brengt.

Wat er in RFC 9991 is gewijzigd (update 2026)

In mei 2026 heeft de IETF een nieuwe reeks DMARC-documenten gepubliceerd die de oorspronkelijke RFC 7489 vervangen: RFC 9989 (kern-DMARC), RFC 9990 (geaggregeerde/RUA-rapportage) en RFC 9991 (fout-/RUF-rapportage). Samen maken deze documenten RFC 7489 overbodig. Dit is wat er concreet is veranderd voor foutmeldingen:

• De RFC-reeks is gewijzigd: RFC 9991 heeft nu betrekking op het melden van storingen en vervangt de paragrafen over storingsmeldingen in RFC 7489. Daarnaast wordt RFC 6591 (AFRF) bijgewerkt met een nauwkeurigere lijst van verplichte velden.
• Het ARF-bestandsformaat zelf is niet veranderd: RFC 5965 vormt nog steeds het onderliggende basisformaat.
• Een nieuw verplicht veld: Identity-Alignment: een door komma’s gescheiden lijst waarin wordt aangegeven welk mechanisme, DKIM of SPF, er niet in is geslaagd een afgestemde identificatiecode te genereren, of „none” als een afgestemde identificatiecode wel tot authenticatie heeft geleid. Dit is het nuttigste veld voor iedereen die een rapport leest, omdat het direct aangeeft of er sprake is van een verkeerde configuratie of van regelrechte spoofing,
• Een nieuw type authenticatiefout: dmarc: wordt specifiek gebruikt wanneer het bericht niet door een bijbehorende identificatiecode is geauthenticeerd, in tegenstelling tot een algemene SPF- of DKIM-fout.
• Nieuwe verplichte velden voor het vaststellen van afstemmingsfouten: DKIM-Domain, DKIM-Identity en DKIM-Selector zijn verplicht wanneer een afgestemde DKIM-handtekening is mislukt. SPF-DNS is verplicht wanneer een afgestemde SPF-controle is mislukt.
• Nieuwe optionele velden voor extra details: ‘Delivery-Result’ en het paar ‘DKIM-Canonicalized-Header/Body’, beschikbaar wanneer een ontvanger meer diagnostische context wil opnemen.

Waarom afstemming op identiteit zo belangrijk is

DMARC controleerde nooit echt of SPF of DKIM afzonderlijk in orde waren; het controleert of een geauthenticeerde identificatie overeenkomt met het domein in het zichtbare „From:”-adres. Een bericht kan technisch gezien zowel aan de SPF- als aan de DKIM-vereisten voldoen en toch niet door de DMARC-controle komen als geen van beide overeenkomt met het „From:”-domein. Dit veld maakt dat duidelijk.

RUA versus RUF: Geaggregeerde rapporten versus foutmeldingen

Aanbeveling (dezelfde als eerder)

Stel in uw DMARC-record altijd `rua=` in. Grote e-mailproviders ondersteunen op grote schaal DMARC Aggregate-rapporten en bieden het dagelijkse inzicht dat u nodig hebt om de authenticatie te controleren. Het instellen van `ruf=` is optioneel en kan aanvullende diagnostische informatie opleveren, maar veel ontvangers sturen geen forensische rapporten, dus beschouw deze als een aanvullende gegevensbron.

Hoe lees je een ARF-rapport (voorbeeld per veld)

Hieronder volgt een voorbeeld van hoe een DMARC-foutmelding eruit zou kunnen zien bij een ‘direct-domain spoof’, waarbij een aanvaller een e-mail verstuurt die zogenaamd afkomstig is van uw domein, maar zonder geldige SPF- of DKIM-verificatie:

Feedback-Type: auth-failure
Version: 1
User-Agent: MailReceiver/2.1
Auth-Failure: dmarc
Identity-Alignment: dkim, spf
Original-Mail-From: <[email protected]>
Reported-Domain: yourdomain.com
Source-IP: 198.51.100.44
SPF-DNS: v=spf1 include:_spf.yourdomain.com ~all
Authentication-Results: mx.receiver.example;
    dmarc=fail (p=reject) header.from=yourdomain.com;
    spf=fail smtp.mailfrom=spoofed-source.net;
    dkim=none
Arrival-Date: Wed, 22 Jul 2026 09:14:02 +0000

Een wandeling door de velden die er het meest toe doen:

• Het feedbacktype ‘auth-failure’ bevestigt dat het hier om een authenticatieprobleem gaat, en niet om een melding van spam of misbruik.
• Auth-Failure: dmarc geeft aan dat het specifiek gaat om een DMARC-alignment-fout, het type dat is geïntroduceerd door RFC 9991.
• Identiteitsafstemming: dkim, spf is de belangrijkste diagnostische regel. Beide mechanismen konden geen afgestemde identificatiecode genereren, wat in combinatie met het ontbreken van een geldige DKIM-handtekening en een mislukte SPF-controle sterk wijst op regelrechte spoofing in plaats van een verkeerde configuratie aan uw kant.
• De velden ‘Source-IP’ en ‘Original-Mail-From’ geven aan waar het bericht daadwerkelijk vandaan komt; dit is handig voor het opstellen van blokkeerlijsten of voor nader onderzoek.
• Met ‘Reported-Domain’ kun je nagaan welk van je domeinen het doelwit was; handig als je er meerdere beheert.
• SPF-DNS geeft het SPF-record weer dat de ontvanger heeft gecontroleerd; zo kun je nagaan of je eigen record correct is gelezen.

Als dit daarentegen een legitieme externe afzender was geweest die je vergeten was te autoriseren, zou je doorgaans zien dat bij ‘Identity-Alignment’ slechts één mechanisme wordt genoemd, terwijl het andere een ‘pass’ aangeeft, wat erop wijst dat het om een configuratiefout gaat in plaats van een aanval.

Waarom je mogelijk geen foutmeldingen ontvangt

Als je ruf= hebt ingesteld en de rapporten verschijnen nooit, of komen slechts sporadisch binnen, zijn daar verschillende legitieme redenen voor:

1. De grote aanbieders sturen ze meestal niet

Gmail en Yahoo, die voor de meeste domeinen tot de grootste bronnen van inkomende e-mail behoren, genereren doorgaans geen foutmeldingen...

2. Privacy en roodmaking

Foutmeldingen kunnen persoonlijke gegevens uit de kopteksten of de hoofdtekst van berichten onthullen, waardoor de afzender risico’s loopt in het kader van de AVG en de CCPA. RFC 6590 behandelt het verwijderen van gevoelige gegevens uit meldingen van misbruik, maar door die gegevens te verwijderen kan een groot deel van de informatie die de melding in de eerste plaats nuttig maakte, verloren gaan.

3. Externe bestemmingen moeten worden geverifieerd

Als uw ruf=-adres naar een locatie buiten het domein van uw eigen organisatie verwijst, schrijft RFC 9991 voor dat de ontvanger een externe bestemmingscontrole moet uitvoeren (hetzelfde mechanisme dat in RFC 9990 voor geaggregeerde rapporten wordt gedefinieerd) voordat er iets naar dat adres wordt verzonden. Zonder dat autorisatierecord zullen de rapporten niet aankomen.

4. Er wordt verwacht dat er een snelheidsbeperking zal optreden

RFC 9991 roept verslaggevers op om het aantal foutmeldingen dat zij naar één bepaalde ontvanger sturen te beperken, deels om te voorkomen dat een mailbox wordt overspoeld en deels om meldingslussen te voorkomen.

5. Geen storingen, geen meldingen

Als je legitieme e-mail correct wordt geverifieerd, is er sowieso geen reden om een foutmelding te genereren.

6. De instellingen van je fo-tag

De fo=-tag bepaalt precies wanneer er een melding wordt gegenereerd: bij fo=0 (de standaardinstelling) wordt alleen een melding gegenereerd als zowel SPF als DKIM mislukken of niet overeenkomen; bij fo=1 wordt een melding gegenereerd als een van beide mislukt; bij fo=d wordt specifiek een melding gegenereerd bij een DKIM-fout; en bij fo=s wordt specifiek een melding gegenereerd bij een SPF-fout. De meeste domeinen die daadwerkelijk nuttige diagnostische informatie willen ontvangen, stellen fo=1 in.

Feedbacklussen via e-mail en ARF

Foutmeldingen zijn niet de enige plek waar ARF voorkomt. Feedbackloops van internetproviders (waaronderde Complaint Feedback Loop van Yahoo en de JMRP/SNDS -programma’s van Microsoft ) maken gebruik van precies hetzelfde ARF-formaat, alleen is bij ‘Feedback-Type’ de waarde ‘abuse’ ingesteld in plaats van ‘auth-failure’.

Deze rapporten worden gegenereerd wanneer een ontvanger een bericht als spam markeert, en ze vormen een nuttig vroege waarschuwing voor bezorgingsproblemen, ook al houden ze helemaal geen verband met DMARC.

Hoe u ARF / foutmeldingen voor uw domein instelt

Als je wilt beginnen met het verzamelen van storingsmeldingen voor je domein:

1. Voeg een ruf=-tag toe aan je DMARC-DNS-record, die verwijst naar een speciale mailbox of een rapportageadres.

2. Stel fo in op 1 als je rapporten wilt ontvangen bij een SPF- of een DKIM-fout, in plaats van alleen wanneer beide mislukken.

3. Als het ruf=-adres buiten het domein van uw organisatie ligt, zorg er dan voor dat het autorisatierecord voor externe bestemmingen is ingesteld, anders zullen ontvangers daar niets naartoe verzenden.

4. Meld je afzonderlijk aan voor feedbackloop-programma’s bij de grote internetproviders, aangezien deze volledig buiten DMARC om verlopen.

5. Ga er niet vanuit dat je deze rapporten met de hand in grote hoeveelheden kunt doorlezen. Zelfs een kleine hoeveelheid e-mail kan al meer onbewerkte ARF-rapporten opleveren dan je handmatig kunt verwerken. Hier komt een geautomatiseerde DMARC-rapportanalysator goed van pas.

Samenvattend

Foutmeldingen vormen een specifieke toepassing van ARF binnen DMARC. RUF biedt u uitgebreide details per bericht zodra dit binnenkomt, maar een aanzienlijk deel van de ontvangers verstuurt deze gegevens niet, waardoor geaggregeerde (RUA) rapportage uw betrouwbare, dagelijkse bron van inzicht vormt. Nu de DMARC-standaard officieel is vastgelegd in RFC 9989, RFC 9990 en RFC 9991, is het belangrijker dan ooit om de terminologie en details correct te gebruiken, vooral als u een daadwerkelijk spoofingincident oplost in plaats van een eenvoudige configuratiefout.

Als u voor het eerst rapportages instelt of deze gegevens wilt inzien zonder zelf de onbewerkte ARF-berichten te moeten ontleden, dan is onze DMARC Report Analyzer precies daarvoor ontworpen. Meld u vandaag nog aan voor een gratis proefperiode en bekijk uw rapporten zonder gedoe!

Veelgestelde Vragen

Wat is een (forensisch) rapport over een DMARC-fout?

Het is een ARF-rapport per bericht dat wordt gegenereerd wanneer een e-mail de DMARC-authenticatie niet doorstaat. Het bevat details over het specifieke bericht, waaronder welke authenticatiemechanismen zijn mislukt en of deze een identificatiecode hebben opgeleverd die overeenkomt met het „From:“-domein. „Forensisch rapport“ is de oudere benaming voor hetzelfde, overgenomen uit RFC 7489.

Wat is het verschil tussen RUA en RUF in DMARC?

RUA-rapporten (geaggregeerd) zijn dagelijkse XML-overzichten van alle e-mailberichten die afkomstig zijn van een domein, zoals nu gedefinieerd in RFC 9990. RUF-rapporten (foutmeldingen) zijn bijna realtime ARF-rapporten over individuele berichten die niet zijn aangekomen, zoals gedefinieerd in RFC 9991. RUA wordt op grote schaal ondersteund; RUF is optioneel en wordt niet altijd verzonden.

Wie verstuurt DMARC-foutmeldingen?

Slechts enkele e-mailclients genereren ze überhaupt, en grote e-mailproviders zoals Gmail en Yahoo doen dat doorgaans niet. De ondersteuning verschilt per e-mailclient, en privacyoverwegingen, vereisten inzake tariefbeperking en regels voor bestemmingsverificatie volgens RFC 9991 zorgen er allemaal voor dat ze in de praktijk minder vaak aankomen.

Wat is het verschil tussen ARF en XARF?

ARF (RFC 5965) is het door de IETF gestandaardiseerde formaat dat wordt gebruikt in DMARC-foutmeldingen en feedbackloops van internetproviders. XARF is een eigen, door een leverancier ontwikkelde uitbreiding die een JSON-payload toevoegt om het parseren te vergemakkelijken. Het is geen IETF-standaard en wordt door grote providers niet gebruikt voor DMARC-rapportage.

Waarom ontvang ik geen DMARC-foutmeldingen?

Mogelijke oorzaken zijn onder meer het verzenden naar grote providers die deze rapporten niet genereren, het inkorten van het rapport door privacyredactie, het ontbreken van een extern verificatierecord voor de bestemming als je ruf=-adres buiten het domein valt, verplichte tariefbeperking aan de kant van de ontvanger, of simpelweg het feit dat er überhaupt geen authenticatiefouten zijn om te rapporteren. Je fo=-taginstelling bepaalt ook precies wanneer een rapport wordt geactiveerd.

• Over
• Laatste berichten

Ahona Rudra

Expert op het gebied van domein- en e-mailbeveiliging bij PowerDMARC

Ahona is marketingmanager bij PowerDMARC en heeft meer dan vijf jaar ervaring met het schrijven over cybersecurity, gespecialiseerd in domein- en e-mailbeveiliging. Ahona heeft een masterdiploma in journalistiek en communicatie, en heeft sinds 2019 haar carrière in de beveiligingssector verder uitgebouwd.

Laatste berichten van Ahona Rudra (Bekijk alle berichten)

• Wat is ARF? Formaat voor het melden van misbruik en DMARC-foutmeldingen (RFC 5965) - 24 juli 2026
• De meeste financiële instellingen beschikken over DMARC. Bijna geen enkele is daardoor beschermd. - 22 juli 2026
• Wat is MFA-moeheid (push-bombing)? - 21 juli 2026