Ich betreue mehrere WordPress-Websites. Auf jeder geht eine Menge E-Mails raus, die kaum jemand auf dem Schirm hat: Kontaktbenachrichtigungen, Passwort-Resets, Bestellbestätigungen, Hinweise an die Betreiber. Das E-Mail-Protokoll in WordPress von FluentSMTP ist das Werkzeug, das ich als Erstes öffne, sobald ein Kunde schreibt „ich habe nichts bekommen“. Früher sah ich in die Logs des SMTP-Servers per Kommandozeile. Ich musste grep und Zeitstempel von Hand abgleichen. Heute öffne ich eine Seite im WordPress-Panel und habe alles vor Augen.
Warum ich das E-Mail-Protokoll in WordPress vor den Server-Logs kontrolliere
Der typische Fall ist immer derselbe. Ein Kontaktformular, das „nicht ankommt“. Ein Kunde, der die Passwort-Reset-E-Mail nicht erhält. Eine Bestellung ohne Bestätigung. Ohne ein Protokoll zur Hand ist die erste Vermutung der Spam-Ordner. Dann die Logs des SMTP-Servers. Dann vielleicht die Firewall. Mit FluentSMTP überspringe ich diese Schritte. Ich sehe sofort, ob WordPress wirklich versucht hat, diese E-Mail zu versenden. An wen, wann, mit welcher Antwort vom Versandserver.
FluentSMTP protokolliert jeden Aufruf von wp_mail(). Nicht nur die E-Mails von Drittanbieter-Plugins, auch die vom Core selbst: Benachrichtigungen über neue Benutzer, Update-Erinnerungen, Fehlerhinweise. Für jeden Versand zeigt das Protokoll Absender, Empfänger, Betreff, vollständige Header, Nachrichtentext. Und die Antwort des SMTP-Providers oder der verwendeten API. Ist eine E-Mail fehlgeschlagen, steht diese Serverantwort genau dort. Ich muss sie nicht raten.
Was wirklich im Versandprotokoll steht
Das Plugin unterstützt Dutzende Connectoren: Amazon SES, SendGrid, Mailgun, Brevo, Postmark, SparkPost. Auch Google Workspace und Microsoft 365 über OAuth, neben dem klassischen generischen SMTP. Auf den Websites, die ich betreue, nutze ich fast immer authentifiziertes SMTP mit der Domain des Kunden. Manchmal eine dedizierte API, wenn das E-Mail-Volumen wächst. In beiden Fällen bleibt das Protokoll gleich. Jede Zeile hat einen Status, versendet oder fehlgeschlagen. Es gibt eine Schaltfläche, um den Inhalt anzusehen oder die Nachricht erneut zu senden, ohne dass der Nutzer die Aktion wiederholen muss, die sie ausgelöst hat.
Der erneute Versand ist die Funktion, die ich am häufigsten nutze. Ein Formular, das zweimal ausgefüllt wurde, weil „es nicht ankam“, wird zu einem Klick im Protokoll. Keine neue Meldung an den Kunden. Für wiederholte Fehlschläge habe ich Benachrichtigungen über Telegram aktiviert. Sobald eine Verbindung nicht mehr funktioniert, weiß ich es, bevor mir jemand schreibt. Statt es aus einem Support-Ticket zu erfahren.
Das Protokoll betrifft nicht nur Benachrichtigungen direkt an mich oder den Kunden, der die Seite verwaltet. Dort landet jede ausgehende E-Mail, die die Website an Dritte schickt: die Bestellbestätigung, die ein Online-Shop an den Endkunden sendet, die Zahlungsquittung, die Versandbenachrichtigung. Kommt diese Bestätigung nicht an, zeigt das E-Mail-Protokoll in WordPress das genauso wie eine interne Benachrichtigung, mit derselben Schaltfläche, um sie an den richtigen Empfänger neu zu senden, ohne dass er den Kauf wiederholen muss.
Wie ich FluentSMTP auf den Websites konfiguriere, die ich betreue
Nach dem Verbinden des passenden Connectors ändere ich die Aufbewahrungsdauer des Protokolls. Standardmäßig bleibt es lange aktiv. Ich stelle sie auf 30 bis 60 Tage, je nach Traffic der Website. Das reicht, um einem spät gemeldeten Problem nachzugehen. Ohne die Datenbank mit Zeilen zu füllen, die ich nie ansehen werde. Danach aktiviere ich mindestens einen Benachrichtigungskanal für Fehlschläge, Telegram oder Slack, je nach Kunde. Das Protokoll allein warnt niemanden, es muss geöffnet werden, um gelesen zu werden.
Auf Websites mit Kontaktformular nutze ich zusätzlich Cisilino Site Defense Network zum Blockieren von Bots. Weniger eingehender Spam bedeutet weniger E-Mails aus den Formularen. Das Protokoll bleibt übersichtlicher, mit weniger Rauschen, das ich beim Suchen der richtigen Nachricht ausblenden muss.
Die SMTP-Zugangsdaten bleiben nicht im Klartext in der Datenbank
Ein Detail, das ich immer prüfe, bevor ich eine Verbindung speichere: wo die Zugangsdaten landen. FluentSMTP verschlüsselt sie standardmäßig mit den SALT-Schlüsseln von WordPress, denselben, die schon in wp-config.php für die Sicherheit der Sitzungen stehen. Man kann die Verschlüsselung deaktivieren, aber das Plugin selbst rät davon ab. Auf den Websites, die ich betreue, bevorzuge ich eine andere Option: das API- oder SMTP-Passwort direkt in wp-config.php speichern, außerhalb der Datenbank, mit Konstanten, die definiert sind, bevor das Plugin sie liest. So legt auch ein Datenbank-Dump oder ein unbefugter Zugriff aufs Panel den Schlüssel des Versandproviders nicht offen. Es ist dasselbe Prinzip, das ich auch sonst anwende: weniger Geheimnisse in der Datenbank, umso besser.
Mehrere Verbindungen gleichzeitig, nicht nur eine nach der anderen
FluentSMTP erlaubt es, mehrere Verbindungen gleichzeitig einzurichten, nicht nur eine nach der anderen. Auf einer Website lege ich die Standardverbindung fest und füge eine zweite als Reserve hinzu: Antwortet der erste Provider nicht, wechselt der Versand automatisch zur Reserveverbindung, ohne dass ich eingreifen muss. Die Wahl der Verbindung hängt von der Absenderadresse ab: Jede Verbindung hat ihr eigenes „Von“, der Rest läuft über die Standardverbindung, mit der Reserve nur bereit, falls die Standardverbindung wirklich ausfällt (ein Fehler des Providers, keine E-Mail, die im Spam landet). Das ist einer der Gründe, warum ich das einem einzelnen SMTP ohne Alternative vorziehe: Haben SendGrid oder Amazon SES ein paar Stunden lang ein Problem, versendet die Website trotzdem weiter, und das E-Mail-Protokoll in WordPress zeigt es sofort. Alles in der kostenlosen Version enthalten, ohne eine kostenpflichtige Pro-Version: Man bezahlt nur den gewählten Versandprovider, nicht das Plugin.
Ein täglicher Gesundheitscheck, nicht nur wenn etwas kaputt ist
Neben dem Protokoll Zeile für Zeile führt FluentSMTP jeden Tag automatisch einen Gesundheitscheck der Verbindung durch. Antwortet der Provider nicht mehr, kommt die Warnung, bevor ein Kunde mir schreibt „die Website versendet keine E-Mails mehr“. Dasselbe Panel zeigt eine Grafik mit den täglichen Gesamtzahlen erfolgreicher und fehlgeschlagener Versände: nützlich, um auf einen Blick zu erkennen, ob ein Rückgang normal ist oder das Symptom für etwas, das gerade kaputtgeht, ohne jedes Mal das Protokoll Zeile für Zeile öffnen zu müssen. Es gibt auch eine periodische Zusammenfassung per E-Mail, mit den Zahlen der Woche: kein Fehlerhinweis, sondern ein Bulletin, das ich kurz überfliege, um zu wissen, ob das Versandvolumen im Rahmen liegt.
Wer wie ich mehrere Websites von der Kommandozeile aus verwaltet, findet in FluentSMTP auch WP-CLI-Befehle: einen Versandtest, einen Gesundheitscheck der Verbindung, Statistiken und das Aufräumen alter Protokolleinträge. Ich nutze sie in denselben Skripten, die schon auf den Servern für andere Wartungsaufgaben laufen, ohne das Panel jeder Website einzeln öffnen zu müssen.
Was das E-Mail-Protokoll in WordPress nicht leisten kann
Es ist keine Wunderlösung. Die Aufbewahrung richtet sich nach Tagen, nicht nach einer Höchstzahl an Zeilen. Auf einer Website mit viel transaktionalem Traffic kann die Protokolltabelle schnell wachsen. Es lohnt sich, sie im Blick zu behalten oder eine kürzere Aufbewahrungsdauer einzustellen. Fehlerbenachrichtigungen kommen nur über die konfigurierten Chat-Kanäle, nicht per E-Mail. Macht Sinn: Eine E-Mail, die vor einer fehlgeschlagenen E-Mail warnt, kann selbst fehlschlagen. Aber das sollte man wissen, bevor man sich darauf verlässt.
Schließlich zeigt das Protokoll, was auf Seiten von WordPress und auf Seiten des Providers passiert ist. Es garantiert nicht die Zustellung im Postfach des Empfängers. Ist eine E-Mail als versendet markiert, landet aber im Spam, ist das ein Problem des Domain-Rufs oder der SPF/DKIM-Konfiguration. Nichts, was ein Protokoll allein lösen kann. Trotzdem bleibt es die erste Stelle, an der ich nachsehe, bevor ich irgendetwas anderes prüfe.
Das Plugin ist kostenlos und Open Source. Die offizielle Seite auf wordpress.org, ohne Funktionen, die hinter einer Pro-Version blockiert sind. Wer auch nur eine Website mit Kontaktformular betreut, für den lohnt es sich, es nur für das E-Mail-Protokoll in WordPress zu installieren. Löst es das erste „ich habe die E-Mail nicht bekommen“ in einer Minute statt in einer halben Stunde, hat es sich bereits ausgezahlt.
Schreibe einen Kommentar