DMARC-Reports auswerten: Wie Sie XML-Berichte lesen und DMARC schrittweise verschärfen

Warum bekommen Sie seit dem DMARC-Eintrag Mails mit XML-Anhängen?

Ein DMARC-Report ist ein täglicher Prüfbericht im gepackten XML-Format (Extensible Markup Language), den Empfangsserver wie Gmail, Microsoft 365 und Yahoo an Ihre hinterlegte rua-Adresse schicken. Diese DMARC-Berichte sind keine Fehlermeldungen, sondern listen alle Server auf, die unter Ihrer Domain mailen. Prüfen Sie darin zuerst, ob Ihre eigenen Versandwege bestehen.

Sobald Sie SPF, DKIM und DMARC im DNS einrichten und im TXT-Eintrag unter _dmarc das Tag rua=mailto:... ergänzen, bitten Sie fremde Mailserver aktiv um Rückmeldung. Diesen Ablauf regelt das Verfahren Domain-based Message Authentication, Reporting, and Conformance (DMARC) im Internet-Standard Request for Comments (RFC) 7489. Ohne eigenes Intervall-Tag ri gilt dort der Standardwert von 86400 Sekunden, sodass Ihnen jeder teilnehmende Anbieter einmal am Tag einen Sammelbericht schickt.

Die Dateinamen im Anhang wirken auf den ersten Blick sperrig, folgen aber dem festen Schema der DMARC-Spezifikation RFC 7489 der IETF: empfaenger!ihre-domain.de!startzeit!endzeit.xml.gz. Darin stehen der meldende Mailanbieter, Ihre geprüfte Domain sowie Beginn und Ende des Messzeitraums als sogenannte Unix-Zeitstempel in Sekunden. Damit die Anhänge beim Versand klein bleiben, packen die Server die XML-Datei per GZIP (.xml.gz) oder als .zip-Archiv.

Weil jeder große Empfänger wie Google, Microsoft, Yahoo oder GMX einen eigenen Tagesbericht sendet, sammeln sich schnell viele E-Mails an. Richten Sie für die rua-Adresse deshalb ein eigenes Sammelpostfach wie dmarc-berichte@example.de ein, statt Ihr persönliches Hauptpostfach zu nutzen. Sollen die Berichte an eine fremde Domain gehen, verlangt das DNS (Domain Name System) dort einen bestätigenden TXT-Eintrag unter ihre-domain.de._report._dmarc.example.de mit dem Wert v=DMARC1. Den neuen Eintrag kontrollieren Sie wie bei jeder Anpassung, indem Sie die DNS-Verteilung nach Änderungen prüfen.

Vielleicht haben Sie in Anleitungen neben rua auch das Tag ruf für einzelne Fehlerberichte (Failure Reports) gesehen. In der Praxis hilft ruf kaum weiter: Sowohl Gmail als auch Microsoft 365 versenden solche Einzelberichte nicht, sondern liefern ausschließlich die täglichen Sammelberichte über rua aus. Um Ihre Versandwege zu prüfen und DMARC später scharfzuschalten, brauchen Sie daher nur die regulären rua-Dateien.

Was steht in einem DMARC-Bericht?

Jeder entpackte DMARC-Bericht besteht aus allgemeinen Kopfdaten zum Empfangsserver und einzelnen Datensätzen im Block record für jede beobachtete Absender-IP-Adresse. Für Ihre Auswertung brauchen Sie daraus nur vier Stellen: die IP-Adresse samt Nachrichtenanzahl unter row, die geprüften Domains unter identifiers sowie die Ergebnisse in policy_evaluated und auth_results.

Wenn Sie ein .xml.gz-Archiv entpacken und die Datei im Texteditor oder Browser öffnen, sehen Sie zuerst die Blöcke report_metadata und policy_published. Darin nennt der Empfangsserver seinen Namen (etwa google.com), den Abfragezeitraum und Ihre aktuell im DNS veröffentlichte DMARC-Regel wie p=none. Darunter folgen die eigentlichen Prüfeinträge: Für jede IP-Adresse, die im Zeitraum unter Ihrer Domain E-Mails eingeliefert hat, legt der Bericht einen eigenen Block <record> an.

<!-- Datensatz 1: Ihr eigenes Postfach / Webhosting besteht alle Prüfungen -->
<record>
  <row>
    <source_ip>198.51.100.10</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.de</header_from>
    <envelope_from>example.de</envelope_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.de</domain>
      <selector>mail</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>example.de</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

<!-- Datensatz 2: Eigener Newsletter-Dienst besteht SPF technisch, scheitert aber am Alignment -->
<record>
  <row>
    <source_ip>203.0.113.45</source_ip>
    <count>120</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.de</header_from>
    <envelope_from>example.com</envelope_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>example.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Im ersten Datensatz hat der Server Ihres Hosting-Anbieters mit der IP-Adresse 198.51.100.10 insgesamt 42 E-Mails verschickt. Unter policy_evaluated steht disposition auf none, weil Ihre Richtlinie bisher nur beobachtet und nichts aussortiert. Sowohl dkim (DomainKeys Identified Mail) als auch spf (Sender Policy Framework) melden dort pass — dieser Versandweg ist sauber eingerichtet.

Der zweite Datensatz mit 120 Nachrichten von 203.0.113.45 zeigt einen typischen Stolperstein beim Lesen von DMARC-Berichten. Ganz unten unter auth_results meldet die reine SPF-Prüfung zwar pass für die technische Rücksprung-Domain example.com. Oben unter policy_evaluated steht für spf aber trotzdem fail.

Wie kommt dieser Widerspruch zustande? Dafür vergleicht DMARC die technische Prüfdomain mit der für den Empfänger sichtbaren Absenderdomain im Kopfzeilen-Feld From nach dem Standard Internet Message Format (RFC 5322) — diese Namensübereinstimmung heißt Identifier Alignment. In identifiers sehen Sie den Unterschied: Im sichtbaren header_from steht Ihre Domain example.de, während der Versanddienst im Rücksprungpfad envelope_from seine eigene Domain example.com nutzt. Weil beide Domains nicht zusammenpassen, verweigert DMARC unter policy_evaluated das pass.

Für eine bestandene DMARC-Prüfung muss mindestens eines der beiden Verfahren — SPF oder DKIM — technisch bestehen und zugleich im Alignment zur header_from-Domain passen. Solange Sie in Ihrem DMARC-Eintrag nichts anderes festlegen, gilt beim Alignment für SPF (aspf=r) und DKIM (adkim=r) der entspannte Modus relaxed, bei dem auch Subdomains wie mail.example.de zur Hauptdomain example.de passen. Im strengen Modus strict (s) müssen beide Domainnamen Zeichen für Zeichen identisch sein.

Woran erkennen Sie einen vergessenen Versanddienst und woran einen Fälscher?

Den Unterschied erkennen Sie am Zusammenspiel zwischen der sendenden IP-Adresse unter source_ip, den technischen Prüfungen in auth_results und der Alignment-Wertung in policy_evaluated. Ein vergessener eigener Dienst sendet von einer nachvollziehbaren Server-IP oder besteht bereits eine Teilprüfung ohne passendes Alignment, während fremde Fälscher von unbekannten IP-Adressen durch sämtliche Prüfungen fallen.

„Die wichtigste Erkenntnis aus aggregierten Berichten besteht darin, die Lücke zwischen Authentifizierungsdurchlauf und Ausrichtungsdurchlauf zu identifizieren.“

— Microsoft Learn, DMARC zum Überprüfen von E-Mails konfigurieren

Genau diese Lücke zwischen Rohprüfung und Alignment begegnet Ihnen beim Durchgehen Ihrer XML-Dateien. Wenn Sie die <record>-Blöcke prüfen, helfen Ihnen fünf typische Muster dabei, jeden Absender eindeutig einzuordnen und den passenden Korrekturschritt abzuleiten:

Das vierte Muster zeigt sich bei Websites: Der Webserver verschickt Bestellbestätigungen oder Anfragen direkt über PHP, ohne im SPF-Eintrag zu stehen oder per DKIM zu signieren. Das ist auch der Grund dafür, warum WordPress-E-Mails nicht ankommen oder wenn das Kontaktformular keine E-Mails zustellt. Binden Sie solche Formulare und Shops fest über ein authentifiziertes Postfach per SMTP ein; im nächsten Tagesbericht ist der Fehler verschwunden.

Wann können Sie von p=none auf quarantine wechseln?

Sie können von p=none auf p=quarantine wechseln, sobald jeder eigene Versandweg Ihrer Domain über einen vollständigen Abrechnungs- und Versandzyklus hinweg in den DMARC-Berichten unter policy_evaluated mindestens bei SPF oder DKIM den Wert pass erreicht. Starten Sie vorsichtig mit einem niedrigen Prozentwert wie pct=10 und erhöhen Sie diesen schrittweise.

Im Beobachtungsmodus p=none weisen Empfangsserver noch keine einzige E-Mail wegen DMARC ab, sondern protokollieren nur. Der Google-Leitfaden zur schrittweisen DMARC-Einführung sieht vor, nach dem Einrichten von SPF und DKIM mindestens 48 Stunden zu warten, dann mit p=none zu starten und die Berichte mindestens eine Woche lang täglich zu prüfen. Für kleinere Unternehmen schlägt Google beim ersten Wechsel auf p=quarantine einen Anteil von pct=5 oder pct=10 vor.

In der Praxis ist eine einzelne Woche Beobachtung allerdings oft zu kurz, weil Rechnungsprogramme, Mahnläufe oder Newsletter-Systeme manchmal nur einmal im Monat senden. Ich gehe bei der Umstellung deshalb immer in festen Stufen vor: Zuerst nur beobachten, dann die Berichte auswerten, erst danach verschärfen. So finde ich fehlende Versandwege, bevor DMARC echte Mails abweist.

Im Komplettpaket läuft DMARC zunächst nur im Beobachtungsmodus. Sechs Wochen lang werte ich die Berichte aus und finde Versandwege, die noch fehlen. Wenn alle echten Mails die Prüfung bestehen, stelle ich DMARC schrittweise auf „in den Spam verschieben“ und dann auf „ablehnen“. Denken Sie auch daran, Ihre E-Mail-Einstellungen beim Hosterwechsel absichern zu lassen, falls während der Beobachtungsphase ein Serverumzug ansteht.

Sind Ihre Versandwege bereit? Bevor Sie im DNS von p=none auf p=quarantine umstellen, haken Sie diese vier Punkte ab:

1. Alle eigenen Versandwege erfasst: Hauptpostfächer, Website-Formulare, Online-Shop, Newsletter-Dienst, Buchhaltung und Kundenverwaltung tauchen in den Berichten auf.
2. Mindestens ein Weg im Alignment: Bei jedem eigenen Dienst zeigt policy_evaluated entweder für dkim oder für spf (besser für beide) dauerhaft pass.
3. Zeitraum deckt Monatsläufe ab: Der Beobachtungszeitraum umfasst auch seltene Aussendungen wie Monatsrechnungen oder Quartals-Newsletter.
4. Sammelpostfach bleibt erreichbar: Die rua-Adresse empfängt weiterhin Berichte, damit Sie die Auswirkung der Verschärfung direkt kontrollieren können.

Für den Übergang steuern Sie mit dem Tag pct (Prozentsatz von 0 bis 100, Standardwert ohne Angabe ist 100), auf welchen Anteil der scheiternden E-Mails die Empfangsserver Ihre neue Richtlinie anwenden. Microsoft beschreibt für den Rollout die Stufenfolge pct=10, pct=25, pct=50, pct=75 und schließlich pct=100 (oder das Weglassen von pct). So können Sie Regeln für fremde Absender festlegen und im Bericht unter <disposition>quarantine</disposition> prüfen, ob wirklich nur unerwünschte Absender im Spam-Ordner landen.

Was ändert sich mit reject, und was kann dabei schiefgehen?

Mit der Einstellung p=reject weisen Empfangsserver nicht authentifizierte E-Mails unter Ihrer Domain bereits während der SMTP-Übertragung (Simple Mail Transfer Protocol) endgültig ab, statt sie nur in den Spam-Ordner zu verschieben. Fehlt zu diesem Zeitpunkt noch ein einziger eigener Versanddienst oder bricht eine Weiterleitung die Prüfung, gehen echte Nachrichten unwiderruflich verloren.

Technisch bricht der empfangende Mailserver die Annahme bei p=reject direkt im Verbindungsaufbau mit einem SMTP-Fehlercode wie 550 5.7.1 ab. Der Empfänger sieht die Nachricht weder im Posteingang noch im Spam-Ordner. Diese schärfste Stufe schützt Ihre Domain wirksam vor Missbrauch und stärkt Ihre Website-Sicherheit für Unternehmen, verzeiht aber keine unvollständige Konfiguration mehr.

Ein oft übersehenes Detail steckt im Zusammenspiel von p=reject und einem gedrosselten pct-Wert wie pct=10. Wenn Sie v=DMARC1; p=reject; pct=10; rua=mailto:dmarc-berichte@example.de eintragen, weisen Empfangsserver zehn Prozent der scheiternden E-Mails hart ab. Die Server lassen die übrigen neunzig Prozent jedoch nicht ungefiltert durch, sondern wenden darauf nach Abschnitt 6.6.4 von RFC 7489 die nächstkleinere Stufe quarantine an — diese Nachrichten landen also weiterhin im Spam-Ordner.

Wo hakt es im Alltag? Vor dem Wechsel auf p=reject sollten Sie drei typische Fehlerquellen prüfen, die immer wieder echte E-Mails blockieren:

• Automatische Weiterleitungen und Verteilerlisten: Leitet ein Empfänger Ihre E-Mail automatisch an ein zweites Postfach weiter, sendet der weiterleitende Server von seiner eigenen IP-Adresse, wodurch SPF zwangsläufig scheitert. Ihre E-Mail übersteht diesen Zwischenschritt nur, wenn Sie ausgehende Nachrichten per DKIM signieren und die Weiterleitung Kopfzeilen sowie Inhalt unverändert lässt.

• Die 10-Lookup-Grenze bei SPF: Nach dem SPF-Standard RFC 7208 darf ein Empfangsserver beim Auflösen Ihres SPF-Eintrags höchstens zehn DNS-Abfragen über Mechanismen wie include, a, mx, ptr, exists oder redirect ausführen. Zu viele eingetragene Dienste reißen diese Grenze und lassen SPF mit permerror abbrechen; genauso führt mehr als ein einziger SPF-TXT-Eintrag auf derselben Domain sofort zu permerror.

• Große Versandmengen ohne saubere Authentifizierung: Ein fehlerhaftes SPF ohne gültige DKIM-Signatur sperrt Ihren eigenen Versand unter p=reject komplett aus. Gerade bei hohem Versandaufkommen prüfen die großen Mailanbieter streng: Seit Februar 2024 verlangen Google und Yahoo für Absender ab 5.000 E-Mails pro Tag zwingend SPF, DKIM und DMARC. Seit dem 5. Mai 2025 setzt Microsoft für Outlook.com vergleichbare Regeln mit dem Ablehnungscode 550; 5.7.515 durch.

DMARC-Berichte selbst lesen oder auswerten lassen?

Die Anzahl Ihrer Versanddienste und die Häufigkeit von Änderungen an Ihrer Infrastruktur entscheiden darüber, ob Sie DMARC-Berichte selbst auswerten oder abgeben. Bei einer einzelnen Domain mit Postfach und Website-Formular genügen oft wenige Kontrollen im Editor, während mehrere externe Dienste für Shop, Newsletter und Abrechnung eine laufende Überwachung erfordern.

Auch beim Datenschutz gibt es einen Unterschied zwischen der Auswertung im eigenen Postfach und externen Analyse-Plattformen. Weil DMARC-Berichte die IP-Adressen der einliefernden Mailserver enthalten, fällt die Verarbeitung zur Abwehr von Missbrauch und zur Netz- und Informationssicherheit unter das berechtigte Interesse nach Artikel 6 Absatz 1 Buchstabe f DSGVO (Datenschutz-Grundverordnung, Erwägungsgrund 49). Gehen Ihre rua-Berichte dagegen an einen externen Auswertungsdienst, verarbeitet dieser die Berichtsdaten in Ihrem Auftrag nach Artikel 4 Nummer 8 DSGVO.

Wenn Sie Ihre Domain nicht selbst durch die XML-Tabellen begleiten möchten, übernehme ich die Einrichtung und Auswertung von SPF, DKIM und DMARC für Sie. Im Paket Einrichtung (249 € zzgl. 19 % USt., Stand Oktober 2026) richte ich SPF, DKIM und DMARC im Beobachtungsmodus für bis zu zwei Versandwege wie Postfach und Kontaktformular ein.

Kommen Shop, Newsletter, Rechnungsprogramm oder Kundenverwaltung hinzu, deckt das Paket Komplett (490 € zzgl. 19 % USt., Stand Oktober 2026) sämtliche Versandwege Ihrer Domain samt sechs Wochen Berichtskontrolle und der stufenweisen Umstellung bis zur strengen Einstellung ab. Für die dauerhafte Kontrolle danach gibt es das Paket Überwachung für 19 € im Monat zzgl. 19 % USt. (Stand Oktober 2026, monatlich kündbar), das Sie unabhängig von einer laufenden WordPress-Wartung buchen können. Den genauen Leistungsumfang sehen Sie bei den Preisen für Einrichtung, Komplettpaket und laufende Überwachung.