E-Mail-Sicherheit · DMARC-Auswertung
DMARC-Aggregatberichte zeigen, welche Systeme E-Mails mit Ihrer sichtbaren Absenderdomain versenden und ob deren SPF- oder DKIM-Identität dazu passt. Eine IP-Adresse mit „SPF pass“ ist dabei noch kein Beleg für einen korrekt autorisierten Unternehmensversand. Erst die Verbindung aus Quelle, Nachrichtenanzahl, sichtbarer Absenderdomain, authentifizierten Domains und DMARC-Ausrichtung ermöglicht eine belastbare Bewertung.
Die Kurzantwort: Jede Versandquelle fachlich zuordnen und ihre ausgerichtete Authentifizierung prüfen
Ein DMARC-Bericht beantwortet drei getrennte Fragen: Wer hat gesendet? Welche Domains wurden durch SPF und DKIM technisch authentifiziert? Passt mindestens eine dieser Domains zur sichtbaren Absenderdomain im From-Feld? Nur wenn diese Ebenen getrennt gelesen werden, lassen sich legitime Dienste von Fehlkonfigurationen und fremden Spoofing-Versuchen unterscheiden.
| Befund | Wahrscheinliche Einordnung | Nächster Schritt |
|---|---|---|
| Bekannte Quelle, DKIM ausgerichtet und bestanden | Legitimer Versandweg arbeitet DMARC-konform | Quelle, Verantwortlichen und Zweck dokumentieren |
| Bekannte Quelle, SPF bestanden, aber nicht ausgerichtet | Dienst authentifiziert eine fremde Envelope-From-Domain | Individuelle Return-Path-Domain oder ausgerichtetes DKIM einrichten |
| Unbekannte Quelle, SPF und DKIM nicht ausgerichtet | Möglicher Spoofing-Versuch oder vergessener Dienst | Quelle gegen Inventar und reale Geschäftsprozesse prüfen |
| Weitergeleitete Nachricht, SPF fehlgeschlagen, DKIM ausgerichtet | Legitimer Versand kann DMARC weiterhin bestehen | DKIM-Ergebnis und Weiterleitungsweg kontrollieren |
| Bekannte Quelle, beide DMARC-Prüfungen fehlgeschlagen | Legitimer Dienst ist falsch oder unvollständig eingerichtet | Nicht vorschnell freigeben; Versanddomain und Signatur korrigieren |
Für jede auffällige Quelle werden sechs Angaben festgehalten
- Quell-IP-Adresse und gemeldete Nachrichtenanzahl
- Sichtbare Absenderdomain aus
header_from - SPF-Domain, SPF-Ergebnis und Ausrichtung zur Absenderdomain
- DKIM-Signaturdomain, Selektor, Ergebnis und Ausrichtung
- Betrieblicher Dienst, verantwortliche Person und legitimer Versandzweck
- Entscheidung: bestätigt, zu korrigieren, einzustellen oder nicht legitim
1. DMARC bewertet die sichtbare Absenderdomain, nicht bloß einzelne SPF- und DKIM-Ergebnisse
SPF, DKIM und DMARC prüfen verschiedene Identitäten einer Nachricht. Eine verständliche Auswertung beginnt deshalb mit der Rolle jeder Domain.
SPF prüft den sendenden Server gegen die Envelope-From-Domain
Beim SMTP-Transport nennt der sendende Server eine Rücklaufadresse, häufig als Envelope From oder Return-Path bezeichnet. Der empfangende Server prüft anhand der SPF-Richtlinie dieser Domain, ob die Quell-IP senden darf. Das sichtbare From-Feld im E-Mail-Programm kann eine andere Domain enthalten.
Ein Newsletterdienst kann deshalb SPF bestehen, obwohl er technisch seine eigene Rücklaufdomain verwendet. Für DMARC reicht dieses SPF-Ergebnis nur dann aus, wenn die SPF-geprüfte Domain zur sichtbaren Absenderdomain ausgerichtet ist. Das bloße Ergänzen eines Anbieter-Includes im SPF-Eintrag der Unternehmensdomain löst eine abweichende Return-Path-Konfiguration nicht zwangsläufig.
DKIM bindet eine Signatur an die im Signaturfeld genannte Domain
DKIM fügt einer Nachricht eine kryptografische Signatur hinzu. Der Empfänger ruft den öffentlichen Schlüssel über den Selektor und die Domain des d=-Werts ab. Ein bestandenes Ergebnis bestätigt, dass die geprüften Nachrichtenteile seit der Signatur nicht unzulässig verändert wurden und dass der Signierende den passenden privaten Schlüssel besitzt.
Auch hier kann ein Versanddienst mit seiner eigenen Domain signieren. Technisch ist die Signatur dann gültig, für DMARC aber nur verwendbar, wenn die DKIM-Domain zur sichtbaren Absenderdomain ausgerichtet ist. Seriöse Plattformen bieten dafür häufig eine kundenspezifische DKIM-Konfiguration über DNS-Einträge an.
DMARC besteht über ausgerichtetes SPF oder ausgerichtetes DKIM
DMARC nimmt die Domain aus dem sichtbaren From-Feld als Referenz. Die Nachricht besteht die DMARC-Prüfung, wenn mindestens einer der beiden Wege erfolgreich ist: SPF besteht und seine geprüfte Domain ist ausgerichtet, oder DKIM besteht und seine Signaturdomain ist ausgerichtet. Beide Mechanismen müssen nicht gleichzeitig bestehen, auch wenn eine saubere Konfiguration häufig beide anstrebt.
Die Ausrichtung kann entspannt oder strikt sein. Bei entspannter Ausrichtung dürfen sichtbare Absenderdomain und authentifizierte Domain unterschiedliche Subdomains derselben organisatorischen Domain sein. Strikte Ausrichtung verlangt eine genaue Domainübereinstimmung. Die veröffentlichten DMARC-Parameter aspf und adkim legen dieses Verhalten fest.
Die zentrale Leseregel
Ein isoliertes „pass“ in den Berichtsdaten ist kein ausreichender Befund. Geprüft wird immer, zu welcher Domain das Ergebnis gehört und ob diese Domain nach der veröffentlichten DMARC-Regel mit header_from ausgerichtet ist.
2. Ein Aggregatbericht wird von außen nach innen gelesen
Empfangende Organisationen senden DMARC-Aggregatberichte meist als komprimierte XML-Dateien an die im rua-Tag veröffentlichte Adresse. Ein Bericht fasst Beobachtungen eines Empfängers und eines Zeitraums zusammen.
Berichtsmetadaten benennen Absender, Zeitraum und eindeutige Kennung
report_metadata enthält unter anderem die berichtende Organisation, Kontaktadresse, Berichts-ID und einen Unix-Zeitraum aus Beginn und Ende. Diese Angaben dienen der Einordnung und Dublettenerkennung. Zwei Dateien verschiedener Empfänger können denselben Versandbestand aus jeweils eigener Sicht darstellen; ihre Zahlen werden nicht als unabhängige Gesamtsumme sämtlicher E-Mails verstanden.
Nicht jeder empfangende Mailanbieter sendet Berichte, und ein Anbieter kann Beobachtungen anders bündeln als ein anderer. Die Daten sind deshalb ein sehr wertvolles Lagebild, aber keine vollständige Buchhaltung des gesamten ausgehenden E-Mail-Verkehrs.
Die veröffentlichte Richtlinie zeigt, was der Empfänger ausgewertet hat
policy_published nennt die untersuchte Domain sowie Richtlinie und Ausrichtungsmodus. p beschreibt die gewünschte Behandlung fehlgeschlagener Nachrichten der Domain: beobachten, in Quarantäne behandeln oder ablehnen. sp kann eine abweichende Richtlinie für Subdomains festlegen; pct begrenzt den Prozentsatz, auf den eine Quarantäne- oder Ablehnungsrichtlinie angewendet werden soll.
Der Bericht gibt die vom Empfänger wahrgenommene Richtlinie wieder. Weicht sie von der erwarteten Veröffentlichung ab, werden DNS-Zustand, abgefragte Domain und Berichtszeitraum geprüft. Eine kürzlich geänderte Richtlinie kann in Berichten älterer Zeiträume noch nicht erscheinen.
Jeder Datensatz verbindet Quelle, Menge und DMARC-Entscheidung
Unter record steht eine Zeile für eine zusammengefasste Kombination. source_ip nennt die beobachtete sendende IP-Adresse, count die Anzahl der zugehörigen Nachrichten. policy_evaluated enthält die DMARC-Ergebnisse für SPF und DKIM sowie die angewendete Behandlung wie none, quarantine oder reject.
Ein Grundfeld kann lokale Abweichungen von der veröffentlichten Richtlinie erläutern, etwa Weiterleitung oder eine andere Empfängerentscheidung. Solche Angaben werden als Hinweis des berichtenden Systems gelesen und mit den Authentifizierungsergebnissen verbunden; sie sind kein pauschaler Freibrief für die Quelle.
Identifikatoren und Rohprüfungen erklären das Ergebnis
identifiers nennt insbesondere header_from, also die sichtbare Absenderdomain, gegen die DMARC die Ausrichtung prüft. Unter auth_results folgen die vom Empfänger beobachteten SPF- und DKIM-Prüfungen mit Domain, Ergebnis und bei DKIM häufig dem Selektor.
Hier wird sichtbar, warum eine Zeile DMARC nicht bestanden hat, obwohl ein Rohmechanismus „pass“ meldet. Beispielsweise kann SPF für bounce.versanddienst.example bestehen, während die sichtbare Absenderadresse rechnung@unternehmen.de lautet. Ohne passende organisatorische Domain besteht keine SPF-Ausrichtung.
| XML-Bereich | Feld | Bedeutung für die Auswertung |
|---|---|---|
| report_metadata | org_name, report_id, date_range | Wer berichtet über welchen Zeitraum? |
| policy_published | domain, p, sp, adkim, aspf, pct | Welche DMARC-Regel wurde ausgewertet? |
| row | source_ip, count | Welche Quelle erzeugte wie viele beobachtete Nachrichten? |
| policy_evaluated | disposition, dkim, spf, reason | Hat DMARC bestanden und welche Behandlung wurde angewendet? |
| identifiers | header_from | Welche sichtbare Absenderdomain war zu schützen? |
| auth_results | dkim domain/selector/result, spf domain/result | Welche technischen Identitäten haben tatsächlich bestanden? |
3. SPF- und DKIM-Ausrichtung werden anhand realer Versandwege unterschieden
Die meisten Fehlinterpretationen entstehen, wenn eine bestandene Authentifizierung mit einem bestandenen DMARC-Ergebnis gleichgesetzt wird.
Microsoft 365 kann SPF und DKIM mit der eigenen Domain ausrichten
Beim direkten Versand über Exchange Online wird SPF über die im Envelope From verwendete Domain bewertet. Für die eigene Geschäftsdomain wird außerdem DKIM aktiviert und über die von Microsoft vorgegebenen CNAME-Einträge bereitgestellt. In den Berichten sollten legitime Microsoft-365-Quellen dann mindestens einen ausgerichteten, bestandenen Mechanismus zeigen.
Eine Microsoft-IP allein bestätigt noch nicht, dass die Nachricht zum eigenen Mandanten und Geschäftsprozess gehört. Cloudplattformen verwenden gemeinsam betriebene Infrastruktur. Domain, Signatur, die eigene Testnachricht und der dokumentierte Versandprozess müssen zusammenpassen.
Newsletter- und Rechnungsdienste benötigen eine kundenspezifische Identität
Viele Plattformen versenden technisch über eigene Bounce- und Signaturdomains. Soll im sichtbaren From-Feld die Unternehmensdomain stehen, wird eine vom Anbieter unterstützte individuelle Versanddomain eingerichtet. Das kann eine DKIM-Signatur mit einer Subdomain des Unternehmens, eine passende Return-Path-Domain oder beides umfassen.
Die nötigen CNAME- oder TXT-Einträge werden exakt aus dem verifizierten Anbieterprojekt übernommen. Eine pauschale SPF-Erweiterung ohne Kenntnis der Envelope-From-Domain kann die Richtlinie vergrößern, ohne die DMARC-Ausrichtung zu reparieren. Ebenso darf ein fremder Dienst nicht allein deshalb autorisiert werden, weil seine IP in einem Bericht häufig erscheint.
Weiterleitungen können SPF brechen, während DKIM erhalten bleibt
Bei einer klassischen Weiterleitung sendet ein anderer Server die Nachricht zur nächsten Station. Dessen IP steht meist nicht im SPF-Eintrag der ursprünglichen Envelope-From-Domain; SPF kann deshalb am endgültigen Empfänger fehlschlagen. Eine intakte, ausgerichtete DKIM-Signatur kann DMARC trotzdem bestehen lassen.
Verändert die Weiterleitung signierte Bestandteile, kann auch DKIM scheitern. ARC kann einem empfangenden System zusätzliche Informationen über frühere Authentifizierungsprüfungen liefern, ändert aber nicht die Grundregel der DMARC-Auswertung. Auffällige Weiterleitungszeilen werden deshalb separat von direkten legitimen Versandquellen betrachtet.
Subdomains benötigen eine bewusste Richtlinie und klare Zuständigkeit
Transaktionssysteme können über Subdomains wie mail.unternehmen.de oder rechnung.unternehmen.de senden. Das trennt technische Verantwortung und Reputation vom normalen Mitarbeiterverkehr. Die Subdomain erhält passende SPF-, DKIM- und gegebenenfalls eigene DMARC-Einträge.
Ohne eigenen DMARC-Eintrag greift nach dem Standard die Richtlinie der organisatorischen Domain und gegebenenfalls deren sp-Wert. Vor einer strengen Richtlinie wird daher inventarisiert, welche Subdomains tatsächlich senden und wer sie betreibt.
4. Eine Quell-IP wird erst durch den zugehörigen Geschäftsprozess verständlich
Reverse DNS, Netzbetreiber und IP-Besitzer liefern Hinweise, aber keinen ausreichenden Berechtigungsnachweis. Entscheidend ist, ob das Unternehmen den konkreten Dienst beauftragt hat und seine Domain dort kontrolliert konfiguriert ist.
Das Versandinventar beginnt bei Geschäftsprozessen
Erfasst werden Microsoft 365, Websiteformulare, Newsletter, Buchhaltung, Warenwirtschaft, Ticketsystem, CRM, Terminplattform, Scanner, Alarmierung und externe Agenturen. Für jeden Prozess werden sichtbare Absenderadresse, technische Plattform, verantwortliche Person, erwartetes Volumen und verwendete Authentifizierung dokumentiert.
Diese Liste wird mit den DMARC-Zeilen abgeglichen. Eine bekannte Plattform mit unerwarteter Domain kann falsch eingerichtet sein; eine unbekannte IP kann zu einem legitimen Dienst gehören, der im Unternehmen nie dokumentiert wurde. Beides verlangt Klärung, bevor die Richtlinie verschärft wird.
Volumen und zeitlicher Verlauf priorisieren die Untersuchung
Eine einmalige Einzelzeile besitzt eine andere betriebliche Bedeutung als täglich tausende Nachrichten. Hohe oder plötzlich steigende Mengen werden zuerst geprüft, besonders wenn beide ausgerichteten Mechanismen fehlschlagen. Gleichzeitig kann eine einzige monatliche Rechnung geschäftskritisch sein; Volumen ersetzt daher nicht die fachliche Zuordnung.
Trends über mehrere Berichtszeiträume zeigen, ob eine Korrektur wirkt oder eine neue Quelle hinzugekommen ist. Tageswerte werden im Kontext von Kampagnen, Abrechnungsläufen und Systemänderungen gelesen. Ein einmaliger Screenshot einer Dashboard-Summe genügt nicht für die Freigabe einer Quelle.
Spoofing-Versuche werden nicht mit legitimen Fehlkonfigurationen vermischt
Versendet eine fremde Infrastruktur ohne Geschäftsbeziehung mit der Unternehmensdomain im sichtbaren From-Feld und bestehen weder ausgerichtetes SPF noch DKIM, spricht dies für unerlaubte Nutzung. Diese Quelle wird nicht in SPF aufgenommen und erhält keine DKIM-Konfiguration. Ihre Behandlung folgt der DMARC-Richtlinie des Unternehmens und den Entscheidungen der Empfänger.
Ein legitimer, aber falsch konfigurierter Rechnungsdienst kann im Bericht zunächst ähnlich aussehen. Der Unterschied ergibt sich aus dem eigenen Dienstinventar, Vertragsbezug und einer reproduzierbaren Testnachricht. Diese fachliche Prüfung verhindert sowohl unnötige Freigaben als auch das versehentliche Blockieren betrieblicher E-Mails.
Entscheidungsmatrix je Quelle
- Legitim und DMARC-konform: dokumentieren und weiter beobachten.
- Legitim, aber nicht ausgerichtet: kundenspezifische DKIM- oder Return-Path-Konfiguration herstellen.
- Legitim, aber nicht mehr benötigt: Versand beenden und alte DNS-Autorisierung entfernen.
- Unbekannt mit möglichem Geschäftsbezug: intern zuordnen und bis zur Klärung nicht pauschal autorisieren.
- Nicht legitim: keine Freigabe ergänzen; Wirkung einer strengeren DMARC-Richtlinie bewerten.
- Weiterleitung oder Sonderfall: DKIM, ARC-Hinweise und realen Transportweg gesondert analysieren.
5. Aus Berichten entsteht ein kontrollierter Weg von Beobachtung zu Schutz
Eine strenge Richtlinie wird nicht nach Kalender, sondern nach nachgewiesener Abdeckung der legitimen Versandwege eingeführt.
p=none liefert Beobachtungsdaten, fordert aber keine Quarantäne oder Ablehnung
Mit einer Beobachtungsrichtlinie bittet der Domaininhaber die Empfänger um Berichte, ohne aufgrund von DMARC eine Quarantäne- oder Ablehnungsbehandlung zu verlangen. Andere Spam- und Sicherheitsprüfungen bleiben davon unabhängig. Die Phase dient dazu, legitime Quellen zu inventarisieren und zu korrigieren.
Eine dauerhafte Beobachtung ohne Auswertung schafft nur Dateien, aber keinen Schutzgewinn. Für jede wiederkehrende fehlschlagende Quelle wird ein Verantwortlicher und eine Entscheidung festgelegt. Erst wenn geschäftlich benötigte Wege ausgerichtet sind, folgt die kontrollierte Verschärfung.
quarantine und reject werden anhand der verbleibenden Fehler bewertet
p=quarantine fordert eine verdächtige Behandlung fehlgeschlagener Nachrichten, häufig im Spam- oder Quarantänebereich. p=reject fordert die Ablehnung. Empfangende Systeme behalten eigenen Entscheidungsspielraum; die Richtlinie ist kein universelles Zustellversprechen.
Vor jeder Stufe werden die zuletzt beobachteten Fehler nach Volumen und Geschäftswert freigegeben. Der Prozentparameter kann eine abgestufte Einführung unterstützen, ersetzt aber keine vorherige Bestandsklärung. Kritische Anwendungen erhalten direkte End-to-End-Tests mit realen Empfängern.
DNS-Berechtigungen werden nach der Bereinigung wieder verkleinert
Wurde ein Newsletter-, CRM- oder Websiteanbieter abgelöst, werden nicht mehr benötigte SPF-Includes, DKIM-Selektoren und Verifikationsrecords nach dokumentierter Prüfung entfernt. Alte Autorisierungen vergrößern die Angriffs- und Fehlerfläche und erschweren spätere Auswertungen.
SPF bleibt eine einzelne Richtlinie pro Domain und wird auf DNS-Lookups sowie tatsächliche Versandquellen geprüft. DKIM-Schlüssel und Selektoren werden dem aktiven Dienst zugeordnet. DMARC enthält eine erreichbare Berichtsadresse, deren Verarbeitung organisatorisch geklärt ist.
Freigabe vor einer strengeren DMARC-Richtlinie
- Alle geschäftlich benötigten Versandprozesse stehen im Inventar.
- Jeder Prozess besteht DMARC über mindestens einen ausgerichteten Mechanismus.
- Hohe und wiederkehrende Fehlermengen sind fachlich erklärt.
- Weiterleitungen und Sonderwege wurden separat getestet.
- Subdomains besitzen eine passende eigene oder geerbte Richtlinie.
- Kritische E-Mail-Arten wurden nach der Änderung praktisch zugestellt und geprüft.
6. Der laufende Betrieb erkennt neue Absender und schleichende Fehlkonfigurationen
DMARC ist nach der Einführung nicht abgeschlossen. Neue Cloudanwendungen, Agenturen oder Websitefunktionen verändern den Versandbestand.
Neue Dienste benötigen vor dem ersten Versand eine Domainentscheidung
Bei der Beschaffung wird geklärt, welche sichtbare Absenderdomain, Return-Path-Domain und DKIM-Signatur der Dienst verwendet. Der Verantwortliche erhält die nötigen DNS-Einträge aus dem richtigen Kundenprojekt und einen Abnahmetest. Ein Dienst geht nicht mit der Unternehmensdomain produktiv, bevor sein DMARC-Ergebnis nachgewiesen ist.
Für Massen- oder Transaktionsversand kann eine eigene Subdomain sinnvoll sein. Sie trennt Konfiguration und Auswertung, ohne eine fremde Markenidentität zu erzeugen. Die Entscheidung wird mit den Anforderungen des Dienstes und den Empfängererwartungen abgestimmt.
Berichte werden nach Veränderung und Risiko priorisiert
Regelmäßige Auswertungen markieren neue Quellnetze, steigende Fehlmengen, veränderte Signaturdomains und Verschiebungen zwischen SPF- und DKIM-Erfolg. Bekannte stabile Quellen benötigen weniger Aufmerksamkeit als ein neuer hochvolumiger Absender oder eine bisher erfolgreiche Anwendung, deren DKIM plötzlich scheitert.
Die Auswertung bewahrt Rohberichte für einen festgelegten Zeitraum und dokumentiert Entscheidungen außerhalb bloßer Dashboard-Kommentare. So bleibt bei Anbieterwechseln oder Störungen nachvollziehbar, welche Quelle wann autorisiert war.
Die Berichtsauswertung wird mit realen Zustelltests verbunden
Aggregatberichte erscheinen zeitversetzt und enthalten keine vollständigen Nachrichteninhalte. Nach einer Korrektur wird deshalb eine eindeutig bezeichnete Testnachricht an unabhängige Empfängersysteme gesendet. Deren Header bestätigen sichtbare Absenderdomain, Return-Path, DKIM-Domain und Authentifizierungsergebnisse.
Der folgende Berichtszeitraum zeigt anschließend, ob die Korrektur auch im normalen Volumen greift. Erst die Kombination aus kontrolliertem Test und aggregierter Beobachtung belegt einen stabilen Versandweg.
Ergebnis einer belastbaren DMARC-Auswertung
- Aktuelles Versandinventar mit Verantwortlichen und Geschäftszweck
- Zuordnung aller volumenstarken und wiederkehrenden DMARC-Quellen
- Nachweis der ausgerichteten SPF- oder DKIM-Authentifizierung je legitimen Dienst
- Dokumentierte Ausnahmen, Weiterleitungen und ausgeschlossene Quellen
- Begründete Richtlinienstufe für Hauptdomain und Subdomains
- Verfahren für neue Dienste, regelmäßige Prüfung und technische Zustelltests
Häufige Fragen zur Auswertung von DMARC-Berichten
Bedeutet „SPF pass“, dass eine Nachricht DMARC bestanden hat?
Nein. Die SPF-geprüfte Domain muss zusätzlich mit der sichtbaren Absenderdomain ausgerichtet sein. Ein Dienst kann SPF mit seiner eigenen Return-Path-Domain bestehen und DMARC über SPF trotzdem verfehlen.
Müssen SPF und DKIM beide bestehen?
Für DMARC genügt mindestens ein bestandener und ausgerichteter Mechanismus. In der Praxis ist es sinnvoll, legitime Versandwege soweit möglich mit beiden Verfahren korrekt zu konfigurieren, weil Weiterleitungen oder technische Änderungen einen einzelnen Mechanismus beeinträchtigen können.
Kann eine unbekannte IP einfach in SPF aufgenommen werden?
Nein. Zuerst wird die IP einem beauftragten Dienst und einem legitimen Geschäftsprozess zugeordnet. Außerdem muss geklärt werden, ob SPF mit der Unternehmensdomain überhaupt der vorgesehene DMARC-Pfad ist. Eine fremde Spoofing-Quelle darf nicht autorisiert werden.
Schützt p=none vor gefälschten Absendern?
Die Richtlinie fordert aufgrund von DMARC keine Quarantäne oder Ablehnung, liefert aber die Grundlage für die Bestandsaufnahme. Andere Filter des Empfängers können unabhängig reagieren. Ein Schutzgewinn durch DMARC entsteht erst mit ausgewerteten Berichten, korrigierten legitimen Quellen und einer begründet strengeren Richtlinie.
Warum unterscheiden sich die Zahlen verschiedener DMARC-Dashboards?
Empfänger berichten nur über ihre eigenen Beobachtungen und können Daten unterschiedlich bündeln. Zeitzonen, Berichtszeiträume, Dublettenerkennung und Aufbereitung des Dienstes beeinflussen Summen. Für Entscheidungen werden deshalb Zeitraum, berichtende Organisation und Rohdatensatz nachvollziehbar gehalten.
Technische Quellen
E-Mail-Sicherheit in Frankfurt
Sie möchten wissen, welche Dienste mit Ihrer Domain versenden?
fra.digital ordnet DMARC-Berichte Ihren tatsächlichen Versandprozessen zu, korrigiert die Authentifizierung legitimer Dienste und bereitet eine nachvollziehbare Richtlinienentscheidung vor.
