DMARC-Report

Ein DMARC-Report (auch DMARC-Bericht) ist eine automatische Rückmeldung, die empfangende Mailserver an die Berichtsadresse im DMARC-Eintrag Ihrer Domain schicken. Er zeigt, welche Server im Berichtszeitraum Mails mit Ihrer Domain als Absender verschickt haben und ob diese Mails die Prüfungen von SPF, DKIM und DMARC bestanden haben. Für Unternehmen mit Microsoft 365 sind diese Berichte die Grundlage, um den Schutz vor gefälschten Absendern schrittweise zu verschärfen, ohne versehentlich eigene, echte Mails abweisen zu lassen.

Was ist ein DMARC-Report?

Der Eintrag für DMARC im DNS legt fest, wie Empfänger mit Mails umgehen, die weder per SPF noch per DKIM passend bestätigt sind. Über zwei Angaben (Tags) nennt er auch, wohin die Rückmeldungen gehen: rua für Sammelberichte, ruf für Einzelberichte. Sammelberichte regelt seit Mai 2026 RFC 9990, Einzelberichte RFC 9991 (RFCs sind die Standarddokumente des Internets). Zusammen mit RFC 9989 lösen sie RFC 7489 ab, das DMARC bisher beschrieb.

XML ist ein strukturiertes Textformat, das für Programme gedacht ist; GZIP ist ein Verfahren zur Komprimierung. Im Alltag arbeiten Sie fast nur mit Sammelberichten. Microsoft empfiehlt, zunächst nur rua zu setzen.

Was steht in einem DMARC-Report?

Ein Sammelbericht kommt als Mail, deren Betreff mit „Report Domain: beispiel.de“ beginnt. Die angehängte Datei enthält einen Kopf mit dem berichtenden Anbieter und dem Zeitraum, die veröffentlichte Richtlinie Ihrer Domain und Datensätze: für jede sendende IP-Adresse mindestens einen, bei unterschiedlichen Prüfergebnissen mehrere. Gekürzt und mit Beispielwerten sieht ein Datensatz so aus:

<record>
  <row>
    <source_ip>198.51.100.10</source_ip>
    <count>214</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>beispiel.de</header_from>
    <envelope_from>bounce.newsletter-dienst.example</envelope_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>newsletter-dienst.example</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.newsletter-dienst.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

So lesen Sie ihn:

• source_ip und count: Von dieser IP-Adresse kamen im Berichtszeitraum 214 Mails mit beispiel.de als Absender.
• identifiers: header_from ist die sichtbare Absenderdomain, envelope_from die Domain der Umschlagadresse (MAIL FROM), die SPF prüft.
• auth_results: das reine Ergebnis von SPF und DKIM, jeweils mit der geprüften Domain.
• policy_evaluated: ob SPF und DKIM mit einer zur sichtbaren Absenderdomain passenden Domain bestanden haben (Ausrichtung, englisch Alignment), und unter disposition, welche Maßnahme der Empfänger nach der DMARC-Richtlinie angewandt hat.

Entscheidend ist der Unterschied zwischen bestanden und passend. Im Beispiel bestehen SPF und DKIM, aber mit Domains des Newsletter-Dienstes, die nicht zu beispiel.de passen. Deshalb steht unter policy_evaluated zweimal fail: Diese Mails bestehen DMARC nicht. Mit p=none hat das keine DMARC-Folgen. Nach einer Umstellung auf p=reject würden Empfänger, die der Richtlinie folgen, genau diese Newsletter abweisen. Abhilfe: Richten Sie beim Dienst eine DKIM-Signatur mit Ihrer Domain (d=beispiel.de) oder eine Umschlagadresse unter Ihrer Domain ein, etwa bounce.beispiel.de.

Weitere typische Muster:

• Microsoft-Server, SPF und DKIM passend: normaler Versand aus Microsoft 365.
• Microsoft-Server, SPF passend, aber keine passende DKIM-Signatur: meist ist DKIM für die eigene Domain noch nicht aktiviert.
• Bekannter Dienst, beides fehlgeschlagen: Er fehlt im SPF-Eintrag und signiert nicht mit DKIM.
• Unbekannte IP-Adressen, viele Fehlschläge: ein Hinweis auf E-Mail-Spoofing, also gefälschte Absender, oder auf einen Versender, den noch niemand erfasst hat.
• Fehlschläge über Verteiler und Weiterleitungen: bei weitergeleiteter Post normal, weil beim Weiterleiten SPF scheitert und Änderungen an der Nachricht DKIM brechen.

DMARC-Report in Microsoft 365

Für eigene Domains gibt es in Microsoft 365 weder Portal noch PowerShell-Befehl für den DMARC-Eintrag. Sie legen ihn samt Berichtsadresse beim DNS-Anbieter an. Ein Einstieg für beispiel.de:

Name:  _dmarc.beispiel.de
Typ:   TXT
Wert:  v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de

Für die Berichte empfiehlt Microsoft ein freigegebenes Postfach oder eine Microsoft-365-Gruppe statt eines persönlichen Postfachs und rät, die Berichte anfangs wöchentlich, später monatlich zu prüfen. Als Empfänger hat Microsoft 365 zwei Eigenheiten:

• Microsoft 365 schickt Sammelberichte an die rua-Adresse des Absenders nur dann, wenn der MX-Eintrag der empfangenden Domain direkt auf Microsoft 365 zeigt. Steht ein Spamfilter eines anderen Anbieters davor oder läuft die Zustellung im Hybridbetrieb (Exchange lokal und in der Cloud) zuerst über lokale Server, verschickt Microsoft 365 für die dort eingehenden Mails keine Sammelberichte.
• Einzelberichte verschickt Microsoft 365 nicht, auch wenn ruf gesetzt ist. Für Details zu einzelnen Mails verweist Microsoft auf die Nachrichtenablaufverfolgung (Message Trace) und die Auswertung der Kopfzeilen, etwa des Eintrags Authentication-Results.

Liegt die Berichtsadresse unter einer anderen Domain, etwa bei einem externen Auswertungsdienst, muss diese Domain die Annahme ausdrücklich freigeben. Das gilt auch zwischen zwei eigenen Domains wie beispiel.de und beispiel.com. Fehlt die Freigabe, müssen die Berichtsersteller die Adresse ignorieren. Den Freigabe-Eintrag setzt der Dienst in seinem eigenen DNS:

beispiel.de._report._dmarc.dmarc-dienst.example   TXT   "v=DMARC1;"

Wozu dienen DMARC-Reports?

Ein DMARC-Eintrag mit p=none fordert Empfänger zu keiner Maßnahme auf, er dient der Beobachtung. Die Berichte zeigen, welche Dienste außer Microsoft 365 mit Ihrer Domain senden, etwa Newsletter-Werkzeug, Shop oder Buchhaltungssoftware, und sie machen Fälschungsversuche sichtbar. Wer ohne diese Auswertung auf p=quarantine oder p=reject umstellt, riskiert, dass Rechnungen beim Kunden im Spam landen oder abgewiesen werden. Wer dauerhaft bei p=none bleibt, bittet Empfänger nie, gefälschte Mails abzuweisen.

Typische Fehler bei DMARC-Reports

• Berichte an ein persönliches Postfach: Pro Anbieter und Domain kommt meist täglich eine Mail mit komprimiertem Anhang. Im persönlichen Posteingang geht das leicht unter.
• Externe Berichtsadresse ohne Freigabe: Fehlt bei der Zieldomain der Eintrag unter _report._dmarc, kommen keine Berichte an.
• Adresse ohne mailto: Die Angabe lautet rua=mailto:dmarc@beispiel.de, nicht nur die nackte Mailadresse.
• Einzelberichte dauerhaft angefordert: Sie können Kopfzeilen oder Inhalte einzelner Mails enthalten. RFC 9991 rät, ruf nur gezielt und zeitlich begrenzt zur Fehlersuche zu nutzen.
• Berichte eingerichtet, aber nie gelesen: Dann bleibt die Domain auf p=none.

Praxis-Tipp: Prüfen Sie vor jeder Stufe nicht nur die Fehlschläge, sondern die vollständige Liste aller Quellen über einen längeren Zeitraum. Ein Dienst, der nur zum Monatsende Rechnungen verschickt, fehlt in den Tagesberichten der übrigen Wochen.

Typische Fragen zu DMARC-Reports

Wie oft kommen DMARC-Reports?

Ein Sammelbericht umfasst meist einen Tag nach UTC (koordinierte Weltzeit). Deshalb kommt von jedem berichtenden Anbieter in der Regel ein Bericht pro Tag, der den Vortag abdeckt. Nicht jeder Empfänger verschickt Berichte, und die Menge schwankt mit Ihrem eigenen Mailaufkommen.

Enthalten DMARC-Reports personenbezogene Daten?

Sammelberichte enthalten laut RFC 9990 keine einzelnen Mailadressen und keine Mailinhalte, sondern Domains, Zählwerte und die IP-Adressen der sendenden Server. Einzelberichte können Kopfzeilen oder Inhalte einzelner Mails enthalten und damit personenbezogene Daten. Geben Sie Berichte an einen externen Dienst, prüfen Sie Vertrag und Serverstandort. Die rechtliche Bewertung gehört in Ihre Datenschutzberatung.

Warum fehlen DMARC-Reports?

Mögliche Ursachen: rua fehlt oder ist falsch geschrieben, die Adresse liegt ohne Freigabe unter einer anderen Domain, oder das Postfach nimmt die Mails nicht an. Stehen unter _dmarc mehrere DMARC-Einträge, werden laut RFC 9989 alle verworfen.

Kann ich DMARC-Reports von einem Dienst auswerten lassen?

Ja. Microsoft verweist auf Auswertungsdienste im MISA-Katalog (Microsoft Intelligent Security Association). Alternativ lassen sich die XML-Dateien mit PowerShell oder Power BI auswerten.

DMARC-Reports mit CodeKlar auswerten

CodeKlar richtet die Einträge für Microsoft 365 sauber ein: Wir erfassen alle Dienste und Systeme, die mit Ihrer Domain Mails versenden, bereinigen den SPF-Eintrag, aktivieren DKIM und führen DMARC stufenweise bis zu p=reject. Dazu übernehmen wir das DMARC-Tracking: Wir werten die Berichte laufend aus, finden vergessene Versender und melden Ihnen Auffälligkeiten wie neue, unbekannte Quellen.

Einen ersten Stand liefert der Microsoft 365 DNS-Checker: Er zeigt den vollständigen DMARC-Eintrag Ihrer Domain. Steht darin rua=, ist eine Berichtsadresse hinterlegt. Die Einrichtung gehört zu unseren Leistungen für Exchange Online und sichere E-Mail-Kommunikation und Microsoft 365 Security und Compliance. Was gegen Phishing zusätzlich hilft, zeigt der Beitrag Microsoft 365 trotz MFA vor Phishing schützen.