Jemand füllt Ihr Kontaktformular aus. Die Seite bestätigt es: „Danke, wir melden uns bei Ihnen.“ Die Person schließt den Tab und wartet auf Ihre Antwort.
Sie rufen nie zurück, weil Sie die Nachricht nie erhalten haben. Keine E-Mail kam an, weder an diesem Tag noch später. Der Interessent wartet eine Weile und sucht dann das nächste Unternehmen, dessen Formular tatsächlich funktioniert. Nichts auf dem Bildschirm hat einem von Ihnen beiden gezeigt, dass etwas schiefgelaufen ist.
Wie WordPress diese E-Mail tatsächlich versendet
Hier die Technik dahinter, einfach erklärt. Wenn jemand ein WordPress-Formular absendet, ruft die Website eine Funktion namens wp_mail auf, die die Nachricht standardmäßig an die eingebaute PHP-Funktion mail() übergibt statt an einen eigenen E-Mail-Dienst. PHP mail meldet sich nirgends an, weist nicht nach, dass wirklich Sie der Absender sind, und läuft nicht über die Art verifizierter Infrastruktur, die Gmail oder Outlook von einem seriösen Absender erwarten. Es bittet einfach Ihren Webserver, eine E-Mail vor die Tür zu schieben, und hofft das Beste. Früher reichte das. Heute kaum noch, weil E-Mail-Anbieter ihre Abwehr genau gegen diese Art von nicht authentifiziertem, lieblosem Versand verschärft haben, und ein einfacher mail()-Aufruf die Hürde nur selten nimmt.
Die E-Mail gibt vor, von Ihnen zu kommen, und niemand glaubt es
Ihr Kontaktformular ist meist so eingestellt, dass es „von“ einer Adresse wie you@yoursite.com sendet, oder von einer Adresse, die es gar nicht gibt, etwa wordpress@yoursite.com. Das Absenderfeld behauptet, Sie seien es, aber der Server, der tatsächlich sendet, wurde nie dazu berechtigt, E-Mails im Namen Ihrer Domain zu verschicken. Jeder große E-Mail-Anbieter prüft diese Berechtigung inzwischen. Fehlt sie, schicken die Anbieter die Nachricht nicht mit einer klaren Fehlermeldung zurück, die Ihnen auffallen würde. Sie verwerfen sie stillschweigend oder legen sie irgendwo ab, wo Sie nie nachsehen. Ihre Website ist nicht auf eine Weise kaputt, die Sie beim Draufschauen bemerken würden. Sie stellt eine Behauptung auf, die sie nicht belegen kann, und die Anbieter glauben ihr das nicht mehr einfach so.
Ihr Hoster verschickt die E-Mails nicht, oder nur wenige
Nicht jeder Hosting-Tarif erlaubt einer Website, frei E-Mails zu versenden. Gerade beim Shared Hosting ist oft begrenzt, wie viele Nachrichten eine Domain pro Stunde senden darf, oder die PHP-Mailfunktion ist ganz gesperrt, weil ein anderer Kunde auf demselben Server sie einmal für Spam genutzt hat und der Anbieter die ganze Funktion abgeschaltet hat. Gehört Ihr Hoster zu den strengen, kann Ihr Formular völlig in Ordnung aussehen (die Seite bestätigt, der Code läuft fehlerfrei), während der eigentliche Versand verschluckt wird, bevor er das Gebäude überhaupt verlässt. Eine Fehlermeldung sehen Sie nicht, weil der Fehler auf einer Infrastruktur passiert, in die Sie keinen Einblick haben.
Ihre Domain kann nicht beweisen, dass die E-Mail echt ist
Selbst wenn die E-Mail tatsächlich verschickt wird, prüfen die empfangenden Anbieter DNS-Einträge namens SPF und DMARC, um zu entscheiden, ob sie ihr vertrauen. Zusammen legen sie für Ihre Domain fest, welche Server in ihrem Namen E-Mails senden dürfen und was ein empfangender Server mit einer Nachricht tun soll, die diese Prüfung nicht besteht. Auf einer WordPress-Website, bei der niemand sie bewusst eingerichtet hat, fehlen sie oft oder sind falsch konfiguriert, und E-Mails von Ihrer Domain sehen dann genau aus wie die Art von Nachricht, die diese Systeme herausfiltern sollen.
Es hat funktioniert, bis ein Update etwas verändert hat
Der WordPress-Kern, Ihr Theme und jedes Plugin auf der Website werden jeweils nach eigenem Zeitplan aktualisiert, und jedes davon kann unbemerkt verändern, wie E-Mails versendet werden. Ein Update des Formular-Plugins tauscht dessen Mail-Bibliothek aus. Ein Sicherheits-Plugin blockiert plötzlich eine ausgehende Verbindung, die es vorher erlaubt hat. Ein Caching-Plugin zeigt weiter die alte Bestätigungsseite an, obwohl der Versand im Hintergrund längst fehlschlägt. Nichts davon erscheint als Fehler in Ihrem Dashboard, weil das Formular aus Sicht von WordPress erfolgreich abgesendet wurde. Was still und leise aufgehört hat zu funktionieren, ist die Schicht darunter, und ein Update ist der häufigste Grund, warum sich diese Schicht verschiebt, ohne dass jemand bewusst daran etwas ändert.
Der 10-Minuten-Test
Bevor Sie irgendetwas reparieren, prüfen Sie, was tatsächlich passiert. Das dauert etwa zehn Minuten und zeigt Ihnen, mit welchem der oben beschriebenen Fehler Sie es zu tun haben.
- Senden Sie einen echten Test ab, und zwar mit einer E-Mail-Adresse, die nicht von Gmail ist: eine Arbeitsadresse, ein Outlook-Konto, was Sie eben haben. Der Spamfilter von Gmail ist für sich genommen schon so streng, dass ein reiner Gmail-Test ein Problem verbergen kann, das ein anderer Anbieter aufgedeckt hätte.
- Prüfen Sie den Spam- oder Junk-Ordner, nicht nur den Posteingang, bei der Adresse, mit der Sie getestet haben. Eine Nachricht im Spam ist ein anderes Problem als eine Nachricht, die nie angekommen ist, und sie verweist eher auf den Abschnitt zu SPF und DMARC oben als auf eine Sperre beim Hoster.
- Sehen Sie sich das tatsächliche Mail-Log an, nicht die Bestätigungsmeldung. Die meisten Hoster bieten ein Mail-Log in cPanel oder in ihrem Control Panel, oder Sie installieren ein kostenloses Plugin wie WP Mail Logging, das jede E-Mail aufzeichnet, die WordPress zu senden versucht, und ob es geklappt hat. Allein dieser Schritt zeigt Ihnen, ob WordPress es überhaupt versucht hat.
- Senden Sie einen zweiten Test an einen anderen Anbieter. Kommt die Nachricht bei Outlook an, aber nicht bei Gmail, ist das ein starkes Zeichen dafür, dass es um ein Authentifizierungsproblem geht, das damit zusammenhängt, wie ein bestimmter Anbieter Ihre Domain bewertet, und nicht um eine pauschale Sperre beim Hoster.
- Prüfen Sie Ihre Domain mit dem Website-Gesundheitscheck. Er prüft Ihre SPF- und DMARC-Einträge (nicht DKIM, dafür ist eine andere Art von Abfrage nötig) und sagt Ihnen in weniger als einer Minute, ob Ihre Domain so eingerichtet ist, dass sie die Echtheit ihrer E-Mails nachweisen kann. Eine Warnung dort erklärt meist alles, was oben steht.
Die ehrlichen Lösungen
Sobald Sie wissen, mit welchem Fehler Sie es zu tun haben, läuft die Lösung meist auf eine von wenigen Möglichkeiten hinaus. Keine davon ist ein Trick; jede ist ein echter Weg, das Problem zu lösen.
Installieren Sie ein SMTP-Plugin. Das ist die Standardantwort von Entwicklern, und sie ist berechtigt. Ein SMTP-Plugin leitet Ihre ausgehenden E-Mails über einen echten E-Mail-Dienst statt über die PHP-Funktion mail(), was das Authentifizierungsproblem an der Wurzel behebt, weil die E-Mails jetzt tatsächlich von einer Infrastruktur kommen, der die Anbieter bereits vertrauen. Das dauert etwa zwanzig Minuten, wenn Sie sich zutrauen, einen API-Schlüssel zu erstellen und in eine Einstellungsseite einzufügen. Wenn nicht, ist es eine überschaubare Stunde Arbeit, die Sie einem Entwickler übergeben können.
Wechseln Sie zu einem Formulardienst. Werkzeuge, die speziell für die Verarbeitung von Formulareinsendungen gebaut wurden, statt als Plugin an wp_mail angehängt zu sein, verschicken Benachrichtigungen oft über ihre eigene verifizierte Versandinfrastruktur und umgehen so das ganze Problem. Sie geben etwas Kontrolle über das genaue Aussehen und Verhalten des Formulars ab. Dafür bekommen Sie einen Dienst, dessen einzige Aufgabe es ist, dafür zu sorgen, dass die Nachricht ankommt.
Lassen Sie jemanden die Website für Sie betreuen. Wenn Sie lieber nicht lernen möchten, wofür SPF steht, ist das eine völlig berechtigte Haltung und kein Versäumnis Ihrerseits. Genau diese Art von Wartung fällt bei einer selbst verwalteten WordPress-Website durchs Raster: Niemand merkt es, bis ein Interessent stattdessen die Konkurrenz anruft. Wenn Sie nicht mehr diejenige Person sein möchten, die jedes Mal ein Mail-Log prüft, sobald ein Update etwas kaputt macht, springen Sie direkt zur Option, sich nie wieder darum kümmern zu müssen.
Warum das immer wieder kaputtgeht
Eine WordPress-Website ist nichts, das man fertigstellt. Sie ist ein Stapel unabhängig voneinander aktualisierter Teile (der Kern, das Theme, ein Dutzend Plugins, der Hoster unter alldem), und jedes davon kann den Boden verschieben, auf dem die anderen stehen. Ein Plugin-Update in sechs Monaten kann genau dieses Formular auf eine völlig andere Weise erneut lahmlegen, und das wird dann genauso wenig Ihre Schuld sein wie jetzt. Das ist der Preis dafür, Software zu betreiben, die niemand aktiv im Blick behält. Der extremste Fall, den wir gesehen haben, hatte nicht einmal mit einem Formular zu tun: 32 versteckte Spam-Links waren in den WordPress-Code eines von Veteranen geführten Umzugsunternehmens eingeschleust worden, unsichtbar auf der Seite, und drückten still und leise dessen Suchmaschinen-Rankings, bis ein Audit sie entdeckte. Ein kaputtes Kontaktformular ist der Fehler, den man bemerkt, weil keine Anfragen mehr kommen. Viele WordPress-Fehler werden überhaupt nie bemerkt.
Wenn Sie das nie wieder selbst debuggen möchten
Wenn Sie nicht diejenige Person sein möchten, die jedes Mal Mail-Logs durchsieht und DNS-Einträge liest, wenn das hier kaputtgeht, dann ist genau das die Aufgabe, die Surmado Sites als Teil der Website-Betreuung übernimmt: Hosting und E-Mail-Zustellung, dazu die Wartung, die verhindert, dass eine Lösung beim nächsten Update wieder aufgeht. Sie bitten einmal darum, in einfachen Worten, und es bleibt behoben.
Häufige Fragen
Warum meldet das Formular „gesendet“, wenn nichts ankommt?
Die Bestätigung „Nachricht gesendet“ erzeugt WordPress in dem Moment, in dem das Formular abgeschickt und wp_mail aufgerufen wird. Sie wartet nicht auf eine Rückmeldung eines Mailservers, ob die Nachricht tatsächlich zugestellt wurde, weil die meisten Kontaktformular-Setups nicht dafür gebaut sind, das zu prüfen. Die Bestätigung bedeutet, dass WordPress den Versand versucht hat. Sie bedeutet nicht, dass jemand die Nachricht erhalten hat.
Landen die Einsendungen im Spam?
Manchmal, aber nicht immer. Wenn Ihre SPF- oder DMARC-Einträge falsch konfiguriert sind, landen E-Mails, die tatsächlich verschickt werden, oft im Spam, weil die empfangenden Anbieter nicht prüfen können, ob sie wirklich von Ihrer Domain stammen. Blockiert Ihr Hoster den Versand komplett, oder stoppt ein Plugin-Konflikt ihn, bevor er Ihren Server verlässt, wird die E-Mail gar nicht erst verschickt und liegt daher auch nicht im Spam. Ein Blick in ein Mail-Log oder in das Ergebnis Ihres Website-Gesundheitschecks zeigt Ihnen, in welcher Situation Sie sich tatsächlich befinden.
Warum hat es nach einem Update aufgehört zu funktionieren?
Weil irgendetwas in dieser Update-Kette verändert hat, wie oder ob E-Mails verschickt werden, und keine dieser Änderungen irgendwo in WordPress als sichtbarer Fehler erscheint. Selten ist es das Plugin, das man zuerst verdächtigt. Deshalb lohnt es sich, das Mail-Log direkt nach jedem Update zu prüfen: Das kostet zwei Minuten, bevor Sie blind mit der Fehlersuche beginnen.
Brauche ich ein SMTP-Plugin?
Nicht immer, aber oft, ja. Wenn die SPF- und DMARC-Einträge Ihrer Domain in Ordnung sind und das eigentliche Problem ein Hoster ist, der PHP-Mail blockiert oder begrenzt, ist ein SMTP-Plugin, das E-Mails über einen echten E-Mail-Dienst leitet, die direkteste Lösung. Liegt das Problem bei den DNS-Einträgen, beheben Sie zuerst diese; eine neue Versandmethode hilft nicht, wenn die Domain selbst immer noch nicht nachweisen kann, dass sie echt ist. So oder so ist ein SMTP-Plugin eine echte, verbreitete Lösung und kein Notbehelf, aber eben auch eine weitere Sache, die eingerichtet und am Laufen gehalten werden muss, und genau diesen Teil nimmt Ihnen ein Formulardienst oder eine betreute Website ab.