DMARC-Fail: Warum er auftritt und wie du ihn behebst

Irgendwo in deinen Testergebnissen oder in den Headern deines Posteingangs steht das Urteil dmarc=fail, und das Verwirrende daran ist, dass es selten das bedeutet, wonach es klingt. Die meisten DMARC-Fails sind keine Fälschung. Sie sind legitime E-Mails, die als die falsche Domain authentifiziert wurden: SPF bürgt für deinen ESP (deine E-Mail-Versandplattform) statt für dich, DKIM ist mit einem geteilten Schlüssel signiert, oder eine Weiterleitung schreibt gerade genug um, um beide Prüfungen auf einmal zu brechen.

Die direkte Antwort zuerst: DMARC schlägt fehl, wenn eine Nachricht nicht mindestens eine Authentifizierungsprüfung vorweisen kann, die sowohl besteht als auch zur Domain in deinem From-Header passt. Alles Weitere in diesem Leitfaden ist Diagnose und Reparatur: woraus das Urteil besteht, die sieben Ursachen, die mir in den Ergebnissen des Spam-Tests immer wieder begegnen, die Lösung für jede einzelne und wie du deine Policy verschärfst, sobald die Fails aufhören.

Mit einem Fail bist du außerdem in der Mehrheit. Über alle Unspam-Checks hinweg bestehen 90 % der Absender SPF und 88 % DKIM, aber nur 55 % bestehen DMARC. DMARC ist mit Abstand das schwächste Glied der Authentifizierungskette, und die Ursachen unten sind die Gründe für diese Lücke.

Was dmarc=fail wirklich bedeutet

DMARC untersucht weder Inhalte noch Links noch Versandvolumen. Es stellt genau zwei Fragen zu einer Nachricht, die vorgibt, von yourbrand.com zu stammen:

1. Hat SPF bestanden, und passt die Domain, für die es bestanden hat, zur From-Domain (das sogenannte Alignment)? SPF validiert den Envelope-Absender (die Return-Path-Adresse aus der SMTP-Sitzung), den der Leser nie sieht. Alignment bedeutet, dass diese verborgene Domain und deine sichtbare From-Domain zusammenpassen.
2. Hat DKIM bestanden, und passt die signierende Domain (der d=-Tag in der Signatur) zur From-Domain?

Ein bestandener Check mit Alignment genügt. SPF kann komplett scheitern, und DMARC besteht trotzdem, wenn eine DKIM-Signatur mit Alignment verifiziert, und umgekehrt. Dieses einzelne ODER ist der praktischste Fakt in diesem ganzen Thema, und es ist auch der Grund, warum so viele Fails Verwirrung stiften: Beide Checks können einzeln bestehen, während DMARC scheitert, weil keiner für deine Domain bestanden hat.

DMARC fragt nie „Hat die Authentifizierung bestanden?“ Es fragt „Hat die Authentifizierung für die Domain bestanden, die der Leser tatsächlich sieht?“

Standardmäßig ist das Alignment relaxed (locker): Jede Subdomain derselben Organisationsdomain zählt, sodass Post, die mail.yourbrand.com signiert hat, zu einem From von yourbrand.com passt. Dein Eintrag kann striktes Alignment verlangen (adkim=s, aspf=s), also eine exakte Übereinstimmung, was eine bewusste Härtung ist und ein häufiger selbstverschuldeter Fail, wie wir noch sehen werden. Einen tieferen Vergleich der beiden zugrunde liegenden Checks findest du unter DMARC vs. DKIM.

Finde zuerst heraus, warum es bei dir fehlschlägt

Repariere nicht blind. Jedes DMARC-Urteil kommt mit angehängten Beweisen, an drei Stellen.

Führe einen Test vor dem Versand durch. Der kostenlose Spam-Test von Unspam authentifiziert genau die Nachricht, die du gleich versenden willst, und zeigt die Ergebnisse für SPF, DKIM und DMARC nebeneinander, inklusive der Domains, die jeder Check ausgewertet hat, neben den SpamAssassin-, Blacklist- und Inhaltsprüfungen. Das ist der einzige Weg, der den Fail abfängt, bevor ein Abonnent ihn sieht.

Lies den Authentication-Results-Header. Bei jeder zugestellten Nachricht schreibt der empfangende Server sein Urteil in die Header. In Gmail öffnest du eine Nachricht und wählst „Original anzeigen“; die Zusammenfassung oben und die rohe Authentication-Results-Zeile erzählen die ganze Geschichte:

Dieses Beispiel ist der mit Abstand häufigste Fail in der Praxis. Beide Checks bestehen, und DMARC scheitert trotzdem, weil bounce.esp-mail.com und esp-mail.com nicht zu yourbrand.com passen. Der Header liefert dir die Diagnose frei Haus: Die Domains hinter smtp.mailfrom= und header.d= sind die, die den Pass geholt haben, und keine davon ist deine.

Lies deine aggregierten Berichte. Wenn dein DMARC-Eintrag eine rua-Adresse enthält, mailen dir Empfänger täglich XML-Zusammenfassungen jeder Quelle, die Post als deine Domain versendet hat: die IPs, die Volumen und wie jede sich authentifiziert hat. Berichte sind der einzige Weg, Fails bei Post zu sehen, die nie über deinen Schreibtisch ging, einschließlich weitergeleiteter Kopien und Spoofing-Versuche.

Bevor du irgendetwas anderes anfasst, richte außerdem den kostenlosen DMARC-Check auf deine Domain, um zu bestätigen, dass der Eintrag selbst vorhanden und syntaktisch sauber ist.

Die sieben Gründe für einen DMARC-Fail, und die Lösung für jeden

Fast jeder dmarc=fail geht auf einen dieser Gründe zurück. Sie sind danach sortiert, wie oft ich sie sehe, arbeite also von oben nach unten.

1. Dein ESP authentifiziert sich als er selbst, nicht als du

Ab Werk nutzen die meisten Versandplattformen ihre eigenen Infrastruktur-Domains: Der Envelope-Absender ist etwas wie bounce.esp-mail.com, damit sie deine Bounces verarbeiten können, und die DKIM-Signatur nutzt ihren geteilten Schlüssel mit ihrer Domain im d=. Beide Checks bestehen, für sie. Deine From-Domain bekommt keinen Pass mit Alignment, und DMARC schlägt fehl, wie im Header oben gezeigt.

Die Lösung ist die Einstellung, die jede seriöse Plattform unter einem Namen wie „Custom Domain Authentication“, „Domain-Verifizierung“ oder „Branded Sending“ anbietet: Du veröffentlichst ein paar CNAME-Einträge, die sie dir gibt, und ab dann werden Nachrichten als yourbrand.com DKIM-signiert (oder als Subdomain, die im Relaxed-Modus zählt) und nutzen eine eigene Bounce-Domain wie bounce.yourbrand.com für das SPF-Alignment. Fang mit DKIM an; eine DKIM-Signatur mit Alignment allein dreht DMARC auf Pass, selbst solange die SPF-Seite noch auf den ESP zeigt.

2. Eine Weiterleitung hat SPF gebrochen

Wenn jemand deine E-Mail automatisch weiterleitet (eine Uni-Adresse, die an Gmail weiterleitet, eine alte Domain, die auf eine neue zeigt), stellt der weiterleitende Server sie von seiner IP zu, die nicht in deinem SPF-Eintrag steht, also scheitert SPF. Weiterleiter, die das „reparieren“, indem sie den Envelope-Absender auf ihre eigene Domain umschreiben, lassen SPF wieder bestehen, aber für ihre Domain, was stattdessen das Alignment bricht. So oder so ist die SPF-Spur bei weitergeleiteter Post tot, dauerhaft und konstruktionsbedingt.

Die Lösung ist, dich nicht länger allein auf SPF zu verlassen. Eine DKIM-Signatur reist im Inneren der Nachricht und verifiziert unabhängig davon, welcher Server sie weitergereicht hat; eine saubere Weiterleitung behält also einen dkim=pass mit Alignment, und DMARC besteht weiterhin. Wenn deine aggregierten Berichte einen Rest von reinen SPF-Fails aus den IP-Bereichen der Mailbox-Provider selbst zeigen, ist das Weiterleitung, es ist normal, und es ist genau der Grund, warum du eine durchsetzende DMARC-Policy nie allein auf SPF-Alignment stützen solltest.

3. Eine Mailingliste hat die Nachricht umgeschrieben

Diskussionslisten sind der härtere Cousin der Weiterleitung: Sie ergänzen typischerweise einen Betreff-Tag wie [members], hängen einen Abmelde-Footer an und versenden neu von der Adresse der Liste. Die Änderungen an Footer und Betreff verändern den signierten Inhalt, also verifiziert deine DKIM-Signatur nicht mehr. Der Envelope der Liste bricht das SPF-Alignment. Beide Spuren scheitern bei Post, deren Zustellung alle Beteiligten wollten.

Die Lösung liegt größtenteils außerhalb deiner Hände, und Ehrlichkeit schlägt hier jedes Herumreden. Moderne Listen entschärfen das selbst, entweder indem sie den From-Header auf die Domain der Liste umschreiben (und deine Domain damit aus der DMARC-Gleichung nehmen) oder indem sie ein ARC-Siegel anbringen, mit dem Empfänger für die ursprünglichen Authentifizierungsergebnisse bürgen können. Auf deiner Seite: Sorge dafür, dass DKIM mit Alignment signiert, damit einfache Weiterleitungen überleben, und rechne mit einem kleinen, harmlosen Rest von Listen-Fails in deinen Berichten. Wenn du die Liste selbst betreibst, aktiviere ihre Optionen zur DMARC-Entschärfung.

4. Striktes Alignment, wo relaxed nötig wäre

Wenn dein Eintrag adkim=s oder aspf=s setzt, zählt nur eine exakte Domain-Übereinstimmung: Post, die mail.yourbrand.com per DKIM signiert hat, besteht mit einem From von yourbrand.com das relaxed Alignment, scheitert aber am strikten. Teams aktivieren den strikten Modus als Härtungsmaßnahme, vergessen, dass ihre Newsletter-Plattform mit einer delegierten Subdomain signiert, und fabrizieren so ihre eigenen Fails.

Die Lösung: Prüfe, ob dein Eintrag adkim=s oder aspf=s enthält (der DMARC-Check zeigt dir alle Tags). Wenn die Domains, die legitim für dich versenden, irgendeine Subdomain umfassen, geh entweder auf relaxed zurück (lösche den Tag; relaxed ist der Standard) oder konfiguriere den Absender so um, dass er mit der exakten From-Domain signiert. Striktes Alignment lohnt sich erst, wenn deine Berichte einen langen, sauberen Lauf zeigen, in dem jede Quelle exakt übereinstimmt.

5. SPF-Permerror: das Limit von zehn Lookups

SPF-Einträge werden mit einem harten Budget ausgewertet: Mechanismen, die DNS-Lookups auslösen (include, a, mx, redirect, exists), dürfen insgesamt zehn nicht überschreiten, rekursiv gezählt durch jedes verschachtelte Include. Staple genug Tools (ein ESP, ein CRM, ein Helpdesk, ein altes Include, an das sich niemand erinnert), und die Auswertung bricht mit permerror ab. Ein Permerror kann nie zu einem Pass mit Alignment werden, also bleibt die SPF-Spur dunkel, bei jedem Empfänger, bei jeder Nachricht.

Die Lösung: Schick deine Domain durch den SPF-Check, der die Lookups für dich zählt. Entferne Includes für Dienste, die du nicht mehr nutzt, und überlege, den Rest zu konsolidieren oder per Flattening zusammenzufassen. Wenn du schon dabei bist, stell sicher, dass der Eintrag auf ~all oder -all endet; ein +all sagt der Welt, dass jeder als du senden darf, was den Sinn des gesamten Authentifizierungs-Stacks zunichtemacht.

6. Der DMARC-Eintrag selbst ist kaputt

Ein überraschender Anteil der Fails passiert, bevor überhaupt eine Nachricht ausgewertet wird, nämlich im DNS-Eintrag:

• Zwei DMARC-Einträge. Zusammengelegte Domains, oder zwei Teams, die je einen anlegen, hinterlassen mehrere TXT-Einträge auf _dmarc. Der Standard ist unerbittlich: Empfänger, die mehr als einen Eintrag finden, wenden keinen davon an.
• Falscher Host. Der Eintrag muss auf _dmarc.yourbrand.com liegen, nicht auf der Root-Domain und nicht auf dmarc. ohne den Unterstrich.
• Syntax-Ausrutscher. Der Eintrag muss mit v=DMARC1 beginnen, Tags werden durch Semikolons getrennt, und rua-Adressen brauchen das Präfix mailto:. Ein Tippfehler wie p=non macht die Policy ungültig.

Die Lösung: Füge deine Domain in den DMARC-Check ein und behebe, was er markiert. Wenn du den String lieber nicht von Hand zusammensetzen willst, baut dir der kostenlose DMARC-Record-Generator einen gültigen aus Dropdown-Auswahlen.

7. Jemand spooft deine Domain tatsächlich

Sind die sechs Fehlkonfigurationen ausgeschlossen, ist das, was in deinen aggregierten Berichten übrig bleibt (unbekannte IPs, oft geografisch unplausibel, die beide Checks nicht bestehen, bei Volumen, das du nie versendet hast), DMARC bei der Arbeit: Es fängt Fälschungen. Das ist der Fail, den du willst.

Die Lösung besteht darin, der falschen zu widerstehen: Lockere deine Policy nicht, weil die Berichte beängstigend aussehen. Bestätige, dass die Quellen nicht deine sind (Schatten-IT ist real; die unbekannte IP ist manchmal das Abrechnungssystem, das jemand 2019 angebunden hat), und lass dann deine p=quarantine- oder p=reject-Policy die Fälschungen schlucken. Dieser Schutz ist der Grund, warum Absender-Reputation und DMARC-Durchsetzung Hand in Hand gehen.

„No DMARC record found“: die Lösung in fünf Minuten

Tools und Postmaster-Seiten melden das, wenn es überhaupt keinen TXT-Eintrag auf _dmarc.yourdomain.com gibt. Das ist kein Fail einer einzelnen Nachricht, aber seit 2024 keine kosmetische Lücke mehr: Gmail und Yahoo verlangen von Versendern von Massen-E-Mails (Google zieht die Grenze bei rund 5.000 Nachrichten pro Tag an Gmail) inzwischen mindestens eine minimale DMARC-Policy, mit SPF oder DKIM im Alignment zur From-Domain, und Microsoft wendet dieselbe Anforderung seit Mai 2025 auf die Consumer-Domains von Outlook an. Kein Eintrag bedeutet heute Drosselung, Spam-Ordner oder glatte Ablehnung bei den größten Mailbox-Providern, und das zeigt sich als genau die nicht zugestellte Post, der Leute dann tagelang hinterherjagen.

Der Starter-Eintrag ist eine Zeile, veröffentlicht als TXT auf dem _dmarc-Host:

v=DMARC1; p=none; rua=mailto:dmarc@yourbrand.com

Er erzwingt nichts, erfüllt das Minimum der Mailbox-Provider und beginnt, die aggregierten Berichte zu sammeln, die du für alles Weitere in diesem Leitfaden brauchst. Erzeuge deinen mit dem oben erwähnten Record-Generator, wenn du dir die Syntax abnehmen lassen willst.

Was empfangende Server mit einer durchgefallenen Nachricht machen

Die Konsequenz von dmarc=fail ist das, was dein eigener Eintrag verlangt, angewandt nach Ermessen des Empfängers:

Zwei Fußnoten, die in der Praxis zählen. Erstens dürfen Empfänger deine Policy in beide Richtungen übersteuern; ein pct-Tag erlaubt dir außerdem, Quarantine oder Reject nur auf einen Stichproben-Anteil der durchgefallenen Post anzuwenden, während du Vertrauen aufbaust. Zweitens ist p=none nicht folgenlos: Die Filter von Gmail und Outlook werten Authentifizierungsergebnisse unabhängig von deiner Policy als Reputationssignal, sodass ein Strom mit chronischen DMARC-Fails zunehmend seltener im Posteingang landet, selbst wenn technisch jede Nachricht zugestellt wird.

DMARC-Fails beheben, Schritt für Schritt

Das ist die Reihenfolge, die funktioniert, egal ob du eine einzelne scheiternde Kampagne oder eine ganze Domain aufräumst:

1. Veröffentliche oder repariere den Eintrag, mit p=none und einer rua-Adresse. Verifiziere ihn mit dem DMARC-Check. Durchsetzung kommt zuletzt, nicht zuerst.
2. Inventarisiere deine Absender. Gib den aggregierten Berichten zwei bis vier Wochen und liste dann jeden Dienst auf, der als deine Domain versendet: ESP, Transaktionsmails, CRM, Helpdesk, Abrechnung, den Bürodrucker.
3. Bring zuerst überall DKIM ins Alignment. Aktiviere für jeden legitimen Absender das Signieren mit eigener Domain, damit d= deine Domain ist. DKIM überlebt Weiterleitungen, also ist es das Alignment, das weiter funktioniert, nachdem die Nachricht dein System verlassen hat.
4. Bring SPF als Zweites ins Alignment. Richte eigene Bounce-Domains ein, wo die Plattform sie unterstützt, und bring deinen Eintrag mit dem SPF-Check unter das Limit von zehn Lookups.
5. Verifiziere pro Nachricht, nicht pro Domain. Schick von jeder Plattform eine echte Nachricht durch den Spam-Test und prüfe alle drei Urteile, mit dem DKIM-Check daneben. Einträge können perfekt sein, während ein bestimmter Mail-Strom trotzdem mit dem falschen Schlüssel signiert.
6. Zieh die Policy stufenweise an. Wenn die Berichte zeigen, dass deine legitimen Quellen bestehen, geh auf p=quarantine (optional per pct gesampelt), beobachte, dann p=reject. Dieser letzte Schritt ist der Sinn der ganzen Übung: Er ist es, der tatsächlich verhindert, dass deine Kunden gefälschte Rechnungen mit deinem Namen darauf bekommen.

Prüfe das Urteil, bevor deine Abonnenten es tun

Ein DMARC-Fail, den du erst in einem aggregierten Bericht entdeckst, hat dich bereits eine Kampagne gekostet. Der kostenlose Spam-Test von Unspam zeigt dasselbe Urteil vor dem Versand: SPF, DKIM und DMARC, ausgewertet an deiner konkreten Nachricht, mit den Domains, die jeder Check gesehen hat, neben Spam-Score, Blacklist- und Inhaltsprüfungen, in etwa 30 Sekunden, ohne Registrierung. Steht dort Pass mit Alignment, versende. Steht dort dmarc=fail, weißt du jetzt, welche der sieben Ursachen du beheben musst, und keine davon braucht länger als einen Nachmittag.