dmarc=fail trotz SPF und DKIM pass: Ursachen und Behebung

Authentication-Results: mx.empfaenger.example;
   spf=pass smtp.mailfrom=bounce.versanddienst.example;
   dkim=pass header.d=versanddienst.example header.s=s1;
   dmarc=fail (p=quarantine) header.from=beispiel.at

So sieht der Fall aus, um den es hier geht, als Beispiel mit Beispieldomains. Zwei Prüfungen bestanden, das Ergebnis trotzdem fail. Kein Widerspruch, sondern die Regel: DMARC zählt ein pass nur, wenn die geprüfte Domain zur Domain im From: passt. Hier hat SPF die Umschlagadresse des Versanddienstes geprüft, DKIM die Signatur des Versanddienstes. Mit beispiel.at hat beides nichts zu tun.

Den Grundsatz, dass eine Mail zwei Absender hat, den sichtbaren und den im Umschlag, erklärt DMARC einrichten. Was bei einem gescheiterten DKIM selbst passiert, steht in DKIM-Selector finden. Hier geht es nur um die Fehlersuche, wenn am Ende dmarc=fail steht.

Was DMARC tatsächlich vergleicht#

Drei Angaben aus dem Header, alle in Authentication-Results:

DMARC besteht, wenn mindestens eines gilt: SPF ist pass und smtp.mailfrom passt zu header.from, oder DKIM ist pass und header.d passt zu header.from. „Passt“ heißt im Normalfall, dass beide dieselbe Organisationsdomain haben. bounce.beispiel.at passt zu beispiel.at, beispiel-newsletter.at nicht. RFC 9989 nennt das „relaxed alignment“, und das ist die Vorgabe, solange im DMARC-Eintrag nichts anderes steht.

Steht dort aspf=s oder adkim=s, verlangt die Domain eine exakte Übereinstimmung. Dann scheitert auch bounce.beispiel.at gegen beispiel.at. Wer den Tag nicht bewusst gesetzt hat, sollte ihn entfernen.

Fehlersuche in fünf Schritten#

1. Den Header der betroffenen Mail holen. Am besten von einer Mail, die beim Empfänger tatsächlich durchgefallen ist, oder eine Testmail an ein Gmail- oder Outlook-Postfach schicken und dort den Originalheader öffnen. Wie das geht und welche Zeile vom eigenen Empfangsserver stammt, steht in E-Mail-Header lesen.

2. Die drei Domains nebeneinanderlegen. header.from, smtp.mailfrom und jedes header.d aus der Authentication-Results-Zeile des Empfängers abschreiben, nicht aus den eigenen Kopfzeilen des Absenders.

3. DKIM zuerst. Gibt es ein dkim=pass mit einem header.d, das zur Absenderdomain passt? Dann sollte DMARC bestehen. Tut es das nicht, ist fast immer adkim=s gesetzt und die Signatur gilt für eine Subdomain. Gibt es nur dkim=pass für fremde Domains, fehlt beim Versanddienst die eigene Absenderdomain. Steht dkim=fail, ist die Signatur unterwegs gebrochen oder der Schlüssel fehlt, dann weiter in DKIM-Selector finden.

4. Dann SPF. spf=pass mit passender smtp.mailfrom reicht für DMARC. spf=pass mit fremder Domain reicht nicht, egal wie oft der Dienst im eigenen SPF-Eintrag steht. Steht spf=fail oder softfail bei der eigenen Domain, sendet ein Server, der im SPF-Eintrag fehlt. Steht permerror, ist der Eintrag kaputt, meist zu viele Abfragen oder zwei Einträge, siehe SPF-Eintrag erstellen.

5. Den Weg prüfen. Bestehen beim Absender beide und beim Empfänger keine, lag eine Station dazwischen. Die Received-Zeilen zeigen, ob die Mail über eine Weiterleitung, eine Mailingliste oder ein Sicherheitsgateway lief.

Die häufigsten Ursachen#

Zwei Zeilen brauchen eine Erklärung. Das Kontaktformular ist der häufigste Fall, den man nicht im Header des Newsletters, sondern in der eigenen Inbox sieht: Der Server der Website schickt eine Mail mit From: kundin@web.de an das eigene Postfach. Der Webserver ist kein Server von web.de, also besteht für web.de weder SPF noch DKIM. Der eigene Empfangsserver sieht eine gefälschte web.de-Mail, und web.de verlangt in seinem DMARC-Eintrag p=quarantine, GMX ebenso, Yahoo sogar p=reject (abgefragt am 05.10.2026). Die Anfrage landet im Spam-Ordner oder gar nicht.

Microsoft 365 signiert Mails einer eigenen Domain laut Microsoft erst, wenn DKIM für sie eingerichtet ist. Bis dahin hängt DMARC allein an SPF. Das geht gut, bis jemand die Mail weiterleitet. Dann kommt sie von einem fremden Server, SPF scheitert, und ohne Signatur bleibt nichts.

Weiterleitungen und Mailinglisten#

RFC 9989 widmet dem Problem einen eigenen Abschnitt und rechnet es offen vor. Eine Bank schickt an jones@alumni.example.edu, eine Adresse, die automatisch weiterleitet. Beim Endempfänger kommt die Mail von einem Server der Universität, nicht der Bank. SPF scheitert, solange die Weiterleitung die Umschlagadresse nicht umschreibt. DKIM bleibt dagegen „im Allgemeinen gültig“. Daraus folgt die schärfste Regel des Standards: Wer p=reject veröffentlicht, darf sich nicht allein auf SPF verlassen und muss jede Mail mit DKIM signieren.

Mailinglisten ändern Mails, hängen eine Fußzeile an oder setzen den Listennamen in den Betreff, und brechen damit DKIM. Laut RFC 9989 haben die Programme für Mailinglisten in den zehn Jahren seit den ersten p=reject-Richtlinien großer Anbieter alle einen Ausweg eingebaut: Sie setzen ihre eigene Adresse ins From: oder schreiben die Adresse des Autors um. ARC, ein Verfahren, das den Prüfstand einer Zwischenstation mitreicht, sollte das Problem technisch lösen. Laut RFC 9989 hat sich bisher keines dieser Verfahren breit durchgesetzt.

Für die eigene Domain heißt das: Bei Mitarbeitenden, die in Fachlisten und Verbandsverteilern schreiben, ist p=quarantine oft die bessere Endstufe als reject. Warum, steht in DMARC-Policy: none, quarantine oder reject.

Eigene Auswertung: 600 Mails im Posteingang#

In eigener Sache: Für den Beitrag über das Header-Lesen habe ich die Kopfzeilen der letzten 600 Mails aus meinem eigenen Posteingang gelesen, eingegangen zwischen 20.09. und 03.10.2026, nur lesend abgeholt. Am 05.10.2026 habe ich dieselben Daten noch einmal ausgewertet, diesmal mit der Frage: Woran hing jedes dmarc=pass? Gezählt ist die Authentication-Results-Zeile meines Empfangsservers, verglichen nach Organisationsdomain.

• 559 Mails haben DMARC bestanden, keine ist mit fail gekommen. 2 Mails trugen keine Prüfzeile meines Servers.
• 411 bestanden doppelt, mit ausgerichtetem SPF und ausgerichtetem DKIM.
• 144 bestanden nur über DKIM. Bei 141 davon stand spf=pass, aber für die Umschlagadresse des Versanddienstes. Das ist der Normalfall bei Newslettern und Plattformen und völlig in Ordnung, solange die Signatur hält. Wird eine dieser Mails weitergeleitet oder über eine Liste verteilt, die den Text ändert, steht dort dmarc=fail.
• 4 bestanden nur über SPF, ohne passende Signatur. Sie überstehen keine einzige Weiterleitung.
• 39 Mails kamen von Domains ohne DMARC-Eintrag (dmarc=none). 21 davon hätten bestanden, wenn es einen gäbe. 18 wären gescheitert, 13 davon mit genau dem Bild vom Anfang: pass, aber für eine fremde Domain.

Ein dmarc=fail kam in diesen zwei Wochen nicht vor, und das überrascht nicht: Was von großen Plattformen kommt, ist meist sauber eingerichtet, und was durchfällt, liegt oft gar nicht im Posteingang. Die Zahl, die zählt, sind die 148 Mails, die auf einem einzigen Bein standen. Absender nenne ich keine.

Was nicht hilft#

Den Dienst ein zweites Mal in den SPF-Eintrag schreiben. SPF prüft die Umschlagadresse. Gehört die dem Dienst, nützt jeder Eintrag in deinem SPF nichts für DMARC.

p=none setzen, damit der Fehler verschwindet. Das fail bleibt, nur die Folge ändert sich. Und gefälschte Mails mit deiner Adresse kommen wieder an, siehe E-Mail-Spoofing.

Den DMARC-Eintrag löschen. Dann steht beim Empfänger dmarc=none. Seit Februar 2024 verlangt Google von Massenversendern einen DMARC-Eintrag, wer ihn löscht, bekommt andere Rückläufer, siehe E-Mail abgelehnt: 550 5.7.1.

Eine dmarc=fail-Mail beim Empfänger auf die Sicherheitsliste setzen lassen. Das verschiebt das Problem auf jeden einzelnen Empfänger.

Häufige Fragen#

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Das Paket E-Mail-Schutz findet über die DMARC-Berichte jeden Versandweg, der durchfällt, richtet beim Dienst die eigene Absenderdomain ein und stellt die Richtlinie danach Stufe für Stufe um. Den Stand der Domain zeigt kostenlos der E-Mail-Check, den Eintrag erzeugt der DMARC-Generator.

Stand 05.10.2026. Quellen an diesem Tag abgerufen, Auswertung am 05.10.2026.