So lesen Sie DMARC-Berichte, bevor Sie durchsetzen

Sobald Sie einen DMARC-Record mit einer rua=-Adresse veröffentlichen, beginnen Mailbox-Provider, Ihnen täglich Berichte über jeden Server zu senden, der Ihre Domain verwendet — und zu lernen, wie man DMARC-Berichte liest, ist der Unterschied zwischen einem sicheren Übergang zur Durchsetzung und dem versehentlichen Versenden Ihrer eigenen Rechnungen in den Spam-Ordner. Der Haken ist, dass diese Berichte als dichtes XML eintreffen, das kein Mensch überfliegen sollte. Dieser Leitfaden erklärt genau, was ein Aggregatbericht enthält, wie Sie ihn interpretieren, um legitime E-Mails zu finden, die scheitern, und wo sich ein Berichtsanalyzer bezahlt macht.

Die kurze Antwort#

DMARC-Aggregatberichte (jene, die durch das rua=-Tag ausgelöst werden) sind XML-Dateien, die ein Empfänger Ihnen etwa einmal täglich sendet. Jeder gruppiert die E-Mails, die er im Namen Ihrer Domain gesehen hat, nach sendender IP und teilt Ihnen für jede Quelle mit: wie viele Nachrichten, ob SPF und DKIM bestanden haben und ausgerichtet waren, und was der Empfänger damit gemacht hat. Sie lesen sie, um ein vollständiges Verzeichnis darüber aufzubauen, wer in Ihrem Namen sendet, und um zu bestätigen, dass jeder legitime Strom im Alignment authentifiziert, bevor Sie Ihre Richtlinie von p=none auf quarantine und reject verschärfen. Rohes XML ist mühsam, daher lädt fast jeder es in einen DMARC-Berichtsanalyzer, der es in eine lesbare Tabelle verwandelt.

Haben Sie bereits einen Bericht zur Hand? Fügen Sie ihn in den kostenlosen DMARC-Berichtsanalyzer ein oder laden Sie ihn hoch, um diesem Leitfaden mit Ihren eigenen Daten zu folgen — er verarbeitet alles in Ihrem Browser, es wird nichts hochgeladen.

Was einen Aggregatbericht auslöst#

Der Auslöser ist ein einziges Tag in Ihrem DMARC-Record. Wenn Sie rua= unter _dmarc.yourdomain.com veröffentlichen, bitten Sie jeden teilnehmenden Empfänger, Ihnen aggregiertes Feedback zuzumailen:

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

Von da an bündeln große Empfänger — Google, Yahoo, Microsoft, Comcast und viele andere — alles, was sie über ein 24-Stunden-Fenster von Ihrer Domain gesehen haben, und senden einen einzigen XML-Bericht pro Domain. Der Bericht trifft üblicherweise als komprimierter Anhang (.xml.gz oder .zip) ein, mit einem Dateinamen, der den Berichterstatter, Ihre Domain und den Datumsbereich kodiert. Sie können rua auf mehrere Adressen richten und sogar Berichte für eine Domain sammeln, die Sie nicht kontrollieren, indem Sie ein externes Ziel verwenden, wobei dies einen zusätzlichen Autorisierungs-Record bei der empfangenden Domain erfordert. Wenn Sie noch keinen Record veröffentlicht haben, beginnen Sie mit der geordneten DMARC-Einrichtungsanleitung — das Reporting beginnt erst, sobald der Record live ist.

So lesen Sie einen DMARC-Aggregatbericht, Zeile für Zeile#

Jeder Aggregatbericht folgt demselben XML-Schema, definiert in RFC 7489. Er besteht aus drei Teilen: wer den Bericht gesendet hat, welche Richtlinie Sie damals veröffentlicht hatten, und dann einem oder mehreren <record>-Blöcken — einer pro sendender Quelle. Hier ein gekürztes Beispiel eines einzelnen Records:

<record>
  <row>
    <source_ip>203.0.113.42</source_ip>
    <count>128</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>example.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Das mit Abstand Wichtigste, das Sie verstehen müssen, ist, dass ein Bericht Ihnen das Authentifizierungsergebnis an zwei verschiedenen Stellen liefert, und diese bedeuten Unterschiedliches:

Der auth_results-Block gibt an, ob SPF und DKIM überhaupt bestanden haben. Der policy_evaluated-Block gibt an, ob sie im Alignment bestanden haben, und das ist das Einzige, was DMARC interessiert. Diese beiden können sich widersprechen, und in dieser Lücke findet der Großteil Ihrer Ermittlungsarbeit statt.

Eine legitime Quelle erkennen, die scheitert#

Hier ist das Muster, nach dem Sie jagen, und warum es wichtig ist. Stellen Sie sich einen Record vor, bei dem die source_ip eindeutig zu einer Marketing-Plattform gehört, die Sie nutzen, header_from Ihre Domain ist und auth_results spf: pass zeigt — aber die aufgeführte SPF-Domain ist die eigene Bounce-Domain der Plattform, nicht Ihre, und policy_evaluated/spf liest sich als fail. Diese Nachricht authentifizierte für jemanden, nur nicht für Sie auf eine Weise, die ausgerichtet ist. Unter p=none ist die disposition weiterhin none, es ging also nichts kaputt — noch nicht. In dem Moment, in dem Sie auf quarantine oder reject wechseln, beginnt jede Nachricht in diesem count im Spam zu landen oder abgewiesen zu werden.

Der Lesevorgang ist also immer derselbe Drei-Schritte-Vergleich:

• Identifizieren Sie die Quelle. Ordnen Sie jede source_ip einem echten Dienst zu. Ein schnelles Reverse-DNS oder die integrierte Beschriftung des Analyzers benennt sie meist. Ihr Ziel ist eine vollständige Liste — die Berichte fördern routinemäßig ein vergessenes Rechnungstool oder eine alte Kampagnenplattform zutage, die noch in Ihrem Namen sendet.
• Prüfen Sie das Alignment, nicht nur die Authentifizierung. Schauen Sie auf policy_evaluated, nicht auf auth_results. Eine Quelle kann SPF oder DKIM bestehen und dennoch an DMARC scheitern, weil die Domain, für die sie authentifizierte, nicht mit Ihrer „Von"-Domain übereinstimmt.
• Entscheiden Sie: beheben oder scheitern lassen. Ist die Quelle legitim, beheben Sie ihr Alignment — fügen Sie sie zu SPF hinzu oder, besser, richten Sie die DKIM-Signierung auf Ihrer Domain ein, sodass die signierende Domain übereinstimmt. Ist es ein Spoofer, ist das Scheitern genau das, was Sie wollen, und es ist der Beleg dafür, dass Ihr künftiges p=reject seine Aufgabe erfüllt.

DKIM-Alignment sollte in der Regel gegenüber SPF priorisiert werden, denn eine DKIM-Signatur reist mit der Nachricht mit und übersteht Weiterleitungen, während SPF-Alignment in dem Moment bricht, in dem die E-Mail weitergeleitet wird. Die Mechanik des Alignments — relaxed versus strict, organisatorische Domain versus exakte Übereinstimmung — wird im Erklärstück zu SPF, DKIM und DMARC behandelt, falls Sie beim Konzept einen Gang zurückschalten möchten.

RUA versus RUF: zwei sehr unterschiedliche Berichte#

DMARC definiert zwei Reporting-Tags, und sie sind nicht austauschbar:

• rua — Aggregatberichte. Die oben beschriebenen täglichen XML-Zusammenfassungen. Sie enthalten Zählungen und Ergebnisse, nach Quelle gruppiert, keinen Nachrichteninhalt, und sie sind das, worauf Sie sich beim gesamten Rollout verlassen. Jeder ernstzunehmende Empfänger sendet sie.
• ruf — forensische (Fehler-)Berichte. Berichte pro Nachricht, die in dem Moment erzeugt werden, in dem eine einzelne Nachricht scheitert. Historisch konnten sie Header und manchmal Teile der Nachricht enthalten, was bedeutet, dass sie personenbezogene Daten tragen können.

Da forensische Berichte Empfängerinformationen preisgeben können, stellten die meisten großen Provider ihren Versand vor Jahren aus Datenschutzgründen ein, und viele Absender veröffentlichen ruf überhaupt nie. Ein Record, der beide anfordert, sieht so aus:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:agg@example.com; ruf=mailto:forensic@example.com"

In der Praxis erhalten Sie einen stetigen Strom von rua-Aggregatberichten und wenige oder keine ruf-forensischen. Planen Sie Ihr Monitoring rund um Aggregatdaten; behandeln Sie etwaige forensische Berichte, die Sie doch erhalten, als gelegentlichen Bonus und aktivieren Sie ruf nur, wenn Sie eine Rechtsgrundlage und einen Ort haben, um zu speichern, was personenbezogene Daten sein könnten.

Warum Sie einen Analyzer wollen, keinen rohen Posteingang#

Sie können das XML von Hand öffnen, und bei einer einzelnen Domain mit zwei oder drei Absendern ist das eine Weile machbar. Es hört schnell auf zu skalieren. Eine stark genutzte Domain erzeugt Dutzende Berichte pro Tag von verschiedenen Empfängern, jeder mit vielen Quell-IPs, und das interessante Signal — ein legitimer Absender, der still am Alignment scheitert — ist in Unix-Zeitstempel-Tags und unbeschrifteten IP-Adressen vergraben.

Ein DMARC-Berichtsanalyzer oder Monitoring-Dashboard nimmt die Berichte an einer dedizierten Adresse entgegen, dekomprimiert und parst das XML, löst IPs zu erkennbaren Dienstnamen auf und fasst alles zu einer Tabelle zusammen, die Sie tatsächlich lesen können: Quellen auf der einen Seite, Pass- und Fail-Volumen auf der anderen, Trends über die Zeit. Die guten heben neue oder neu scheiternde Quellen hervor, sodass Sie eine Veränderung bemerken, ohne jede Datei erneut zu lesen. Ob Sie einen gehosteten Dienst oder einen selbst gehosteten Parser nutzen, die Aufgabe ist dieselbe — einen Haufen XML in „hier ist, wer in Ihrem Namen sendet, und hier ist, wer noch nicht ausgerichtet ist" zu verwandeln. Diese Klarheit macht die Berichte umsetzbar statt bloß archiviert.

Wie das zum sicheren Rollout passt#

Berichte zu lesen ist keine vom Konfigurieren von DMARC getrennte Pflicht — es ist die Mitte des Rollouts, und es zu überspringen ist der Weg, auf dem Menschen ihre eigene Post begraben. Die Reihenfolge:

1. Veröffentlichen Sie p=none mit rua. An der Behandlung Ihrer E-Mails ändert sich nichts; das Reporting wird lediglich eingeschaltet.
2. Lesen Sie die Aggregatberichte über einen vollen Sendezyklus hinweg. Mindestens ein paar Wochen, länger, wenn Sie niederfrequente Ströme wie monatliche Abrechnungen haben. Bauen Sie das vollständige Verzeichnis der Quellen auf.
3. Beheben Sie jede legitime Quelle, die am Alignment scheitert. Hier fließt die eigentliche Zeit hin, und hierhin weisen Sie die Berichte.
4. Wechseln Sie zu quarantine, dann reject. Erst wenn die Berichte zeigen, dass jeder echte Strom im Alignment besteht. p=reject ist die Einstellung, die Spoofing tatsächlich stoppt und die Massenversender-Regeln der Absenderanforderungen von Google und Yahoo erfüllt.

Die Berichte machen sich auch nach Erreichen von reject weiterhin bezahlt — sie sind, wie Sie ein neu hinzugefügtes SaaS-Tool erwischen, das in Ihrem Namen zu senden beginnt, oder eine Spoofing-Kampagne, die gegen Ihre Marke hochfährt. Sie neben Ihren Feedback-Loop-Beschwerden und Ihrer allgemeinen Absenderreputation zu beobachten, gibt Ihnen ein Frühwarnsystem statt einer einmaligen Einrichtungsaufgabe.

Eine ehrliche Grenze: DMARC im Alignment zu bestehen beweist, wer Sie sind, nicht, dass Sie ein guter Absender sind. Eine perfekt ausgerichtete Domain, die tote Adressen oder Spam-Traps anschreibt, landet trotzdem im Spam — Authentifizierung ist die Eintrittskarte, und Listenqualität und Engagement entscheiden über die Platzierung. Dieses größere Bild ist Thema des Deliverability-Leitfadens, und es ist der häufigste Grund, warum legitime E-Mails trotzdem im Spam landen, selbst bei sauberen Berichten.

Häufig gestellte Fragen#

Was enthalten DMARC-Aggregatberichte eigentlich?#

Ein Aggregatbericht (rua) ist eine XML-Datei, die die E-Mails, die ein Empfänger von Ihrer Domain gesehen hat, nach sendender IP-Adresse gruppiert. Für jede Quelle listet er die Nachrichtenanzahl, die rohen SPF- und DKIM-Ergebnisse und gegen welche Domains diese liefen, das DMARC-ausgerichtete Urteil sowie die Behandlung auf, die der Empfänger gemäß Ihrer veröffentlichten Richtlinie angewendet hat. Er enthält niemals Betreffzeilen, Nachrichtentexte oder Empfängeradressen — nur aggregierte Zählungen und Authentifizierungsergebnisse, und genau das macht ihn datenschutzkonform.

Was ist der Unterschied zwischen RUA- und RUF-Berichten?#

rua fordert tägliche Aggregatberichte an: zusammengefasste Zählungen und Pass/Fail-Ergebnisse, nach Quelle gruppiert, ohne Nachrichteninhalt. ruf fordert forensische oder Fehlerberichte an, die pro fehlgeschlagener Nachricht erzeugt werden und historisch Header und Nachrichtendaten enthalten konnten. Da forensische Berichte personenbezogene Daten enthalten können, senden die meisten großen Empfänger sie nicht mehr, weshalb Sie Ihr Monitoring auf Aggregatberichte aufbauen und etwaige forensische Daten als gelegentliche Zugabe behandeln sollten.

Warum zeigt eine Quelle in meinem Bericht SPF pass, aber DMARC fail?#

Weil DMARC Alignment verlangt, nicht nur Authentifizierung. Eine Nachricht kann SPF für die eigene Domain des sendenden Dienstes bestehen, während Ihre Domain im sichtbaren „Von" steht — SPF besteht, aber die Domains passen nicht zusammen, also scheitert DMARC. Lesen Sie das policy_evaluated-Ergebnis statt der rohen auth_results: Ersteres spiegelt das Alignment wider. Zur Behebung müssen Sie die Quelle meist zu Ihrem SPF-Record hinzufügen oder, robuster, die DKIM-Signierung auf Ihrer eigenen Domain aktivieren, sodass die signierende Domain übereinstimmt.

Brauche ich einen DMARC-Analyzer, oder kann ich die Berichte selbst lesen?#

Bei einer Domain mit ein paar Absendern können Sie das rohe XML eine Weile selbst lesen. Es hört schnell auf, praktikabel zu sein, denn eine stark genutzte Domain erhält Dutzende Berichte pro Tag voller unbeschrifteter IPs und Zeitstempel. Ein Analyzer oder Monitoring-Dashboard dekomprimiert und parst die Berichte, benennt die Quellen und fasst die Daten zu einer lesbaren Tabelle mit Trends zusammen — und genau das macht aus den Berichten Entscheidungen statt eines ungelesenen Ordners.

Aggregatberichte sagen Ihnen, wer in Ihrem Namen sendet; sie sagen Ihnen nicht, ob die Liste hinter dieser Post sauber ist. Lassen Sie Ihre Adressen durch den kostenlosen E-Mail-Checker laufen, um tote Domains, Tippfehler und Spam-Traps zu entfernen, bevor sie bouncen — denn eine perfekt ausgerichtete Domain braucht trotzdem eine gesunde Liste, um den Posteingang zu verdienen.