DMARC-Berichte nach dem Standard-Update: Was Newsletter-Teams jetzt prüfen sollten

DMARC-Berichte wirken auf den ersten Blick wie technischer Ballast: komprimierte XML-Dateien, IP-Adressen, Prüfergebnisse und kryptische Kennungen. Für Newsletter-Teams sind sie jedoch eine der verlässlichsten Quellen, um zu erkennen, wer im Namen der eigenen Domain sendet und ob SPF sowie DKIM mit der sichtbaren Absenderdomain zusammenpassen.

Das Thema ist aktuell, weil im Mai 2026 zwei neue Standards veröffentlicht wurden. RFC 9989 beschreibt das DMARC-Grundprotokoll und ersetzt RFC 7489. RFC 9990 lagert die Aggregatberichte in eine eigene Spezifikation aus. Für Marketing-Verantwortliche bedeutet das nicht, dass über Nacht jeder DNS-Eintrag geändert werden muss. Es ist vielmehr ein guter Anlass, die vorhandenen Berichte endlich als laufendes Kontrollinstrument zu nutzen.

Was ein DMARC-Aggregatbericht tatsächlich zeigt

Empfangende Mailbox-Anbieter können regelmäßig einen Bericht an die im DMARC-Eintrag hinterlegte rua-Adresse senden. Ein solcher Bericht fasst Zustellversuche für einen Zeitraum zusammen. Typische Angaben sind die sendende IP-Adresse, die Anzahl beobachteter Nachrichten, die angewandte DMARC-Richtlinie sowie die Ergebnisse von SPF, DKIM und deren Alignment.

Alignment ist der entscheidende Punkt. Ein technischer SPF- oder DKIM-Erfolg allein genügt für DMARC nicht. Mindestens eines der beiden Verfahren muss erfolgreich sein und zur Domain im sichtbaren From-Feld passen. Deshalb kann ein Versanddienst technisch korrekt signieren und trotzdem bei DMARC scheitern, wenn er eine andere Domain verwendet oder die Konfiguration nicht sauber auf die Absenderdomain abgestimmt ist.

Die Berichte enthalten laut RFC 9990 keine einzelnen Empfängeradressen, keine IP-Adressen von Endnutzerinnen und Endnutzern und keinen Nachrichteninhalt. Dennoch sind sie sensible Betriebsdaten: Sie legen Versandquellen, Volumen und Authentifizierungsprobleme offen. Zugriffe, Aufbewahrung und Weitergabe sollten daher klar geregelt sein.

Was sich mit RFC 9989 und RFC 9990 geändert hat

Die wichtigste organisatorische Änderung ist die Trennung: Das Grundprotokoll und das Format der Aggregatberichte stehen nun in eigenen RFCs. RFC 9989 führt außerdem die DNS Tree Walk Discovery ein und ersetzt damit die frühere Abhängigkeit von der Public Suffix List. Neue Tags wie np, psd und t präzisieren den Umgang mit nicht vorhandenen Subdomains, Public-Suffix-Domains und Testbedingungen.

Gleichzeitig entfallen im neuen Grundstandard unter anderem die Tags pct, rf und ri. Das ist für die Praxis relevant, weil bestehende Anleitungen von Mailbox-Anbietern teilweise noch mit pct eine schrittweise Richtlinienverschärfung erklären. Solche Dokumentationen sind nicht automatisch falsch: Sie beschreiben den aktuellen Betrieb ihrer Systeme. Teams sollten daher weder alte Tags unkritisch fortschreiben noch sie allein wegen eines neuen RFCs sofort löschen. Entscheidend sind die tatsächlich unterstützten Verfahren der relevanten Empfänger und ein kontrollierter DNS-Änderungsprozess.

RFC 9990 präzisiert das XML-Format, den Transport, die Deduplizierung und die externe Autorisierung einer Berichtsadresse. Liegt die rua-Adresse außerhalb der überwachten Domain, muss die Zieldomain den Empfang per DNS autorisieren. Das verhindert, dass beliebige fremde Postfächer mit Berichten überflutet werden.

Fünf Fragen, die jeder Bericht beantworten sollte

1. Sind alle legitimen Versandquellen bekannt?

Beginnen Sie mit einer Positivliste: Mailaura, Transaktionsmail-Dienst, Shop, CRM, Support-System, Bewerbungsplattform und interne Mailserver. Vergleichen Sie diese Liste mit den im Bericht sichtbaren IP-Adressen und Authentifizierungsdomains. Eine unbekannte Quelle ist nicht automatisch ein Angriff. Häufig steckt ein vergessenes Formular, ein altes Tool oder ein Dienstleister dahinter. Sie ist aber immer ein Prüfauftrag.

2. Wo scheitert SPF oder DKIM?

Ein einzelner Fehler bei sehr geringem Volumen kann ein Test oder eine Weiterleitung sein. Wiederkehrende Fehler mit relevantem Volumen verdienen Priorität. Prüfen Sie dabei nicht nur das Ergebnis, sondern auch die verwendete Domain. Bei SPF können Weiterleitungen das Ergebnis verändern; eine korrekt ausgerichtete DKIM-Signatur wird deshalb oft zum robusteren DMARC-Pfad.

3. Stimmt das Alignment mit dem sichtbaren Absender?

Marketing-Teams sollten den im Newsletter sichtbaren Absender nicht isoliert betrachten. From-Domain, DKIM-Signaturdomain und SPF-Domain müssen als System geplant werden. Der Beitrag zur Prüfung von SPF, DKIM und DMARC vor dem Versand erklärt die technische Grundlage. Ergänzend hilft die saubere Wahl von From-Name, Absenderadresse und Reply-to, damit Technik und Markenauftritt zusammenpassen.

4. Welche Richtlinie wurde angewandt?

Ein Bericht kann zeigen, ob Nachrichten trotz DMARC-Fehler zugestellt, in Quarantäne verschoben oder abgewiesen wurden. Bei p=none steht Beobachtung im Vordergrund. p=quarantine und p=reject greifen stärker ein. Eine Verschärfung sollte erst erfolgen, wenn legitime Quellen erfasst, Fehler behoben und die Auswirkungen über mehrere Berichtszyklen stabil verstanden sind.

5. Ist der Trend besser oder nur das Volumen kleiner?

Absolute Fehlerzahlen täuschen, wenn das Versandvolumen schwankt. Vergleichen Sie deshalb Anteile: Wie viel Prozent des legitimen Volumens bestehen DMARC? Wie hoch ist der Anteil unbekannter Quellen? Welche Absender verursachen wiederholt Fehler? Ein gutes Dashboard trennt bekannte und unbekannte Quellen und zeigt Entwicklungen pro Domain, Provider und Authentifizierungspfad.

Ein praktikabler Wochenprozess für KMU

Für kleine Teams reicht ein fester, kurzer Kontrollrhythmus. Google empfiehlt in seiner Anleitung zur Überwachung mit DMARC-Berichten, die täglichen Berichte regelmäßig zu prüfen. Bei größeren Domains können so viele Dateien eintreffen, dass ein eigenes Postfach oder eine Auswertungssoftware sinnvoll wird.

1. Berichte vollständig sammeln: Verwenden Sie eine dedizierte Adresse und prüfen Sie, ob alle wichtigen Mailbox-Anbieter Berichte liefern.
2. Dubletten entfernen: Nutzen Sie Report-ID, Zeitraum und Dateiname, statt denselben Bericht mehrfach zu zählen.
3. Quellen klassifizieren: Markieren Sie bekannte Systeme, Dienstleister, Weiterleitungen und ungeklärte Sender getrennt.
4. Fehler priorisieren: Bearbeiten Sie zuerst legitime Quellen mit hohem Volumen und dauerhaft fehlendem Alignment.
5. Änderungen dokumentieren: Halten Sie DNS-Anpassung, verantwortliches System, Testdatum und erwartete Wirkung fest.
6. Nachkontrolle einplanen: Bewerten Sie die nächsten vollständigen Berichtszyklen, bevor Sie die Richtlinie weiter verschärfen.

Bei Mailaura lässt sich im Domain-Setup eine Adresse für DMARC-Aggregatberichte hinterlegen. Für den eigentlichen Newsletter-Versand bietet die Seite Newsletter erstellen den passenden Einstieg. Die Auswertung sollte zusätzlich alle anderen Systeme berücksichtigen, die mit derselben Unternehmensdomain senden.

Typische Fehlinterpretationen vermeiden

Ein DMARC-Erfolg ist kein Gütesiegel für Inhalt oder Zustellung im Posteingang. Er bestätigt die autorisierte Nutzung einer Domain, verhindert aber weder Spam-Beschwerden noch schlechte Listenqualität. Wenn Beschwerden steigen, hilft die Analyse im Beitrag Newsletter-Spam-Beschwerden richtig einordnen.

Umgekehrt ist nicht jede fremde IP ein Betrugsversuch. Weiterleitungen, Mailinglisten und Infrastruktur von Dienstleistern können plausible Abweichungen erzeugen. Entscheidend ist die Kombination aus Quelle, Volumen, wiederkehrendem Muster, verwendeter Domain und internem Systemwissen.

Auch das Verarbeiten der XML-Dateien verdient Aufmerksamkeit. Komprimierte Berichte und XML-Parser können durch übergroße oder manipulierte Dateien belastet werden. RFC 9990 weist ausdrücklich auf Risiken wie Archiv- und XML-Bomben sowie gefälschte Berichte hin. Automatisierte Auswertungen sollten daher Größenlimits, sichere Parser, Deduplizierung und eine Prüfung der Absenderauthentifizierung vorsehen.

Checkliste vor der nächsten DMARC-Entscheidung

• Alle legitimen Versanddienste und verantwortlichen Teams sind erfasst.
• Die rua-Adresse empfängt Berichte zuverlässig und ist bei externer Domain autorisiert.
• SPF-, DKIM- und Alignment-Ergebnisse werden getrennt ausgewertet.
• Bekannte und unbekannte Quellen sind nachvollziehbar klassifiziert.
• Fehlerquoten werden relativ zum Versandvolumen beobachtet.
• DNS-Änderungen erfolgen dokumentiert und mit ausreichender Nachbeobachtung.
• Alte und neue Standardangaben werden gegen die reale Provider-Unterstützung geprüft.
• Berichtsdateien werden sicher verarbeitet und nur angemessen lange aufbewahrt.

Fazit: Aus XML wird eine operative Entscheidungshilfe

Die neuen RFCs machen DMARC nicht zu einem einmaligen Technikprojekt. Sie unterstreichen vielmehr, dass Richtlinie und Reporting zwei zusammengehörige Betriebsaufgaben sind. Wer Aggregatberichte regelmäßig auswertet, erkennt vergessene Versandquellen, fehlerhaftes Alignment und verdächtige Nutzung früher.

Für Newsletter-Teams ist der pragmatische Weg klar: zuerst Transparenz schaffen, dann legitime Fehler beheben und erst danach eine strengere Richtlinie erwägen. So wird aus einer Sammlung schwer lesbarer XML-Dateien ein belastbarer Prozess für Absenderschutz und Zustellbarkeit.

Quellen

• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC), Mai 2026.
• RFC 9990: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting, Mai 2026.
• Google Workspace: DMARC-Berichte überwachen und auswerten.