Jede Website verschickt E-Mails: Bestellbestätigungen, Links zum Zurücksetzen von Passwörtern, Nachrichten aus Kontaktformularen oder Buchungserinnerungen. Transaktionsmails sind der Bereich, den niemand einplant, auf den sich aber alle verlassen. Meist richtet die Person, die die Website gebaut hat, den Versand einmal ein und niemand prüft ihn später erneut.
Dann erhalten Kunden plötzlich keine Bestellbestätigungen mehr und es stellt sich heraus, dass sie seit acht Monaten im Spam landen. Dieser Beitrag erklärt, warum das unabhängig von der verwendeten Plattform passiert und wie Sie es verhindern.
Warum Transaktionsmails unbemerkt scheitern
Die Standardeinstellung der meisten Plattformen verschickt E-Mails direkt vom Webserver über die Mailfunktion der jeweiligen Programmiersprache. Im Test funktioniert das, weil Sie in Ihr eigenes Postfach schauen und Ihr eigener Anbieter Ihnen vertraut.
Im Produktivbetrieb scheitert der Versand aus einem Grund, der nichts mit Ihrem Code zu tun hat. Der Webserver besitzt keine Absenderreputation, seine IP-Adresse wird mit anderen Diensten des Hosters geteilt und die Nachricht gibt Ihre Domain als Absender an, obwohl sie von einem Server kommt, den diese Domain nie autorisiert hat. Empfangende Anbieter behandeln genau dieses Muster als Fälschung, weil es sich meistens tatsächlich darum handelt. Aus diesem Grund verlangen die Richtlinien von Google für E-Mail-Absender eine Authentifizierung.
Auf Ihrer Seite bleibt der Fehler unsichtbar. Die Website meldet den erfolgreichen Versand, die Protokolle enthalten keinen Fehler und nichts weist darauf hin, dass die Nachricht beim Empfänger im Spamordner abgelegt wurde. Transaktionsmails einer Website teilen besonders schlecht mit, dass sie nicht funktionieren. Deshalb wird das Problem oft erst Monate später durch eine Kundenbeschwerde entdeckt.
Dasselbe Problem auf jeder Plattform
Das ist kein reines WordPress-Problem. WordPress wird nur besonders häufig dafür verantwortlich gemacht, weil es so weit verbreitet ist. Der Mechanismus ist überall derselbe.
WordPress verwendet standardmäßig die Mailfunktion von PHP und sendet damit direkt vom Server, einschließlich aller beschriebenen Nachteile. Ein SMTP-Plugin ersetzt diese Funktion und ist die übliche Lösung.
Shopify, Wix und Squarespace versenden Transaktionsmails über ihre eigene, in der Regel gut gepflegte Infrastruktur. Ohne zusätzliche Einrichtung lässt sich die eigene Domain jedoch nicht immer zuverlässig und korrekt authentifiziert nutzen. Eine E-Mail, die angeblich von Ihrem Unternehmen kommt, kann dann nicht zweifelsfrei als solche bestätigt werden.
Webflow, Ghost und eigene Anwendungen unterscheiden sich im Detail, das Muster bleibt jedoch gleich: Der standardmäßige Versandweg ist nur selten für Ihre Domain authentifiziert.
Die einheitliche Lösung für alle Plattformen besteht darin, Transaktionsmails über eine authentifizierte SMTP-Verbindung zu leiten und im DNS der Domain ausdrücklich festzulegen, dass diese Verbindung senden darf.
Die Lösung aus drei Bausteinen
Drei Bausteine sind erforderlich. Fehlt einer davon, können die Nachrichten weiterhin im Spam landen.
Ein SMTP-Konto für den Versand. Anstatt selbst zu senden, meldet sich die Website an einem Mailserver an und übergibt ihm die Nachricht. Jede Plattform unterstützt das entweder direkt oder über ein Plugin.
DNS-Einträge, die den Versand autorisieren. Sie benötigen einen SPF-Eintrag, der den sendenden Server nennt, und eine DKIM-Signatur, anhand derer sich die Nachricht überprüfen lässt. Ohne beides wirkt selbst ein authentifizierter Versand für den Empfänger unbefugt. Unsere Anleitungen zu SPF und DKIM erklären die entsprechenden Einträge.
Eine tatsächlich vorhandene Absenderadresse. Der Versand über noreply@ihredomain.de, obwohl dieses Postfach nicht existiert, ist ein kleines, aber echtes negatives Signal. Außerdem gehen Antworten verloren. Hier verursacht das Anlegen des Postfachs keine Zusatzkosten, da Postfächer nicht pro Nutzer abgerechnet werden.
Trennung von der persönlichen Korrespondenz
Ab einem bestimmten Volumen sollten Transaktionsmails der Website über einen eigenen Versandweg laufen.
Automatisierte und von Menschen geschriebene E-Mails verhalten sich unterschiedlich und werden unterschiedlich bewertet. Fünfhundert Passwort-Resets nach einem Sicherheitsvorfall sehen ganz anders aus als die Korrespondenz einer Person. Wenn beides denselben Versandweg nutzt, wird die Reputation des automatisierten Datenverkehrs auch zur Reputation Ihrer geschäftlichen Nachrichten.
SMTP-Profile pro Domain erleichtern die Trennung: Leiten Sie die Domain Ihrer Anwendung über einen Versandweg und die Domain Ihrer Mitarbeiter über einen anderen. Ein Problem auf einer Seite bleibt dann auf diese beschränkt. Die Einrichtung erläutern wir unter individuelles SMTP pro Domain.
Einige Unternehmen gehen noch weiter und nutzen für sämtliche automatisierten Nachrichten eine eigene Subdomain. Damit wird die Reputation vollständig isoliert, allerdings wirkt die Absenderadresse etwas weniger aufgeräumt. Ob sich das lohnt, hängt vom Versandvolumen ab.
Wann ein Transaktionsmail-Anbieter sinnvoll ist
Die Grenze sollte klar benannt werden: Bei wirklich hohem Volumen gibt es spezialisierte Transaktionsmail-Dienste aus gutem Grund.
Wenn Sie täglich Zehntausende Nachrichten versenden, benötigen Sie Zustellereignisse für jede einzelne E-Mail, Webhook-Rückmeldungen bei Unzustellbarkeit, Vorlagenverwaltung und detaillierte Auswertungen. Genau dafür wurden diese Dienste entwickelt, und ein allgemeiner E-Mail-Hoster kann diese Aufgaben nicht ebenso gut erfüllen.
Unsere täglichen Grenzen sind auf Korrespondenz statt auf Kampagnen ausgelegt: 1.000 Nachrichten pro Postfach und Tag bei Starter, bis zu 2.500 bei Agency. Die Transaktionsmails eines kleinen Shops oder Buchungssystems bleiben problemlos in diesem Rahmen. Eine Plattform mit hohem Volumen tut das nicht. Dort ist ein über ein individuelles SMTP-Profil angebundener Transaktionsmail-Anbieter die richtige Architektur. E-Mail-Hosting und Massenversand bleiben getrennt, ohne dass Sie zwei Anbieter für Ihre Postfächer benötigen.
Prüfen, ob der Versand wirklich funktioniert
Da diese Art von Versand unbemerkt scheitert, sollten Sie die Zustellung überprüfen, statt sie einfach vorauszusetzen.
Lösen Sie eine echte Nachricht aus: Geben Sie eine Testbestellung auf oder fordern Sie einen Passwort-Reset an. Senden Sie die Nachricht an Adressen bei zwei verschiedenen großen Anbietern. Öffnen Sie die Kopfzeilen und prüfen Sie, ob SPF und DKIM bestanden wurden und DMARC eine Übereinstimmung meldet. Sind alle drei Prüfungen erfolgreich, ist die Einrichtung tatsächlich abgeschlossen.
Wiederholen Sie diese Kontrolle vierteljährlich und sofort nach Änderungen am DNS oder einem Hostingwechsel. Transaktionsmails gehen meistens nicht bei der Ersteinrichtung kaputt, sondern wenn sich etwas in ihrer Umgebung ändert. Nach dem Wechsel eines Nameservers denkt kaum jemand daran, die Bestellbestätigungen erneut zu testen.
Wenn Nachrichten ankommen, aber im Spam landen, zeigen die Zustellstatistiken der Domain und vorhandene DMARC-Berichte die Ursache meist schneller als versuchsweise Änderungen am Inhalt.
