Ein DMARC-Eintrag ohne rua-Adresse schützt eine Domain blind: Er blockiert oder lässt E-Mails durch, ohne je zu sagen, wer sie verschickt hat. DMARC-Sammelberichte (RUA) schließen diese Lücke, indem sie täglich auflisten, welche IP-Adressen im Namen der Domain E-Mails versendet haben und wie ihre SPF- und DKIM-Authentifizierung ausgefallen ist. Seit Mai 2026 hat sich der technische Rahmen dafür geändert: Die RFCs 9989, 9990 und 9991 ersetzen die RFC 7489 von 2015 und heben DMARC vom Status Informational auf den Status Proposed Standard der IETF.
Warum RUA-Berichte unverzichtbar bleiben
Eine Domain, die auf p=reject umstellt, ohne vorher ihre Sammelberichte gelesen zu haben, riskiert, eigene Marketingkampagnen, Support-Tools oder einen vergessenen Dienstleister zu blockieren. RUA-Berichte liefern die vollständige Liste der Versandquellen, die große Empfänger (Gmail, Outlook, Yahoo) in einem bestimmten Zeitraum beobachtet haben, jeweils mit Nachrichtenvolumen und SPF/DKIM-Alignment-Ergebnis. Es ist die einzige Datenquelle, die nicht von einer Selbstauskunft der Domain abhängt.
Der Leitfaden zu SPF, DKIM und DMARC behandelt die Einrichtung aller drei Mechanismen; dieser Artikel konzentriert sich auf den oft übersprungenen nächsten Schritt: die tatsächliche Auswertung der Berichte, sobald die rua-Adresse eingetragen ist.
Der Aufbau eines Sammelberichts
Ein RUA-Bericht ist ein XML-Dokument, das einmal täglich von jedem Empfänger verschickt wird, der E-Mails von der Domain erhalten hat. Die RFC 9990 legt seine Struktur fest: ein report_metadata-Kopf, der die versendende Organisation und den abgedeckten Zeitraum benennt, ein policy_published-Block, der die zum Auswertungszeitpunkt im DNS gelesene DMARC-Richtlinie wiedergibt, und schließlich eine Reihe von record-Elementen, eines pro Quelle-Ergebnis-Paar.
| Element | Inhalt | Praktischer Nutzen |
|---|---|---|
report_metadata | Versendende Organisation, Berichts-ID, Zeitraum (date_range) | Eingehende Berichte deduplizieren und datieren |
policy_published | Richtlinie p, sp, np, Alignment-Modus | Prüfen, ob der Empfänger die erwartete Richtlinie gelesen hat |
row / source_ip | Quell-IP-Adresse und Nachrichtenanzahl | Unbekannte oder nicht autorisierte Absender erkennen |
policy_evaluated | Angewandte Maßnahme (none, quarantine, reject) sowie SPF/DKIM-Ergebnisse | Die tatsächliche Auswirkung einer strengeren Richtlinie messen |
identifiers / header_from | Für den Empfänger sichtbare Domain | Abgleich mit der ausgewerteten Domain bestätigen |
Hier ein vereinfachter Auszug dessen, was ein Bericht für einen einzelnen Absender enthält:
<record>
<row>
<source_ip>203.0.113.45</source_ip>
<count>412</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>mail-studio.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>mail-studio.com</domain>
<selector>s1</selector>
<result>pass</result>
</dkim>
<spf>
<domain>sendgrid.net</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
Dieser Datensatz zeigt einen häufigen Fall: Die Nachricht besteht DKIM (die Signatur der Domain ist gültig), scheitert aber an SPF, weil der Umschlagabsender die Domain des Versanddienstleisters statt der eigenen Website trägt. Da DMARC nur verlangt, dass mindestens einer der beiden Mechanismen besteht und aligned ist, gilt diese Nachricht trotz des SPF-Fehlers weiterhin als konform.
Was DMARCbis (RFC 9989 bis 9991) ändert
Die drei im Mai 2026 veröffentlichten Dokumente teilen das Protokoll in drei getrennte Texte auf: RFC 9989 für den Protokollkern (Richtlinie, Alignment, Verarbeitung der Einträge), RFC 9990 für Sammelberichte und RFC 9991 für Fehlerberichte. Die sichtbarste Änderung beim Lesen der Berichte betrifft das Feld discovery_method im Block policy_published: Es gibt nun an, ob die Organisationsdomain über die Public Suffix List (PSL) oder über einen aufwärts gerichteten DNS-Durchlauf, den „Tree Walk“, ermittelt wurde, der nicht mehr von einer extern gepflegten Liste abhängt.
Das Tag pct, das als uneinheitlich zwischen Empfängern umgesetzt galt, entfällt in der RFC 9989 (siehe deren Anhang zu dieser Streichung). Zwei Tags übernehmen präzisere Aufgaben:
| Tag | Funktion | Status |
|---|---|---|
pct | Anteil der Nachrichten, die der Richtlinie unterliegen | Aus der RFC 9989 entfernt |
np | Richtlinie für nicht existierende Subdomains | In der RFC 9989 definiert |
psd | Kennzeichnet eine Public-Suffix-Domain | In der RFC 9989 definiert |
t | Testmodus der Richtlinie (y oder n) | In der RFC 9989 definiert |
Eine dringende Migration ist nicht erforderlich: Ein bestehender DMARC-Eintrag bleibt gültig, und die Syntax beginnt weiterhin mit v=DMARC1. Die konkrete Maßnahme besteht darin, pct aus Einträgen zu entfernen, die es noch verwenden, und zu prüfen, ob die Plattform oder der Dienstleister, der die Sammelberichte verarbeitet, die RFCs 9989 bis 9991 versteht.
Berichte lesen ohne kostenpflichtige Plattform
Empfänger senden die Berichte komprimiert (gzip oder zip) an die in rua angegebene Adresse. Für eine Domain mit überschaubarem Volumen reicht ein Skript, das entpackt, das XML parst und nach source_ip aggregiert, völlig aus: Die meisten Sprachen bringen einen nativen XML-Parser mit, und die oben beschriebene Struktur lässt sich gut in eine Tabelle überführen. Entscheidend ist, nach Absender statt Bericht für Bericht zu lesen, da das Tagesvolumen bei einer aktiven Domain schnell mehrere Dutzend Dateien erreichen kann.
RUA-Berichte decken nur ab, was Empfänger preisgeben wollen: Sie sagen nichts über die endgültige Zustellung einer Nachricht (Posteingang, Werbe-Tab oder Spam-Ordner). Für diese Detailtiefe müssen Sammelberichte mit einem empfängerspezifischen Reputationstool abgeglichen werden, etwa Google Postmaster Tools auf der Gmail-Seite, das einen Domain- und IP-Reputationswert unabhängig vom Inhalt der DMARC-Berichte liefert. Beide Quellen ergänzen sich: DMARC zeigt, wer sendet und mit welchem Authentifizierungsergebnis, Postmaster Tools zeigt, wie diese authentifizierte Post tatsächlich wahrgenommen wird.
Typische Interpretationsfehler
Ein SPF-Fehler ist nicht zwangsläufig ein Problem: Sobald eine Nachricht über eine externe Versandplattform läuft (Marketing-Tool, Support-Tool), trägt der Umschlag die Domain des Dienstleisters, und SPF scheitert mechanisch, ohne dass DKIM betroffen ist. Es gibt auch die umgekehrte Falle: Eine legitime Quelle, die über einen längeren Zeitraum sowohl SPF als auch DKIM nicht besteht, deutet fast immer auf eine unvollständige Konfiguration beim Dienstleister hin, die vor einer strengeren Richtlinie zu beheben ist. Der Leitfaden zur Darstellung von HTML-E-Mails behandelt weitere Abweichungen zwischen dem, was ein Absender verschickt, und dem, was ein E-Mail-Client anzeigt, im selben Geist: erst prüfen, dann diagnostizieren.
Eine weitere Falle besteht darin, Nachrichtenvolumen mit Schweregrad zu verwechseln. Eine unbekannte Quelle, die nur wenige Nachrichten pro Tag versendet, verdient es, identifiziert zu werden, rechtfertigt aber nicht, den Wechsel zu p=quarantine hinauszuzögern, wenn die Hauptquellen sauber sind. Umgekehrt muss eine Quelle, die einen erheblichen Anteil des Gesamtvolumens ausmacht und das Alignment systematisch verfehlt, vor jeder Richtlinienänderung behoben werden, sonst droht ein spürbarer Teil der legitimen Post der Domain blockiert zu werden. Fehlerberichte (RUF, nun durch die RFC 9991 definiert) liefern zu dieser Diagnose Details auf Nachrichtenebene, werden aber nicht von jedem Empfänger verschickt, und ihr Inhalt kann Teile der ursprünglichen Nachricht enthalten: Sie verlangen dieselbe Vorsicht beim Datenschutz wie jede andere Kopfzeilen-Information einer E-Mail.
Was bleibt festzuhalten
DMARC-Sammelberichte bleiben die verlässlichste Datenquelle, um nachzuvollziehen, wer im Namen einer Domain E-Mails versendet. DMARCbis verändert ihre Lesart nicht grundlegend, klärt aber, wie die Organisationsdomain bestimmt wird, und streicht ein mehrdeutiges Tag zugunsten eindeutigerer Einstellungen. Vor jedem Wechsel zu einer strengeren Richtlinie bleibt die einzig robuste Methode, die Berichte über mehrere Wochen hinweg quellenweise zu beobachten.
Ich habe mehr als einen Kunden erlebt, der allein auf Basis eines Tutorials zu p=reject gewechselt ist, ohne je einen einzigen Sammelbericht geöffnet zu haben, und dabei die Transaktionsmails eines seit Monaten vergessenen Dienstleisters verloren hat. RUA-Berichte sind weder kompliziert noch teuer in der Auswertung: Die Schwierigkeit liegt fast immer in der Organisation, nicht in der Technik — Simon Janvier.
Zum Weiterlesen: der vollständige Text der RFC 9990 beschreibt das komplette XML-Schema der DMARC-Sammelberichte.
