Jede E-Mail trägt zwei Absenderadressen. Deine Leser sehen die eine. SPF prüft die andere, und DMARC besteht oder scheitert daran, ob beide zur selben Domain gehören.
Die sichtbare ist der From-Header. Die von SPF geprüfte ist der Umschlagabsender, den der empfangende Server bei der Annahme als Header Return-Path in die Nachricht schreibt. Eine Nachricht kann SPF mit einem Rückweg, der deiner Versandplattform gehört, makellos bestehen und trotzdem an DMARC scheitern, weil die Adresse im From-Header dir gehört und die authentifizierte nicht.
Return-Path ist der Umschlagabsender, nicht die From-Adresse
SMTP hat einen Umschlag und eine Nachricht, und beide tragen eigene Adressen. Der Umschlagabsender wird im Befehl MAIL FROM zu Beginn der Transaktion angegeben, bevor irgendein Header gesendet wird. Der From-Header gehört zur Nachricht und wird von dem geschrieben, was sie verfasst hat.
Der empfangende Server ist es, der das eine in das andere überführt: Bei der Annahme stempelt er den Umschlagabsender ganz oben als Header Return-Path ein. Ein Return-Path in einer empfangenen Nachricht ist also eine Aufzeichnung dessen, was der sendende Server auf der Leitung behauptet hat, vom Empfänger notiert. Der Absender setzt ihn nicht als Header, und ein vom Absender hinzugefügter Return-Path bedeutet nichts.
Drei Adressen werden regelmäßig verwechselt, und jede hat eine andere Aufgabe:
| Feld | Gesetzt von | Wofür |
|---|---|---|
| Return-Path | Dem Empfänger, aus MAIL FROM | SPF, und wohin Bounces gehen |
| From | Dem Verfassenden | Was deine Leser sehen, und was DMARC schützt |
| Reply-To | Dem Verfassenden | Wohin eine Antwort geht |
SPF authentifiziert den Rückweg, und deshalb stoppt SPF allein kein Spoofing
SPF fragt, ob der verbindende Server für eine Domain senden darf, und die dafür verwendete Domain ist die des Umschlagabsenders. RFC 9989 vergleicht RFC5321.MailFrom und nie den HELO-Namen, ein Werkzeug, das SPF-Ausrichtung aus der HELO-Identität meldet, beantwortet also eine andere Frage.
Das ist der ganze Grund, warum SPF für sich genommen nie das Fälschen des Anzeigenamens verhindert hat. Jeder kann eine Nachricht mit MAIL FROM: bounces@a-domain-they-own.example und einem From-Header mit deinem Firmennamen senden. SPF besteht, weil der Absender für die von ihm gewählte Umschlagdomain tatsächlich autorisiert ist. Die Leser sehen deinen Namen im Posteingang. Nichts daran ist ein Mangel von SPF, es ist SPF beim Prüfen genau des Bezeichners, für den es entworfen wurde.
DMARC ist die Schicht, die das schließt, indem sie verlangt, dass der authentifizierte Bezeichner mit dem sichtbaren zusammenhängt.
DMARC braucht die Rückwegdomain in Übereinstimmung mit deiner From-Domain
Die Ausrichtung ist der Vergleich, den DMARC anstellt. Sie fragt nicht, ob SPF bestanden hat. Sie fragt, ob SPF für eine Domain bestanden hat, die zu der im From-Header passt.
Deine Marketingplattform kann SPF jedes Mal auf ihrer eigenen Bounce-Domain bestehen, und dein DMARC-Ergebnis ist auf der SPF-Seite trotzdem ein Fehlschlag, weil die beiden Bezeichner nicht zusammenhängen. DKIM kann die Nachricht retten, wenn die Plattform als deine Domain signiert, und oft ist es das Einzige, was das tut. Über die Domains, die wir für den Unspam 2026 Email Deliverability Benchmark testen, veröffentlichen nur 48 % eine DMARC-Richtlinie, und unter denen, die es tun, ist ein nicht ausgerichteter Rückweg einer der häufigsten Gründe, warum eine Domain ein Jahr lang bei p=none stehen bleibt.
Das sichtbare Symptom, noch bevor ein Bericht eintrifft, ist der Posteingang, der dich verrät. Gmail zeigt eine Nachricht als gesendet „via“ die Domain der Plattform, wenn der Rückweg nicht zur From-Domain passt, und andere Programme drucken Ähnliches. Sagt deine Mail „via“ jemand anderen, ist dein Rückweg nicht ausgerichtet.
Entspannte Ausrichtung ist aus Headern allein nicht entscheidbar
DMARC kennt zwei Ausrichtungsmodi, und der Unterschied zählt beim Lesen der Ausgabe eines Prüfwerkzeugs.
- Strikt heißt, die beiden Domains sind identisch. Das ist aus den Headern vor dir entscheidbar.
- Entspannt, die Voreinstellung, heißt, die beiden teilen eine Organisationsdomain. Das ist aus den Headern nicht entscheidbar, denn wo die organisatorische Grenze liegt, ist eine DNS-Frage.
RFC 9989 hat genau dafür die Public Suffix List durch einen DNS-Baumdurchlauf ersetzt. Beim alten Verfahren konnte ein Werkzeug eine Kopie der Liste mitführen und offline antworten, um den Preis, jedes Mal falsch zu liegen, wenn die Liste sich bewegte. Beim heutigen verlangt die Antwort das Auflösen des Baums, ein Header-Analysator, der ohne Abfragen „ausgerichtet“ meldet, hat also entweder nur den strikten Fall geklärt oder geraten.
Unser E-Mail-Header-Analysator klärt die strikte Ausrichtung aus den Headern und meldet die Beziehung zwischen den beiden Domains: identisch, Subdomain der Autordomain, der Autor ist Subdomain, gemeinsamer Vorfahr, oder nicht verwandt. Die entspannte Ausrichtung wird gesondert mit dem Baumdurchlauf geklärt, denn ein Ergebnis, das nicht gemessen wurde, ist kein Ergebnis.
Diese Unterscheidung ist praktisch, nicht pedantisch. bounces.example.com gegen example.com ist entspannt ausgerichtet und strikt nicht ausgerichtet, was der Normalzustand eines korrekt eingerichteten eigenen Rückwegs ist, und ein Werkzeug, das ihn als Fehler meldet, schickt dich los, etwas zu reparieren, das schon stimmt.
Ein eigener Rückweg ist der Weg, wie eine Plattform SPF-Ausrichtung bekommt
Die übliche Lösung ist eine Subdomain, die du an die Plattform delegierst. Du veröffentlichst ein CNAME auf etwas wie bounces.example.com, das auf die Infrastruktur der Plattform zeigt, die Plattform verwendet diesen Namen als Umschlagabsender, und SPF besteht nun auf einer Domain, die deine Organisationsdomain teilt, also entspannt ausgerichtet ist.
Vier Details entscheiden, ob das funktioniert:
- Es muss eine Subdomain deiner From-Domain sein. Ein CNAME auf einer anderen Domain, die dir ebenfalls gehört, richtet sich mit nichts aus.
- Der maßgebliche SPF-Record ist der auf der Rückwegdomain, nicht der auf deiner From-Domain. Dieser Schritt wird am häufigsten übersprungen, weil Leute den falschen Record prüfen und ein Bestehen sehen.
- Die Plattform muss dafür eingestellt werden. Das DNS zu veröffentlichen ist die Hälfte; die Versandplattform hat eine Einstellung, und eine ungesetzte bedeutet, dass sie weiter ihre eigene Bounce-Domain verwendet.
- Eine Subdomain erbt deine DMARC-Richtlinie über den Baumdurchlauf, sofern du nicht
spveröffentlichst, um etwas anderes zu sagen, sie ist also von deiner Durchsetzung abgedeckt.
Der Leitfaden zu SPF-Records behandelt den Record selbst, und unser Leitfaden zu DMARC-Records behandelt die Richtlinie und ihre Tags.
Bounces gehen an den Rückweg und sonst nirgends
Die andere Aufgabe des Umschlagabsenders ist, die Adresse für Unzustellbarkeitsberichte zu sein. Ein Server, der deine Nachricht nicht zustellen kann, schickt den Fehlschlag an den Rückweg, nicht an deine From-Adresse und nicht an Reply-To.
Deshalb ändert ein eigener Rückweg, wer die Bounces sieht. Delegierst du ihn an eine Plattform, sammelt die Plattform sie ein, und genau das erlaubt ihr, tote Adressen automatisch zu unterdrücken. Zeigt er auf ein unbeobachtetes Postfach auf deiner eigenen Domain, stapeln sich die Berichte dort, wo niemand liest, und so verrottet eine Liste im Stillen.
Deshalb gibt es auch den Rückweg <>, den Nullabsender. Bounce-Nachrichten selbst werden mit leerem Umschlagabsender gesendet, damit ein Bounce nicht bouncen kann, und eine Nachricht mit leerem Rückweg ist ein automatischer Bericht und keine von jemandem geschriebene Mail.
Wie du den Rückweg einer bereits gesendeten Nachricht liest
Die schnellste Prüfung läuft an einer echten Nachricht und nicht im DNS, denn den Rückweg gibt es erst, wenn ein Empfänger ihn notiert hat.
- Schick dir eine Nachricht über die zu prüfende Plattform, an ein Postfach bei einem anderen Anbieter.
- Sieh dir die Originalheader an und such
Return-Path. Gmail nennt das „Original anzeigen“; die meisten Programme haben eine Entsprechung. - Vergleiche dessen Domain mit der From-Domain. Identisch ist strikte Ausrichtung, eine Subdomain deiner From-Domain ist der normale entspannte Fall, eine nicht verwandte Domain heißt, dass SPF zu DMARC überhaupt nichts beitragen kann.
- Lies
Authentication-Resultsderselben Nachricht. Die Eigenschaftsmtp.mailfromist die Domain, die der Empfänger tatsächlich authentifiziert hat, und damit die maßgebliche Antwort, wenn sie vorhanden ist. - Wiederhole das für jede Plattform, die in deinem Namen sendet. Jede hat ihre eigene Einstellung, und sie werden zu verschiedenen Zeiten von verschiedenen Leuten eingerichtet.
Die Ausrichtung des Rückwegs ist einer von zwei Wegen, auf denen eine Nachricht DMARC genügt, und der andere ist DKIM, das Weiterleitungen übersteht, wo SPF es nicht tut. Unser Leitfaden zur E-Mail-Authentifizierung behandelt, wie die drei Records voneinander abhängen, und der stille Fehler auf der SPF-Seite ist das Thema unseres Leitfadens zum SPF-Mechanismus include.
Um beide Bezeichner an einer echten Nachricht zu sehen, neben allem anderen, was ein Empfänger bewertet, mach einen kostenlosen Spam-Test.
