So lesen Sie DMARC-Berichte: Ein umfassender Leitfaden zu RUA und RUF

Sie haben einen DMARC-Eintrag veröffentlicht, „rua=“ auf Ihre E-Mail-Adresse gesetzt, und nun landen Berichte als komprimierte XML-Dateien in Ihrem Posteingang. Sie sind schwer zu lesen, stammen von Unternehmen, von denen Sie noch nie gehört haben, und es ist nicht klar, was Sie damit überhaupt tun sollen – wenn überhaupt etwas.

Dieser Leitfaden schafft hier Abhilfe. Er erklärt, was DMARC-Berichte enthalten, wie man das XML Feld für Feld auswertet, was RUA und RUF eigentlich bedeuten und – was am wichtigsten ist – welche Maßnahmen zu ergreifen sind, wenn ein Absender die Prüfung besteht, durchfällt oder unerwartet auftaucht. Wenn Sie gerade Ihren ersten Bericht in der Hand halten, beginnen Sie oben und arbeiten Sie sich nach unten vor.

In diesem Blog wird davon ausgegangen, dass Sie bereits über einen Eintrag verfügen. Falls dies nicht der Fall ist, veröffentlichen Sie zunächst einen DMARC-Eintrag und kehren Sie anschließend zurück, um die dadurch generierten Berichte auszuwerten.

Was sind DMARC-Berichte?

DMARC-Berichte sind tägliche Zusammenfassungen, die von den empfangenden Mail-Servern an die Adresse in Ihrem „rua=“-Tag gesendet werden. In jedem Bericht werden alle IP-Adressen aufgeführt, von denen während eines Berichtszeitraums E-Mails versendet wurden, die angeblich von Ihrer Domain stammen, sowie die Angabe, ob SPF und DKIM für die jeweilige Quelle bestanden oder nicht bestanden haben. Sie sind das wichtigste Instrument zur Überwachung der E-Mail-Authentifizierung Ihrer Domain. Sie bieten Ihnen den einzigen wirklichen Einblick darin, wer E-Mails in Ihrem Namen versendet – ob legitim oder nicht.

Wer versendet DMARC-Berichte?

Jeder Mailserver, der E-Mails von Ihrer Domain empfängt, sendet einen Bericht, sofern Sie „rua=“ konfiguriert haben. Dazu gehören natürlich Google, Microsoft und Yahoo. Ebenfalls dazu zählen kleinere E-Mail-Dienstleister (ESPs), Mail-Gateways von Unternehmen, Universitätssysteme sowie internationale Anbieter, die Ihre Empfänger zufällig nutzen. 

Wenn Sie Berichte von Organisationen erhalten, die Sie nicht kennen ist normal und zu erwarten. Das kann einfach bedeuten, dass ein Server irgendwo eine Nachricht verarbeitet hat, die scheinbar von Ihrer Domain stammte. Beachten Sie jedoch, dass ein hohes E-Mail-Aufkommen in diesen Meldungen von einer IP-Adresse, die Sie nicht kontrollieren, dennoch eine Untersuchung rechtfertigt, da es sich dabei um ein Anzeichen für Spoofingist.

Die Anzahl der Berichte, die Sie täglich erhalten, hängt davon ab, wie viele verschiedene Mailserver Ihre E-Mail empfangen haben. Wenn Sie nur an eine Handvoll Empfänger senden, erhalten Sie möglicherweise zwei oder drei Berichte pro Tag. Absender mit hohem Versandvolumen können Hunderte davon erhalten. Das allein deutet noch nicht auf ein Problem hin. Die Anzahl der Berichte spiegelt die Streuung Ihrer Empfänger wider, nicht den Zustand Ihrer Domain.

Wann gehen die Berichte ein?

Die meisten Anbieter versenden alle 24 Stunden einen Sammelbericht, und die Berichte gehen in der Regel innerhalb von 24 bis 48 Stunden nach den darin beschriebenen E-Mail-Aktivitäten ein. Sie erhalten von jeder berichtenden Organisation einen separaten Bericht (Google und Microsoft versenden ihre Berichte unabhängig voneinander), sodass die E-Mails eines einzigen Tages an verschiedene Empfänger mehrere Berichte ergeben, die denselben Zeitraum abdecken.

Berichte werden von automatisierten Absendern als komprimierte Anhänge im Format .zip oder .gz versendet. Manche E-Mail-Programme stufen diese als verdächtig ein. Wenn Sie also Berichte erwarten, aber keine erhalten, überprüfen Sie bitte Ihren Spam- oder Junk-Ordner, bevor Sie davon ausgehen, dass etwas nicht funktioniert.

Arten von DMARC-Berichten: RUA vs. RUF

Es gibt zwei Arten von DMARC-Berichten. Bei fast allen Domains müssen Sie sich lediglich mit der ersten Art befassen.

Aggregierte Berichte (RUA): Der Standard

DMARC-Aggregatberichte sind eine 24-Stunden-Zusammenfassung des gesamten E-Mail-Verkehrs Ihrer Domain, der von einem bestimmten Mailserver verarbeitet wurde. Sie werden als komprimierte XML-Datei bereitgestellt und zeigen Ihnen die Absender-IPs, das Nachrichtenvolumen, den SPF-Erfolg/Fehlschlag, den DKIM-Erfolg/Fehlschlag sowie die DMARC-Entscheidung (die vom Empfänger ergriffene Maßnahme). Entscheidend ist, dass sie keinerlei E-Mail-Inhalte und keine personenbezogenen Daten enthalten, sondern lediglich Metadaten zur Authentifizierung, wodurch sie in jeder Region sicher empfangen und gespeichert werden können. Auf diesen Bericht konzentriert sich dieser Leitfaden. 

Fehlerberichte (RUF): Fehler pro Nachricht

DMARC-Fehlerberichte (früher als forensische Berichte bezeichnet) sind Benachrichtigungen nahezu in Echtzeit, dass eine bestimmte Nachricht die Authentifizierung nicht bestanden hat. RFC 9991 (Mai 2026) hat diesen Berichtstyp offiziell standardisiert. Da ein Fehlerbericht Nachrichten-Header und manchmal auch den Inhalt der Nachricht (Daten, die möglicherweise personenbezogene Daten enthalten) umfassen kann, versenden große Anbieter wie Google, Microsoft und Yahoo solche Berichte grundsätzlich nicht. Aktivieren Sie „ruf=“ nur, wenn Sie über einen dedizierten Prozessor für die Daten verfügen, und rechnen Sie ohnehin nicht mit Berichten von den großen E-Mail-Anbietern. 

RUA gegen RUF 

Was ein DMARC-Bericht enthält: Feld für Feld

Ein DMARC-Gesamtbericht ist eine XML-Datei, die in drei Hauptabschnitte unterteilt ist: Berichtsmetadaten (wer ihn wann gesendet hat), veröffentlichte Richtlinie (Ihr DMARC-Eintrag, wie er beim Empfänger angezeigt wurde) sowie Einträge, eine Zeile pro Absender. Wenn Sie diese drei Blöcke verstehen, ist der Rest nur noch Detailwissen.

Section 1: Report Metadata (<report_metadata>)

In diesem Abschnitt erfahren Sie, wer den Bericht übermittelt hat und welchen Zeitraum er abdeckt.

• org_name: die meldende Organisation (z. B. google.com).
• E-Mail: Die Kontaktadresse des Absenders des Berichts.
• report_id: Eine eindeutige Kennung für diesen bestimmten Bericht.
• date_range (begin + end): Das Berichtsfenster, angegeben als Epoch-Zeitstempel, die Sie in ein für Menschen lesbares Datum umwandeln müssen.

Was Sie hier überprüfen sollten: Vergewissern Sie sich, dass der Bericht den von Ihnen erwarteten Zeitraum abdeckt.

Section 2: Policy Published (<policy_published>)

Hier wird Ihr DMARC-Eintrag genau so angezeigt, wie er vom Empfänger zum Zeitpunkt der Verarbeitung ausgewertet wurde.

• Domäne: Die Domäne, für die die Richtlinie gilt.
• adkim / aspf: DKIM- und SPF-Abgleichmodi (locker oder streng).
• p: Ihre Richtlinie (keine, Quarantäne oder Ablehnung).
• sp: Ihre Subdomain-Richtlinie, sofern festgelegt.
• pct: Ein veraltetes Prozentfeld. Bitte beachten Sie, dass „pct“ gemäß RFC 9989 (Mai 2026) entfernt wurde; es kann zwar noch in älteren Berichten vorkommen, sollte in neuen Datensätzen jedoch nicht mehr enthalten sein.

Was Sie hier überprüfen sollten: Vergewissern Sie sich, dass die veröffentlichte Richtlinie Ihren Absichten entspricht. Ist dies nicht der Fall, hat sich Ihre DNS möglicherweise noch nicht vollständig verbreitet.

Section 3: Records (<record>): The Important Part

Each <record> represents all the emails from one source IP during the reporting period. This is where you spend most of your time.

• source_ip: Die Absender-IP-Adresse. Überprüfen Sie diese, um festzustellen, wer die E-Mail gesendet hat.
• Anzahl: Wie viele Nachrichten kamen von dieser IP-Adresse?
• policy_evaluated/disposition: die ergriffene Maßnahme (keine, Quarantäne oder Ablehnung).
• policy_evaluated/dkim und policy_evaluated/spf: das jeweils an DMARC angepasste Ergebnis „bestanden“ oder „nicht bestanden“.
• identifiers/header_from: Die sichtbare „From:“-Domäne, die durch DMARC geschützt wird.
• auth_results/spf: Die SPF-Domäne und das Ergebnis.
• auth_results/dkim: Die DKIM-Domäne, der Selektor und das Ergebnis.

Was Sie hier überprüfen sollten: Erfüllt jede IP-Adresse, die Sie erkennen, die DMARC-Anforderungen, und gibt es IP-Adressen, die Sie nicht erkennen?

Beispiel für einen DMARC-XML-Bericht

Hier finden Sie einen realistischen, anonymisierten Gesamtbericht, der drei Absenderquellen zeigt: einen legitimen Absender, der die Prüfung bestanden hat, einen legitimen Absender, der die Prüfung nicht bestanden hat, und eine unbekannte IP-Adresse. Jedes Feld ist mit einem Kommentar in leicht verständlichem Englisch versehen. 

<?xml version="1.0" encoding="UTF-8"?>
<feedback>

  <!-- ===== SECTION 1: WHO SENT THIS REPORT AND WHEN ===== -->
  <report_metadata>
    <org_name>google.com</org_name>             <!-- The provider that generated this report -->
    <email>[email protected]</email>  <!-- Where the report came from -->
    <report_id>1234567890123456789</report_id>  <!-- Unique ID for this report -->
    <date_range>
      <begin>1718928000</begin>                 <!-- Start of window (epoch) = 2024-06-21 00:00 UTC -->
      <end>1719014400</end>                      <!-- End of window (epoch)   = 2024-06-22 00:00 UTC -->
    </date_range>
  </report_metadata>

  <!-- ===== SECTION 2: YOUR POLICY AS THE RECEIVER SAW IT ===== -->
  <policy_published>
    <domain>example.com</domain>                <!-- The domain this report is about -->
    <adkim>r</adkim>                             <!-- DKIM alignment: r = relaxed -->
    <aspf>r</aspf>                               <!-- SPF alignment:  r = relaxed -->
    <p>none</p>                                  <!-- Your policy: monitoring only -->
    <sp>none</sp>                                <!-- Subdomain policy -->
  </policy_published>

  <!-- ===== SECTION 3: ONE RECORD PER SENDING SOURCE ===== -->

  <!-- RECORD 1: Legitimate sender (Google). All passing, no action needed. -->
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>      <!-- A Google sending IP -->
      <count>150</count>                         <!-- 150 messages from this IP -->
      <policy_evaluated>
        <disposition>none</disposition>          <!-- No action taken -->
        <dkim>pass</dkim>                         <!-- DKIM aligned & passed -->
        <spf>pass</spf>                           <!-- SPF aligned & passed -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Visible From: domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>google</selector>
        <result>pass</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 2: Known ESP. SPF passes but DKIM is not configured.
       Action: ask the provider to enable DKIM signing for your domain. -->
  <record>
    <row>
      <source_ip>198.51.100.42</source_ip>      <!-- Your email service provider -->
      <count>45</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>                         <!-- DKIM not aligned / not signed -->
        <spf>pass</spf>                           <!-- SPF passes -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>esp-vendor.example.org</domain>  <!-- Signed by vendor domain, not yours -->
        <selector>s1</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 3: Unknown sender. Both DKIM and SPF fail.
       Low volume here = monitor. High volume would signal active spoofing. -->
  <record>
    <row>
      <source_ip>203.0.113.17</source_ip>       <!-- Unrecognized IP -->
      <count>8</count>
      <policy_evaluated>
        <disposition>none</disposition>          <!-- Not blocked yet (p=none) -->
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Claiming to be your domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>unknown</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

</feedback>

So lesen Sie Ihre DMARC-Berichte: Schritt für Schritt

Schritt 1: Den Bericht öffnen und entpacken

Die Berichte werden als Anhang einer E-Mail mit einer Betreffzeile wie „Report Domain: yourdomain.com, Submitter: google.com, Report-ID: …“ gesendet. Speichern Sie den Anhang, entpacken Sie ihn (die in Ihrem Betriebssystem integrierten Entpackungsprogramme können .zip- und .gz-Dateien problemlos verarbeiten) und öffnen Sie die resultierende .xml-Datei in einem beliebigen Texteditor. 

Wenn Sie mehr als nur einen kurzen Blick darauf werfen möchten, laden Sie die Datei in unseren DMARC-Berichtsanalysator hoch, anstatt das Roh-XML zu lesen, um die Daten in einem für Menschen lesbaren Format eingehend zu analysieren.

Schritt 2: Ermittlung der berichtenden Organisation

Check <org_name> in the metadata so you know whose view you are looking at. Google’s report covers your Gmail recipients; Microsoft’s covers Outlook and Hotmail. You will get separate reports from each, so never assume one report is the whole picture.

Schritt 3: Überprüfen Sie Ihre veröffentlichte Richtlinie

Confirm <p>, <sp>, <adkim>, and <aspf> match what you intended to publish. If they do not, your record may have been propagated incorrectly or edited. Verify the live record with our DMARC Checker.

Schritt 4: Überprüfen Sie jeden Datensatz (Absender)

For each <record>: look up the <source_ip> with a reverse DNS or IP lookup to identify the service (for example, 209.85.220.41 resolves to Google). Check the <count>. High volume from an IP you do not recognize is a red flag. Then check the disposition and the DKIM/SPF results. A legitimate sender should show both dkim=pass and spf=pass; a failure on either for a sender you recognize means something needs fixing.

Schritt 5: Jede Quelle einer Kategorie zuordnen

Ordne jede Quelle einer der drei Kategorien zu:

1. Korrekt und gültig: Es sind keine Maßnahmen erforderlich.
2. Korrekt, aber fehlerhaft: muss behoben werden (siehe das unten stehende Aktionsrahmenwerk).
3. Unbekannt und sendet: mögliches Spoofing; überwachen Sie das Volumen und erwägen Sie eine Verschärfung Ihrer Richtlinien, falls es hoch ist.

DMARC-Berichte in großem Umfang auswerten: Tools und Automatisierung

Sobald täglich Berichte von mehreren Anbietern eingehen, ist das manuelle Auswerten von XML-Dateien nicht mehr praktikabel. Eine Domain, die an Nutzer von Gmail, Outlook und Yahoo sendet, erhält jeden Tag mindestens drei Berichte, und das manuelle Auswerten jedes einzelnen Berichts ist bereits nach der ersten Woche nicht mehr zu bewältigen. Die automatisierte Auswertung ist nicht ohne Grund der Branchenstandard.

Für eine schnelle einmalige Überprüfung bieten kostenlose Tools wie der DMARC Report Analyzer von PowerDMARC die Möglichkeit, eine XML-Rohdatei hochzuladen und deren Inhalt in einem für Menschen lesbaren Format anzuzeigen, ohne einen Texteditor öffnen zu müssen.

Für die kontinuierliche Überwachung in großem Maßstab übernimmt eine spezielle Plattform alle Aufgaben automatisch: Sie fasst die Berichte aller Anbieter in einer einheitlichen Ansicht zusammen, benachrichtigt Sie, wenn ein unbekannter Absender auftaucht, speichert den Verlauf und erstellt exportierbare Daten, die für Audits geeignet sind. 

Für PowerDMARC-Nutzer übernimmt unser Berichts-Dashboard all dies sowohl in Umgebungen mit einer als auch mit mehreren Domains, sodass die Analyse kontinuierlich erfolgt und nicht erst dann, wenn Sie daran denken, nachzuschauen.

• Alle Ihre Berichte an einem Ort: Anstatt Dutzender einzelner XML-Dateien, die über den Posteingang verstreut sind, werden alle Berichte aller Anbieter in einer einzigen Ansicht zusammengefasst.
• Abdeckung aller Domänen: Für Teams, die mehr als eine Domäne verwalten, erstreckt sich diese Konsolidierung über das gesamte Portfolio, sodass ein einziges Dashboard alle Domänen abdeckt, für die Sie verantwortlich sind.
• Historische Daten, nicht nur Momentaufnahmen: Dank der gespeicherten Historie können Sie Ihre Erfolgsquote Woche für Woche verfolgen, sicherstellen, dass eine Korrektur an einem fehlerhaften Absender tatsächlich Wirkung gezeigt hat, und einen langsamen Anstieg verdächtiger Aktivitäten erkennen, bevor daraus ein Vorfall wird.
• Filtern und Suchen: Isolieren Sie eine bestimmte Absenderquelle oder eine bestimmte Fehlerart, anstatt jeden Datensatz manuell zu überprüfen.
• Benachrichtigung bei neuen Absendern: Lassen Sie sich benachrichtigen, wenn ein neuer, nicht autorisierter Absender auftaucht, damit Sie nicht auf die nächste manuelle Überprüfung warten müssen, um ihn zu erkennen.
• Prüfungsfähiger Export: Erstellen Sie exportierbare Berichte für Compliance-Prüfungen und die Berichterstattung an Interessengruppen.

Was tun mit Ihren DMARC-Berichten?

Das Lesen des Berichts ist der erste Schritt. Erst durch konkrete Maßnahmen können Sie Ihre Domain tatsächlich schützen. Gehen Sie die folgenden Punkte der Reihe nach durch, wenn Sie eine neue Reihe von Berichten prüfen.

Problem mit legitimen Absendern beheben, bei denen Fehler auftreten

Wenn ein Absender, den Sie kennen (Ihr E-Mail-Dienstanbieter, Ihr CRM, Ihr Helpdesk oder Ihre Newsletter-Plattform), den Status „dkim=fail“ oder „spf=fail“ anzeigt:

1. Bei SPF-Fehlern: Fügen Sie den IP-Bereich des Absenders hinzu oder nehmen Sie den Mechanismus „include:“ in Ihren SPF-Eintrag auf und führen Sie anschließend eine erneute Überprüfung mit unserem SPF-Checker.
2. Bei DKIM-Fehlern: Bitten Sie den Provider, die benutzerdefinierte DKIM-Signierung für Ihre Domain zu aktivieren, und veröffentlichen Sie den von ihm bereitgestellten Schlüssel. Führen Sie anschließend eine Überprüfung mit unserem DKIM-Checker.

Unbekannte Absender identifizieren und überwachen

Eine IP-Adresse, die Sie nicht erkennen und von der E-Mails unter Ihrer Domain versendet werden, könnte ein Tool sein, das ein Team ohne vorherige Ankündigung eingeführt hat, ein legitimer Weiterleitungsdienst oder ein aktiver Spoofing-Versuch. Ein geringes E-Mail-Aufkommen von einer unbekannten IP-Adresse ist üblich und stellt ein geringes Risiko dar. Ein hohes E-Mail-Aufkommen von einer unbekannten IP-Adresse ist ein deutliches Anzeichen für Spoofing, und in diesem Fall können Sie den Missbrauch aktiv unterbinden, indem Sie Ihre Richtlinien so anpassen, dass die E-Mails unter Quarantäne gestellt oder abgelehnt werden.

Verfolgen Sie Ihre Erfolgsquote im Zeitverlauf

Ihre DMARC-Bestandsquote ist der Prozentsatz der E-Mails, die die DMARC-Authentifizierung bestehen. Bei „p=none“ hat dies keinen Einfluss auf die Zustellung, gibt Ihnen jedoch Aufschluss darüber, wie gut Sie auf die Durchsetzung vorbereitet sind. Streben Sie eine Bestandsquote von über 95 % bei allen legitimen Absendern an, die dauerhaft aufrechterhalten wird, bevor Sie Ihre Richtlinie verschärfen. Überwachen Sie diese Quote mindestens zwei bis vier Wochen lang wöchentlich, anstatt auf die Entwicklung eines einzelnen Tages zu reagieren.

Entscheiden Sie, wann Sie Ihre Police erhöhen möchten

Wechseln Sie zu „p=quarantine“, wenn alle drei Bereitschaftsprüfungen erfüllt sind:

1. Alle bekannten legitimen Absender weisen einen DMARC-Pass auf.
2. In Ihren Berichten tauchen keine unerwarteten Absender mit hohem Versandvolumen auf.
3. Die Erfolgsquote liegt durchweg bei über 95 %.

Wechseln Sie zu „p=reject“, wenn dieselben Bedingungen während der ein- bis zweiwöchigen Quarantänephase ohne unerwartete Vorkommnisse bestehen bleiben. Der gesamte Ablauf der Richtlinienanpassung wird in unserem DMARC-Einrichtungsanleitung.

PowerDMARC automatisiert diese gesamte Analyse. Unsere Plattform erfasst die Durchlaufquoten, identifiziert Absender anhand ihres Namens statt ihrer IP-Adresse und benachrichtigt Sie sofort, sobald ein neuer, nicht autorisierter Absender auftaucht. So wird die Entscheidung über die Zulassung für Sie getroffen, anstatt sie aus rohen XML-Daten rekonstruieren zu müssen.

Warum erhalte ich keine DMARC-Berichte?

Wenn Sie einen Datensatz mit dem Attribut „rua=“ veröffentlicht haben, aber noch keine Berichte eingegangen sind, liegt dies fast immer an einer dieser sechs Ursachen.

Problem 1: In Ihrem DMARC-Eintrag fehlt das „rua=“-Tag. Dies ist die häufigste Ursache. Ohne „rua=“ haben Sie den Empfang von Berichten ausdrücklich abgelehnt. Lösung: Fügen Sie „rua=mailto:[email protected]“ zu Ihrem Eintrag hinzu und überprüfen Sie dies mit unserem DMARC-Checker.

Problem 2: Falsche oder ungültige E-Mail-Adresse. Ein Tippfehler, ein nicht existierender Posteingang oder ein volles Postfach führen dazu, dass Berichte unbemerkt verloren gehen. Lösung: Überprüfen Sie, ob die „rua=“-Adresse tatsächlich E-Mails empfangen kann, indem Sie eine Testnachricht an diese Adresse senden.

Problem 3: Externer Berichtsempfänger nicht autorisiert. Wenn Ihr „rua=“ auf eine Adresse in einer anderen Domain verweist als Ihr DMARC-Eintrag (Ihre Domain lautet „company.com“, „rua=“ verweist jedoch auf „[email protected]“), muss die externe Domain unter „_report._dmarc.reportingservice.com“ einen Autorisierungseintrag mit „v=DMARC1“ veröffentlichen. Ohne diesen Eintrag werden Berichte verworfen. Die meisten DMARC-Plattformen übernehmen dies automatisch für Sie.

Problem 4: Sie haben einen neuen Eintrag veröffentlicht, aber die DNS-Änderung wurde noch nicht übernommen. Berichte treffen 24 bis 48 Stunden nach der weltweiten Veröffentlichung Ihres Eintrags ein. Um dieses Problem zu beheben, überprüfen Sie die Übernahme mit unserem DNS-Propagierungs-Checker.

Ausgabe 5: Die Berichte landen im Spam-Ordner. Die Berichte werden als komprimierte Anhänge von automatisierten Absendern verschickt und oft herausgefiltert. Um dies zu beheben, überprüfen Sie bitte Ihren Spam-Ordner und setzen Sie die Absender der Berichte auf die Whitelist ([email protected], [email protected]).

Ausgabe 6: Es wurde noch keine E-Mail versendet. Berichte werden erst erstellt, wenn Ihre Domain tatsächlich E-Mails versendet hat, die einen Provider erreicht haben. Wenn seit der Veröffentlichung des Eintrags noch keine E-Mails versendet wurden, gibt es noch nichts zu berichten.

RFC 9990: Der Standard für den Gesamtbericht 2026

Stand: Mai 2026, regelt RFC 9990 regelt das Format und die Übermittlung von DMARC-Gesamtberichten und übernimmt damit die Berichtsfunktion, die zuvor in RFC 7489 geregelt war. Das XML-Schema ist abwärtskompatibel (bestehende Parser und die Berichte, die Sie bereits erhalten, funktionieren weiterhin), und die wichtigste Änderung besteht in der formalen Standardisierung des Berichtsformats und der täglichen Berichtsfrequenz. 

Eine vollständige Übersicht über die neuesten Aktualisierungen finden Sie in unserem DMARC-RFC 9989/9990/9991 Leitfaden. 

Häufig gestellte Fragen

Was ist ein DMARC-Bericht?

Ein DMARC-Bericht ist eine tägliche XML-Datei, die von empfangenden Mail-Servern an die in Ihrem „rua=“-Tag angegebene Adresse gesendet wird. Darin sind alle IP-Adressen zusammengefasst, von denen E-Mails über Ihre Domain versendet wurden, sowie die jeweiligen Ergebnisse der SPF- und DKIM-Prüfungen. Anbieter wie Google, Microsoft und Yahoo erstellen diese Berichte jedes Mal, wenn sie E-Mails erhalten, die angeblich von Ihrer Domain stammen. Sie sind das wichtigste Instrument zur Überwachung des E-Mail-Authentifizierungsstatus Ihrer Domain.

Was ist der Unterschied zwischen RUA und RUF bei DMARC?

RUA-Berichte (Gesamtberichte) sind tägliche XML-Zusammenfassungen, die alle E-Mail-Aktivitäten Ihrer Domain abdecken. RUF-Berichte (Fehlerberichte) sind Fehlerbenachrichtigungen pro Nachricht, die individuelle E-Mail-Header-Daten enthalten können. Die meisten großen Anbieter, darunter Google, Microsoft und Yahoo, versenden aufgrund datenschutzrechtlicher Auflagen keine Fehlerberichte mehr, sodass Gesamtberichte häufiger vorkommen und weltweit unterstützt werden.

Wie oft werden DMARC-Berichte versendet?

Die meisten Anbieter versenden alle 24 Stunden einen Sammelbericht. Da jeder empfangende Mailserver einen eigenen Bericht versendet, erhalten Sie einen Bericht von jedem Anbieter, dessen Nutzer Ihre E-Mails erhalten haben. Eine Domain, die E-Mails an Nutzer von Gmail, Outlook und Yahoo versendet, muss daher mit mindestens drei Berichten pro Tag rechnen.

Wie lese ich einen DMARC-XML-Bericht?

Ein DMARC-XML-Bericht besteht aus drei Hauptabschnitten: „report_metadata“ (Absender und Zeitraum), „policy_published“ (Ihr ausgewerteter DMARC-Eintrag) und „records“ (ein Eintrag pro sendender IP-Adresse mit den entsprechenden SPF- und DKIM-Ergebnissen). Eine praktische Anleitung finden Sie im XML-Beispiel weiter oben in diesem Leitfaden. Die meisten IT-Teams verwenden jedoch einen automatisierten Analysator, der Absender anhand ihres Namens identifiziert, anstatt das XML-Rohdatenformat zu lesen.

Warum erhalte ich DMARC-Berichte von Organisationen, die ich nicht kenne?

Jeder Mailserver, der E-Mails empfängt, die angeblich von Ihrer Domain stammen, sendet eine Meldung, sofern Sie „rua=“ konfiguriert haben. Dazu gehören kleine Internetdienstanbieter, Mail-Gateways von Unternehmen und internationale Anbieter, die Ihre Empfänger nutzen – nicht nur Google und Microsoft. Es ist normal, Meldungen von unbekannten Organisationen zu erhalten; dies bedeutet lediglich, dass diese Server E-Mails verarbeitet haben, die scheinbar von Ihrer Domain stammten.

• Über
• Neueste Beiträge

Maitham Al Lawati

Experte für Cybersicherheit, Geschäftsführer bei PowerDMARC

Maitham ist ein Tech-Unternehmer, Cybersecurity-Experte, CEO und Gründer von PowerDMARC mit mehr als 15 Jahren Branchenerfahrung. Maitham hat einen Global MBA von der University of Manchester und verschiedene berufliche Zertifizierungen, darunter CISSP, CISM, CRISC und ISC2 CCSP.

Neueste Beiträge von Maitham Al Lawati (alle anzeigen)

• So richten Sie DMARC ein: Vollständige Schritt-für-Schritt-Anleitung zur Konfiguration (2026) – 20. Juni 2026
• So lesen Sie DMARC-Berichte: Ein umfassender Leitfaden zu RUA und RUF – 10. Juni 2026
• Was ist DMARC? Definition, Funktionsweise und Bedeutung – 28. April 2026