Bevor Sie Ihre DMARC-Richtlinie verschärfen, erfassen Sie die Systeme, die legitime E-Mails über Ihre Domain versenden. Berichte können einen Absender aufdecken, dessen Authentifizierung angepasst werden muss, bevor eine Durchsetzung seine E-Mails blockieren würde.
Welchen Bericht sollten Sie verwenden?
Verwenden Sie aggregierte Berichte, um Sendequellen und Authentifizierungsergebnisse über einen Berichtszeitraum zu vergleichen. Die rua-Adresse in Ihrem DMARC-Record fordert diese XML-Zusammenfassungen von teilnehmenden Empfängern an.
Die ruf-Adresse fordert individuelle Fehlerberichte an, manchmal auch forensische Berichte genannt. Sie verwenden ein Authentifizierungsfehler-Berichtsformat und können Header oder Nachrichteninhalte enthalten. Empfänger können sie schwärzen oder weglassen, da diese Inhalte personenbezogene Daten offenlegen können. Die Berichtsregeln von RFC 7489 beschreiben die beiden Berichtstypen.
Aggregierte Berichte decken den Datenverkehr ab, den jeder berichtende Empfänger beobachtet hat. Ein fehlender Bericht ist kein Beweis dafür, dass keine Nachrichten Ihre Domain verwendet haben. Die Erklärung zum DMARC-Record beschreibt, wo Sie die Berichtsadressen festlegen.
Was enthält ein aggregierter Bericht?
Ein aggregierter Bericht identifiziert die berichtende Organisation, den Berichtszeitraum und die veröffentlichte Richtlinie, gefolgt von Datensätzen, die Nachrichten mit gemeinsamen Merkmalen gruppieren. Eine Quell-IP kann in mehreren Datensätzen erscheinen, wenn sich deren Authentifizierungsergebnisse oder andere Gruppierungsfelder unterscheiden.
Dieser beispielhafte Auszug enthält die Felder, die zum Vergleich einer Quelle mit ihren Authentifizierungsergebnissen benötigt werden:
<report_metadata>
<org_name>google.com</org_name>
<date_range><begin>1718323200</begin><end>1718409600</end></date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>none</p>
</policy_published>
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>42</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><result>pass</result></dkim>
<spf><domain>example.com</domain><result>pass</result></spf>
</auth_results>
</record>Dieser Datensatz repräsentiert 42 Nachrichten von 203.0.113.10 mit example.com in der sichtbaren Absenderadresse. Beide Authentifizierungsmethoden haben bestanden und waren abgestimmt. Der Empfänger hat keine DMARC-Durchsetzung auf diese Nachrichten angewandt; das sagt nichts über deren Platzierung im Posteingang aus.
Welche Felder zeigen ein Authentifizierungsproblem an?
Vergleichen Sie policy_evaluated mit auth_results, um einen Authentifizierungsfehler von einem Domain-Alignment-Fehler zu unterscheiden.
| Feld | Worauf Sie achten sollten |
|---|---|
source_ip | Identifizieren Sie den sendenden Server und den dafür verantwortlichen Dienst. |
count | Zählen Sie die Nachrichten, die dieser Datensatz repräsentiert, nicht den gesamten Bericht. |
header_from | Bestätigen Sie die Domain, die dem Empfänger angezeigt wird. |
disposition | Prüfen Sie, ob der Empfänger none, quarantine oder reject angewandt hat. |
dkim und spf in policy_evaluated | Prüfen Sie, ob jede Methode für DMARC bestanden hat und abgestimmt war. |
auth_results | Vergleichen Sie die rohen Authentifizierungsergebnisse und die authentifizierten Domains. |
Zum Beispiel kann SPF unter auth_results bestehen, aber unter policy_evaluated fehlschlagen, wenn die authentifizierte Domain nicht mit der Absenderdomain übereinstimmt. Ein abgestimmtes Bestehen von DKIM kann diese Nachricht trotzdem DMARC bestehen lassen. Wie DMARC funktioniert erklärt diesen Zusammenhang.
Was sollten Sie mit jeder Sendequelle tun?
Ordnen Sie jede Quelle einem von Ihnen autorisierten Dienst zu, bevor Sie die Richtlinie ändern. Authentifizierungsergebnisse allein sagen nicht aus, ob Ihre Organisation diesen Dienst zum Versand vorgesehen hat.
- Bestätigen Sie bei einem bekannten Absender, der besteht und abgestimmt ist, dass das gemeldete Volumen dem erwarteten Datenverkehr entspricht.
- Korrigieren Sie bei einem bekannten Absender, der fehlschlägt, dessen Authentifizierung oder Alignment und prüfen Sie spätere Berichte auf das Ergebnis.
- Ermitteln Sie bei einem unbekannten Absender, der besteht, wer ihn konfiguriert hat und ob er die Autorisierung behalten sollte.
- Untersuchen Sie bei einem unbekannten Absender, der fehlschlägt, ob es sich um einen falsch konfigurierten legitimen Dienst oder eine unautorisierte Nutzung Ihrer Domain handelt.
Beheben Sie legitime Fehler, bevor Sie von der Überwachung zur Quarantäne oder Ablehnung wechseln, da diese Nachrichten andernfalls Kandidaten für die Durchsetzung wären. DMARC-Fehler beheben behandelt häufige Ursachen.
Wie prüfen Sie Berichte für eine Bird-Sendedomain?
Sie können aggregierte Berichte über die rua-Adresse in Ihrem DMARC-Record an Ihr eigenes Postfach weiterleiten. Verwenden Sie den DMARC-Berichtsanalysator, um das XML zu prüfen, oder öffnen Sie einen Bericht in einem Texteditor.
Die DNS-Verifizierung von Bird prüft Ihre veröffentlichte Richtlinie; Empfängerberichte beschreiben Authentifizierungsergebnisse für Nachrichten. Das sind separate Prüfungen. Der Authentifizierungsleitfaden behandelt die Richtlinie und die zu veröffentlichenden DNS-Records.