WordPress-Kundenmails zuverlässig versenden: zentrales Mailgateway, Mail-Log und HTML-Tagesbericht

Bei automatisierten Buchungen reicht es nicht, dass „irgendeine Mail“ verschickt wird. Entscheidend ist, ob später nachvollziehbar bleibt, was an wen wann und mit welchem Ergebnis gesendet wurde. Genau deshalb habe ich den Mailversand mehrerer WordPress-Projekte auf ein zentrales Gateway umgestellt.

Aus einem Parkplatz-Buchungssystem ist dabei ein Muster entstanden, das sich auch für Shops, Formulare, Terminbuchungen und interne Reportings eignet.

1. Ein zentraler Versandweg statt vieler SMTP-Konfigurationen

Wenn jedes WordPress-Projekt seinen eigenen SMTP-Weg pflegt, entstehen schnell unterschiedliche Passwörter, Plugins, Fehlerbilder und Logs. Ein zentrales Mailgateway reduziert diese Varianten.

Die Website übergibt den Versandauftrag an eine zentrale Mailfunktion. Diese kümmert sich um:

  • Absender,
  • Empfänger,
  • Betreff,
  • HTML- oder Textinhalt,
  • Versand,
  • Fehlerbehandlung,
  • Protokollierung.

Vorteil: Die Geschäftslogik muss nicht wissen, wie SMTP im Detail funktioniert. Sie ruft nur eine definierte Versandfunktion auf.

2. Was ein Mail-Log wirklich speichern sollte

Ein Log mit nur „Mail gesendet“ ist fast wertlos. Ich speichere mindestens:

Zeitpunkt
Projektkennung
Empfänger
Betreff
Nachrichtentyp
HTML/Text
Versandstatus
Fehlertext
SMTP-/Transportcode
zugehörige Buchungs- oder Anfrage-ID

Damit kann man später nicht nur prüfen, ob eine Mail gesendet wurde, sondern auch, ob der richtige Inhalt zum richtigen Vorgang gehörte.

3. Kundenmail und Betreiberkopie getrennt behandeln

Bei wichtigen Kundenmails verschicke ich zusätzlich eine Kopie an den Betreiber. Der Betreff bekommt einen eindeutigen Präfix wie „KOPIE …“. Dadurch bleibt im Postfach sofort erkennbar, welche Nachricht der Kunde erhalten hat.

Wichtig ist, dass diese Kopie nicht den eigentlichen Versandstatus verschleiert. Im Log sollten Kundenmail und Betreiberkopie als getrennte Versandvorgänge erscheinen.

4. HTML-Mail ist nicht automatisch HTML-Mail

Ein klassischer Fehler: Der Inhalt enthält HTML, aber der Versand erfolgt mit Text-Headern. Dann landet beim Empfänger eine unformatierte Mail oder sogar sichtbarer HTML-Code.

Deshalb muss die Mailfunktion ausdrücklich zwischen Text und HTML unterscheiden und den passenden Content-Type setzen. Erst danach lohnt es sich, Tabellen, farbige Statusboxen oder strukturierte Tagesberichte zu bauen.

5. Tagesbericht als Betriebsmonitor

Zusätzlich zu einzelnen Kundenmails verschickt mein System jeden Morgen einen Aktivitätsbericht. Für ein kleines Buchungssystem sind dabei nicht nur Bestellungen interessant. Viel aufschlussreicher ist oft der Weg davor.

Der Bericht enthält zum Beispiel:

  • Anzahl eindeutiger Suchsitzungen,
  • Anzahl Preisabfragen,
  • gesuchte Reisezeiträume,
  • angezeigte Preise,
  • Anfragen ohne Abschluss,
  • Buchungen bzw. erfolgreiche Abschlüsse.

So sieht man schnell, ob überhaupt Nachfrage vorhanden ist – auch wenn an einem Tag keine Bestellung entstanden ist.

6. Eine Zeile pro Session statt eine Zeile pro Klick

Bei Preisrechnern entsteht sonst sehr schnell Datenmüll: Ändert ein Kunde seine Rückkehrzeit dreimal, stehen plötzlich vier oder fünf fast identische Datensätze im Bericht.

Besser ist ein Session-Modell. Jede Sitzung erhält einen stabilen Schlüssel. Weitere Preisabfragen aktualisieren denselben Datensatz:

session_id
first_seen
last_seen
search_count
last_requested_start
last_requested_end
last_price
contact_known
booking_id

Dadurch entspricht eine Tabellenzeile tatsächlich einem Interessenten bzw. Browserlauf und nicht einem einzelnen Tastendruck.

7. Was in einen guten HTML-Tagesbericht gehört

Eine reine Zahlenwüste liest niemand gern. Bewährt hat sich eine kompakte Struktur:

  • Kopfbereich: Datum und wichtigste Kennzahlen,
  • Zusammenfassung: Suchsitzungen, Preisanzeigen, Anfragen, Buchungen,
  • Tabelle: Zeitraum, Preis, Zeitpunkt, Session, Status,
  • Auffälligkeiten: Fehler oder abgebrochene Prozesse,
  • Technikstatus: ob Versand und Protokollierung erfolgreich waren.

Die Mail sollte mobil lesbar bleiben. Deshalb lieber wenige Spalten mit klaren Zeilenumbrüchen statt einer riesigen Desktop-Tabelle.

8. Fehler müssen sichtbar bleiben

Wenn ein Kundenversand scheitert, darf das System nicht einfach weitermachen und nur intern „false“ zurückgeben. Der Fehler gehört in das Mail-Log und idealerweise zusätzlich in einen Betreiberhinweis.

Mindestens unterscheiden sollte man:

  • Nachricht erfolgreich an Gateway übergeben,
  • Gateway erfolgreich versendet,
  • Gateway abgelehnt,
  • Authentifizierungsfehler,
  • temporärer Transportfehler,
  • ungültiger Empfänger.

9. Kundenvorgang und Mailvorgang verknüpfen

Das Mail-Log sollte eine Buchungs-, Bestell- oder Anfrage-ID enthalten. Dann lässt sich aus der Kundenverwaltung direkt nachvollziehen:

  • Bestätigung gesendet?
  • Zahlungsaufforderung gesendet?
  • Erinnerung am Fälligkeitstag gesendet?
  • Storno-Mail gesendet?
  • Kopie an Betreiber erfolgreich?

Das ist besonders wertvoll, wenn Kunden später sagen, sie hätten eine bestimmte Nachricht nie erhalten.

10. Versandfunktionen zentral testen

Nach Änderungen teste ich nicht nur eine beliebige Mail, sondern gezielt den gesamten Weg:

  1. Testmail mit eindeutigem Betreff erzeugen.
  2. HTML-Version aktiv versenden.
  3. Empfang im Zielpostfach prüfen.
  4. Mail-Log prüfen.
  5. Kontrollieren, ob dort wirklich HTML und nicht die alte Textvariante gespeichert wurde.
  6. Bei Betreiberkopien beide Versandvorgänge prüfen.

11. Sicherheitsaspekt: Zugangsdaten nicht verteilen

Das zentrale Gateway reduziert auch die Zahl der Stellen, an denen SMTP-Zugangsdaten liegen. WordPress-Projekte sollten möglichst nur das Nötigste kennen. Passwörter und Tokens gehören nicht in öffentlich sichtbare Snippets, JavaScript oder Git-Repositories.

Fazit

Ein zuverlässiger WordPress-Mailversand besteht nicht nur aus SMTP. Erst die Kombination aus zentralem Versandweg, detailliertem Mail-Log, klarer Zuordnung zum Geschäftsvorgang und lesbarem HTML-Tagesbericht macht aus E-Mail einen kontrollierbaren Prozess.

Der größte praktische Nutzen liegt für mich im Tagesbericht: Man sieht nicht nur Bestellungen, sondern auch Suchinteresse, Preisabfragen und abgebrochene Wege. Damit wird aus einem Mailbericht gleichzeitig ein einfacher Betriebsmonitor.