Jede E-Mail trägt zwei Absenderadressen. Ihre 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 Ihrer Versandplattform gehört, makellos bestehen und trotzdem an DMARC scheitern, weil die Adresse im From-Header Ihnen 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 Ihre 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 Ihrem Firmennamen senden. SPF besteht, weil der Absender für die von ihm gewählte Umschlagdomain tatsächlich autorisiert ist. Die Leser sehen Ihren 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 Ihrer 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.
Ihre Marketingplattform kann SPF jedes Mal auf ihrer eigenen Bounce-Domain bestehen, und Ihr 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 Ihre 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 Sie 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 Ihre Mail "via" jemand anderen, ist Ihr 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 Ihnen 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 Sie 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 Sie an die Plattform delegieren. Sie veröffentlichen 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 Ihre Organisationsdomain teilt, also entspannt ausgerichtet ist.
Vier Details entscheiden, ob das funktioniert:
- Es muss eine Subdomain Ihrer From-Domain sein. Ein CNAME auf einer anderen Domain, die Ihnen ebenfalls gehört, richtet sich mit nichts aus.
- Der maßgebliche SPF-Record ist der auf der Rückwegdomain, nicht der auf Ihrer 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 Ihre DMARC-Richtlinie über den Baumdurchlauf, sofern Sie nicht
spveröffentlichen, um etwas anderes zu sagen, sie ist also von Ihrer 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 Ihre Nachricht nicht zustellen kann, schickt den Fehlschlag an den Rückweg, nicht an Ihre From-Adresse und nicht an Reply-To.
Deshalb ändert ein eigener Rückweg, wer die Bounces sieht. Delegieren Sie 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 Ihrer 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 Sie den Rückweg einer bereits gesendeten Nachricht lesen
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.
- Senden Sie sich eine Nachricht über die zu prüfende Plattform, an ein Postfach bei einem anderen Anbieter.
- Sehen Sie sich die Originalheader an und suchen Sie
Return-Path. Gmail nennt das "Original anzeigen"; die meisten Programme haben eine Entsprechung. - Vergleichen Sie dessen Domain mit der From-Domain. Identisch ist strikte Ausrichtung, eine Subdomain Ihrer From-Domain ist der normale entspannte Fall, eine nicht verwandte Domain heißt, dass SPF zu DMARC überhaupt nichts beitragen kann.
- Lesen Sie
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. - Wiederholen Sie das für jede Plattform, die als Sie 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, machen Sie einen kostenlosen Spam-Test.
