„Passwort-Reset-E-Mail kommt nicht an“ ist eine der frustrierendsten Support-Anfragen, die es gibt: Der Nutzer kann sich nicht einloggen, findet nichts im Posteingang und meist auch nichts im Spam-Ordner. Anders als bei Newsletter-Beschwerden hat man hier keine Zeit für A/B-Tests – die Mail muss innerhalb von Sekunden bis wenigen Minuten ankommen, sonst bricht der Nutzer den Registrierungs- oder Login-Prozess ab. Die gute Nachricht: Die Ursachen sind fast immer technisch nachvollziehbar und lassen sich gezielt prüfen.
Warum Passwort-Mails besonders anfällig sind
Transaktions-E-Mails wie Passwort-Resets gelten technisch oft als „harmlos“, laufen aber in der Praxis über dieselbe Infrastruktur wie der Marketing-Versand – gleiche Domain, oft sogar dieselbe IP oder derselbe ESP-Account. Wenn die Newsletter-Reputation der Domain leidet, weil zu viele Empfänger sich beschweren oder die Spamrate zu hoch ist, sinkt die Zustellbarkeit auch für die Passwort-Mail mit – obwohl der Nutzer aktiv um genau diese Mail gebeten hat. Provider wie T-Online sind dafür bekannt, besonders empfindlich auf Absenderreputation und Beschwerdequoten zu reagieren, während GMX und Web.de zwar eine gemeinsame Infrastruktur nutzen (beide gehören zu United Internet), die Reputation aber pro Marke separat bewerten.
Die häufigsten Ursachen im Überblick
- SPF, DKIM oder DMARC fehlen oder greifen nicht. Ohne diese drei Mechanismen kann der Empfängerserver die Absenderdomain nicht verifizieren – manche Filter stufen die Mail dann als Spam ein, strengere lehnen sie sofort ab.
- Plattform-Standardversand ohne eigene Domain. Shopware, JTL-Shop oder WooCommerce (über PHPs
wp_mail()) versenden standardmäßig über den Hosting-Server, nicht über eine authentifizierte Absenderdomain – das ist einer der häufigsten Gründe für verschwundene Passwort-Mails im deutschen E-Commerce. - Geteilte Reputation mit Marketing-Mails. Läuft alles über denselben ESP und dieselbe Domain, zieht ein schlecht gepflegter Newsletter die transaktionale Mail mit runter.
- Erstkontakt-Verzögerung (Greylisting). Manche Filter, besonders bei neuen IPs oder Domains, verzögern die Zustellung beim ersten Kontakt bewusst um einige Minuten – für den Nutzer sieht das wie „kommt nicht an“ aus.
- Eigene Postfach-Regeln. Nutzer bei Web.de oder GMX haben oft Werbeordner oder Filterregeln eingerichtet, die automatisierte Mails unabhängig vom Absender-Score aussortieren.
- Tippfehler oder alte Adresse. Banal, aber real – vor der technischen Fehlersuche lohnt sich immer der Blick auf die tatsächlich hinterlegte Adresse.
SPF, DKIM und DMARC richtig prüfen
Für Transaktions-Domains gilt dieselbe Grundregel wie für Marketing-Domains: SPF muss den Versandserver autorisieren, DKIM muss korrekt signieren und mit der sichtbaren Absenderdomain übereinstimmen (Alignment), und DMARC entscheidet, was mit Mails passiert, die diese Prüfung nicht bestehen.
Ein typischer SPF-Eintrag für einen Versanddienst sieht so aus:
v=spf1 include:_spf.beispiel-esp.de ~allp=reject und stimmt die Ausrichtung von SPF oder DKIM nicht mit der sichtbaren Absenderdomain überein, wird die Mail nicht in den Spam-Ordner einsortiert – sie wird beim Empfängerserver komplett abgelehnt. Für den Nutzer ist das vom „kommt einfach nicht an“ nicht zu unterscheiden. Vor einer Verschärfung der DMARC-Policy immer erst mit p=none die Aggregatberichte auswerten.Eigene Absenderdomain statt Plattform-Standard
Bei vielen deutschen Shopsystemen ist die verschwundene Passwort-Mail ein Konfigurationsproblem, kein Filterproblem. Shopware und JTL-Shop verlangen einen expliziten SMTP-Connector mit eigener, authentifizierter Domain – ohne diesen Schritt läuft der Versand über den generischen Hosting-Mailserver, der bei Google, Microsoft und den deutschen Providern kaum Vertrauen genießt. Bei WooCommerce löst ein SMTP-Plugin (verbunden mit einem echten Versanddienst statt wp_mail()) dasselbe Problem. Shopify verlangt die Verifizierung der eigenen Domain per SPF/DKIM, bevor Mails darüber laufen dürfen, und auch bei HubSpot im B2B-Einsatz muss die Absenderdomain erst verbunden und bestätigt werden, bevor Transaktions- und Marketing-Mails zuverlässig zugestellt werden.
Diagnose in wenigen Minuten
Statt zu raten, lässt sich der Weg der Mail direkt nachvollziehen: Einen Passwort-Reset an die eigene Testadresse auslösen und parallel mit einem kostenlosen Inbox-Placement-Test prüfen, wo die Mail bei GMX, Web.de, T-Online, Gmail und Outlook tatsächlich landet – im Posteingang, im Spam-Ordner oder gar nicht. Das Tool zeigt zusätzlich die SPF/DKIM/DMARC-Ergebnisse und die Verdikte der Spam-Engines für jede getestete Adresse, so dass sich sofort erkennen lässt, ob es an der Authentifizierung, an der Reputation oder an der Zustellverzögerung liegt.
Zusätzlich lohnt sich ein Blick auf die eigenen Adoptionsdaten: Auf /email-stats/ zeigt der wöchentliche Scan, wie verbreitet SPF, DKIM, DMARC, BIMI und MTA-STS aktuell im Web sind – ein guter Referenzpunkt, um die eigene Domain einzuordnen.
Trennung von Transaktions- und Marketing-Versand
Der wirksamste strukturelle Fix ist, Passwort-Reset- und andere Transaktionsmails über eine eigene Subdomain zu versenden, getrennt von Newslettern – etwatransaktional.beispiel.de statt der Hauptdomain. So bleibt die Reputation der kritischen Login-Mails unabhängig davon, wie aggressiv der Marketing-Versand ist. Jede Subdomain braucht dafür einen eigenen DKIM-Selector und sollte im SPF-Eintrag sauber aufgeführt sein, damit Filter sie klar von der Haupt- oder Newsletter-Domain unterscheiden können.
Warum landet die Passwort-Mail nicht mal im Spam-Ordner, sondern verschwindet komplett?
p=reject) ohne korrektes SPF/DKIM-Alignment: Der Empfängerserver lehnt die Mail direkt beim Versand ab, statt sie zuzustellen und im Spam-Ordner einzusortieren. Für den Nutzer ist beides gleich unsichtbar, technisch aber ein deutlicher Unterschied, der sich in den DMARC-Aggregatberichten nachweisen lässt.