DMARC schlägt fehl, obwohl SPF besteht: das Alignment verstehen

Von Thomas · virtueller CISO · 20. August 2026

Es ist das verwirrendste Symptom, das ein DMARC-Bericht hervorbringen kann: Für dieselbe Gruppe von Nachrichten zeigt die Zeile spf=pass — die SPF-Authentifizierung war erfolgreich — und trotzdem lautet das DMARC-Urteil fail. Auf den ersten Blick ein glatter Widerspruch: Wie kann eine Prüfung zugleich bestehen und scheitern? Viele Remediationen stecken genau an dieser Stelle fest und suchen stundenlang nach einem Fehler in einem SPF-Eintrag, der in Wirklichkeit einwandfrei funktioniert.

Dabei gibt es weder einen Bug noch ein Paradox. SPF und DMARC prüfen schlicht nicht dasselbe. SPF validiert eine technische Domain, die der Empfänger nie zu Gesicht bekommt: die des Umschlags der Nachricht, den berühmten Return-Path. DMARC verlangt dagegen, dass diese validierte Domain mit der Adresse übereinstimmt — „aligned", also ausgerichtet ist —, die der Empfänger tatsächlich im Mailprogramm liest. Ein SPF-Pass für die falsche Domain ist in den Augen von DMARC wertlos. Das ist die ganze Logik des Alignments, und sie erklärt das Symptom in fast allen Fällen.

Dieser Artikel — das Fundament der DMARC-Fehlersuche — entwickelt die Argumentation vom Symptom her: was SPF wirklich validiert, was das Alignment obendrauf verlangt, die drei typischen Situationen, die ein nutzloses spf=pass erzeugen, wie sich das Muster in einem Aggregatbericht erkennen lässt, und schließlich die Korrekturen, die ein dauerhaftes Alignment herstellen. Eine nicht verhandelbare Voraussetzung für jeden Wechsel zu p=reject.

Das Symptom: ein Pass, der nicht zählt

In einem Aggregatbericht beschreibt jede Zeile eine Gruppe von Nachrichten, die ein empfangender Anbieter gesehen hat — und diese Zeile enthält tatsächlich zwei SPF-Urteile, die zwei ganz verschiedene Fragen beantworten. Das erste, das rohe Ergebnis der Authentifizierung, sagt: „Diese Domain hat diese IP zum Versand autorisiert." Das zweite, das von DMARC bewertete Ergebnis, sagt: „Kommt dieser Pass der Domain zugute, die im From: steht?" Das klassische Symptom sieht so aus:

<policy_evaluated>
  <dkim>fail</dkim>
  <spf>fail</spf>
</policy_evaluated>
…
<auth_results>
  <spf>
    <domain>bounces.versand-router.net</domain>
    <result>pass</result>
  </spf>
</auth_results>

Unten besteht SPF — aber für bounces.versand-router.net. Oben zählt DMARC SPF als Fehlschlag, weil die Nachrichten From: beispiel.de anzeigten und versand-router.net mit beispiel.de nicht das Geringste zu tun hat. Der Pass ist völlig real; er kommt nur der falschen Domain zugute. Der gesamte Rest des Artikels steckt in diesem einen Satz.

Was SPF validiert: den Umschlag, nicht die angezeigte Adresse

Eine E-Mail transportiert zwei Absenderidentitäten, und ihre Verwechslung ist die Wurzel des ganzen Problems. Die erste lebt im SMTP-Umschlag: das MAIL FROM, auch Return-Path oder Bounce-Adresse genannt — dorthin schicken die Server die Unzustellbarkeitsmeldungen zurück. Im Mailprogramm bleibt diese Adresse unsichtbar. Die zweite ist der From:-Header, den der Empfänger liest. Nichts in den Standards zwingt beide zur Übereinstimmung; im industrialisierten Versand stimmen die beiden selten überein.

SPF betrachtet ausschließlich die erste. Der empfangende Server nimmt die Domain des MAIL FROM, fragt deren SPF-TXT-Eintrag ab und prüft, ob die verbindende IP-Adresse dort autorisiert ist. Wenn ja: spf=pass. Zu keinem Zeitpunkt zieht SPF die angezeigte Adresse heran. Das ist kein Konstruktionsversehen: SPF ist älter als DMARC und zielte auf die Fälschung des Umschlags, nicht auf die visuelle Täuschung. Die Konsequenz ist brutal: Ein Betrüger, der von einer voll kontrollierten eigenen Domain versendet — eigener Umschlag, tadelloser SPF-Eintrag — und dabei From: beispiel.de anzeigt, erhält ein unbestrittenes spf=pass. Die Authentifizierung gelingt, die Täuschung ebenfalls. Die Rollenverteilung der drei Mechanismen ist in SPF, DKIM und DMARC erklärt dargelegt.

Das Alignment: die Anforderung, die DMARC hinzufügt

DMARC schließt genau diese Lücke, und das Grundprinzip von DMARC läuft auf genau das hinaus: die technische Authentifizierung an die Adresse zu binden, die ein Mensch tatsächlich sieht. Das DMARC-Urteil ist nur dann ein Pass, wenn mindestens einer der beiden Mechanismen besteht und die von ihm validierte Domain mit der From:-Domain ausgerichtet ist. Bei SPF wird die Domain des MAIL FROM verglichen; bei DKIM das d= der Signatur.

Das Alignment gibt es in zwei Modi, gesteuert durch zwei Tags im DMARC-Eintrag. Im relaxed-Modus (aspf=r, adkim=r — die Standardwerte, selten ausgeschrieben) genügt es, dass beide Seiten dieselbe organisatorische Domain teilen: bounce.beispiel.de ist mit beispiel.de ausgerichtet. Seit DMARCbis wird diese organisatorische Domain über den DNS Tree Walk bestimmt — das Hinaufklettern im DNS-Baum — und nicht mehr über die Public Suffix List. Im strict-Modus (aspf=s, adkim=s) muss die Übereinstimmung exakt sein: bounce.beispiel.de ist dann nicht mehr mit beispiel.de ausgerichtet.

Ein typischer Eintrag ist also nichts Exotisches:

v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de

Die relaxed-Modi gelten implizit. Und ein Kernpunkt, der sehr oft übersehen wird: DMARC verlangt nicht, dass beide Mechanismen ausgerichtet sind. Einer genügt. Ein nicht ausgerichtetes SPF neben einem ausgerichteten DKIM ergibt dmarc=pass — und genau das ist, wie die Korrekturen zeigen werden, der Schlüssel zu den meisten Remediationen.

Drei typische Fälle hinter dem Symptom

Ein nicht ausgerichtetes spf=pass entsteht fast nie zufällig. Drei Konfigurationen versammeln den Großteil dessen, was in den Aggregatberichten zu sehen ist.

Fall 1: die Versandplattform, die SPF mit der eigenen Domain besteht. Der große Klassiker. Eine E-Mail-Plattform — Mailchimp, Brevo, SendGrid, Mailjet — verschickt den Newsletter von beispiel.de standardmäßig mit einem Umschlag auf der eigenen Domain: MAIL FROM bounces.versand-router.net. Die Plattform pflegt ihr SPF, die IP ist autorisiert, spf=pass — für versand-router.net. Das From: zeigt beispiel.de: Kein Alignment ist möglich, die beiden Domains sind einander fremd. Trägt die Standard-DKIM-Signatur obendrein d=versand-router.net, ist der Fehlschlag komplett: Alles ist authentifiziert, nur nichts im Namen der richtigen Domain.

Fall 2: die Weiterleitung, die den Umschlag umschreibt. Eine beim Versand tadellos ausgerichtete Nachricht geht an eine Adresse, die weiterleitet — der Alias eines früheren Mitarbeiters, ein Uni-Postfach mit Umleitung auf ein privates Konto. Der weiterleitende Server versendet plötzlich von einer IP, die im SPF des ursprünglichen Absenders fehlt; um eine Abweisung zu vermeiden, schreiben viele den Umschlag auf den eigenen Namen um (der SRS-Mechanismus). Das Ergebnis: spf=pass, aber für die Domain des Weiterleiters — wieder nicht ausgerichtet. Die vollständige Mechanik steht in warum Weiterleitungen die Prüfung brechen. Die rettende Nuance: Die DKIM-Signatur reist mit der Nachricht und überlebt, solange der Inhalt unverändert bleibt — daher das Gewicht von „einer genügt".

Fall 3: die falsch ausgerichtete Subdomain. Die Organisation versendet mit MAIL FROM auf newsletter.beispiel.de und From: auf beispiel.de. Im relaxed-Modus ist alles in Ordnung: dieselbe organisatorische Domain. Erzwingt der Eintrag jedoch aspf=s, wird der Pass über Nacht zum nicht ausgerichteten. Die tückischere Variante: eine separate „technische" Domain, beispiel-mailing.de, vor Jahren gewählt, „um den Versand zu isolieren". Diese Domain wird sich nie mit beispiel.de ausrichten, auch nicht im relaxed-Modus: Es handelt sich um zwei verschiedene organisatorische Domains.

Den nicht ausgerichteten Pass im Aggregatbericht erkennen

Die Berichtstheorie muss an dieser Stelle nicht wiederholt werden — die Lektüre der DMARC-Aggregatberichte behandelt sie Feld für Feld. Für dieses konkrete Symptom genügt ein einziger Reflex: die Domain des header_from mit der Domain vergleichen, die am SPF-Ergebnis hängt. Lautet das Ergebnis pass, unterscheiden sich aber die beiden Domains — und teilen keine gemeinsame organisatorische Domain —, dann beschreibt die Zeile einen nicht ausgerichteten Pass, der auf DMARC-Seite als Fehlschlag zählt.

Die Lektüre lohnt sich pro Quelle. Eine Plattform-IP, die ausschließlich nicht ausgerichtete Passes zeigt, signalisiert eine nie angepasste Standardkonfiguration (Fall 1). Verstreute Zeilen mit kleinem Volumen, deren SPF-Domains zu Zugangsanbietern oder Universitäten gehören, verraten Weiterleitungen (Fall 2). Und ein plötzliches Kippen eines ganzen Flusses von ausgerichtet zu nicht ausgerichtet begleitet häufig eine Änderung des aspf-Tags oder eine Plattformmigration (Fall 3). Das Symptom ist in allen drei Fällen identisch; das Heilmittel hängt von der Diagnose ab.

Die Korrekturen: eigene Return-Path-Domain und ausgerichtetes DKIM

Die eigene Return-Path-Domain. Für den Plattformfall trägt die Korrektur bei jedem seriösen Anbieter einen Namen: Custom Return-Path, Bounce-Domain, Umschlagdomain. Das Prinzip: eine dedizierte Subdomain anlegen — bounce.beispiel.de — und per CNAME auf die Infrastruktur der Plattform zeigen lassen. Der Umschlag der Sendungen wird zu MAIL FROM bounce.beispiel.de: Das SPF der Plattform lässt die IP weiterhin passieren, doch der Pass kommt nun einer Subdomain von beispiel.de zugute — ausgerichtet im relaxed-Modus. Ein paar DNS-Einträge, keinerlei Änderung am Inhalt der Nachrichten.

Die ausgerichtete DKIM-Signatur. Die robusteste Korrektur liegt woanders: die Nachrichten mit d=beispiel.de signieren lassen, über die Schlüssel oder CNAMEs, die die Plattform bei der Einrichtung der Domain bereitstellt. Ein ausgerichtetes DKIM macht das DMARC-Urteil vom Schicksal des Umschlags unabhängig: Es überlebt Weiterleitungen, hängt an keiner SRS-Umschreibung und genügt allein, um dmarc=pass zu produzieren. Deshalb passt die Doktrin in eine Zeile: ausgerichtetes DKIM zuerst, ausgerichtetes SPF als Sicherheitsgurt — und beides, wo die Plattform es erlaubt, was heute die Regel ist.

Bleibt der Sonderfall des strict-Modus: Bevor aspf=s oder adkim=s erzwungen wird, ist eine Inventur der Versand-Subdomains unverzichtbar, sonst fabriziert die Verschärfung des Modus selbst die nicht ausgerichteten Passes. Der relaxed-Modus, der Standard, deckt die große Mehrheit der realen Bedürfnisse ab.

Was das Alignment für p=reject bedeutet

Solange die Policy bei p=none bleibt, kostet ein nicht ausgerichteter Pass nichts: Die Nachrichten kommen an, die Berichte sammeln sich, das Symptom bleibt akademisch. Bei p=reject wird dieselbe Zeile zu abgewiesener Post. Jede legitime Quelle, die im Moment der Verschärfung noch nicht ausgerichtet ist, verwandelt sich in einen Zustellbarkeitsvorfall — Rechnungen, die nicht mehr ankommen, HR-Benachrichtigungen, die lautlos abgewiesen werden.

Das Kriterium für den Übergang lässt sich deshalb einfach formulieren: Jede legitime Quelle muss mindestens einen ausgerichteten Pass produzieren, vorzugsweise per DKIM, bevor die Policy verschärft wird. Gewöhnliche Weiterleitungen nehmen diese Hürde dank DKIM; der hartnäckige Fall bleiben Mailinglisten, die den Inhalt verändern — und damit DKIM brechen — und zugleich den Umschlag umschreiben — und damit SPF aus der Ausrichtung bringen. Für den Übergang selbst bietet DMARCbis einen expliziten Testmodus (t=y), den Nachfolger des aus dem Standard entfernten pct-Tags, der eine strenge Policy ankündigt und den Empfängern zugleich eine Erprobungsphase signalisiert.

Fazit

spf=pass und dmarc=fail in derselben Zeile sind weder ein Bug noch ein Widerspruch: SPF hat die Domain des Umschlags validiert, und DMARC stellt fest, dass diese Domain nicht zum angezeigten From: passt. Der Pass existiert, aber er kommt der falschen Domain zugute. Drei Konfigurationen erzeugen den Großteil des Symptoms — die Plattform auf ihrem Standard-Umschlag, die Weiterleitung, die das MAIL FROM umschreibt, die schlecht ausgerichtete Subdomain oder Schwesterdomain — und zwei Korrekturen schaffen Abhilfe: die eigene Return-Path-Domain, die SPF wieder ausrichtet, und die DKIM-Signatur unter dem d= der eigenen Domain, die das Urteil selbst durch Weiterleitungen hindurch robust hält. Ein einziger ausgerichteter Mechanismus genügt DMARC; beide zu haben ist die Sicherheitsmarge, die p=reject zu einem gelassenen Schritt macht.

Für die Diagnose muss keine einzige XML-Datei geöffnet werden: Eine kostenlose DMARC-Analyse der Domain zeigt Quelle für Quelle, welche Passes nicht der richtigen Domain zugutekommen und wie es um die Ausrichtung wirklich steht. Die Einrichtung eines Kontos erlaubt anschließend, Bericht für Bericht zu verfolgen, wie jede Quelle in die Ausrichtung findet — bis zu dem Tag, an dem der Wechsel zu p=reject kein Wagnis mehr ist, sondern eine Formalität.