JTL-Shop versendet keine E-Mails – und keiner merkt es: Microsoft 365, SMTP prüfen und Mailversand überwachen

Ein Kunde ruft an: Er habe bestellt, aber nie eine Bestätigung bekommen. Ein anderer kommt mit „Passwort vergessen“ nicht weiter. Einzelfälle, denkt man – Spamordner, Tippfehler in der Adresse. Bis sich herausstellt, dass der Shop seit Monaten keine einzige E-Mail mehr verschickt hat.

Genau das haben wir in der Praxis erlebt: Über mehrere Monate gingen Tausende Mails ins Leere – Bestellbestätigungen, Versandbestätigungen, Passwort-Mails. Der Shop lief, Bestellungen kamen herein, nur die Kommunikation mit den Kunden fand nicht mehr statt. Bemerkt hat es lange niemand.

Warum der Ausfall so lange unbemerkt bleibt

Der JTL-Shop verschickt Mails nicht direkt im Moment der Bestellung, sondern legt sie in einer Warteschlange in der Datenbank ab (Tabelle emails). Ein Hintergrundprozess arbeitet diese Warteschlange ab. Scheitert der Versand, wird der Fehler am Eintrag vermerkt – sonst passiert nichts.

Für den Besucher sieht alles normal aus: Die Bestellung wird angenommen, die Danke-Seite erscheint. Eine Fehlermeldung im Frontend gibt es nicht. Und die naheliegende Idee, sich bei Problemen per E-Mail warnen zu lassen, funktioniert ausgerechnet hier nicht – der Mailversand ist ja das, was kaputt ist.

Häufigste Ursache: abgelaufene Anmeldung bei Microsoft 365

Viele Shops versenden über ein Microsoft-365-Postfach. Die Anmeldung läuft dabei nicht mehr über ein einfaches Passwort, sondern über OAuth: Der Shop hält ein sogenanntes Refresh-Token, mit dem er sich bei jedem Versand neue Zugangsberechtigungen holt.

Dieses Token kann ablaufen. In unserem Fall stand in der Fehlerspalte jeder gescheiterten Mail:

AADSTS700082: The refresh token has expired due to inactivity.

Microsoft hat das Token also wegen Inaktivität für ungültig erklärt. Ab diesem Moment scheitert jeder Versandversuch, bis das Mailkonto im Shop neu angemeldet bzw. autorisiert wird.

Neben dem Refresh-Token kann bei Microsoft 365 auch das Client-Secret der registrierten Anwendung ablaufen – es wird mit einem Ablaufdatum angelegt. Notieren Sie sich dieses Datum bei der Einrichtung und planen Sie die Erneuerung rechtzeitig ein.

Weitere typische Auslöser sind Änderungen am Mailkonto selbst: neues Passwort, geänderte SMTP-Einstellungen beim Anbieter, deaktivierte Authentifizierungsverfahren oder ein umgezogenes Postfach. Daneben gibt es vorübergehende Fehler, etwa Verbindungsabbrüche (in den Fehlertexten zum Beispiel als cURL error 35: Recv failure). Diese verschwinden oft von selbst – aber nicht immer wird die betroffene Mail danach noch versendet.

Prüfen: Wird überhaupt noch versendet?

Der schnellste praktische Test: Lösen Sie im Shop selbst eine Mail aus, zum Beispiel über „Passwort vergessen“ mit einem eigenen Kundenkonto, und prüfen Sie, ob sie ankommt. Kommt nichts an, lohnt der Blick in die Datenbank.

Die folgenden Abfragen lesen nur. Sie laufen in der MySQL- bzw. MariaDB-Datenbank des Shops, etwa über phpMyAdmin oder einen anderen Datenbank-Client.

Wie viele Mails sind gescheitert?

SELECT COUNT(*) FROM emails WHERE errorCount > 0;

Welche Fehler treten auf?

SELECT lastError, COUNT(*) AS Anzahl
  FROM emails
 WHERE errorCount > 0
 GROUP BY lastError;

Die Spalte lastError enthält den letzten Fehlertext – hier steht zum Beispiel der AADSTS-Code. Ein Detail, das bei eigenen Auswertungen leicht übersehen wird: Bei gescheiterten Mails ist dateSent nicht leer (NULL), sondern steht auf 0000-00-00. Eine Abfrage mit dateSent IS NULL findet diese Mails also nicht.

Die zweite Tabelle, temailhistory, enthält die Versandhistorie – allerdings nur erfolgreich versendete Mails, und nur mit Metadaten. Gescheiterte Mails tauchen dort nicht auf. Genau das macht sie nützlich: Ist der jüngste Eintrag dort Tage alt, obwohl regelmäßig bestellt wird, ist der Versand mit hoher Wahrscheinlichkeit gestört.

Der blinde Fleck: Mails, die nie in der Warteschlange landen

Nicht jede fehlende Mail steht in emails. Scheitert eine Mail schon an der Vorprüfung, wird sie gar nicht erst eingereiht. Dann gibt es nur einen Eintrag im Shop-Protokoll (Tabelle tjtllog, Meldung „Error sending mail“).

Ein Beispiel aus der Praxis: Nach einem Shop-Update stand eine E-Mail-Vorlage auf inaktiv. Die zugehörigen Mails wurden still verworfen – in der Warteschlange war nichts zu sehen. Prüfen Sie nach Updates deshalb auch, ob alle benötigten E-Mail-Vorlagen aktiv sind, und werfen Sie einen Blick in das Protokoll im Backend.

Ursache beheben – vor dem Nachversand

Bevor Sie irgendetwas erneut versenden, muss der Versand wieder funktionieren. Bei AADSTS700082 heißt das: Mailkonto in den E-Mail-Einstellungen des Shops neu mit Microsoft 365 verbinden bzw. neu autorisieren. Bei SMTP-Problemen: Zugangsdaten, Server, Port und Verschlüsselung mit den aktuellen Vorgaben Ihres Anbieters abgleichen.

Danach erneut eine Testmail auslösen. Erst wenn diese ankommt, geht es an die liegengebliebenen Mails.

Gescheiterte Mails finden und gezielt nachversenden

Hier liegt die zweite Falle. Der Shop holt aus der Warteschlange nur Mails, die weniger als drei Fehlversuche haben – oder ausdrücklich zum erneuten Versand markiert sind (reSend = 1). Eine Mail mit drei oder mehr Fehlversuchen wird nie wieder angefasst, auch wenn das Problem längst behoben ist.

Sichern Sie zuerst die betroffenen Einträge:

CREATE TABLE emails_sicherung_20261014 AS
SELECT * FROM emails WHERE errorCount > 0;

Entscheiden Sie dann je Mailart, ob ein Nachversand sinnvoll ist:

• Versand- und Bestellbestätigungen der letzten Tage: meist sinnvoll.
• Bestätigungen, die Wochen oder Monate alt sind: eher nicht. Kunden, die eine längst gelieferte Bestellung erneut bestätigt bekommen, sind verunsichert. Wichtige Fälle besser persönlich klären.
• Passwort-Mails und ähnliche Links: nach längerer Zeit in der Regel nicht mehr brauchbar. Der Kunde fordert bei Bedarf eine neue an.

Für die ausgewählten Einträge setzen Sie dann reSend – mit einer genau eingegrenzten Bedingung:

UPDATE emails
   SET reSend = 1
 WHERE errorCount > 0
   AND /* Ihre geprüfte Auswahl, z. B. bestimmte IDs */;

Ein UPDATE ohne sorgfältige Eingrenzung schickt unter Umständen Tausende veraltete Mails auf einmal an Ihre Kunden – und das lässt sich nicht zurückholen. Testen Sie zuerst mit einer einzelnen Mail an eine eigene Adresse und prüfen Sie die Auswahl vorher mit einem SELECT mit derselben Bedingung.

Fehlerarten unterscheiden: Anmeldefehler nie blind wiederholen

Nicht jeder Fehler sollte zu einem erneuten Versuch führen. Bewährt hat sich die Unterscheidung in drei Gruppen:

• Vorübergehende Fehler (Verbindungsabbruch, Zeitüberschreitung): erneuter Versuch mit wachsendem Abstand ist sinnvoll.
• Anmeldefehler (z. B. AADSTS-Codes, abgelehnte Zugangsdaten): kein automatischer Nachversand. Solange die Anmeldung kaputt ist, scheitert jeder Versuch – und jeder Versuch erhöht nur den Fehlerzähler. Erst die Ursache beheben.
• Dauerhafte Fehler (ungültige Empfängeradresse u. ä.): nicht wiederholen, sondern die Daten korrigieren.

Lösen Sie die Erneuerung des Microsoft-Tokens nicht „auf Verdacht“ selbst aus, etwa per Skript. Bei der Erneuerung gibt Microsoft ein neues Token aus und kann das bisherige dabei ungültig machen. Läuft das schief, haben Sie sich den Versand selbst abgeschaltet.

Fehlerbild auf einen Blick

Künftig überwachen

Der eigentliche Schaden entsteht nicht durch den Fehler, sondern durch die Zeit, in der ihn niemand bemerkt. Eine Überwachung muss deshalb nicht kompliziert sein, aber regelmäßig laufen. Diese Prüfungen haben sich bewährt:

• Gescheiterte Mails: Gibt es Einträge in emails mit errorCount > 0?
• Aufgegebene Mails: Einträge mit drei oder mehr Fehlversuchen, die nicht zum erneuten Versand markiert sind.
• Herzschlag: Wann gab es den letzten Eintrag in temailhistory? Bleibt er über viele Stunden aus, obwohl der Shop normal läuft, ist etwas faul.
• Hängende Warteschlange: Mails, die ungewöhnlich lange unversendet in emails stehen – etwa weil der zuständige Hintergrundprozess nicht mehr läuft.
• Protokoll: neue Einträge „Error sending mail“ in tjtllog.
• Auffällige Mengen: viele Mails mit gleichem Betreff in kurzer Zeit an fremde Adressen können auf Missbrauch eines Formulars hindeuten.

Wichtig ist der Alarmweg: Er darf nicht über denselben Mailversand laufen, den er überwachen soll. Besser geeignet sind ein deutlicher Hinweis im Shop-Backend, ein Eintrag im Protokoll oder ein Webhook an ein System, das ohnehin täglich im Blick ist.

Bei unseren Kunden setzen wir dafür eine eigene Überwachung ein, die genau diese Prüfungen regelmäßig ausführt, vorübergehende Fehler mit wachsendem Abstand selbst erneut versucht und Anmeldefehler bewusst nicht wiederholt, sondern meldet.

Wenn Sie Unterstützung brauchen

Sie vermuten, dass Ihr Shop schon länger keine Mails mehr verschickt, oder möchten den Nachversand nicht selbst in der Datenbank anstoßen? Als zertifizierter JTL-Servicepartner hilft PC-Mixx bei der Analyse, beim gezielten Nachversand und bei der Einrichtung einer dauerhaften Überwachung.

Häufige Fragen