Was ist ARF? Format zur Meldung von Missbrauch und DMARC-Fehlerberichte (RFC 5965)

Was ist ARF (Abuse Reporting Format)?

ARF steht für „Abuse Reporting Format“. Es handelt sich um ein standardisiertes, maschinenlesbares Format, um Absender darüber zu informieren, dass eine E-Mail ein Problem verursacht hat. Es wurde bereits 2010 in RFC 5965 definiert, zu einer Zeit, als Missbrauchsmeldungen meist uneinheitliche E-Mails im Klartext waren, die Mail-Administratoren von Hand lesen mussten. Das funktionierte gut, solange das Volumen gering war, versagte jedoch in dem Moment, als Anbieter begannen, Prozesse zu automatisieren. ARF bot Empfängern, Internetdienstanbietern und E-Mail-Anbietern eine einheitliche Struktur, sodass Missbrauchsfälle den Domain-Inhabern und Absendern in einem Format gemeldet werden konnten, das Skripte und Parser problemlos verarbeiten konnten.

Heute taucht ARF an vier Hauptorten auf:

• DMARC-Fehlerberichte – Wenn eine Nachricht die DMARC-Authentifizierung nicht besteht, kann der Empfänger einen ARF-Bericht senden, in dem genau beschrieben wird, was schiefgelaufen ist.
• ISP-Feedback-Schleifen – Wenn ein Empfänger auf „Das ist Spam“ klickt, leiten einige Provider diese Beschwerde im ARF-Format an den Absender weiter.
• Beschwerden über den Abuse-Desk – manuell gemeldete Missbrauchsfälle, die über automatisierte Systeme zur Bearbeitung von Missbrauchsfällen weitergeleitet werden.
• Phishing- und Betrugsmeldungen – Meldungen, die eine Nachricht als betrügerisch und nicht nur als unerwünscht kennzeichnen.

Um das gleich klarzustellen: Dieses ARF hat nichts mit anderen Abkürzungen zu tun, an die Sie vielleicht gerade denken. In der E-Mail-Welt steht ARF immer für „Abuse Reporting Format“ (Format zur Meldung von Missbrauch).

Wie ein ARF-Bericht aufgebaut ist (die drei Teile)

RFC 5965 definiert ARF als eine MIME-Nachricht vom Typ „multipart/report“, was einfach bedeutet, dass es sich um eine E-Mail handelt, die aus drei verschiedenen, miteinander verbundenen Teilen besteht. Jeder Teil richtet sich an einen anderen Leser: einer ist für Menschen bestimmt, einer für Maschinen und einer dient als Nachweis.

Teil 1: Für Menschen lesbare Zusammenfassung (text/plain)

Der erste Teil ist ein Klartextblock, der für Personen gedacht ist, die ihren Posteingang überfliegen. Er enthält in der Regel eine ein- oder zweizeilige Zusammenfassung des Geschehens, sodass jemand, der den Bericht nur flüchtig überfliegt, die maschinenlesbaren Felder nicht analysieren muss, um den Kern des Berichts zu verstehen.

Teil 2: Maschinell lesbarer Bericht (message/feedback-report)

Dies ist der Kern des Berichts und der Teil, den automatisierte Systeme tatsächlich auswerten. Es handelt sich um einen Block aus Schlüssel-Wert-Feldern wie „Feedback-Type“, „Version“, „User-Agent“, „Source-IP“ und „Arrival-Date“ sowie um authentifizierungsspezifische Felder wie „Auth-Failure“. Hier liegt der eigentliche diagnostische Wert des Berichts.

Teil 3: Die ursprüngliche Nachricht (message/rfc822 oder text/rfc822-headers)

Der letzte Teil enthält entweder die vollständige Originalnachricht oder nur deren Kopfzeilen – je nachdem, wie der Absender die Einstellungen vorgenommen hat und wie viele Details der Empfänger preisgeben möchte. Da der Inhalt der Nachricht persönliche Informationen enthalten kann, beschränken viele Empfänger diesen Teil auf die Kopfzeilen oder schwärzen Teile davon, bevor sie den Bericht weiterleiten.

ARF-Feedback-Typen

Das Feld „Feedback-Typ“ gibt Auskunft darüber, um welche Art von Bericht es sich handelt:

Im Zusammenhang mit DMARC wird hier immer nur ein Wert angezeigt: „auth-failure“. Weitere Feedback-Typen können bei der IANA registriert werden, falls sich ein neuer Anwendungsfall ergibt, doch im DMARC-Anwendungsfall wird seit jeher ausschließlich „auth-failure“ verwendet.

ARF, AFRF, RUF, forensische Gutachten: Die Terminologie entwirren

Wenn Sie sich mit DMARC-Berichten beschäftigt haben und festgestellt haben, dass die Begriffe ARF, AFRF, RUF und „forensischer Bericht“ fast synonym verwendet werden, dann bilden Sie sich das nicht nur ein. Diese Begriffe überschneiden sich tatsächlich, und hier erfahren Sie, in welchem Zusammenhang sie stehen:

• ARF ist das in RFC 5965 definierte Basis-Wire-Format. Es ist generisch und war nie DMARC-spezifisch.
• AFRF (Authentication Failure Reporting Format) ist die in RFC 6591 definierte Erweiterung, mit der ARF speziell für die Meldung von SPF-, DKIM- und DMARC-Authentifizierungsfehlern angepasst wurde.
• RUF ist das DMARC-Tag (ruf=), das Sie in Ihren DNS-Eintrag einfügen, um festzulegen, dass Fehlerberichte für einzelne Nachrichten an eine bestimmte Adresse gesendet werden sollen.
• „Forensic Report“ ist die ältere Bezeichnung für dasselbe Artefakt, die aus der ursprünglichen DMARC-Spezifikation (RFC 7489) übernommen wurde. In den aktuellen RFCs wird es stattdessen als „Failure Report“ bezeichnet.

Wenn also jemand nach einem „Beispiel für einen forensischen Bericht“ fragt und ein anderer davon als „DMARC-Fehlerbericht“ spricht, meinen beide dasselbe. Die Bezeichnung hat sich mit dem Standard geändert, nicht der zugrunde liegende Mechanismus.

ARF und DMARC: Fehlerberichte erklärt

Wenn Sie Ihrem DMARC-DNS-Eintrag ein „ruf=“-Tag hinzufügen, fordern Sie damit die empfangenden Mailserver auf, Ihnen jedes Mal einen Bericht zu senden, wenn eine Nachricht, die angeblich von Ihrer Domain stammt, die DMARC-Prüfung nicht besteht. Im Gegensatz zu aggregierten Berichten, bei denen der gesamte Datenverkehr eines Tages in einer XML-Zusammenfassung zusammengefasst wird, sollen Fehlerberichte zeitnah zum Zeitpunkt des Fehlers erstellt werden und sich auf eine einzelne Nachricht beziehen.

Ein DMARC-Fehlerbericht liefert Ihnen Informationen, die ein aggregierter Bericht nicht bieten kann: die Authentifizierungsergebnisse für diese bestimmte Nachricht, Details darüber, welcher Mechanismus genau versagt hat, Informationen zur Absenderquelle sowie entweder die vollständige Nachricht oder deren Header, damit Sie nachvollziehen können, woher sie tatsächlich stammt. Gerade dieser Detaillierungsgrad macht Fehlerberichte so nützlich, um Spoofing-Versuche nahezu in Echtzeit aufzudecken – vorausgesetzt, Sie erhalten tatsächlich einen solchen Bericht, was uns zum nächsten Abschnitt bringt.

Was sich durch RFC 9991 geändert hat (Aktualisierung 2026)

Im Mai 2026 veröffentlichte die IETF eine neue Reihe von DMARC-Dokumenten, die den ursprünglichen RFC 7489 ersetzen: RFC 9989 (DMARC-Kern), RFC 9990 (Aggregat-/RUA-Berichterstattung) und RFC 9991 (Fehler-/RUF-Berichterstattung). Zusammen machen sie RFC 7489 hinfällig. Hier sind die konkreten Änderungen bei den Fehlerberichten:

• Die RFC-Reihe hat sich geändert: RFC 9991 behandelt nun die Fehlermeldung und ersetzt die Abschnitte zur Fehlermeldung in RFC 7489. Außerdem aktualisiert er RFC 6591 (AFRF) mit einer präziseren Auflistung der erforderlichen Felder.
• Das ARF-Wire-Format selbst hat sich nicht geändert: RFC 5965 ist nach wie vor das zugrunde liegende Basisformat.
• Ein neues Pflichtfeld: „Identity-Alignment“: Eine durch Kommas getrennte Liste, in der angegeben wird, welcher Mechanismus – DKIM oder SPF – keinen abgeglichenen Identifikator erzeugen konnte, oder „none“, falls ein abgeglichener Identifikator die Authentifizierung erfolgreich durchgeführt hat. Dies ist das nützlichste Feld für jeden, der einen Bericht liest, da es direkt Aufschluss darüber gibt, ob es sich um eine Fehlkonfiguration oder um regelrechten Spoofing handelt,
• Ein neuer Auth-Failure-Typ: dmarc: Wird speziell dann verwendet, wenn kein abgeglichener Identifikator die Nachricht authentifiziert hat – im Gegensatz zu einem generischen SPF- oder DKIM-Fehler.
• Neue Pflichtfelder zur Diagnose von Abgleichfehlern: „DKIM-Domain“, „DKIM-Identity“ und „DKIM-Selector“ sind erforderlich, wenn eine abgeglichene DKIM-Signatur fehlgeschlagen ist. „SPF-DNS“ ist erforderlich, wenn eine abgeglichene SPF-Prüfung fehlgeschlagen ist.
• Neue optionale Felder für zusätzliche Details: „Delivery-Result“ und das Paar „DKIM-Canonicalized-Header/Body“, die verfügbar sind, wenn ein Empfänger weitere diagnostische Informationen angeben möchte.

Warum die Identitätsausrichtung so wichtig ist

DMARC hat nie wirklich geprüft, ob SPF oder DKIM für sich genommen den Test bestanden haben, sondern es wird geprüft, ob eine authentifizierte Kennung mit der Domain in der sichtbaren „From:“-Adresse übereinstimmt. Eine Nachricht kann sowohl SPF als auch DKIM technisch bestehen und dennoch den DMARC-Test nicht bestehen, wenn keine der beiden mit der „From:“-Domain übereinstimmt. Dieses Feld macht dies direkt deutlich.

RUA vs. RUF: Gesamtberichte vs. Fehlerberichte

Empfehlung (wie zuvor)

Konfigurieren Sie in Ihrem DMARC-Eintrag stets „rua=“. Die großen E-Mail-Anbieter unterstützen DMARC-Aggregatberichte weitgehend und bieten Ihnen die tägliche Transparenz, die Sie zur Überwachung der Authentifizierung benötigen. Die Konfiguration von „ruf=“ ist optional und kann zusätzliche Diagnosedaten liefern, doch da viele Empfänger keine forensischen Berichte versenden, sollten Sie diese als ergänzende Datenquelle betrachten.

So lesen Sie einen ARF-Bericht (Beispiel mit Erläuterungen zu den einzelnen Feldern)

Im Folgenden finden Sie ein Beispiel dafür, wie ein DMARC-Fehlerbericht bei einer „Direct-Domain-Spoofing“-Attacke aussehen könnte, bei der ein Angreifer eine E-Mail versendet, die vorgibt, von Ihrer Domain zu stammen, ohne dass ein gültiger SPF- oder DKIM-Eintrag dahintersteht:

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

Ein Spaziergang durch die Felder, die am wichtigsten sind:

• Der Feedback-Typ „auth-failure“ bestätigt, dass es sich um eine Beschwerde bezüglich der Authentifizierung handelt und nicht um eine Spam- oder Missbrauchsmeldung.
• Auth-Failure: dmarc gibt an, dass es sich bei dem Fehler konkret um einen DMARC-Alignment-Fehler handelt, wie er durch RFC 9991 eingeführt wurde.
• Identitätsabgleich: „dkim, spf“ ist die entscheidende Diagnosenzeile. Bei beiden Mechanismen konnte kein abgeglichener Identifikator ermittelt werden, was in Verbindung mit einer fehlenden gültigen DKIM-Signatur und einer fehlgeschlagenen SPF-Prüfung stark auf eine regelrechte Fälschung hindeutet und nicht auf eine Fehlkonfiguration Ihrerseits.
• Die Felder „Source-IP“ und „Original-Mail-From“ geben Auskunft darüber, woher die Nachricht tatsächlich stammt – nützlich für die Aufnahme in Sperrlisten oder weitere Untersuchungen.
• „Reported-Domain“ zeigt an, welche Ihrer Domains betroffen war – besonders praktisch, wenn Sie mehrere Domains verwalten.
• SPF-DNS zeigt den SPF-Eintrag an, anhand dessen der Empfänger die Überprüfung durchgeführt hat. So können Sie überprüfen, ob Ihr eigener Eintrag korrekt gelesen wurde.

Wäre es sich stattdessen um einen legitimen Drittanbieter-Absender gehandelt, dessen Zugriff Sie vergessen hatten zu autorisieren, würde „Identity-Alignment“ in der Regel nur einen Mechanismus nennen, während der andere als „bestanden“ angezeigt würde – was darauf hindeutet, dass es sich eher um eine Konfigurationskorrektur als um einen Angriff handelt.

Warum Sie möglicherweise keine Fehlermeldungen erhalten

Wenn Sie „ruf=“ eingerichtet haben und die Berichte nie erscheinen oder nur spärlich eingehen, gibt es dafür mehrere plausible Gründe:

1. Die großen Anbieter versenden diese meist nicht

Gmail und Yahoo, die für die meisten Domains zu den größten Absendern eingehender E-Mails zählen, generieren in der Regel keine Fehlerberichte.

2. Datenschutz und Schwärzung

Fehlermeldungen können personenbezogene Daten aus den Kopfzeilen oder dem Textkörper von Nachrichten offenlegen, was für den Absender ein Risiko hinsichtlich der DSGVO und des CCPA darstellt. RFC 6590 regelt die Schwärzung sensibler Daten in Missbrauchsmeldungen, doch durch diese Schwärzung kann ein Großteil dessen verloren gehen, was die Meldung ursprünglich erst nützlich gemacht hat.

3. Externe Ziele müssen überprüft werden

Wenn Ihre „ruf=“-Adresse auf eine Stelle außerhalb Ihrer eigenen Organisationsdomäne verweist, schreibt RFC 9991 vor, dass der Empfänger eine externe Zielüberprüfung durchführen muss (derselbe Mechanismus, den RFC 9990 für aggregierte Berichte definiert), bevor er etwas dorthin sendet. Ohne diesen Autorisierungsdatensatz kommen die Berichte nicht an.

4. Es ist mit einer Ratenbegrenzung zu rechnen

RFC 9991 fordert die Absender auf, die Anzahl der Fehlermeldungen, die sie an einen einzelnen Empfänger senden, zu begrenzen – zum einen, um eine Überlastung des Postfachs zu vermeiden, und zum anderen, um Melde-Schleifen zu verhindern.

5. Keine Ausfälle, keine Meldungen

Wenn Ihre legitimen E-Mails die Authentifizierung einwandfrei durchlaufen, gibt es gar keinen Grund, der eine Fehlermeldung auslösen könnte.

6. Ihre Einstellungen für das „fo“-Tag

Das „fo=“-Tag steuert genau, wann eine Meldung ausgelöst wird: „fo=0“ (Standardeinstellung) löst nur dann eine Meldung aus, wenn sowohl SPF als auch DKIM fehlschlagen oder nicht übereinstimmen; „fo=1“ löst eine Meldung aus, wenn eines der beiden Verfahren fehlschlägt; „fo=d“ meldet speziell einen DKIM-Fehler, und „fo=s“ meldet speziell einen SPF-Fehler. Die meisten Domains, die tatsächlich nützliche Diagnosedaten erhalten möchten, setzen „fo=1“.

E-Mail-Feedbackschleifen und ARF

Fehlerberichte sind nicht der einzige Ort, an dem ARF zum Einsatz kommt. Auch Feedback-Schleifen von Internetdienstanbietern (darunterdie „Complaint Feedback Loop“ von Yahoo und die JMRP/SNDS- Programme von Microsoft ) verwenden genau dasselbe ARF-Format, lediglich mit dem Wert „abuse“ anstelle von „auth-failure“ für den Parameter „Feedback-Type“.

Diese Berichte werden ausgelöst, wenn ein Empfänger eine Nachricht als Spam markiert, und sie sind ein nützliches Frühwarnsignal für Zustellbarkeitsprobleme, auch wenn sie überhaupt nichts mit DMARC zu tun haben.

So richten Sie ARF / Fehlerberichte für Ihre Domain ein

Wenn Sie damit beginnen möchten, Fehlermeldungen für Ihre Domain zu sammeln:

1. Fügen Sie Ihrem DMARC-DNS-Eintrag ein „ruf=“-Tag hinzu, das auf ein spezielles Postfach oder eine Meldeadresse verweist.

2. Setzen Sie „fo=1“, wenn Sie Berichte sowohl bei einem SPF- als auch bei einem DKIM-Fehler erhalten möchten und nicht nur, wenn beide fehlschlagen.

3. Befindet sich die „ruf=“-Adresse außerhalb Ihrer Organisationsdomäne, stellen Sie sicher, dass der Autorisierungsdatensatz für externe Ziele vorhanden ist, da Empfänger andernfalls keine Nachrichten an diese Adresse senden.

4. Melden Sie sich separat bei den großen Internetdienstanbietern für Feedback-Loop-Programme an, da diese völlig unabhängig von DMARC ablaufen.

5. Planen Sie nicht, diese Berichte in nennenswertem Umfang manuell durchzulesen. Schon eine geringe Menge an E-Mails kann mehr ARF-Rohberichte erzeugen, als manuell ausgewertet werden kann. Hier kommt ein automatisierter DMARC-Berichtsanalysator ins Spiel, der die Arbeit vereinfacht.

Resümee

Fehlerberichte sind eine spezifische Anwendung von ARF innerhalb von DMARC. RUF liefert Ihnen bei Eingang einer Nachricht umfassende Details zu dieser einzelnen Nachricht, doch ein nicht unerheblicher Anteil der Empfänger sendet diese nicht, weshalb die aggregierte (RUA-)Berichterstattung Ihre zuverlässige, alltägliche Quelle für Transparenz darstellt. Da der DMARC-Standard nun in den RFCs 9989, 9990 und 9991 formalisiert ist, ist es wichtiger denn je, die Terminologie und Details korrekt zu verstehen – insbesondere, wenn Sie einen tatsächlichen Spoofing-Vorfall und nicht nur eine einfache Fehlkonfiguration beheben.

Wenn Sie die Berichterstellung zum ersten Mal einrichten oder diese Daten einsehen möchten, ohne die ARF-Rohnachrichten selbst auswerten zu müssen, ist unser DMARC Report Analyzer genau dafür gedacht. Melden Sie sich noch heute für eine kostenlose Testversion an und lesen Sie Ihre Berichte ganz unkompliziert aus!

Häufig gestellte Fragen

Was ist ein DMARC-Fehlerbericht (forensisch)?

Es handelt sich um einen ARF-Bericht pro Nachricht, der erstellt wird, wenn eine E-Mail die DMARC-Authentifizierung nicht besteht. Er enthält Details zur jeweiligen Nachricht, darunter Angaben dazu, welche Authentifizierungsmechanismen fehlgeschlagen sind und ob sie eine Kennung erzeugt haben, die mit der „From:“-Domäne übereinstimmt. „Forensic Report“ ist die ältere Bezeichnung für dasselbe, die aus RFC 7489 übernommen wurde.

Was ist der Unterschied zwischen RUA und RUF bei DMARC?

RUA-Berichte (Aggregatberichte) sind tägliche XML-Zusammenfassungen, die alle von einer Domain empfangenen E-Mails abdecken und nun in RFC 9990 definiert sind. RUF-Berichte (Fehlerberichte) sind nahezu in Echtzeit erstellte ARF-Berichte über einzelne fehlgeschlagene Nachrichten, die in RFC 9991 definiert sind. RUA wird weitgehend unterstützt; RUF ist optional und wird nicht einheitlich versendet.

Wer versendet DMARC-Fehlerberichte?

Nur einige Empfänger generieren sie überhaupt, und große E-Mail-Anbieter wie Gmail und Yahoo tun dies in der Regel nicht. Die Unterstützung variiert je nach Empfänger, und Datenschutzbedenken, Anforderungen zur Ratenbegrenzung sowie Regeln zur Zielüberprüfung gemäß RFC 9991 führen dazu, dass sie tatsächlich seltener ankommen.

Was ist der Unterschied zwischen ARF und XARF?

ARF (RFC 5965) ist das von der IETF standardisierte Format, das in DMARC-Fehlerberichten und ISP-Feedback-Loops verwendet wird. XARF ist eine proprietäre, von Anbietern entwickelte Erweiterung, die eine JSON-Nutzlast hinzufügt, um die Auswertung zu vereinfachen. Es handelt sich dabei nicht um einen IETF-Standard und wird von den großen Anbietern nicht für die DMARC-Berichterstattung verwendet.

Warum erhalte ich keine DMARC-Fehlermeldungen?

Mögliche Gründe hierfür sind unter anderem der Versand an große Provider, die keine solchen Berichte erstellen, eine durch Datenschutzmaßnahmen bedingte Kürzung des Berichts, ein fehlender externer Zielüberprüfungsdatensatz, falls Ihre „ruf=“-Adresse außerhalb der Domain liegt, eine obligatorische Ratenbegrenzung auf Empfängerseite oder schlichtweg das Fehlen von Authentifizierungsfehlern, die überhaupt gemeldet werden könnten. Ihre „fo=“-Tag-Einstellung bestimmt zudem genau, wann ein Bericht ausgelöst wird.

• Über
• Neueste Beiträge

Ahona Rudra

Experte für Domain- und E-Mail-Sicherheit bei PowerDMARC

Ahona ist Marketing-Managerin bei PowerDMARC und verfügt über mehr als 5 Jahre Erfahrung im Schreiben über Cybersicherheitsthemen, insbesondere im Bereich Domain- und E-Mail-Sicherheit. Ahona hat einen Postgraduierten-Abschluss in Journalismus und Kommunikation und ist seit 2019 in der Sicherheitsbranche tätig.

Neueste Beiträge von Ahona Rudra (alle anzeigen)

• SSL- und TLS-Protokolle: Was ist der Unterschied? – 13. August 2026
• Was ist URL-Manipulation (URL-Rewriting)? Wie Angreifer vertrauenswürdige Links missbrauchen, um Phishing zu verschleiern – 10. August 2026
• Sicherheitswarnung per E-Mail zum Microsoft-Konto: So erkennen Sie Betrugsversuche und schützen Ihre Domain – 9. August 2026