DMARC Reports verstehen

Aggregate Reports (rua)

Aggregate Reports sind XML-Dateien, die von empfangenden Mailservern (Google, Microsoft, Yahoo usw.) an die im rua-Tag Ihres DMARC Records angegebenen Adressen gesendet werden. Sie enthalten:

• Die Identität der berichtenden Organisation
• Den abgedeckten Zeitraum (normalerweise 24 Stunden)
• Ihre veröffentlichte DMARC Policy
• Statistiken pro Source IP: Wie viele E-Mails gesendet wurden und ob sie SPF, DKIM und DMARC bestanden oder nicht bestanden haben

Reports werden typischerweise als gzip-komprimierte XML-Dateien (.xml.gz) oder ZIP-Archive (.zip) als E-Mail-Anhänge gesendet.

Forensic Reports (ruf)

Forensic Reports (auch „Failure Reports" genannt) liefern Details zu einzelnen E-Mails, die DMARC nicht bestanden haben. Sie enthalten Header und manchmal auch Nachrichteninhalt der fehlgeschlagenen E-Mails. Allerdings:

• Viele große Empfänger (Google, Microsoft) senden keine Forensic Reports aufgrund von Datenschutzbedenken
• Wenn sie gesendet werden, können sie geschwärzt oder eingeschränkt sein
• Sie sind am nützlichsten für das Debugging spezifischer Authentifizierungsfehler

Konzentrieren Sie sich auf Aggregate Reports — sie bieten die nötige Transparenz für 99 % der DMARC-Verwaltungsaufgaben.

Das Verständnis der XML-Struktur ist essenziell für die Interpretation Ihrer Reports. Hier ein vollständig kommentiertes Beispiel:

<feedback>
  <!-- WER hat diesen Report gesendet -->
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>16234567890123456789</report_id>
    <date_range>
      <begin>1709164800</begin>  <!-- Unix-Zeitstempel: 28.02.2024 00:00 UTC -->
      <end>1709251200</end>      <!-- Unix-Zeitstempel: 29.02.2024 00:00 UTC -->
    </date_range>
  </report_metadata>

  <!-- Ihre veröffentlichte DMARC Policy zum Zeitpunkt -->
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>    <!-- DKIM Alignment: relaxed -->
    <aspf>r</aspf>      <!-- SPF Alignment: relaxed -->
    <p>quarantine</p>   <!-- Policy: Fehlschlagende E-Mails in Quarantäne -->
    <sp>none</sp>       <!-- Subdomain Policy: Nur überwachen -->
    <pct>100</pct>      <!-- Auf 100% der fehlschlagenden E-Mails anwenden -->
  </policy_published>

  <!-- EINZELNE RECORDS — einer pro Source IP + Ergebnis-Kombination -->
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>  <!-- Die IP, die diese E-Mails gesendet hat -->
      <count>1542</count>                    <!-- Anzahl der E-Mails von dieser IP -->
      <policy_evaluated>
        <disposition>none</disposition>       <!-- Was der Empfänger GETAN hat -->
        <dkim>pass</dkim>                    <!-- DMARC DKIM-Auswertung -->
        <spf>pass</spf>                      <!-- DMARC SPF-Auswertung -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>  <!-- Die From:-Header-Domain -->
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>  <!-- Domain, die signiert hat -->
        <result>pass</result>
        <selector>google</selector>   <!-- Welcher DKIM Key verwendet wurde -->
      </dkim>
      <spf>
        <domain>example.com</domain>  <!-- Domain im Return-Path -->
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Das Feld <source_ip> in jedem Record zeigt, welcher Server E-Mails gesendet hat, die vorgaben, von Ihrer Domain zu stammen. Dies sind die handlungsrelevantesten Daten in DMARC Reports.

Wie man Source IPs analysiert

1. IP identifizieren: Verwenden Sie Reverse DNS (PTR), WHOIS oder IP-Geolokation, um den Eigentümer der IP zu ermitteln.
2. Absender kategorisieren:
   • Eigene Server: IPs aus dem Netzwerk Ihrer Organisation
   • Autorisierte Drittanbieter: Google, Microsoft, SendGrid, Mailchimp usw.
   • Weiterleitungsdienste: Mailinglisten, Weiterleitungsregeln, Security Gateways
   • Unbekannt/verdächtig: Möglicherweise gespoofte E-Mails — weiter untersuchen
3. Anzahl prüfen: Hohes Volumen von einer nicht autorisierten IP deutet auf aktiven Missbrauch hin.
4. Disposition prüfen: none bedeutet, die E-Mail wurde zugestellt; quarantine bedeutet Spam-Ordner; reject bedeutet blockiert.

Häufige Source IP-Bereiche

Reports enthalten zwei Ergebnis-Sets, die häufig verwechselt werden:

<policy_evaluated>

Dies ist das DMARC-Urteil. Es zeigt, ob DMARC bestanden oder fehlgeschlagen ist, unter Berücksichtigung des Alignment:

• dkim=pass bedeutet DKIM hat bestanden UND die DKIM-Domain war aligned mit der From:-Domain
• spf=pass bedeutet SPF hat bestanden UND die SPF-Domain war aligned mit der From:-Domain
• disposition zeigt, was der Empfänger tatsächlich mit der E-Mail gemacht hat

<auth_results>

Dies ist das rohe Authentifizierungsergebnis, unabhängig vom Alignment:

• SPF-Ergebnis für die tatsächliche Return-Path-Domain (kann sich von der From:-Domain unterscheiden)
• DKIM-Ergebnis für jede gefundene Signatur (kann Drittanbieter-Signaturen enthalten)
• Die Felder domain und selector zeigen genau, welcher Key verwendet wurde

Beispiel: SPF bestanden, aber DMARC fehlgeschlagen

<!-- E-Mail: From: ceo@example.com, Return-Path: bounce@sendgrid.net -->
<policy_evaluated>
  <dkim>fail</dkim>  <!-- Keine aligned DKIM-Signatur -->
  <spf>fail</spf>   <!-- SPF-Domain (sendgrid.net) ≠ From-Domain (example.com) -->
</policy_evaluated>
<auth_results>
  <spf>
    <domain>sendgrid.net</domain>  <!-- SPF bestanden für sendgrid.net... -->
    <result>pass</result>           <!-- ...aber nicht aligned mit example.com -->
  </spf>
</auth_results>

Lösung: Konfigurieren Sie SendGrid für einen benutzerdefinierten Return-Path wie bounce.example.com und richten Sie DKIM-Signierung mit d=example.com ein.