Warum zeigt eine Zeile Ihres DMARC-Berichts spf=fail an, obwohl die Domain geschützt bleibt und die Nachricht trotzdem im Posteingang gelandet ist? Für jede Versandquelle listet ein aggregierter DMARC-Bericht das SPF-Ergebnis auf. Er ergänzt das DKIM-Ergebnis und die tatsächlich vom empfangenden Server angewendete Entscheidung. Ein fehlgeschlagenes SPF in Kombination mit einem erfolgreich ausgerichteten DKIM richtet keinen Schaden an: Die DMARC-Spezifikation gilt als bestanden, sobald einer der beiden Mechanismen mit der im From-Header sichtbaren Domain übereinstimmt.
Genau diese Art von Zeile sorgt zu Unrecht für Beunruhigung, wenn Kampagnen im Spam landen, das E-Mail-Marketing-Tool aber trotzdem eine durchweg grüne Deliverability-Quote anzeigt. Falls die Grundlagen der E-Mail-Authentifizierung (SPF, DKIM, DMARC) noch nicht klar sind, schafft das DMARC-Protokoll erklärt den Rahmen, bevor es weitergeht. Dieser Leitfaden konzentriert sich auf einen einzigen Punkt: einen aggregierten Bericht Feld für Feld zu lesen und eine normale Zeile von einem echten Alarm zu unterscheiden.
Wo der Bericht ankommt und in welchem Format
Der aggregierte Bericht wird an die im Tag rua= des DNS-Eintrags _dmarc angegebene Adresse gesendet, in der Regel einmal täglich pro empfangendem Anbieter (Google, Microsoft, Yahoo). Die Details zu den DNS-Tags, die diesen Versand steuern, behandelt der Artikel über die DMARCbis-DNS-Tags, die vor der Umstellung 2026 korrigiert werden müssen; dieser Artikel hier geht davon aus, dass das DNS bereits eingerichtet ist. Jede Nachricht kommt als komprimierter Anhang an, eine XML-Datei in einem .zip- oder .gz-Archiv. Sie muss vor dem Lesen entpackt werden, oder man nutzt ein Analysetool, das dies automatisch erledigt.
MailerCheck unterscheidet 2024 zwischen aggregierten Berichten und forensischen Berichten: Erstere fassen die Authentifizierungsaktivität über einen bestimmten Zeitraum zusammen, Letztere beschreiben einen konkreten Fehlschlag im Detail und werden von E-Mail-Anbietern nur selten implementiert (MailerCheck, 2024). Dabei werden keine sensiblen Daten übertragen. Fast das gesamte DMARC-Monitoring stützt sich daher auf den aggregierten Bericht. Das ist auch die DMARC-Richtlinie, die Gmail und Yahoo seit 2024 für Domains verlangen, die mehr als 5.000 Nachrichten pro Tag versenden. Wer das überprüfen will, kommt am aggregierten Bericht kaum vorbei.
Der Aufbau der XML-Datei, Feld für Feld
Die XML-Datei gliedert sich in drei Blöcke. report_metadata identifiziert den Absender des Berichts (org_name, E-Mail, abgedeckter Zeitraum). policy_published gibt die zum Zeitpunkt der Analyse von Ihrer Domain veröffentlichte DMARC-Richtlinie wieder. Der Block record enthält eine oder mehrere row-Zeilen, von denen jede einer eindeutigen Kombination aus Quelle und Ergebnissen entspricht.
Um eine Zeile zu interpretieren, ohne den Überblick zu verlieren, kommt es auf die Lesereihenfolge an.
- Die Quelle identifizieren: source_ip gibt die IP-Adresse an, die die Nachricht tatsächlich versendet hat; ein Abgleich mit einem Reverse-DNS zeigt, ob es sich um Ihren ESP, ein Relais eines Drittanbieters oder eine unbekannte IP handelt.
- Das Volumen betrachten: count gibt die Anzahl der Nachrichten an, die dieser exakten Kombination über den gesamten Berichtszeitraum zugeordnet sind.
- Die angewendete Entscheidung lesen: disposition (none, quarantine oder reject) im Block policy_evaluated, also die vom empfangenden Server tatsächlich getroffene Entscheidung.
- dkim und spf in policy_evaluated vergleichen: Diese beiden Werte geben das Alignment-Ergebnis an, das sich vom rohen Protokollergebnis unterscheidet.
- auth_results prüfen für das rohe Ergebnis jedes Mechanismus sowie die tatsächlich signierende oder deklarierte Domain.
Diese Unterscheidung zwischen Alignment (policy_evaluated) und rohem Ergebnis (auth_results) ist die Ursache der meisten Missverständnisse. Ein technisch gültiges SPF auf der Envelope-Domain kann in policy_evaluated dennoch fail anzeigen, weil diese Domain nicht mit der im From-Header sichtbaren Domain übereinstimmt. Der folgende Fall zeigt genau das.
Die 4 Kombinationen aus DKIM und SPF und ihr DMARC-Urteil
Ein aggregierter Bericht zeigt 4 wiederkehrende Konfigurationen. Jede erzählt eine andere Geschichte darüber, was zwischen Ihrem Versandserver und dem Postfach des Empfängers passiert ist.
| DKIM | SPF | DMARC-Ergebnis | Häufigste Ursache |
|---|---|---|---|
| Pass, ausgerichtet | Pass, ausgerichtet | Pass | Direkter Versand von der im DNS deklarierten Infrastruktur |
| Pass, ausgerichtet | Fail | Pass, über DKIM | Forwarding, Mailingliste, Weiterleitung des Postfachs |
| Fail | Pass, ausgerichtet | Pass, über SPF | Relais, das die Nachricht nicht signiert, oder unterwegs beschädigte Signatur |
| Fail | Fail | Fail | Domain-Spoofing oder im DNS falsch deklarierte Versandquelle |
Nur die 4. Zeile erfordert eine sofortige Korrektur. Die ersten 3 entsprechen einem erwarteten Verhalten der Spezifikation, jede mit ihrer eigenen Lesart.
SPF fehlgeschlagen, DKIM erfolgreich: Ist das besorgniserregend?
In den meisten Fällen nicht. SPF prüft die Adresse MAIL FROM, die im SMTP-Dialog direkt nach dem anfänglichen EHLO-Austausch über den gleichnamigen Befehl übermittelt wird, also die Envelope-Adresse. DKIM signiert den Inhalt der Nachricht mit einem privaten Schlüssel, der an die Absenderdomain gebunden ist; diese Signatur reist mit der Nachricht mit, unabhängig davon, welcher Server sie anschließend weiterleitet. Wenn ein Empfänger eine E-Mail an ein anderes Postfach weiterleitet oder eine Mailingliste eine Nachricht an ihre Abonnenten verteilt, wird der weiterleitende Server zur neuen Versand-IP. SPF, das die IP gegen den Eintrag der ursprünglichen Domain prüft, schlägt dabei zwangsläufig fehl. Die DKIM-Signatur hingegen bleibt intakt, solange der Body und die signierten Header unterwegs nicht verändert werden.
Spamresource dokumentiert im November 2025 eine Microsoft-Ablehnung, die diese Mechanik anschaulich in die andere Richtung zeigt: Eine Nachricht mit DKIM pass und DMARC pass wurde blockiert, weil SPF fehlschlug.
550 5.7.515 Access denied, sending domain doesn’t meet the required authentication level. Spf= Fail, Dkim= Pass, DMARC= Pass
Der erweiterte Statuscode 5.7.515 signalisiert hier eine Microsoft-eigene Anforderung, eine zusätzliche Ebene oberhalb des eigentlichen DMARC-Ergebnisses. Seit Mai 2025 verlangt Microsoft von Massenversendern, dass alle 3 Mechanismen (SPF, DKIM, DMARC) gleichzeitig bestehen, selbst wenn die DMARC-Spezifikation selbst nur ein erfolgreiches Alignment voraussetzt (spamresource.com, 2025). Der in diesem Fall festgestellte SPF-Fehlschlag stammte laut demselben Artikel von einer Weiterleitung an ein Postfach außerhalb der Microsoft-Server. Das sollte man wissen, bevor man einem CMO erklärt, dass die Open Rate sinkt: DMARC kann in Ihrem Bericht pass anzeigen, während einzelne Nachrichten trotzdem durch eine Regel blockiert werden, die dem empfangenden Anbieter eigen ist.
Zwei Dinge unterscheiden diesen Fall von einem echten, zu behebenden Konfigurationsproblem. Erstens das Volumen: Einzelne Zeilen mit niedrigem count, verteilt auf verschiedene IPs, entsprechen eher individuellem Forwarding als einer ganzen Kampagne. Zweitens die Quelle: Ein Reverse-DNS auf diese source_ip verweist in der Regel auf einen Consumer-E-Mail-Anbieter oder einen Mailinglisten-Server, niemals auf Ihre eigene Versandinfrastruktur. Ein wiederholter SPF-Fehlschlag auf Ihren eigenen Versand-IPs, ohne erkennbares Forwarding, deutet auf eine andere Ursache hin: das Limit von 10 DNS-Lookups im SPF-Eintrag, das geprüft werden sollte, bevor man vorschnell auf eine simple Weiterleitung schließt.
Häufige Fallstricke beim Lesen eines aggregierten Berichts
Erster Fallstrick: das rohe Ergebnis von auth_results mit dem Alignment-Ergebnis von policy_evaluated zu verwechseln. Ein SPF kann auf der Envelope-Domain technisch bestehen und trotzdem im Alignment scheitern, weil diese Domain vom sichtbaren From abweicht, ein häufiges Szenario bei Absendern, die einen bei einem Drittanbieter gemeinsam genutzten IP-Pool verwenden.
Zweiter Fallstrick: einen einzelnen Bericht als endgültigen Beweis zu behandeln. Die großen Anbieter (Google, Microsoft, Yahoo) versenden tägliche Berichte. Ein einmaliger Vorfall kann an einem einzigen Tag auftauchen und am nächsten wieder verschwinden. Prüfen Sie count und disposition über mindestens eine Woche, bevor Sie Schlussfolgerungen ziehen.
Dritter Fallstrick: das Feld org_name im Block report_metadata zu ignorieren. Es identifiziert, wer den Bericht erstellt hat, nützlich, um einen sekundären Anbieter zu erkennen, der zusätzlich zu Ihrer eigenen eine eigene Filterrichtlinie anwendet, unabhängig von den ISP-Feedback-Loops, die Sie auf Ihrer Seite bereits abonniert haben.
Was das für Ihre Deliverability bedeutet
Ein sauberer Bericht mit einer bei den nicht-fremden Zeilen konsistenten disposition auf none oder quarantine bestätigt eine stabile Sender Reputation auf Authentifizierungsebene. Das ist ein anderes Signal als das übliche Post-Versand-Monitoring: Die Open Rate oder die Bounce Rate zeigt die Wirkung auf Empfängerseite, der DMARC-Bericht zeigt die Ursache auf Seite des empfangenden Servers, noch bevor die Nachricht überhaupt ein Postfach erreicht. Beide Signale ergänzen sich. Der Gmail-Postmaster und das Microsoft-Äquivalent, die SNDS (Smart Network Data Services), liefern eine ähnliche Sicht auf die IP-Reputation, die mit denselben im Bericht identifizierten source_ip abgeglichen werden sollte.
Sobald die Authentifizierung über mehrere Tage hinweg als sauber bestätigt ist, bleibt die nächste Variable mit Einfluss auf die Reputation die Sauberkeit der versendeten Liste. Eine hohe Hard-Bounce-Rate schädigt die Sender Reputation ebenso sicher wie ein falsch ausgerichtetes SPF, und keine Zeile eines DMARC-Berichts zeigt das an. Eine Stichprobe der nächsten Liste vor dem Versand zu verifizieren, zeigt, ob die Bremse bei der Authentifizierung oder bei der List Hygiene liegt.
Was der aggregierte Bericht nicht abdeckt
Ein DMARC-Bericht sagt nichts über den Inhalt der Nachricht aus und nichts über die tatsächliche Beschwerdequote auf Empfängerseite. Ähnliche Domains (Typosquatting), die nie einen DMARC-Eintrag veröffentlicht haben, entgehen diesem Reporting-Mechanismus komplett. Die Umstellung auf p=reject blockiert die direkte Usurpation Ihrer Domain, eine technische Voraussetzung, um anschließend BIMI zu aktivieren. Auf eine optisch ähnliche, von einem Dritten registrierte Domain hat das jedoch keine Auswirkung. Die 5 Dinge, die DMARC nicht kann, beschreiben diese blinden Flecken jenseits des Reportings im Detail.
Speichern Sie Ihre Berichte über mehrere Wochen, bevor Sie die Richtlinie anpassen. Nur so lässt sich ein echtes Signal von vorübergehendem Rauschen unterscheiden. Jede Zeile des aggregierten Berichts zeigt, welchen Weg eine Nachricht bis zum Posteingang tatsächlich genommen hat.
