DMARC-Fehlerberichte (RUF): Was sie sind, wie sie funktionieren und wie man sie sicher aktiviert

Veröffentlichung eines DMARC-Eintrags ist ein wichtiger Schritt zum Schutz Ihrer Domain vor Spoofing, Phishing und unbefugter E-Mail-Nutzung. Der eigentliche operative Nutzen liegt jedoch in den Berichten, die aufzeigen, ob legitime Absender die E-Mail-Authentifizierung und wo Fehler auftreten.

Viele Unternehmensteams stützen sich bei der Überwachung des allgemeinen Zustands ihrer Domains auf aggregierte DMARC-Berichte, doch diese Zusammenfassungen liefern möglicherweise nicht genügend Details für die Reaktion auf Vorfälle, Compliance-Untersuchungen oder die Fehlerbehebung bei komplexen Problemen mit externen Absendern. DMARC-Fehlerberichte (RUF) liefern zusätzliche Informationen auf Nachrichtenebene, die Sicherheits- und IT-Teams dabei helfen können, die Ursache von Authentifizierungsfehlern schneller zu ermitteln. 

In diesem Leitfaden wird erläutert, was RUF-Berichte sind, wie sie sich von aggregierten Daten unterscheiden und wie man sie effektiv nutzt.

Was ist ein DMARC-Fehlerbericht?

Ein DMARC-Fehlerbericht (auch als Fehlerbericht oder RUF-Bericht bezeichnet) ist eine detaillierte Benachrichtigung, die nahezu in Echtzeit von den empfangenden E-Mail-Servern gesendet wird, wenn eine Nachricht die DMARC-Authentifizierung nicht besteht. Er enthält Diagnosedaten auf Nachrichtenebene, darunter Authentifizierungsergebnisse, die Absenderquelle und die Nachrichten-Header, sodass Domain-Inhaber potenzielle Spoofing-Versuche untersuchen und Probleme bei der E-Mail-Authentifizierung beheben können.

Anmerkung zur Terminologie: Die Begriffe „DMARC-Fehlerbericht“, „DMARC-Fehlerbericht“ und „RUF-Bericht“ beziehen sich alle auf denselben Berichtstyp. Das zugrunde liegende Format ist AFRF (Authentication Failure Reporting Format), definiert in RFC 6591, einer DMARC-spezifischen Erweiterung von ARF (Abuse Reporting Format, RFC 5965). Diese Begriffe werden in der Branche häufig synonym verwendet.

• Wer erstellt diese Berichte? E-Mail-Empfangsserver, Internetdienstanbieter (ISPs), E-Mail-Gateways von Unternehmen und Sicherheitsgeräte – allerdings nur, wenn sie RUF unterstützen und einen Authentifizierungsfehler erkennen. Domain-Inhaber fordern Berichte über das „ruf=“-Tag an, wobei die Empfänger anhand ihrer eigenen Datenschutzrichtlinien und Konfiguration entscheiden, ob sie diese versenden.
• Wohin wird sie gesendet? Es wird an die E-Mail-Adresse gesendet, die im „ruf=“-Tag Ihres DMARC-DNS-Eintrags angegeben ist.
• Welches Format wird verwendet? Im Gegensatz zu Sammelberichten, die als XML-Dateien bereitgestellt werden, verwenden RUF-Berichte das AFRF (Authentication Failure Reporting Format), um detaillierte Daten zu Authentifizierungsfehlern in einer besser lesbaren Struktur bereitzustellen.

Welche Informationen enthalten DMARC-Fehlerberichte?

Weil RUF DMARC-Berichte für eine eingehende Fehlerbehebung konzipiert sind, enthalten sie spezifische Metadaten zur fehlerhaften Nachricht, die Sie in aggregierten Berichten nicht finden. Ein typischer RUF-Bericht umfasst:

• IP-Adresse des Absenders: die genaue IP-Adresse, von der aus versucht wurde, die Nachricht zu senden
• Absender- und Return-Path-Adressen: der „From“-Header und der Absender im Umschlag
• Betreff: Der eigentliche Betreff der fehlgeschlagenen E-Mail
• Authentifizierungsergebnisse: genaue Angaben dazu, warum SPF oder DKIM fehlgeschlagen sind und ob eine DMARC-Übereinstimmung erreicht wurde
• E-Mail-Header: die vollständigen Feedback-Header der Nachricht
• Empfangszeit: der Zeitstempel, zu dem die Nachricht beim empfangenden Server eingegangen ist
• Angewandte DMARC-Richtlinie: die Richtlinie, die auf die Nachricht angewendet wurde – entweder „keine“, „Quarantäne“ oder „Ablehnen“
• Zustellungsergebnis: ob die Nachricht zugestellt, unter Quarantäne gestellt oder abgelehnt wurde
• Personenbezogene Daten (PII): Da diese Berichte Betreffzeilen und Empfängeradressen enthalten können, enthalten sie häufig personenbezogene Daten

Hinweis zum Datenschutz

Aufgrund der enthaltenen personenbezogenen Daten haben sich viele große E-Mail-Anbieter dafür entschieden, keine RUF-Berichte zu versenden, um die Privatsphäre der Nutzer zu schützen. PowerDMARC löst dieses Problem durch die Unterstützung von PGP-Verschlüsselung für RUF-Berichte, sodass sensible Daten verschlüsselt bleiben und nur für Sie zugänglich sind. Einige Empfänger, die RUF-Berichte versenden, schwärzen zunächst sensible Teile des Textkörpers oder der Betreffzeile, weshalb manche Fehlerberichte leer ankommen oder [REDACTED]-Zeichenfolgen enthalten.

Beispiel für einen DMARC-Fehlerbericht: So interpretieren Sie die einzelnen Felder

Um zu verstehen, was im Hintergrund vor sich geht, sehen Sie sich die Rohdaten an. Wenn eine E-Mail nicht zugestellt werden kann, erstellt der Empfänger einen Bericht im AFRF-Format. Im Folgenden finden Sie ein repräsentatives Beispiel unter Verwendung reservierter Domänen und IP-Bereiche gemäß RFC 5737.

Feldweise Auswertung

Praktischer Tipp

Gehen Sie bei der Überprüfung eines RUF-Berichts nacheinander die folgenden vier Fragen durch: Befindet sich die Quell-IP in Ihrer Liste der zugelassenen Absender? Ist SPF oder DKIM fehlgeschlagen – oder beides? Stimmt die „Original-Mail-From“-Angabe mit Ihrer Domain überein? Handelt es sich hier um einen Sonderfall bei der Weiterleitung oder um eine Weiterleitung über eine Mailingliste? Wenn Sie diese Fragen nicht mit Sicherheit beantworten können, leiten Sie den Bericht zur Untersuchung an Ihr Sicherheitsteam weiter.

So sieht der Eintrag in Ihrem DNS aus

Um diese Berichte zu erhalten, muss Ihr DMARC-Eintrag das „ruf=“-Tag enthalten. Ein repräsentatives Beispiel:

Wenn Sie Berichte an eine andere Domain als Ihre eigene senden, muss die Ziel-Domain einen DNS-Eintrag veröffentlichen, der sie zum Empfang von Berichten in Ihrem Namen berechtigt. Die Tags im Einzelnen:

• v=DMARC1: das Standard-Versionskennzeichen zur Identifizierung des DMARC-Protokolls
• p=none: Überwachungsmodus; Nachrichten werden weder abgelehnt noch unter Quarantäne gestellt, und die Empfänger werden aufgefordert, die Authentifizierungsergebnisse zu melden
• rua=: der Speicherort für tägliche Gesamtberichte, in denen alle Authentifizierungsaktivitäten zusammengefasst werden
• ruf=: die Zieladresse für Fehlermeldungen; leiten Sie diese an eine sichere, eigens dafür vorgesehene Verarbeitungsplattform weiter, anstatt an einen allgemeinen Posteingang
• fo=1: weist Empfänger an, einen Bericht zu erstellen, wenn entweder SPF oder DKIM fehlschlägt

DMARC-Gesamtbericht vs. Fehlerbericht: RUA vs. RUF

Beide Berichtstypen werden innerhalb desselben DMARC-Eintrags konfiguriert, dienen jedoch unterschiedlichen Zwecken. RUA bietet domänenweite Transparenz über einen bestimmten Zeitraum hinweg; RUF liefert detaillierte Informationen auf Nachrichtenebene zu bestimmten Fehlern. Eine ausführlichere Aufschlüsselung finden Sie in diesem Vergleich von RUA- und RUF-Berichten.

So aktivieren Sie DMARC-Fehlerberichte in Ihrem DNS-Eintrag

Um RUF zu aktivieren, müssen Sie Ihren bestehenden DMARC-TXT-Eintrag im DNS aktualisieren. Befolgen Sie dazu die folgenden Schritte.

1. Rufen Sie die Seite Ihres DNS-Anbieters auf. Melden Sie sich bei der DNS-Verwaltungskonsole für Ihre Domain an.
2. Suchen Sie Ihren DMARC-TXT-Eintrag. Suchen Sie den TXT-Eintrag, der unter _dmarc.yourdomain.com veröffentlicht ist.
3. Fügen Sie das RUF-Ziel hinzu. Fügen Sie eine ruf=mailto:-Adresse ein, an die Fehlerberichte gesendet werden sollen, sofern dies unterstützt wird.
4. Fehleroptionen konfigurieren. Fügen Sie das fo=-Tag hinzu, um festzulegen, wann Berichte generiert werden sollen. Dies wird im nächsten Abschnitt behandelt.
5. Verwenden Sie eine sichere Verarbeitung. Leiten Sie Berichte an eine sichere Plattform wie PowerDMARC weiter, anstatt sie in einen allgemeinen Posteingang zu senden.
6. Speichern und die Weitergabe zulassen. Es kann bis zu 48 Stunden dauern, bis sich DNS-Änderungen weltweit durchgesetzt haben.

Das Senden von RUF-Berichten an einen Standard-Posteingang sorgt für Unübersichtlichkeit und erhöht das Risiko einer Datenpreisgabe. Eine Berichtsplattform zentralisiert DMARC-Daten, wandelt Rohdaten zur Authentifizierung in übersichtliche Dashboards um und setzt Fehler mit den Ergebnissen der SPF-, DKIM- und DMARC-Konformitätsprüfung in Zusammenhang, sodass Teams Probleme schneller erkennen können.

DMARC-Tag „fo“ erklärt: Wann Fehlerberichte ausgelöst werden

Das „fo“-Tag ist ein Bestandteil des DMARC-Eintrags, der dem empfangenden Server mitteilt, wann ein Fehlerbericht erstellt werden soll.

Die meisten Sicherheitsexperten verwenden „fo=1“, da dies einen maximalen Einblick in Authentifizierungsfehler bietet. Allerdings sollte „fo=1“ an eine dedizierte, sichere Verarbeitungsplattform weitergeleitet werden und nicht in den Posteingang eines Mitarbeiters. Das Volumen der dadurch generierten Berichte kann ohne Automatisierung unüberschaubar werden, und das Senden an einen ungeschützten Posteingang erhöht das Risiko, dass sensible Nachrichtendaten offengelegt werden. A DKIM-Fehler kann insbesondere eine Flut von Meldungen auslösen, die von einem gemeinsam genutzten Postfach isoliert werden sollten.

Warum Sie möglicherweise keine DMARC-Fehlerberichte erhalten

Wenn Sie RUF aktiviert haben, Ihr Berichtsempfänger jedoch leer ist, deutet dies nicht zwangsläufig auf einen Konfigurationsfehler hin. Es gibt mehrere häufige Ursachen, die dazu führen können, dass keine Berichte empfangen werden.

Aus diesem Grund berichtet die RUA-Berichte als maßgebliche Quelle für die Überwachung des allgemeinen Zustands der Domäne gelten, während RUF-Berichte als ergänzendes Untersuchungsinstrument für bestimmte Ausfallszenarien dienen.

Bedenken hinsichtlich Datenschutz und Sicherheit

Da RUF-Berichte Betreffzeilen, Empfängeradressen, Kopfzeilen und manchmal auch den Inhalt der Nachrichten enthalten können, müssen sie im Rahmen von Datenschutzbestimmungen wie der DSGVO und CCPAsorgfältig behandelt werden. Für Organisationen in regulierten Branchen wie dem Finanzwesen, dem Gesundheitswesen, dem Bildungswesen, dem Einzelhandel und dem öffentlichen Sektor sollten Fehlerdaten über sichere, zugriffskontrollierte Systeme verarbeitet werden, die Datenschutz- und Compliance-Verpflichtungen erfüllen.

Für Unternehmen, die die Anforderungen von Google, Microsoft, PCI DSS, DSGVO oder behördliche Vorgaben zur E-Mail-Authentifizierung erfüllen müssen, sind sichere Berichtsworkflows von entscheidender Bedeutung. RUF-Daten können zwar bei Untersuchungen helfen, doch die umfassende Transparenz hinsichtlich DMARC, der Fortschritt bei der Durchsetzung sowie das Management authentifizierter Absender bleiben für die langfristige Compliance-Bereitschaft unerlässlich.

Bewährte Verfahren

• Verwenden Sie eine spezielle, sichere Meldeplattform.
• PGP-Verschlüsselung aktivieren: Ein „Bring-Your-Own-Key“-Modell bedeutet, dass nur autorisierte Benutzer mit dem privaten Schlüssel die vertraulichen Inhalte von Fehlerberichten einsehen können.
• Beschränken Sie den Zugriff auf Fehlerdaten entsprechend der Rolle und dem betrieblichen Bedarf.
• Legen Sie Richtlinien zur Datenaufbewahrung für gespeicherte RUF-Daten gemäß den geltenden Datenschutzbestimmungen fest.
• Führen Sie eine rechtliche Prüfung durch, bevor Sie RUF in Ländern mit strengen Datenschutzanforderungen aktivieren.

So nutzen Sie RUF-Berichte, um Spoofing zu erkennen und Fehler zu beheben

Sobald Sie Fehlerdaten erhalten, sollten Sie jeden Bericht eher als Anhaltspunkt für weitere Untersuchungen denn als endgültiges Urteil betrachten. Überprüfen Sie die Ergebnisse anhand genehmigter Absenderverzeichnisse, aggregierter DMARC-Trends, Mail-Gateway-Protokolle und Bedrohungsinformationen, bevor Sie Entscheidungen zur Behebung treffen. Fünf Szenarien decken den Großteil der in den Fehlerdaten auftretenden Fälle ab.

Erkennung von Domain-Spoofing

Wenn in einem Fehlerbericht eine unbekannte Quell-IP-Adresse identifiziert wird, die Ihre Domain in der „From“-Adresse des Headers verwendet, sollten Sie dies als Hinweis für weitere Untersuchungen betrachten. Überprüfen Sie die Quelle zunächst anhand von Listen zugelassener Absender, aggregierter Trends, Gateway-Protokollen und Bedrohungsinformationen. Sollte sich herausstellen, dass es sich um eine unbefugte IP-Adresse handelt, kann diese in Sperrlisten aufgenommen und Ihr Security Operations Center benachrichtigt werden.

Behebung berechtigter Fehler

Manchmal scheitern legitime E-Mails, weil ein Absender eines Drittanbieters nicht korrekt zugeordnet ist, ein DKIM-Selektor falsch konfiguriert ist oder der SPF-Eintrag der Domain zu komplex geworden ist. Eine Berichtsplattform hilft Teams dabei, diese Fehler im Kontext zu erkennen und die SPF-Verwaltung durch gehostetes SPF und automatisierte Vereinfachung zu vereinfachen, wodurch das Risiko von Zustellproblemen bei der Einführung neuer SaaS-Tools verringert wird.

Diagnose von Fehlern im Zusammenhang mit der Weiterleitung

Die E-Mail-Weiterleitung führt häufig zu einem Verstoß gegen die SPF-Richtlinie, da die IP-Adresse des Weiterleitungsservers nicht im SPF-Eintrag des ursprünglichen Absenders aufgeführt ist. Wenn ein RUF-Bericht Fehler von einem bekannten Weiterleitungsdienst oder einem Mailinglisten-Relay anzeigt, ist die Ursache wahrscheinlich ein Verstoß gegen die SPF-Richtlinie und nicht ein Spoofing-Versuch. Überprüfen Sie in diesen Fällen, ob DKIM weiterhin gültig ist, da DKIM-Signaturen die Weiterleitung in der Regel unbeschadet überstehen, und ob die DMARC-Richtlinie allein durch DKIM-Alignment erfüllt werden kann.

Aufdeckung von Schatten-IT und nicht autorisierten Absendern

RUF-Berichte können Absender aufdecken, die von den IT-Teams nicht autorisiert wurden oder denen diese nicht bekannt sind – beispielsweise ein Marketingteam, das ein neues Automatisierungstool eingebunden hat, ohne den SPF-Eintrag zu aktualisieren. Wenn ein Fehlerbericht einen Fehler von einer IP-Adresse anzeigt, die zu einer kürzlich eingeführten SaaS-Plattform gehört, handelt es sich eher um eine Konfigurationslücke als um einen Angriff. Fügen Sie den Dienst zu Ihrer Liste autorisierter Absender hinzu und aktualisieren Sie Ihren DMARC-Eintrag entsprechend.

Ablauf der Untersuchung

1. Ermitteln Sie die Quell-IP-Adresse im RUF-Bericht.
2. Berechtigung prüfen: Ist diese IP-Adresse mit einem Tool oder Dienst verknüpft, den Ihre Organisation nutzt?
3. Übereinstimmung prüfen: Überprüfen Sie die SPF- und DKIM-Ergebnisse im Feld „Authentication-Results“.
4. Überprüfen Sie das Verhalten bei Weiterleitungen oder Mailinglisten: Stellen Sie fest, ob der SPF-Fehler von einem zwischengeschalteten Relay verursacht wird.
5. Risiko klassifizieren: autorisierter Absender mit Fehlkonfiguration, nicht autorisierter Absender, Weiterleitungsartefakt oder Shadow-IT-Quelle.
6. Behebung: Falls autorisiert, aber fehlgeschlagen, korrigieren Sie die SPF- oder DKIM-Einstellungen. Falls nicht autorisiert, wenden Sie Ihre DMARC-Richtlinie mit „p=quarantine“ oder „p=reject“ an, um den Schutz durchzusetzen.
7. Überwachung anhand von Sammelberichten: Überprüfen Sie anhand der nachfolgenden RUA-Berichte, ob die Korrekturmaßnahmen wirksam sind.

Wann es sich lohnt, RUF zu aktivieren, und wann man darauf verzichten sollte

RUF ist nicht für jede Domäne standardmäßig aktiviert. Ob es seinen Platz verdient, hängt davon ab, wer die Berichte liest und wozu sie dienen. Es gibt drei Situationen, in denen es sich lohnt, und zwei, die dagegen sprechen.

• Aktivieren Sie diese Funktion, wenn Sie über ein Sicherheitsteam verfügen, das auf der Grundlage der Daten Maßnahmen ergreifen kann. SOC-Analysten und Incident-Responder nutzen die Details auf Nachrichtenebene, um bestätigte Spoofing-Vorfälle zu untersuchen – dies ist der größte Nutzen des Berichts.
• Aktivieren Sie diese Funktion während der aktiven Fehlerbehebung. Wenn bei einem Absender eines Drittanbieters immer wieder Fehler auftreten und die aggregierten Daten nicht spezifisch genug sind, verkürzt die Angabe der genauen IP-Adresse und des Ausrichtungsergebnisses die Diagnose.
• Setzen Sie es in regulierten Umgebungen ein, in denen bereits sichere Verarbeitungsprozesse vorhanden sind. Wenn Sie bereits eine verschlüsselte, zugriffskontrollierte Berichterstellung nutzen, ist das zusätzliche Risiko durch die vertiefte Untersuchung gering.
• Überdenken Sie dies noch einmal, falls die Berichte in einem gemeinsamen Posteingang landen würden. Ohne Verschlüsselung und Zugriffskontrollen birgt der Empfang von Berichten, die personenbezogene Daten enthalten, Compliance-Risiken, die den Nutzen überwiegen.
• Überdenken Sie es noch einmal, wenn niemand für die Ergebnisse verantwortlich ist. Ein hohes fo=1-Volumen ohne Analysten, der es auswertet, wird zu Rauschen, und die aggregierten Berichte decken die Überwachung des Zustands des Bereichs bereits ab.

Für die meisten Teams gilt standardmäßig der Ansatz „Aggregate-First“. Führen Sie RUA durch, um den Zustand der Domäne und den Fortschritt der Durchsetzungsmaßnahmen zu überprüfen, und aktivieren Sie RUF dann gezielt, wenn eine Untersuchung oder ein hartnäckiger Fehler eines Absenders eine detaillierte Analyse auf Nachrichtenebene erfordert, die an eine Plattform weitergeleitet wird, die für den Umgang mit sensiblen Daten ausgelegt ist.

Einschränkungen bei DMARC-Fehlerberichten

Zu verstehen, was RUF-Berichte nicht leisten können, ist ebenso wichtig wie zu wissen, was sie leisten können. Betrachten Sie Fehlerberichte als ergänzendes Untersuchungsinstrument und nicht als primäre Grundlage für Entscheidungen im Rahmen des DMARC-Programms.

• Eingeschränkte Unterstützung durch Anbieter: Große E-Mail-Anbieter wie Gmail und Microsoft 365 senden aus Datenschutzgründen in der Regel keine RUF-Berichte, sodass die Abdeckung von Fehlern naturgemäß unvollständig ist
• Redigierte Daten: Empfänger, die Berichte versenden, können Betreffzeilen, Nachrichtentexte oder Empfängeradressen vor der Zustellung schwärzen
• Falschpositive durch Weiterleitung: Mailinglisten-Relays und Weiterleitungsdienste verursachen häufig SPF-Fehler, die wie Authentifizierungsfehler aussehen, jedoch keine Spoofing-Versuche sind
• Meldungsvolumen und Lärm: Bei fo=1 erhalten Absender mit hohem Versandvolumen möglicherweise eine unüberschaubare Anzahl von Meldungen, von denen viele eher das erwartete Weiterleitungsverhalten widerspiegeln als echte Bedrohungen.
• Kein Ersatz für RUA: Aggregierte Berichte bleiben die maßgebliche Quelle für den Authentifizierungsstatus der gesamten Domäne, daher sollte RUF die laufende RUA-Überwachung ergänzen und nicht ersetzen.
• Risiko der Offenlegung personenbezogener Daten: Ohne Verschlüsselung und Zugriffskontrollen kann bereits der Empfang von RUF-Berichten an sich Compliance-Verpflichtungen gemäß der DSGVO, dem CCPA und ähnlichen Rechtsrahmen begründen.

Wie MSPs DMARC-Fehlerberichte über verschiedene Kundendomänen hinweg nutzen können

Für MSPs und MSSPs sind Fehlerberichte besonders wertvoll, wenn ein Kunde fehlende Nachrichten, vermutetes Spoofing oder unerklärliche Authentifizierungsfehler meldet. Unverarbeitete RUF-Berichte lassen sich jedoch in großem Umfang nur schwer verwalten. Sie können sensible Kundendaten enthalten, gleichzeitig von mehreren Domänen eingehen und müssen mit anderen Authentifizierungssignalen abgeglichen werden, um verwertbar zu sein.

• Transparenz über mehrere Domänen hinweg: Die Zusammenführung von Berichten aus Dutzenden oder Hunderten von Kundendomänen ohne eine zentralisierte Plattform ist mit erheblichem manuellem Aufwand verbunden
• Umgang mit sensiblen Daten: RUF-Berichte aus Kundendomänen können personenbezogene Daten von Endkunden enthalten, was für den MSP Compliance-Verpflichtungen mit sich bringt
• Verwaltung des Berichtsvolumens: Kundendomänen mit hohem Datenaufkommen können eine große Anzahl von Fehlerberichten generieren, die die Arbeitsabläufe der Techniker überlasten
• Rollenbasierter Zugriff: Techniker sollten nur Berichte für die ihnen zugewiesenen Kundendomänen einsehen können

Eine zentralisierte Plattform wie PowerDMARC für MSPs und MSSPs hilft Dienstanbietern dabei, RUF-Daten sicher zu verarbeiten, Kundendomänen voneinander zu trennen, den Zeitaufwand für manuelle Untersuchungen zu reduzieren und Technikern einen schnellen Überblick darüber zu verschaffen, welcher Absender, welche IP-Adresse oder welcher Authentifizierungsmechanismus einen Fehler verursacht hat – ohne sensible Daten unnötig offenzulegen.

Wie PowerDMARC bei DMARC-Fehlermeldungen hilft

PowerDMARC verarbeitet DMARC-Fehlerdaten sicher und wandelt Rohdaten zu Authentifizierungsfehlern in verwertbare Erkenntnisse um. Anstatt sensible RUF-Berichte an einen normalen Posteingang zu senden, können Teams die Berichte in einem zentralen Dashboard einsehen, sensible Daten durch PGP-Verschlüsselung schützen und Fehler mit den Ergebnissen der SPF-, DKIM- und DMARC-Konformitätsprüfung in Zusammenhang bringen.

• Klare Transparenz: Identifizieren Sie fehlerhafte Absender, Authentifizierungsergebnisse und verdächtige IP-Adressen schneller über alle Ihre Domains hinweg
• Sicherer Umgang: Die PGP-Verschlüsselung mit einem „Bring-Your-Own-Key“-Modell verringert das Risiko, dass sensible Fehlerdaten offengelegt werden, sodass selbst PowerDMARC die verschlüsselten Inhalte nicht lesen kann
• Zentralisierte Verwaltung: Überwachen Sie DMARC, SPF, DKIM, BIMI, MTA-STS und TLS-RPT von einer einzigen Plattform aus, ohne zwischen verschiedenen Tools wechseln oder Roh-XML-Daten auswerten zu müssen
• Schnellere Fehlerbehebung: Beheben Sie Fehler bei legitimen Absendern und Spoofing-Versuche, ohne AFRF-Berichte manuell auswerten zu müssen – dank gehostetem SPF und automatisierter Flattening-Funktion, um Zustellungsfehler zu reduzieren, wenn neue SaaS-Tools hinzugefügt werden
• Compliance-Bereitschaft: Prüfpfade, rollenbasierte Zugriffskontrollen sowie Unterstützung für Google, Microsoft, PCI DSS, DSGVO und behördliche Anforderungen an Absender

Häufig gestellte Fragen

Was genau ist ein DMARC-Fehlerbericht?

Ein nahezu in Echtzeit erstellter Fehlerbericht, der generiert wird, wenn eine einzelne E-Mail die in Ihrer DMARC-Richtlinie und den Fehleroptionen definierten Authentifizierungsprüfungen nicht besteht. Er enthält Details auf Nachrichtenebene, im Gegensatz zu aggregierten Berichten, die die Aktivitäten aller Nachrichten über einen Zeitraum von 24 Stunden zusammenfassen.

Inwiefern unterscheidet sich RUF von RUA?

RUA liefert täglich eine domänenweite Zusammenfassung im XML-Format, die alle Nachrichten umfasst. RUF liefert nahezu in Echtzeit Informationen zu einzelnen fehlerhaften Nachrichten im AFRF-Format (RFC 6591, eine Erweiterung von ARF in RFC 5965), enthält nachrichtenbezogene Details und kann personenbezogene Daten enthalten. RUA tut dies nicht.

Wie aktiviere ich diese Berichte?

Fügen Sie „ruf=mailto:[email protected]“ zu Ihrem DMARC-TXT-Eintrag unter _dmarc.yourdomain.com hinzu. Fügen Sie „fo=1“ hinzu, um einen Bericht zu erhalten, wenn entweder SPF oder DKIM fehlschlägt. Leiten Sie Berichte an eine sichere Plattform weiter, anstatt sie in einen normalen Posteingang zu senden.

Ich habe RUF eingerichtet, aber es passiert nichts. Ist es kaputt?

Nicht unbedingt. Viele Anbieter versenden aus Datenschutzgründen keine RUF-Meldungen, und beim Durchlauf von Nachrichten wird kein Bericht erstellt. Wenn aggregierte RUA-Berichte eingehen, ist Ihr Datensatz wahrscheinlich korrekt. Überprüfen Sie die Tabelle zur Fehlerbehebung auf weitere Ursachen.

Senden alle E-Mail-Anbieter DMARC-Fehlerberichte?

Nein. Gmail und Microsoft 365 tun dies in der Regel nicht und verweisen dabei auf den Datenschutz der Nutzer. Die Abdeckung beschränkt sich auf Empfänger, die RUF-Unterstützung implementiert haben, typischerweise einige E-Mail-Gateways von Unternehmen, Internetdienstanbieter und unabhängige E-Mail-Server. Dies ist eine wesentliche Einschränkung.

Ist es unbedenklich, DMARC-Fehlerberichte zu erhalten?

Sie können personenbezogene Daten wie Betreffzeilen, Empfängeradressen und Kopfzeilen enthalten. Der Empfang solcher E-Mails ohne entsprechende Kontrollmaßnahmen kann Verpflichtungen gemäß DSGVO und CCPA nach sich ziehen. Am sichersten ist es, sie an eine sichere Plattform mit PGP-Verschlüsselung, rollenbasiertem Zugriff und festgelegten Aufbewahrungsfristen weiterzuleiten.

Was bewirkt das „fo“-Tag?

Die Abkürzung steht für „Failure Options“ (Fehleroptionen) und legt fest, wann Empfänger einen Bericht erstellen. Bei „fo=0“ (Standard) müssen sowohl SPF als auch DKIM fehlschlagen. Bei „fo=1“ wird bei einem der beiden Fehler ein Bericht gesendet. „fo=d“ wird nur bei einem DKIM-Fehler ausgelöst; „fo=s“ nur bei einem SPF-Fehler.

• Über
• Neueste Beiträge

Milena Baghdasaryan

Content-Spezialist bei PowerDMARC

Milena ist eine erfahrene Autorin und Inhaltserstellerin mit mehr als 7 Jahren Erfahrung in der Erstellung ansprechender Inhalte über IT, Cybersicherheit, virtuelle Veranstaltungen und mehr. Sie hat eine nachgewiesene Erfolgsbilanz bei der Erstellung hochwertiger Arbeiten für internationale Magazine und ist Absolventin renommierter Institutionen wie der New York University Abu Dhabi, UWC China und dem College of Europe.

Neueste Beiträge von Milena Baghdasaryan (alle anzeigen)

• „Antworten“ vs. „Allen antworten“: Verhaltensregeln und Sicherheitsrisiken – 14. August 2026
• DMARC-Fehlerberichte (RUF): Was sie sind, wie sie funktionieren und wie man sie sicher aktiviert – 11. August 2026
• E-Mail-Authentifizierung bei den weltweit größten KI-Unternehmen – 10. August 2026