DMARC-Probleme beheben: Ein Praxisleitfaden

Kurzfassung: Die meisten DMARC-Probleme lassen sich auf Abgleichsprobleme zurückführen. Zwar können SPF oder DKIM bestehen, aber die authentifizierte Domain stimmt nicht mit dem From-Header überein. Beheben Sie diese Probleme, indem Sie Drittanbieter so konfigurieren, dass sie Ihre Domain im Return-Path und in der DKIM-Signatur verwenden, prüfen Sie die DNS-Syntax und nutzen Sie ARC zum Umgang mit Weiterleitungen. Beginnen Sie mit p=none, werten Sie die Berichte wöchentlich aus, und gehen Sie erst nach einer Erfolgsquote von über 95 % in den Durchsetzungsmodus.

Die wichtigsten Erkenntnisse

• Abgleich ≠ Authentifizierung: SPF und DKIM können erfolgreich sein, während DMARC dennoch fehlschlägt, wenn die authentifizierte Domain nicht mit der From-Header-Domain übereinstimmt.
• Nur einer muss übereinstimmen: DMARC ist bestanden, wenn entweder SPF oder DKIM übereinstimmt. Beide sind nicht erforderlich.
• Drittanbieter sind häufig die Ursache: Marketingplattformen, CRMs und Support-Tools versenden oft mit ihren eigenen Domains und unterbrechen so den Abgleich
• Verwenden Sie entspannten Abgleich (Standard), es sei denn, Sie haben sehr hohe Sicherheitsanforderungen. Er erlaubt die Ausrichtung von Subdomains auf Elterndomains.
• Starten Sie mit p=none: Sammeln Sie für mindestens 2 Wochen Berichte, bevor Sie auf Quarantäne oder Ablehnung wechseln
• Erreichen Sie mindestens einen Erfolgswert von 95 % für mindestens einen Monat, bevor Sie p=reject aktivieren
• Überprüfen Sie aggregierte Berichte wöchentlich: Ein plötzlicher Rückgang der Erfolgsrate weist auf Änderungen hin
• ARC erhält Authentifizierung beim Weiterleiten: Es ersetzt nicht SPF/DKIM, hilft aber beim Weiterleiten von E-Mails
• SPF hat ein Limit von 10 DNS-Lookups: Wird dieses überschritten, kommt es zu gelegentlichen Fehlern. Reduzieren Sie Includes auf IPs, falls nötig.

DMARC-Authentifizierungsfehler blockieren legitime E-Mails, schaden dem Absender-Ruf und reißen Sicherheitslücken, die Angreifer ausnutzen. Ein falsch konfigurierter DNS-Eintrag kann hunderte unternehmenskritische Nachrichten im Spam-Ordner verschwinden lassen. Wenn SPF erfolgreich ist und DKIM korrekt signiert, aber DMARC weiterhin fehlschlägt, verbringen IT-Teams Stunden mit der Auswertung von XML-Berichten, DNS-Fehlersuche und der Abstimmung mit Dienstleistern, um die Ursache zu finden.

Die gute Nachricht: Die meisten DMARC-Probleme lassen sich auf einige wenige, gut behebbare Konfigurationsfehler zurückführen. Abgleichsprobleme, Syntaxfehler in DNS und Drittanbieterprobleme verursachen die meisten Authentifizierungsfehler. Wer weiß, wie er jede Fehlerart debuggt, löst unspezifische "DMARC funktioniert nicht"-Meldungen zielgerichtet.

Sicherheitsteams, die für die E-Mail-Authentifizierung zuständig sind, brauchen systematische Debugging-Strategien, um Fehler schnell zu isolieren – egal ob sie an internen DNS-Einträgen, bei Drittanbieter-Marketinglösungen oder bei Einstellungen für Weiterleitungen liegen. Dieser Leitfaden gibt praktische Schritte fürs Debugging, damit E-Mails zuverlässig authentifiziert und zugestellt werden.

• Was sind DMARC-Fehler?
• SPF- und DKIM-Abgleich beheben
• DMARC-Berichte auswerten
• DNS-Eintragsfehler korrigieren
• Umgang mit Weiterleitungen und Drittanbietern
• ARC für bessere Ergebnisse einsetzen
• DMARC-Fehler reduzieren: Beste Praktiken
• Laufende Überwachung und Verbesserung
• Häufige Fragen zum Debugging von DMARC-Fehlern

DMARC-Fehler treten auf, wenn E-Mails die Abgleichsprüfung nicht bestehen – auch wenn SPF oder DKIM einzeln erfolgreich sind. Das DMARC-Protokoll verlangt, dass entweder SPF oder DKIM mit der Domain im From-Header übereinstimmt. Abgleich heißt: Die authentifizierte Domain stimmt mit der sichtbaren Domain des Absenders überein.

Typisches Abgleichsproblem:

Marketing-Newsletter landen im Spam, obwohl SPF für mailserver.vendor.com erfolgreich ist und die DKIM-Signatur gültig ist. Im From-Header steht marketing@company.com, aber authentifiziert wurde für Domains von vendor.com – ein Abgleichsfehler entsteht.

Lösung: Konfigurieren Sie Ihre Marketingplattform so, dass sowohl im Return-Path als auch im DKIM-Signatur-d-Parameter company.com verwendet wird. Sobald der Abgleich stimmt, besteht DMARC und die Zustellbarkeit kehrt zurück.

Eine E-Mail von marketing@company.com, authentifiziert durch mailserver.vendor.com, besteht DMARC nicht, weil die Domains nicht übereinstimmen. Die SPF-Prüfung kann für die Vendor-Domain erfolgreich sein, aber DMARC verlangt die Übereinstimmung mit company.com.

Authentifizierungsfehler erscheinen in aggregierten Berichten als fehlgeschlagener SPF-Abgleich, fehlgeschlagener DKIM-Abgleich oder beides. Empfangende Mailserver senden diese XML-Berichte täglich an die in Ihrem DMARC-Eintrag angegebene E-Mail-Adresse.

SPF-Abgleichsprobleme entstehen oft durch Return-Path-Domain-Unstimmigkeiten. Wenn E-Mails von Drittanbietern stammen, verwendet der Return-Path häufig deren Domain statt Ihrer eigenen. Die SPF- und DKIM-Anleitung erklärt, wie diese Protokolle die Identität des Absenders authentifizieren.

DMARC-Sammelberichte kommen als komprimierte XML-Dateien als Anhang zu täglichen E-Mails [4]. Jeder Bericht enthält Authentifizierungsergebnisse nach Quelle gruppiert und zeigt Erfolgs-/Fehleranzahlen für SPF- und DKIM-Abgleich.

Die Quell-IP identifiziert jedes sendende System. Vergleichen Sie IPs mit bekannten internen Mailservern, Drittanbieter-Marketingplattformen und SaaS-Anwendungen. Unbekannte IPs sollten geprüft werden, ob sie von legitimen oder unautorisierten Systemen stammen.

Wenn SPF und DKIM beide fehlschlagen, analysieren Sie konkrete Abgleichsprobleme. Fehlgeschlagenes SPF weist auf Return-Path-Probleme hin; bei DKIM auf fehlende oder nicht passende Signaturen.

Priorisieren Sie beim Debugging: Zuerst Probleme mit hohem Volumen, dann unbekannte IPs, dann Fälle mit geringem Volumen.

DNS-Syntax-Grundlagen:

SPF-Einträge müssen mit v=spf1 beginnen und mit -all oder ~all enden. Die Anweisung -all lehnt unautorisierte Absender strikt ab, ~all ist weicher. Prüfen Sie mit DMARC-Tools die Syntax, bevor Sie veröffentlichen.

Befehle zur DNS-Überprüfung:

• DMARC: dig _dmarc.yourdomain.com TXT
• SPF: dig yourdomain.com TXT
• DKIM: dig selector._domainkey.yourdomain.com TXT
• Verbreitung: nslookup -type=TXT _dmarc.yourdomain.com 8.8.8.8
• Syntaxprüfung: redsift.com/tools/investigate

Profi-Tipp: Die meisten SPF-Probleme entstehen durch Lookup-Limits oder Selector-Abweichungen. Konzentrieren Sie den Debugging-Einsatz zuerst auf diese beiden Bereiche für eine schnelle Lösung.

Das Weiterleiten von E-Mails bricht die SPF-Authentifizierung, weil weitergeleitete Nachrichten von Zwischensystemen stammen, die nicht in SPF-Einträgen aufgeführt sind. Wenn user@company.com E-Mails an personal@gmail.com weiterleitet, sieht Gmail die IP des Weiterleitungsservers, nicht die initial autorisierte Absender-IP.

So beeinflussen Weiterleitungen die Authentifizierung:

Vor dem Weiterleiten: Ursprüngliche Absender-IP: 192.0.2.1 (in SPF autorisiert) → Return-Path: sender@company.com → From: sender@company.com → SPF besteht ✓ → DMARC besteht ✓

Nach Weiterleitung auf private E-Mail: Weiterleitungsserver-IP: 203.0.113.5 (NICHT in SPF) → Return-Path: sender@company.com (unverändert) → From: sender@company.com → SPF schlägt fehl ✗ → DMARC schlägt fehl ✗

SPF schlägt fehl, da der Envelope-Sender (Return-Path) weiterhin auf die ursprüngliche Domain verweist, aber die sendende IP sich zur des Weiterleitungsservers geändert hat. DKIM-Signaturen bleiben manchmal erhalten, sofern Nachrichten nicht verändert werden.

Drittanbieter-Konfiguration:

• Senden über Subdomains - z.B. news.yourdomain.com statt yourdomain.com
• Veröffentlichen Sie SPF-Einträge für alle Subdomains - Subdomains erben nichts von der Elterndomain
• Konfigurieren Sie benutzerdefinierte Return-Path-Domains - erhält SPF-Abgleich, während Anbieter die Infrastruktur verwalten
• Aktualisieren Sie bei Anbieterwechseln - Dienstleister fügen ohne Benachrichtigung Server hinzu

Authenticated Received Chain (ARC) erhält Authentifizierungsresultate beim E-Mail-Weiterleiten und durch Mailinglisten-Änderungen. Beim Durchlauf über Zwischenstationen erstellt ARC eine Kette von Authentifizierungsergebnissen, die vom empfangenden Server verifiziert werden können [1].

Jeder Vermittler fügt seine eigenen ARC-Header hinzu und baut damit eine überprüfbare Authentifizierungskette auf.

Implementierungsoptionen:

• Google Workspace / Microsoft 365 – Automatische ARC-Header (null Konfiguration)
• Postfix / Sendmail – Selbst gehostet über OpenARC-Module
• OnDMARC – Kommerzielle Plattform mit ARC-Validierung

Wichtig: ARC ersetzt SPF oder DKIM nicht. Es ergänzt sie, indem die Authentifizierungsergebnisse erhalten bleiben, wenn das Weiterleiten sonst die DMARC-Übereinstimmung aufheben würde. Empfangende Server, die ARC unterstützen, können die Kette validieren und Nachrichten vertrauen, die ursprünglich authentifiziert waren.

Dokumentieren Sie alle autorisierten Absenderquellen, bevor Sie DMARC-Richtlinien implementieren. Fragen Sie Mitarbeitende nach den von ihnen genutzten E-Mail-Tools. Typische Schatten-IT-Quellen sind Support-Plattformen (Zendesk), Marketing-Tools (HubSpot, Mailchimp), CRM-Systeme (SalesForce) und Umfrageplattformen.

Selbstbewertung: Ist Ihre DMARC-Konfiguration gefährdet?

1. p=quarantine/p=reject aktiv, ohne zuvor mindestens 2 Wochen p=none betrieben zu haben
2. Authentifizierungsrate unter 95 % für legitime Absender
3. Drittanbieterdienste versenden ohne SPF/DKIM-Konfiguration
4. Kein wöchentlicher Prüfprozess für aggregierte Berichte
5. DNS-Einträge wurden seit über 6 Monaten nicht geprüft
6. Mitarbeitende können E-Mail-Tools ohne IT-Freigabe hinzufügen

Wenn Sie 3 oder mehr ankreuzen: Beheben Sie diese Lücken, bevor Sie striktere Richtlinien einführen.

Beginnen Sie mit p=none und sammeln Sie zwei Wochen lang Berichte. Analysieren Sie diese, um alle Absenderquellen und deren Authentifizierungsstatus zu identifizieren. Wechseln Sie zu p=quarantine mit 25 % (mittels pct=-Tag) und erhöhen Sie schrittweise auf pct=100, bevor Sie auf p=reject gehen.

Der DMARC Enforcement Guide begleitet Sie durch die Entscheidungen bei der Richtlinienumstellung. Wechseln Sie erst auf p=reject, wenn Sie für mindestens einen Monat Authentifizierungsraten von über 95 % erreicht haben.

DMARC erfordert eine fortlaufende Verwaltung und ist keine Einmal-Konfiguration. Drittanbieter ändern ihre Versand-Infrastruktur, neue Anwendungen versenden ohne IT-Freigabe E-Mails und gelegentlich verfallen DNS-Einträge bei Domainverlängerungen.

Verfolgen Sie Authentifizierungsquoten je Absenderquelle. Sinkt die Erfolgsrate einer Marketingplattform plötzlich von 99 % auf 85 %, ist sofortige Überprüfung angebracht.

Aggregierte Berichte zeigen Spoofing-Versuche von unautorisierten IPs. Forensische Berichte (ruf=) liefern Beispielnachrichten zum Debugging, enthalten aber E-Mail-Inhalte – daher nur vorübergehend für aktives Debugging verwenden.

OnDMARC bietet Echtzeitwarnungen bei sinkenden Authentifizierungsraten, erkennt automatisch neue Absenderquellen und überwacht die Richtlinieneinhaltung über mehrere Domains hinweg.

[1] Wikipedia-Autoren. „Authenticated Received Chain.“ Wikipedia, Die freie Enzyklopädie. https://en.wikipedia.org/wiki/Authenticated_Received_Chain

[2] InfraForge. „Why DMARC Fails When SPF and DKIM Pass.“ InfraForge AI Blog. https://www.infraforge.ai/blog/why-dmarc-fails-when-spf-and-dkim-pass

[3] Kitterman, S. „RFC 7208 - Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1.“ Internet Engineering Task Force (IETF). April 2014. https://datatracker.ietf.org/doc/html/rfc7208

[4] Kucherawy, M. und Zwicky, E. „RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC).“ Internet Engineering Task Force (IETF). März 2015. https://datatracker.ietf.org/doc/html/rfc7489