DMARC-Aggregate-Report (rua) lesen und richtig auswerten

Ein DMARC-Aggregate-Report ist eine tägliche Zusammenfassung, die große E-Mail-Provider an die Adresse im rua-Tag Ihres DMARC-Eintrags senden. Er listet jede IP-Adresse auf, die Mails mit Ihrer Domain in der From-Zeile versendet hat, wie viele Nachrichten jeweils verschickt wurden und ob SPF und DKIM bestanden haben und mit Ihrer Domain übereinstimmen (Alignment). Nachrichteninhalte, Betreffzeilen oder Empfängeradressen enthält er nicht.

Aus diesen Reports erfahren Sie, wer tatsächlich in Ihrem Namen sendet: Ihre eigenen Mailserver, das CRM, das Rechnungsprogramm, die Newsletter-Plattform und jeder andere, der Ihre Domain einfach in die From-Zeile schreibt. Genau diese Liste brauchen Sie, bevor Sie Ihre Policy von p=none auf eine durchsetzende Stufe umstellen.

Seit Mai 2026 ist das Format in RFC 9990 festgelegt, das zusammen mit RFC 9989 (dem eigentlichen DMARC-Mechanismus) das ältere RFC 7489 abgelöst hat. Wenn Sie die 3 Einträge kurz auffrischen möchten, beginnen Sie mit SPF, DKIM und DMARC erklärt.

Wie die Reports zu Ihnen gelangen

Reports fordern Sie mit dem rua-Tag in Ihrem DMARC-Eintrag an:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Jeder teilnehmende Provider schickt Ihnen dann eine XML-Datei per E-Mail, meist komprimiert. Laut RFC 9990 SOLLTE das XML mit GZIP komprimiert sein, mit der Endung .xml.gz, und der Dateiname folgt einem festen Muster:

mail.receiver.example!example.com!1013662812!1013749130.xml.gz

Das sind die meldende Organisation, Ihre Domain sowie Beginn und Ende des Zeitraums als Unix-Zeitstempel. Der Berichtszeitraum umfasst in der Regel einen einzelnen UTC-Tag.

Sollen die Reports an ein Postfach unter einer anderen Domain gehen (zum Beispiel an einen Reporting-Dienst unter reports.example.net), muss diese Domain bestätigen, dass sie die Reports annimmt. Empfänger suchen dazu einen TXT-Eintrag wie example.com._report._dmarc.reports.example.net mit dem Inhalt v=DMARC1. Fehlt er, ignorieren sie die rua-Adresse. Ein fehlender Bestätigungseintrag ist ein häufiger Grund, warum nie Reports ankommen.

Der Aufbau eines Reports

Jeder Report besteht aus denselben 3 Teilen. Hier ein gekürztes Beispiel auf Basis des Musters aus RFC 9990:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <report_metadata>
    <org_name>Sample Reporter</org_name>
    <date_range><begin>302832000</begin><end>302918399</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>quarantine</p>
    <testing>n</testing>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.123</source_ip>
      <count>123</count>
      <policy_evaluated>
        <disposition>pass</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>example.com</envelope_from>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><result>pass</result><selector>abc123</selector></dkim>
      <spf><domain>example.com</domain><result>fail</result></spf>
    </auth_results>
  </record>
</feedback>

• report_metadata: wer den Report gesendet hat und welchen Zeitraum er abdeckt.
• policy_published: der DMARC-Eintrag, den der Empfänger gesehen hat. Vergleichen Sie ihn mit dem, was Sie veröffentlicht zu haben glauben.
• record: ein Block pro Kombination aus sendender IP und Ergebnissen. Eine stark genutzte Domain erhält viele davon.

Einen Eintrag Feld für Feld lesen

source_ip und count. Der Server, der sich mit dem Empfänger verbunden hat, und wie viele Nachrichten er in diesem Zeitraum zugestellt hat. Hier identifizieren Sie die Absender: Ein Reverse-DNS-Lookup (dig -x 192.0.2.123 +short) oder der Inhaber der IP verrät oft, ob sie zu Ihrem Mail-Provider, Ihrem CRM oder zu jemand Unbekanntem gehört.

policy_evaluated. Das DMARC-Urteil. dkim und spf sind hier nicht die Rohergebnisse, sondern die Alignment-Ergebnisse: Hat die Prüfung für eine Domain bestanden, die zu Ihrer From-Domain passt? DMARC ist bestanden, wenn mindestens eines davon pass ist. disposition zeigt, was der Empfänger getan hat: none, pass, quarantine oder reject. Weicht das von Ihrer Policy ab, erklärt ein reason-Element den Grund, zum Beispiel eine Ausnahme wegen Weiterleitung oder Mailingliste.

identifiers. header_from ist die Domain, die Ihre Empfänger gesehen haben. envelope_from ist die Domain, die für die SPF-Prüfung verwendet wurde, oft eine Subdomain Ihres Versanddienstes statt Ihrer eigenen.

auth_results. Die Rohergebnisse von SPF und DKIM mit den Domains, für die geprüft wurde. RFC 9990 schreibt nun den DKIM-Selektor vor, was Ihnen hilft zu erkennen, welcher Dienst die Nachricht signiert hat.

Im Beispiel oben hat DKIM bestanden und war aligned, SPF ist fehlgeschlagen, und die Nachricht hat DMARC trotzdem bestanden. Das ist ein typisches Bild für einen Dienst, der mit Ihrer Domain signiert, aber von seiner eigenen Envelope-Domain sendet.

Absender in 3 Gruppen einteilen

Nach einigen Wochen mit Reports lässt sich jede Quell-IP einer dieser Gruppen zuordnen:

1. Bekannt und bestanden. Ihr Mail-Provider und korrekt eingerichtete Dienste. Nichts zu tun.
2. Bekannt, aber fehlgeschlagen. Ein legitimes Tool (Helpdesk, Rechnungsprogramm, Newsletter), das ohne aligned DKIM sendet oder im SPF-Eintrag fehlt. Aktivieren Sie in diesem Tool DKIM mit Ihrer Domain oder nehmen Sie es in SPF auf und achten Sie dabei auf das Limit von 10 DNS-Lookups.
3. Unbekannt und fehlgeschlagen. Server, die Sie keinem Ihrer Dienste zuordnen können. Manche sind Weiterleitungen und Mailinglisten, andere sind jemand, der Ihre Domain in die From-Zeile setzt. Genau diese Nachrichten würde eine Policy p=quarantine oder p=reject stoppen, dieselbe Art von Mails, die bei Betrug mit gefälschten Rechnungen eingesetzt wird.

Vor der Umstellung kommt es auf Gruppe 2 an. Wechseln Sie auf p=quarantine, während ein legitimes Tool noch fehlschlägt, landen dessen Mails im Spam.

Praktische Tipps

• Nutzen Sie ein eigenes Postfach oder ein Tool zur Report-Auswertung. Täglich rohes XML von mehreren Providern ist von Hand kaum lesbar.
• Achten Sie auf den Wert testing. RFC 9989 hat das alte pct-Tag durch ein Testmodus-Tag t ersetzt; t=y bittet Empfänger, eine mildere Maßnahme als Ihre Policy anzuwenden.
• Schauen Sie auf das Volumen, nicht nur auf Fehler. Eine plötzlich neue Quelle mit hohem count verdient Aufmerksamkeit, auch wenn sie besteht.
• Bewahren Sie Reports einige Monate auf, damit Sie den Zustand vor und nach einer Änderung vergleichen können.
• Denken Sie daran, dass E-Mail-Provider DMARC von Massenversendern zunehmend erwarten, wie in Anforderungen von Gmail und Yahoo an Absender beschrieben.

Kurze Checkliste

• DMARC-Eintrag mit einer rua-Adresse, die tatsächlich jemand liest.
• Externe Report-Ziele mit einem _report._dmarc-Eintrag bestätigt.
• Jede Quell-IP einem bekannten Dienst zugeordnet.
• Aligned DKIM für jeden legitimen Absender aktiviert.
• Unbekannte fehlgeschlagene Quellen geprüft, danach die Policy auf p=quarantine und später auf p=reject umgestellt.

Wo Guarding ansetzt

DMARC-Reports zeigen, was die Empfänger gesehen haben. Wir beobachten täglich die andere Seite von außen: Ihre SPF-, DKIM- und DMARC-Einträge, ähnlich aussehende Domains und den Rest Ihrer externen Angriffsfläche. Wird ein Eintrag abgeschwächt oder verschwindet ein Selektor, prüft ein Mensch die Änderung, und Sie erhalten die genaue Korrektur, wie unter was passiert, wenn wir etwas finden beschrieben. Wie das aussieht, sehen Sie im Beispiel-Dashboard.