Debugging von DMARC-Fehlern: ein praktischer Leitfaden

TL;DR: Die meisten DMARC-Fehler beruhen auf einem Ausrichtungsproblem. SPF oder DKIM können zwar bestanden werden, aber die authentifizierte Domain stimmt nicht mit dem From-Header überein. Beheben Sie die Ausrichtung, indem Sie Drittanbieterdienste so konfigurieren, dass sie Ihre Domain im Return-Path und in den DKIM-Signaturen verwenden, überprüfen Sie die DNS-Syntax und nutzen Sie ARC für das Handling von Weiterleitungen. Starten Sie mit p=none, überwachen Sie die Reports wöchentlich und führen Sie erst eine Durchsetzung ein, wenn die Erfolgsrate bei über 95 % liegt.

Wichtigste Erkenntnisse

• Ausrichtung ≠ Authentifizierung: SPF und DKIM können bestehen, trotzdem kann DMARC fehlschlagen, wenn die authentifizierte Domain nicht mit der Domain im From-Header übereinstimmt
• Nur eine muss übereinstimmen: DMARC besteht, wenn entweder SPF oder DKIM ausgerichtet ist. Beides ist nicht erforderlich.
• Drittanbieter-Sender sind meist die Ursache: Marketing-Plattformen, CRMs und Support-Tools senden oft mit eigenen Domains, wodurch die Ausrichtung unterbrochen wird
• Verwenden Sie die entspannte Ausrichtung (Standard), sofern keine strengen Sicherheitsanforderungen vorliegen. Dies erlaubt, dass Subdomains zur Hauptdomain ausgerichtet werden.
• Starten Sie mit p=none: Sammeln Sie mindestens 2 Wochen lang Berichte, bevor Sie auf quarantine oder reject umstellen
• Erreichen Sie mindestens einen Monat lang eine Erfolgsrate von 95 %, ehe p=reject erzwungen wird
• Wöchentlich aggregierte Reports prüfen: Ein plötzlicher Rückgang der Erfolgsrate zeigt eine Änderung an
• ARC bewahrt Authentifizierung bei Weiterleitungen: Er ersetzt SPF/DKIM nicht, hilft aber bei weitergeleiteten E-Mails
• SPF hat ein Limit von 10 DNS-Lookups: Wird dies überschritten, gibt es sporadische Fehler. Reduzieren Sie nötigenfalls Includes auf einzelne IPs.

DMARC-Authentifizierungsfehler blockieren legitime Mails, schaden Ihrem Absenderruf und hinterlassen Sicherheitslücken, die Angreifer gezielt ausnutzen. Ein einziger nicht ausgerichteter DNS-Eintrag kann Hunderte geschäftskritische Nachrichten in Spam-Ordner schicken. Wenn SPF und DKIM korrekt durchlaufen, aber DMARC trotzdem fehlschlägt, verbringen IT-Teams Stunden mit der Analyse von XML-Berichten, DNS-Fehlersuche und Absprachen mit Dienstleistern, um die Ursache zu finden.

Die gute Nachricht: Die meisten DMARC-Fehler sind auf einige wenige, lösbare Konfigurationsfehler zurückzuführen. Abweichungen bei der Ausrichtung, DNS-Syntaxfehler und Probleme bei Drittanbietersendern machen den Hauptanteil an Authentifizierungsproblemen aus. Wer versteht, wie man die jeweilige Fehlerart analysiert, kann aus diffusen „DMARC funktioniert nicht“-Problemen konkrete und gezielte Lösungen machen.

Sicherheitsteams, die für E-Mail-Authentifizierung verantwortlich sind, brauchen systematische Debugging-Methoden, die Ursachen rasch aufdecken – egal ob das Problem von internen DNS-Einträgen, Marketingplattformen Dritter oder von Weiterleitungseinstellungen stammt. Dieser Leitfaden behandelt die praktischen Schritte beim Debugging, damit E-Mails zuverlässig authentifiziert und zugestellt werden.

• Was sind DMARC-Fehler?
• Lösungen für SPF- und DKIM-Ausrichtung
• DMARC-Reports interpretieren
• Korrektur von DNS-Fehlern
• Umgang mit Weiterleitungen und Drittanbieter-Sendern
• ARC einsetzen für bessere Ergebnisse
• Weniger DMARC-Fehler: Best Practices
• Laufendes Monitoring und Optimierung
• FAQ zum Debugging von DMARC-Fehlern

DMARC-Fehler entstehen, wenn E-Mails die Ausrichtungsprüfung nicht bestehen, auch wenn SPF oder DKIM einzeln erfolgreich sind. DMARC verlangt, dass entweder SPF oder DKIM mit der Domain im From-Header übereinstimmt. Ausrichtung bedeutet, dass die authentifizierte Domain mit der sichtbaren Absenderdomain, die der Nutzer sieht, übereinstimmt.

Typisches Beispiel für Ausrichtungsfehler:

Marketing-Newsletter landen im Spam, obwohl SPF für mailserver.vendor.com besteht und gültige DKIM-Signaturen vorhanden sind. Im From-Header steht marketing@company.com, aber die Authentifizierung bezieht sich auf Domains von vendor.com – es entsteht ein Ausrichtungsfehler.

Lösung: Konfigurieren Sie Ihre Marketingplattform so, dass sowohl im Return-Path als auch im DKIM-Signatur-d= Parameter company.com verwendet wird. Nach der Ausrichtung besteht DMARC und die Zustellung normalisiert sich wieder.

Eine E-Mail von marketing@company.com, die durch mailserver.vendor.com authentifiziert ist, scheitert am DMARC, weil die Domains nicht übereinstimmen. Der SPF-Check kann zwar für die Vendor-Domain erfolgreich sein, DMARC verlangt aber die Ausrichtung auf company.com.

Authentifizierungsfehler werden in aggregierten Reports als nicht bestandene SPF- oder DKIM-Ausrichtung (oder beides) ausgewiesen. Empfangende Mailserver senden täglich XML-Berichte an die in Ihrem DMARC-Eintrag hinterlegte Adresse.

SPF-Ausrichtungsfehler beruhen meist auf Return-Path-Domain-Abweichungen. Wenn E-Mails von Drittanbieterdiensten stammen, wird der Return-Path häufig mit der Domain des Anbieters statt Ihrer eigenen gesetzt. Der SPF- und DKIM-Leitfaden erklärt, wie diese Protokolle die Absenderidentität authentifizieren.

DMARC-Aggregatberichte kommen als komprimierte XML-Dateien per täglicher E-Mail [4]. Jeder Bericht enthält nach Versandquelle gruppierte Authentifizierungsergebnisse und zeigt Anzahl der SPF- und DKIM-Ausrichtungstreffer/-fehler.

Die Quell-IP-Adresse identifiziert jede sendende Instanz. Vergleichen Sie IPs mit bekannten internen Mailservern, Drittanbieter-Marketingplattformen und SaaS-Anwendungen. Unbekannte IPs müssen geprüft werden, ob sie zu legitimen Diensten oder unautorisierten Absendern gehören.

So sieht ein einzelner Datensatz im Aggregatbericht tatsächlich aus:

<record>
  <row>
    <source_ip>192.0.2.10</source_ip>
    <count>438</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>company.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>company.com</domain><result>pass</result></dkim>
    <spf><domain>mail.vendor.com</domain><result>pass</result></spf>
  </auth_results>
</record>

So lesen Sie das: 438 Nachrichten kamen von einer IP. DKIM authentifizierte für company.com und ist mit dem From-Header ausgerichtet, daher besteht DMARC durch DKIM. SPF authentifizierte für mail.vendor.com, war aber nicht mit company.com ausgerichtet; daher steht unter policy_evaluated beim SPF-Ergebnis fail. Die Nachricht besteht dennoch DMARC, weil nur eine Methode ausgerichtet sein muss. Diese Zeile falsch zu interpretieren, ein SPF-„fail“ zu sehen und anzunehmen, dass die gesamte Nachricht fehlschlug, ist der häufigste Anfängerfehler bei DMARC-Auswertungen.

Wenn SPF und DKIM beide fehlschlagen, prüfen Sie gezielt das jeweilige Ausrichtungsproblem. Fehler bei SPF weisen auf Return-Path-Probleme hin; Fehler bei DKIM auf fehlende oder falsche Signaturen.

Klassifizieren Sie das Debugging: Erst Fehler bei hohem E-Mail-Volumen beheben, dann unbekannte IPs, dann geringvolume Fehler.

DNS-Syntax-Grundlagen:

SPF-Einträge müssen mit v=spf1 beginnen und mit -all oder ~all enden. Die Anweisung -all blockiert unautorisierte Absender, ~all markiert diese als Softfail. Nutzen Sie DMARC-Prüftools zur Syntaxvalidierung, bevor Sie Werte veröffentlichen.

DNS-Validierungskommandos:

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

Profi-Tipp: Die meisten SPF-Fehler gehen auf Lookup-Limits oder Selector-Fehlzuweisungen zurück. Fokussieren Sie Ihr Troubleshooting auf diese zwei Bereiche für eine schnellere Lösung.

E-Mail-Weiterleitungen führen zu SPF-Fehlern, weil weitergeleitete Nachrichten von zwischengeschalteten Mailservern stammen, die nicht in den SPF-Einträgen gelistet sind. Wenn user@company.com E-Mails an personal@gmail.com weiterleitet, sieht Gmail die IP des weiterleitenden Servers, nicht die des ursprünglichen Absenders.

So „zerstört“ eine Weiterleitung die Authentifizierung:

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

Nach Weiterleitung an Privatadresse: Weiterleitende Server-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, weil der Envelope Sender (Return-Path) weiterhin auf die ursprüngliche Domain zeigt, die sendende IP nun aber die des Weiterleitungsdienstes ist. DKIM-Signaturen überstehen Weiterleitungen manchmal, wenn die Nachrichten unangetastet bleiben.

Drittanbieter-Sender – Konfigurationstipps:

• Senden von Subdomains – z.B. news.yourdomain.com statt yourdomain.com
• SPF-Einträge für alle Subdomains veröffentlichen – Subdomains erben nichts von der Hauptdomain
• Individuelle Return-Path-Domains konfigurieren – erhält SPF-Ausrichtung, während Anbieter ihre Infrastruktur verwalten
• Bei Anbieter-Wechseln nachziehen – Service-Provider fügen oft Server ohne Ankündigung hinzu

Authenticated Received Chain (ARC) bewahrt Authentifizierungsergebnisse bei Weiterleitungen und Modifikationen durch Verteilerlisten. Wenn Nachrichten Zwischenstationen durchlaufen, entsteht mit ARC eine Kette von Authentifizierungsergebnissen, die Empfängerserver validieren können [1].

Jede Zwischenstation fügt eigene ARC-Header hinzu und baut so eine überprüfbare Authentifizierungskette auf.

Implementierungsoptionen:

• Google Workspace / Microsoft 365 – Automatische ARC-Header (keine Konfiguration notwendig)
• 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 es Authentifizierungsergebnisse bewahrt, wenn das Weiterleiten ansonsten die DMARC-Übereinstimmung aufheben würde. Empfangende Server, die ARC unterstützen, können die Kette validieren und Nachrichten vertrauen, die ursprünglich die Authentifizierung bestanden haben.

Dokumentieren Sie alle autorisierten Absenderquellen, bevor Sie DMARC-Richtlinien implementieren. Befragen Sie Mitarbeitende zu eingesetzten E-Mail-Tools. Häufige 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 mindestens 2 Wochen bei p=none
2. Weniger als 95 % Authentifizierungsrate bei legitimen Absendern
3. Drittanbieter versenden E-Mails ohne SPF/DKIM-Einrichtung
4. Kein wöchentliches Verfahren zur Überprüfung von Aggregatberichten
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: Schließen Sie diese Lücken, bevor Sie zu restriktiven Richtlinien übergehen.

Beginnen Sie mit p=none und sammeln Sie zwei Wochen lang Berichte. Analysieren Sie diese, um alle Absenderquellen und Authentifizierungsstatus zu identifizieren. Fahren Sie mit p=quarantine bei 25 % mittels pct= Tag fort und erhöhen Sie dann schrittweise auf pct=100, bevor Sie zu p=reject übergehen.

Der DMARC Enforcement Guide beschreibt die Entscheidungspunkte für die Richtlinien-Eskalation. Wechseln Sie erst zu p=reject, wenn Sie mindestens einen Monat lang eine Authentifizierungsrate von über 95 % erreicht haben.

DMARC erfordert fortlaufende Verwaltung, nicht nur eine einmalige Konfiguration. Drittanbieter ändern Versandinfrastruktur, neue Anwendungen versenden E-Mails ohne IT-Freigabe und DNS-Einträge verfallen gelegentlich bei Domainverlängerungen.

Verfolgen Sie die Authentifizierungsraten getrennt nach Absenderquelle. Wenn eine Marketing-Plattform üblicherweise 99 % erreicht und plötzlich auf 85 % fällt, ist sofortiger Handlungsbedarf gegeben.

Aggregatberichte legen Spoofing-Versuche über unautorisierte IPs offen. Forensikberichte (ruf=) enthalten Beispielnachrichten zum Debugging, sie beinhalten jedoch E-Mail-Inhalte – nutzen Sie diese Berichte nur vorübergehend für aktives Debugging.

OnDMARC bietet Echtzeit-Benachrichtigungen bei sinkenden Authentifizierungsraten, erkennt automatisch neue Absenderquellen und überwacht die Richtlinien-Compliance über mehrere Domains hinweg.

[1] Wikipedia-Mitwirkende. „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