WordPress-Fallback-SMTP-Server: Trotz 401-, 500-Fehler oder überschrittenem Kontingent weiter versenden

WordPress-Fallback-SMTP-Server: Das Problem in den Foren

Diese Frage taucht im WordPress.org-Forum häufig auf: Die Website versendet ihre E-Mails über Mailgun, Brevo, einen anderen Anbieter oder ein SMTP-Konto. Eines Tages schlägt der Versand fehl. Die Nachrichten lauten manchmal „401 Forbidden“ oder „450 4.7.1 monthly message limit exceeded“. Manchmal antwortet der Anbieter auch einfach mit einem 500-Fehler. Kontaktformulare, Bestellungen und Passwortzurücksetzungen werden nicht mehr verschickt.

Jemand fasst es im Forum so zusammen: Das E-Mail-Plugin schlägt fehl, und anstatt auf etwas anderes auszuweichen, blockiert es alles. Was man in diesem Fall sucht, ist ein SMTP-Fallback-Server für WordPress: ein zweiter Versandweg, der genutzt wird, wenn der erste verweigert wird.

Um so weit zu kommen, muss man zunächst wissen, warum der Hauptserver ablehnt. Erst danach entscheidet man, ob ein Backup ausreicht oder ob der Fehler an der Quelle behoben werden muss.

Den Fehler lesen, bevor man nach einem Backup sucht

Die drei oben genannten Fehler haben nicht dieselbe Ursache. Sie werden auch nicht auf dieselbe Weise behoben.

Ein 401-Fehler bedeutet, dass der Anbieter die Zugangsdaten nicht erkennt: widerrufener oder falsch kopierter API-Schlüssel, geändertes Passwort, gesperrtes Konto oder vom Anbieter noch nicht bestätigte Domain. Ein Fallback-Server ermöglicht es, weiter zu senden, aber solange der Schlüssel nicht korrigiert wird, startet der Hauptserver nicht wieder.

Ein überschrittenes Kontingent, wie „450 4.7.1 monthly message limit exceeded“, stammt von Ihrem Tarif beim Anbieter. Der Server funktioniert, weigert sich aber, vor dem Ende des Zeitraums weitere E-Mails zu senden. Dies ist der Fall, in dem ein zweiter Server am nützlichsten ist – vorausgesetzt, er verwendet nicht dasselbe Konto und somit nicht dasselbe Kontingent.

Ein 500-Fehler kommt meistens vonseiten des Anbieters und ist häufig nur vorübergehend. Das Backup dient dann dazu, während des Ausfalls nichts zu verlieren.

In nexya führt das E-Mail-Modul ein Versandprotokoll. Für jede E-Mail, die nicht versendet wurde, zeigt es die genaue Ursache an, die vom Server angegeben wurde. Hier liest man den Code und die Nachricht, anstatt raten zu müssen, warum ein Formular nicht mehr reagiert.

• 401: Zugangsdaten abgelehnt, muss beim Anbieter oder in der Verbindung korrigiert werden.
• Kontingent überschritten: Tariflimit erreicht, ein zweites Konto oder ein zweiter Anbieter springt ein.
• 500: Fehler aufseiten des Anbieters, oft vorübergehend, das Backup verhindert Verluste.

Was die kostenlose Version des E-Mail-Moduls tut

Das E-Mail-Modul ist wie der Rest von nexya kostenlos und für eine unbegrenzte Anzahl von Websites nutzbar. Es wird über den Hub aktiviert. Solange es ausgeschaltet ist, läuft keiner seiner Hooks auf der Website.

Es bietet drei Versandarten an: einen SMTP-Server, einen API-Anbieter oder ein über OAuth verbundenes Gmail- oder Microsoft-365-Konto, ohne dass ein Passwort auf der Website gespeichert wird. Eine Test-E-Mail überprüft die Verbindung, sobald sie eingerichtet ist.

Das Versandprotokoll nennt die Ursache für jeden Fehlschlag. Bei einem isolierten Ausfall reicht das oft aus: Man liest den Fehler, korrigiert den Schlüssel oder wechselt den Tarif und sendet dann eine Test-E-Mail.

Die kostenlose Version enthält dagegen weder einen zweiten Versandserver noch Benachrichtigungen im Fehlerfall. Dieser Code ist darin überhaupt nicht enthalten, er ist Teil von nexya Pro.

Was nexya Pro hinzufügt: Einen zweiten Server und eine Benachrichtigung

nexya Pro, erhältlich auf nexya.dev, fügt dem E-Mail-Modul einen zweiten Versandserver und Benachrichtigungen bei Fehlschlägen hinzu. Wenn der Hauptserver eine E-Mail ablehnt, wird der Versand auf den Backup-Server umgeschaltet und eine Benachrichtigung weist Sie auf das Problem hin.

Die Nachricht geht also trotzdem raus, und Sie wissen, dass Sie sich den Hauptserver ansehen müssen. Genau das fordern die Forenthemen: nicht mehr von einem einzigen Anbieter abhängig zu sein und einen Ausfall nicht erst drei Tage später durch einen Kunden zu entdecken, der seine Bestätigung nie erhalten hat.

nexya Pro wird nach dem Kauf von Freemius bereitgestellt. Es übernimmt die Nachfolge des kostenlosen Plugins mit denselben Einstellungen: Die bereits konfigurierte Hauptverbindung bleibt bestehen, es muss nur die zweite hinzugefügt werden. nexya Pro behält außerdem die Protokolle länger bei, was dabei hilft, einen wiederkehrenden Ausfall zu erkennen.

Ein Backup-Server ersetzt nicht die Behebung des Fehlers: Er sorgt dafür, dass die Website sendebereit bleibt, während Sie ihn korrigieren.

Einrichten eines Backup-Versandservers Schritt für Schritt

1. 1

   Das Mail-Modul einschalten

   Schalten Sie das Mail-Modul im nexya-Hub ein. Solange es ausgeschaltet ist, läuft keines seiner Hooks auf der Website.

   
2. 2

   Die Fehlerursache im Protokoll ablesen

   Öffnen Sie das Versandprotokoll und notieren Sie sich den Code und die Nachricht des Servers: 401, Kontingent überschritten oder Fehler 500. Korrigieren Sie an der Quelle, was korrigiert werden kann, zum Beispiel einen API-Schlüssel oder eine nicht validierte Domain.

   
3. 3

   Die Hauptverbindung überprüfen

   Überprüfen Sie die Hauptversandmethode (SMTP, API-Anbieter, Gmail oder Microsoft 365 mit OAuth) und senden Sie dann eine Test-E-Mail, um zu bestätigen, dass sie wieder funktioniert.

   
4. 4

   Den zweiten Server mit nexya Pro hinzufügen

   Fügen Sie mit nexya Pro einen zweiten Versandserver über ein anderes Konto oder einen anderen Anbieter hinzu. Im Falle eines Ausfalls des Hauptservers wird der Versand auf diese Absicherung umgeschaltet und eine Benachrichtigung warnt Sie. Testen Sie ihn sofort mit der Test-E-Mail.

   

Den Backup-Server mit Bedacht wählen

Ein Backup ist nur dann nützlich, wenn es nicht zur gleichen Zeit wie der Hauptserver ausfällt. Ein paar einfache Regeln helfen bei der Auswahl.

Nehmen Sie ein anderes Konto oder noch besser einen anderen Anbieter. Zwei Verbindungen über dasselbe Konto teilen sich dasselbe Kontingent und dieselben Zugangsdaten: Ein überschrittenes Kontingent oder ein widerrufener Schlüssel blockiert beide.

Variieren Sie nach Möglichkeit die Methode. Zum Beispiel eine API als Hauptserver und ein über OAuth verbundenes Gmail- oder Microsoft-365-Konto als Backup oder ein SMTP bei Ihrem Hosting-Anbieter. Alle drei Methoden des E-Mail-Moduls können in der jeweiligen Rolle dienen.

Überprüfen Sie die Absenderadresse. Der Backup-Server muss das Recht haben, für Ihre Domain zu senden. Andernfalls werden die E-Mails zwar verschickt, landen aber möglicherweise im Spam-Ordner. Das Modul überprüft keine SPF-, DKIM- oder DMARC-Einträge: Dies muss beim Anbieter und in der DNS-Zone der Domain kontrolliert werden.

Testen Sie das Backup schließlich nach der Einrichtung mit der Test-E-Mail, ohne auf den nächsten Ausfall zu warten.

• Ein anderes Konto oder ein anderer Anbieter als der Hauptanbieter.
• Wenn möglich eine andere Methode: API, SMTP oder OAuth.
• Eine beim Backup-Anbieter autorisierte Absenderdomain.
• Eine Test-E-Mail, die direkt nach der Konfiguration gesendet wird.

Was nexya noch nicht tut

Eine Einschränkung betrifft diesen Fall direkt: Eine Verbindung kann nicht deaktiviert werden, ohne sie zu löschen. Wenn Sie den Hauptserver vorübergehend beiseitelegen möchten, um ein Schlüsselproblem zu lösen, müssen Sie ihn löschen und danach neu konfigurieren. Notieren Sie sich daher vor dem Löschen einer Verbindung deren Einstellungen: Host, Port, Benutzername, Schlüssel oder verbundenes Konto.

Die bekannten Fakten des Moduls beschreiben ebenfalls keinen automatischen Rückfall auf die PHP-Funktion mail(). Die vorgesehene Absicherung ist ein zweiter Server, den Sie selbst in nexya Pro konfigurieren.

Das Modul verfügt außerdem über keine Schaltfläche zum erneuten Senden einer fehlgeschlagenen E-Mail. Das Protokoll zeigt an, was nicht gesendet wurde und warum. Das erneute Senden erfolgt über das ursprüngliche Tool, zum Beispiel durch erneutes Bearbeiten der über ein Formular empfangenen Anfrage.