Ein Bericht ist zunächst eine Rückmeldung
Eine Nachricht mit einem Betreff wie „Report domain“ ist nicht automatisch eine Störungsmeldung. Ein empfangender Mailanbieter fasst darin zusammen, welche Nachrichten mit Ihrer Absenderdomain er im Berichtszeitraum beobachtet hat. Diese Rückmeldung kann vollständig unauffällig sein. Sie ist weder eine Bestätigung eines Kontoeinbruchs noch die Unzustellbarkeitsmeldung einer bestimmten E-Mail.
Aggregatberichte werden über das rua-Ziel im DMARC-Eintrag angefordert. Die eigentlichen Daten stehen im XML-Anhang, häufig komprimiert. Ein leerer Nachrichtentext macht den Bericht deshalb nicht unbrauchbar. Auch der sichtbare Absendername allein belegt seine Echtheit nicht: Berichte gehören in einen kontrollierten Auswertungsweg. [1] [3]
Zuerst Zeitraum und Zählweise prüfen
Beginnen Sie mit report_metadata: Wer berichtet, welche Report-ID ist angegeben und welchen UTC-Zeitraum umfasst date_range? Danach prüfen Sie die Domain unter policy_published. Das Eingangsdatum im Postfach ersetzt den Berichtszeitraum nicht. Der Zähler count steht für zusammengefasste Nachrichten mit der jeweiligen Kombination von Prüfergebnissen, nicht für Kunden, Personen oder Sicherheitsvorfälle.
Wer Dateien sammelt, braucht eine nachvollziehbare Zählregel. Vergleichen Sie Berichtersteller, Domain, Report-ID, Zeitraum und Inhalt. Identische Wiederholungen dürfen die Nachrichtenzahl nicht erhöhen. Bei teilweise überlappenden Berichten lässt sich eine Überschneidung nicht immer exakt herausrechnen; kennzeichnen Sie diese Einschränkung, statt eine scheinbar präzise Gesamtsumme zu veröffentlichen. [1]
SPF-Pass und DMARC-Pass sind nicht dasselbe
auth_results enthält die Ergebnisse der einzelnen SPF- und DKIM-Prüfungen. policy_evaluated beschreibt deren Bewertung für DMARC einschließlich der Domain-Zuordnung, dem Alignment. Vergleichen Sie beides mit header_from, der Domain im sichtbaren Absenderfeld. Ein technisches „pass“ für die Domain eines Versanddienstes reicht nicht, wenn die erforderliche Zuordnung zu Ihrer Absenderdomain fehlt.
DMARC besteht, wenn mindestens einer der Wege SPF oder DKIM erfolgreich ist und zugleich zur sichtbaren From-Domain passt. Deshalb kann SPF fehlschlagen und DMARC trotzdem bestehen, etwa über eine gültige, passende DKIM-Signatur. Mehrere DKIM-Signaturen können unterschiedliche Ergebnisse liefern. Entscheidend ist der passende erfolgreiche Nachweis, nicht ein einzelnes herausgegriffenes „fail“. [1] [2]
Bericht abgrenzen
Berichtersteller, Domain, Zeitraum und Report-ID erfassen; Duplikate aussondern.
Versandweg zuordnen
Quelle, SPF/DKIM-Ergebnisse und Alignment mit dem freigegebenen Versandbestand vergleichen.
Abweichung klären
Legitimen Fehler korrigieren, unbekannte Quelle untersuchen oder Beobachtung dokumentieren.
Eine Entscheidung mit Beleg
Zuständige Person, geprüften Versandweg und nächsten Kontrolltermin festhalten. Die Zustellung separat nachweisen.
Schematische Auswertung ohne echte Nachrichten- oder Kundendaten. Ein DMARC-Ergebnis und eine Zustellbestätigung sind unterschiedliche Nachweise.
Was die häufigsten Kombinationen bedeuten
Die folgende Tabelle bezieht sich auf die SPF- und DKIM-Werte in policy_evaluated, nicht auf die rohen Ergebnisse unter auth_results. Sie dient der Einordnung; sie bestätigt weder die Berechtigung eines konkreten Dienstes noch den Inhalt einer Nachricht. [1] [2]
Die Tabelle lässt sich seitlich verschieben.
| Im Bericht | Einordnung | Nächster Schritt |
|---|---|---|
| SPF pass, DKIM pass | Beide Wege bestehen die DMARC-Bewertung. | Quelle dem freigegebenen Versanddienst zuordnen. |
| SPF fail, DKIM pass | DMARC besteht über DKIM. | SPF-Abweichung und mögliche Weiterleitung getrennt prüfen. |
| SPF pass, DKIM fail | DMARC besteht über SPF. | DKIM für diesen Versandweg untersuchen; SPF allein ist weniger robust bei Weiterleitung. |
| SPF fail, DKIM fail | Kein passender erfolgreicher Authentifizierungsweg. | Legitime Fehlkonfiguration, Weiterleitung und unberechtigte Nutzung unterscheiden. |
| Ergebnis fehlt oder ist unlesbar | Keine belastbare Bewertung aus diesem Datensatz. | Berichtsformat und Auswertung prüfen; nicht als null Fehler zählen. |
Eine unbekannte IP ist ein Prüfauftrag
Ein Anbietername oder ein Rechenzentrumsstandort sagt noch nicht, wer einen bestimmten Versand veranlasst hat. Geteilte Mailinfrastruktur kann Nachrichten vieler Kunden transportieren. Gleichen Sie die Quelle deshalb mit Ihren tatsächlich freigegebenen Diensten ab: Postfach, Website, Rechnungssoftware, Supportsystem und Newsletter gehören jeweils separat in den Bestand.
Für die Zuordnung helfen die beteiligten Domains, DKIM-Selektoren, Versandprotokolle und eine kontrolliert empfangene Nachricht. Eine unbekannte IP nicht vorsorglich in SPF übernehmen. Erst die Berechtigung klären. Ist ein eigener Dienst betroffen, erhält die Korrektur eine verantwortliche Person und einen konkreten Nachweis für die Nachprüfung. Ein erfolgreicher Test aus Webmail prüft nicht automatisch das Website-Formular. [2] [4]
„none“ bestätigt keinen Posteingang
disposition beschreibt die gemeldete Behandlung im Rahmen der DMARC-Auswertung. „none“ ist kein Zustellbeleg; „quarantine“ verrät nicht zuverlässig den späteren Ordner einer einzelnen Nachricht. Empfangende Systeme können zusätzliche Regeln anwenden. Auch ein DMARC-Pass garantiert weder Posteingangsplatzierung noch vertrauenswürdigen Inhalt. Für eine konkrete vermisste E-Mail brauchen Sie Versandprotokolle, Rückläufer und gegebenenfalls die empfangene Originalnachricht.
Berichte zeigen außerdem nur die Sicht der jeweils berichtenden Systeme im angegebenen Zeitraum. Fehlende Berichte oder leere Datenausschnitte bedeuten nicht null Versand und nicht null Missbrauch. Dokumentieren Sie diese Lücke. Für einen Trend vergleichen Sie gleich lange Zeiträume derselben Berichtersteller und prüfen Änderungen der Abdeckung. [1] [4]
Wann Sie handeln sollten
Handlungsbedarf besteht besonders, wenn ein freigegebener, geschäftlich wichtiger Versandweg DMARC nicht besteht oder sich seine Ergebnisse unerwartet ändern. Wiederkehrende unbekannte Quellen benötigen eine Zuordnung. Die richtige Maßnahme folgt aus dem Befund; sie ist nicht automatisch eine strengere oder schwächere DNS-Regel. Vor einem Policywechsel müssen legitime Versandwege erfasst, geprüft und bekannte Authentifizierungsfehler behoben sein. [2]
- Berichtersteller, Domain, UTC-Zeitraum und Duplikate prüfen.
- SPF/DKIM-Rohergebnisse von DMARC-Alignment unterscheiden.
- Auffällige Quelle einem Dienst und einer verantwortlichen Person zuordnen.
- Berechtigte Testnachricht sowie relevante Header und Versandprotokolle prüfen.
- Korrektur, Änderungsfenster und Rückfallweg festlegen.
- Nach der Änderung Authentifizierung und tatsächliche Zustellung getrennt kontrollieren.