Wichtige Erkenntnisse
Innerhalb von 24–72 Stunden nach Veröffentlichung eines DMARC-Eintrags trifft der erste zusammenfassende Bericht ein und zeigt sofort alle legitimen und unautorisierten Server an, die in diesem Zeitraum E-Mails in Ihrem Namen versendet haben. Der Haken dabei ist, wie in [Referenz einfügen] dokumentiert. DMARC.orgLaut Protokollspezifikation handelt es sich bei diesen Berichten um maschinenformatierte XML-Dateien, die für automatisierte Parser und nicht für menschliche Leser bestimmt sind.
Wer DMARC-Berichte richtig lesen kann, wandelt diese Rohdaten in operative Erkenntnisse um. Die gewonnenen Informationen sind wirklich wertvoll, aber erst, nachdem das XML in ein handlungsrelevantes Format dekodiert wurde. Aktuell E-Mail-Spam-Statistiken Zeigen Sie, warum diese Transparenz wichtig ist: Spoofing und Identitätsdiebstahl sind weit verbreitet, daher benötigen Sie DMARC-Berichte, um festzustellen, welche Absender E-Mails in Ihrem Namen versenden.
Der erste Lesevorgang dauert 15–30 Minuten. Nachfolgende Lesevorgänge von denselben Absendern dauern 2–3 Minuten, sobald das Muster bekannt ist. Die folgenden Schritte beschreiben einen vollständigen DMARC-Aggregatbericht von Anfang bis Ende.
Hier ist ein anonymisierter XML-Ausschnitt, der die in den folgenden Überprüfungsschritten verwendete Berichtsstruktur veranschaulicht:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>[email protected]</email>
<report_id>10296513920663916120</report_id>
<date_range>
<begin>1716768000</begin>
<end>1716854400</end>
</date_range>
</report_metadata>
<policy_published>
<domain>yourdomain.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>209.85.220.41</source_ip>
<count>847</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<auth_results>
<dkim>
<domain>yourdomain.com</domain>
<result>pass</result>
</dkim>
<spf>
<domain>yourdomain.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>198.51.100.23</source_ip>
<count>312</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<auth_results>
<dkim>
<domain>unknownsender.net</domain>
<result>fail</result>
</dkim>
<spf>
<domain>unknownsender.net</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
</feedback>Stellen Sie sicher, dass ein dedizierter Posteingang Berichte an die in Ihrem DMARC-Eintrag unter dem Tag rua= angegebene Adresse sammelt (zum Beispiel, [E-Mail geschützt] Da E-Mail-Anbieter täglich aggregierte Berichte versenden, sammeln sich selbst bei einer Domain mit geringem Datenverkehr Dutzende von XML-Dateien pro Monat an; dadurch wird ein gemeinsam genutzter Posteingang schnell unüberschaubar.
Für kleine Domains mit gelegentlichem Prüfbedarf ist ein dediziertes Postfach ausreichend. Bei mehr als wenigen Berichten pro Woche oder für Organisationen, die mehrere Domains verwalten, sollte das rua=-Tag auf die Eingangsadresse eines DMARC-Analyzers für die automatisierte Analyse verweisen.
Laden Sie die der Berichts-E-Mail beigefügte Datei herunter. Die meisten Berichte werden als .xml.gz- oder .zip-Archive geliefert, die zuerst entpackt werden müssen (unter macOS und Linux per Doppelklick oder mit gunzip; unter Windows per Rechtsklick und „Extrahieren“).
Öffnen Sie die erstellte .xml-Datei in einem beliebigen Texteditor, z. B. VS Code, Sublime Text oder Notepad++. Alternativ können Sie sie auch in einem Browser öffnen, was das Lesen von XML-Dateien oft erleichtert, da die Abschnitte als ausklappbare Knoten anstatt als ein langer Textblock angezeigt werden.
Wenn Sie nur gelegentlich einen Bericht prüfen, reicht es aus, die XML-Datei manuell zu öffnen. Erhalten Sie jedoch mehr als einige Berichte pro Woche, empfiehlt sich die Verwendung eines automatisierten Parsers. DMARC-Berichte folgen einer einheitlichen Struktur, sodass Tools die XML-Datei deutlich schneller in Tabellen und Zusammenfassungen umwandeln können.
Suchen Sie die Der Block am Anfang der Datei gibt die meldende Organisation (Google, Microsoft, Yahoo, Mail.ru oder andere) sowie die Unix-Zeitstempel für Beginn und Ende des Berichtszeitraums an. Durch die Umwandlung dieser Zeitstempel in lesbare Datumsangaben lässt sich der 24-Stunden-Zeitraum des Berichts ermitteln.
Suchen Sie die Der Block wird unmittelbar danach angezeigt. Er zeigt die während des Berichtszeitraums aktive DMARC-Richtlinie (p=none, p=quarantine oder p=reject) sowie die Ausrichtungsmodi für SPF (aspf) und DKIM (adkim) an. Der Wert „r“ bedeutet lockere Ausrichtung, „s“ bedeutet strikte Ausrichtung.
Bitte prüfen Sie, ob die im Bericht angezeigte Richtlinie mit den aktuellen Daten Ihres DNS-Eintrags übereinstimmt. Eine Abweichung bedeutet, dass der Bericht einen Zeitraum vor der kürzlich erfolgten Richtlinienänderung abdeckt. Dies ist zu erwarten und kein Problem, sondern dient lediglich der Kontextualisierung der Ergebnisse.
Scrollen Sie zu Blöcke. Jeder Eintrag repräsentiert eine sendende IP-Adresse und deren Ergebnisse, gruppiert nach Nachrichtenanzahl. Im obigen Ausschnitt hat 209.85.220.41 847 Nachrichten gesendet und den DMARC-Test bestanden; 198.51.100.23 hat 312 Nachrichten gesendet und sowohl SPF als auch DKIM nicht bestanden.
Erfassen Sie für jeden Datensatz die Und Die IP-Adresse identifiziert den Server, der behauptet hat, Nachrichten im Namen Ihrer Domain zu senden, während die Anzahl angibt, wie viele Nachrichten während des Berichtszeitraums von diesem Server eingegangen sind.
Führen Sie für jede unbekannte Quell-IP eine Reverse-DNS-Abfrage durch. Legitime Absenderadressen werden zu bekannten Hostnamen aufgelöst (z. B. mail-sor-f41.google.com für Gmail, sendgrid.net für SendGrid und amazonses.com für AWS SES). Unbekannte IP-Adressen sollten überprüft werden, bevor man von ihrer Legitimität ausgeht.
Finde in jedem Datensatz die Der Block enthält das SPF-Ergebnis und das DKIM-Ergebnis für die jeweilige Quell-IP-Adresse sowie die Domain, zu der die einzelnen Authentifizierungsmethoden ausgewertet wurden.
Für die Gültigkeit der DMARC-Prüfung der gesamten Nachricht genügt es, dass entweder SPF oder DKIM im ausgerichteten Modus erfolgreich ist. Das Feld zeigt das endgültige Urteil (keine, Quarantäne oder Ablehnung) basierend auf der während des Berichtszeitraums aktiven Richtlinie an.
Kennzeichnen Sie alle Einträge, bei denen sowohl SPF als auch DKIM fehlschlagen, sofern der Absender als legitim gilt. Es handelt sich um einen falsch konfigurierten Absender, der korrigiert werden muss, bevor die Richtlinie sicher verschärft werden kann. Ein Eintrag mit spf=fail, aber dkim=pass ist in der Regel unproblematisch, da die Nachricht insgesamt die DMARC-Prüfung besteht.
DMARC-Aggregatberichte entsprechen RFC 7489. Alle konformen Berichte verwenden dieselbe Struktur, unabhängig vom E-Mail-Anbieter. Verwenden Sie diese Feldreferenz bei jeder Berichtsprüfung:
Sobald Sie diese vier Muster kennen, lassen sich DMARC-Berichte deutlich leichter lesen. Anstatt eine unübersichtliche XML-Datei zu durchsuchen, können Sie jeden Datensatz einer klaren Kategorie zuordnen.
Wenn ein bekannter Absender, wie beispielsweise Ihr ESP, Ihre Marketingplattform, Ihr Helpdesk oder Ihr CRM, im Bericht mit sowohl dkim=pass als auch spf=pass erscheint, bedeutet dies, dass die Einrichtung für diese Quelle korrekt funktioniert.
Überprüfen Sie per Reverse-DNS, ob die Quell-IP-Adresse zum erwarteten Provider gehört, insbesondere bei einer hohen Anzahl von Einträgen. Ein hohes E-Mail-Aufkommen von einer bekannten IP-Adresse mit dmarc=pass ist zu erwarten. Bestätigen Sie dies einmalig und verwenden Sie es anschließend als Grundlage für zukünftige Berichte.
Unbekannte IPs, die Hunderte oder Tausende von Nachrichten mit dmarc=fail senden, lassen sich in zwei Kategorien einteilen: Entweder handelt es sich um nicht autorisierte Absender, die aktiv Ihre Domain fälschen, oder um einen vergessenen legitimen Absender (ein altes Marketing-Tool, eine Schatten-IT-Integration), der nie ordnungsgemäß authentifiziert wurde.
Untersuchen Sie die Absenderadressen anhand der WHOIS- und Reverse-DNS-Einträge. Eine bekannte Spam-IP-Adresse deutet in der Regel auf Spoofing hin, während eine vergessene SaaS-Plattform meist auf ein Authentifizierungsproblem hinweist. In diesen beiden Fällen sind unterschiedliche Maßnahmen erforderlich: Gefälschte E-Mails sollten blockiert oder zurückgewiesen werden, während die SPF- oder DKIM-Konfiguration für legitime Absender korrigiert werden sollte.
Eine Nachricht, die den SPF-Test nicht besteht, aber den DKIM-Test, deutet oft auf eine E-Mail-Weiterleitung hin. Der weiterleitende Server ist nicht im SPF-Eintrag des ursprünglichen Absenders aufgeführt, daher schlägt der SPF-Test fehl. DKIM funktioniert anders. Es signiert die Nachrichtenkopfzeilen, und diese Signatur bleibt beim Weiterleiten der E-Mail oft erhalten. Deshalb kann DKIM auch dann noch erfolgreich sein, wenn der SPF-Test fehlschlägt.
DMARC funktioniert grundsätzlich, wenn entweder SPF oder DKIM übereinstimmen; diese Einträge stellen also kein Problem dar. Für Domains mit Empfängern, die E-Mail-Weiterleitung nutzen, ist dies das erwartete Verhalten. Der Bericht zeigt, wie sich die Weiterleitung auf die Authentifizierung auswirkt, nicht etwa einen Fehler in der DMARC-Konfiguration.
Eine zuvor unbekannte IP-Adresse, die plötzlich ein hohes Nachrichtenaufkommen versendet, obwohl sowohl SPF als auch DKIM fehlschlagen, ist ein klassisches Beispiel für Spoofing. Jemand versendet E-Mails, die vorgeben, von Ihrer Domain zu stammen, über seine eigene Infrastruktur und versucht so, Spamfilter zu umgehen, indem er die Vertrauenssignale Ihrer Domain missbraucht.
Überprüfen Sie die IP-Adresse in Threat-Intelligence-Tools wie AbuseIPDB oder Cisco Talos. Wenn die IP-Adresse mit Spam oder Missbrauch in Verbindung gebracht wird, ist der Anstieg wahrscheinlich bösartig. In diesem Fall ist es wichtig, die Einstellung „p=reject“ zu aktivieren. Sobald alle legitimen Absender korrekt konfiguriert sind, hilft die vollständige Durchsetzung, gefälschte E-Mails zu blockieren, bevor sie Schaden anrichten können. Reputation des E-Mail-Absenders.
Die meisten Teams stellen innerhalb der ersten Woche nach Erhalt der Berichte von der manuellen XML-Prüfung auf einen automatisierten Parser um. Die Wahl hängt vom Berichtsvolumen, dem Budget und dem erforderlichen Detaillierungsgrad der Analyse ab.
Für die meisten Teams am Anfang ist die Kombination aus MXToolbox für gelegentliche manuelle Prüfungen und Postmark DMARC Digests für die passive Überwachung eine praktische und kostenlose Lösung. Wechseln Sie zu einem spezialisierten Analysetool wie DMARCian, wenn die Anzahl der Domains oder das tägliche Berichtsvolumen eine manuelle Überprüfung unpraktikabel macht.
Das Lesen von DMARC-Berichten ist nur dann hilfreich, wenn man sie zur Entscheidungsfindung nutzt. Der Prozess ist einfach: Alle Absender identifizieren, Ausrichtungsprobleme beheben und dann die Durchsetzung einleiten.
Kombinieren Sie die Optimierung Ihrer E-Mail-Liste mit einer konsequenten Listenpflege. Die Authentifizierung bestätigt, dass die E-Mail von Ihnen stammt, während saubere Listen die Bounce-Rate reduzieren, die Ihrem Ruf unabhängig vom Authentifizierungsstatus schadet. Die Validierung von Listen vor größeren Versandmengen hält die Bounce-Rate niedrig. Bereinigen Ihrer E-Mail-Liste Die Vermeidung veralteter oder ungültiger Kontakte schützt die Reputationssignale, die jede Phase des politischen Fortschritts unterstützen.
DMARC-Aggregatberichte liefern operative Daten. Es geht nicht darum, sie theoretisch zu lesen, sondern auf Grundlage ihrer Erkenntnisse zu handeln. Korrigieren Sie legitime Absender, die die Synchronisierung nicht bestehen. Untersuchen Sie unbekannte IP-Adressen. Ergreifen Sie Maßnahmen zur Durchsetzung der DMARC-Richtlinien, sobald Ihre vertrauenswürdigen Quellen die Anforderungen zuverlässig erfüllen.
Ziel ist ein unauffälliger Bericht: bekannte Quellen, konstante Erfolgsquoten und keine plötzlichen Anstiege des Anfragevolumens durch unbekannte IPs. Diese Vorhersagbarkeit macht p=reject sicher und schützt Ihre Domain vor Identitätsdiebstahl.
Validieren Sie im Rahmen Ihrer Ausrichtungsphase Ihre Absenderlisten mit DeBounce. Validierung der E-Mail-Liste Entfernt ungültige, temporäre und risikoreiche Adressen aus den Listen Ihrer authentifizierten Versandströme. Dadurch bleiben die Bounce-Raten niedrig und Ihre durch Authentifizierung aufgebaute Reputation geschützt. Laden Sie Ihre Liste hoch, entfernen Sie unerwünschte Einträge und versenden Sie E-Mails mit der Gewissheit, dass saubere Authentifizierung und saubere Daten Hand in Hand gehen.
Aggregierte Berichte sind tägliche XML-Zusammenfassungen aller Authentifizierungsergebnisse innerhalb eines Berichtszeitraums; forensische Berichte hingegen sind Echtzeitwarnungen zu einzelnen fehlgeschlagenen Nachrichten. Forensische Berichte sind aufgrund von Datenschutzbedenken selten geworden: Die meisten Anbieter versenden sie nicht mehr, und die meisten Teams verlassen sich ausschließlich auf aggregierte Berichte.
Zusammenfassende Berichte werden in der Regel einmal täglich von den einzelnen berichtenden Organisationen versendet und decken den Zeitraum der letzten 24 Stunden ab. Große Anbieter wie Google und Microsoft versenden Berichte täglich; kleinere Anbieter versenden sie möglicherweise seltener oder gar nicht.
Entweder wurden im Berichtszeitraum keine E-Mails von der Domain versendet, oder die rua=-Adresse ist falsch konfiguriert, und die Berichte erreichen den Posteingang nicht. Überprüfen Sie, ob das rua=-Tag im DNS-Eintrag korrekt ist und ob das Postfach existiert und externe E-Mails empfängt.
Prüfen Sie in den ersten zwei Wochen stichprobenartig einige Tagesberichte, um das Absenderverhalten Ihrer spezifischen Absender zu erkennen. Anschließend sollten automatisierte Tools Auffälligkeiten erkennen. Lesen Sie die vollständigen Berichte nur dann, wenn im Übersichts-Dashboard etwas Ungewöhnliches auftaucht.
Mindestens 2–4 Wochen im Status „p=none“ (keine Angabe) zur Erfassung aller Absender, gefolgt von weiteren 2–4 Wochen zur Bestätigung der konsistenten Übereinstimmung, bevor auf „p=quarantäne“ (Quarantäne) umgeschaltet wird. Anschließend 2–4 Wochen im Status „p=quarantäne“, bevor auf „p=reject“ (Ablehnung) umgeschaltet wird. Die Richtlinien sollten nur dann verschärft werden, wenn die Berichte über mehrere aufeinanderfolgende Berichtszyklen hinweg konsistente Erfolgsquoten aufweisen.
Hier finden Sie schnelle Antworten auf Ihre Fragen zu unseren Preisen und Tarifen.
Spamfallen sind echte Postfächer, die erstellt oder wiederverwendet werden, um unseriöse E-Mail-Listenpraktiken aufzudecken. Das Öffnen einer solchen Falle kann die Reputation des Absenders und die Platzierung Ihrer E-Mails im Posteingang beeinträchtigen.
Das E-Mail-Versandlimit variiert je nach Anbieter und reicht von pro Minute über stündlich bis hin zu täglich. Die genauen Limits im jeweiligen Fall zu kennen, ist daher wichtig.
Eine Sperrliste ist eine Datenbank mit Adressen, an die keine E-Mails gesendet werden dürfen. Sie verhindert, dass E-Mails an bestimmte Adressen zugestellt werden. Eine Sperrliste spielt eine wichtige Rolle...
BEC-Angriffe sind allein durch Identitätsdiebstahl und Social Engineering erfolgreich und umgehen so die meisten technischen Sicherheitsvorkehrungen, die auf die Erkennung von Schadcode oder verdächtigen Links abzielen.
Dynamische E-Mail-Inhalte ersetzen statische, standardisierte Nachrichten durch personalisierte Inhaltsblöcke, die sich anhand von Daten, Verhalten oder Echtzeitsignalen an den jeweiligen Empfänger anpassen. Engagement...
Viele E-Commerce-Marketer investieren sehr gerne in E-Mail-Marketing. Sie erweitern ihre Verteilerlisten, versenden ansprechende E-Mail-Kampagnen, um Besucher zu binden oder, noch besser...
