Warum die Nachricht aus deinem Kontaktformular nicht ankommt

Das Formular meldet „Vielen Dank, deine Nachricht wurde gesendet." Im Postfach liegt nichts.

Beides ist gleichzeitig wahr, und darin liegt das ganze Problem. Die Website hat die Nachricht abgegeben. Was danach passiert ist, hat sie nie erfahren.

Wenn du diesen Artikel liest, weil ein Kunde dir gesagt hat, er habe sich gemeldet und nie eine Antwort bekommen: Das ist keine Kleinigkeit. Jede Anfrage, die verschwindet, ist ein Auftrag, den jemand anders bekommen hat.

Was „gesendet" tatsächlich bedeutet

Eine Website verschickt keine E-Mails. Sie übergibt eine Nachricht an etwas anderes, das verschicken soll.

Die Erfolgsmeldung im Formular sagt nur: Die Übergabe hat geklappt. Sie sagt nichts darüber, ob die Nachricht das Haus verlassen hat, ob sie unterwegs angenommen wurde, oder ob sie am Ziel in einem Ordner gelandet ist, in den niemand schaut.

Das ist keine Nachlässigkeit im Formular. Es liegt daran, dass die Website an dieser Stelle wirklich nichts mehr erfährt — die Antwort kommt Sekunden bis Stunden später, an einem anderen Ort, und niemand hört dann noch zu.

Die Kette hat vier Stationen

Erstens übergibt das Formular an die Website. Zweitens übergibt die Website an einen Versandweg. Drittens entscheidet der Server des Empfängers, ob er die Nachricht annimmt. Viertens entscheidet das Postfach, in welchen Ordner sie kommt.

Ausfallen kann jede Station. Melden tut sich keine.

Station zwei ist die häufigste Ursache

Die eingebaute Versandfunktion, die viele Systeme standardmäßig benutzen, ist die schwächste Stelle der Kette.

Sie setzt voraus, dass auf dem Server selbst ein Maildienst läuft. Auf vielen Paketen ist das der Fall, auf manchen nicht. Ist keiner da, wird nichts verschickt — und die Website merkt es nicht.

Und selbst wenn einer da ist, verschickt er unter der Identität des Servers, nicht unter der deiner Domain. Für den Empfänger sieht das aus wie Post von einem Absender, der behauptet, für dich zu sprechen.

Das ist der Grund, warum diese Funktion allgemein als ungeeignet gilt. Sie ist umständlich zu konfigurieren, sie verlangt Handarbeit an Stellen, die eine ordentliche Versandbibliothek von selbst erledigt, und sie ist die Ursache eines großen Teils aller nicht angekommenen Formularnachrichten.

Der Fehler, den fast jedes selbstgebaute Formular macht

Hier wird es konkret, und dieser Punkt allein erklärt viele Fälle.

Ein Formular fragt nach der E-Mail-Adresse des Besuchers. Naheliegend ist, diese Adresse als Absender der Benachrichtigung einzutragen — dann kann man im Postfach direkt auf „Antworten" klicken.

Das ist bequem und technisch falsch.

Denn damit verschickt dein Server eine Nachricht, die behauptet, von einer fremden Domain zu kommen. Der empfangende Server prüft, ob dein Server dazu berechtigt ist. Er ist es nicht — er kann es gar nicht sein, weil die fremde Domain nichts von ihm weiß.

Und selbst wenn deine eigene Domain sauber eingerichtet ist, hilft das hier nicht: Die Prüfung verlangt, dass die sichtbare Absenderdomain zu der Domain passt, die den Versand freigegeben hat. Steht im Absenderfeld eine fremde Adresse, passt nichts zusammen. Die Prüfung schlägt fehl, obwohl deine Einträge in Ordnung sind.

Richtig ist: Als Absender steht deine eigene Adresse. Die Adresse des Besuchers steht im Antwort-an-Feld. Der Antworten-Knopf funktioniert genauso, und die Prüfung geht durch.

Das ist eine Einstellung, kein Umbau. Und sie ist an erschreckend vielen Formularen falsch gesetzt.

Station drei entscheidet anhand deiner Domain

Was danach passiert, hängt nicht mehr an deiner Website, sondern an Einträgen bei deiner Domain. Ob der versendende Server für dich sprechen darf, ob die Nachricht unterwegs unverändert blieb, und was mit ihr geschehen soll, wenn eine dieser Prüfungen nicht aufgeht.

Das ist ein eigenes Thema und steht in einem eigenen Artikel. Für hier reicht ein Satz: Ein Formular kann technisch einwandfrei sein und trotzdem nichts zustellen, wenn diese Einträge fehlen oder nicht zum Versandweg passen.

Station vier: dein eigenes Postfach

Der unspektakulärste Fall, und er kommt oft genug vor, um ihn zuerst zu prüfen.

Nachrichten, die immer gleich aussehen, immer vom selben Absender kommen und nie beantwortet werden, wandern nach einer Weile in den Spam-Ordner. Oder eine Filterregel, die vor Jahren jemand angelegt hat, sortiert sie in einen Unterordner, in den niemand mehr schaut.

Bevor du irgendetwas an der Website änderst: Sieh im Spam-Ordner nach und prüfe deine Filterregeln.

Die zwei ordentlichen Versandwege

Es gibt zwei Wege, die tatsächlich funktionieren, und sie unterscheiden sich in dem, was sie dir zurückgeben.

Der erste Weg: die Website meldet sich bei einem echten Mailserver an und übergibt die Nachricht dort — mit Adresse, Zugangsdaten und verschlüsselter Verbindung, so wie ein Mailprogramm es auch tut. Die Nachricht geht dann unter der Identität deiner Domain raus, weil sie tatsächlich von deinem Postfach kommt.

Das ist der naheliegende Weg. Er ist in wenigen Minuten eingerichtet und löst die meisten Fälle.

Der zweite Weg: ein Versanddienst, der auf nichts anderes spezialisiert ist. Die Website übergibt dort über eine Schnittstelle. Das ist schneller als der erste Weg, weil keine Anmeldung an einem Mailserver stattfindet, und es skaliert besser.

Der Preis dafür: Damit ein solcher Dienst unter deiner Domain verschicken darf, müssen bei der Domain Einträge gesetzt werden. Das ist der aufwendigere Teil der Einrichtung, und er ist der Grund, warum viele beim ersten Weg bleiben.

Was der zweite Weg dafür zurückgibt

Und hier liegt der Punkt, der die Sache interessant macht: ein Protokoll.

Ein Mailserver allein sagt dir nicht, was aus einer Nachricht geworden ist. Er nimmt sie an, und danach herrscht Stille. Ein Versanddienst führt Buch: zugestellt, abgelehnt, unzustellbar. Bei einer Ablehnung steht der Grund dabei.

Besonders wertvoll ist eine Kategorie davon: die Nachricht an eine Adresse, die es nicht gibt. Der empfangende Server lehnt sie hart ab, und der Versanddienst schreibt das auf.

Das schließt eine Lücke, die im Formular selbst nicht zu schließen ist. Beim Ausfüllen lässt sich nämlich mit keinem Verfahren feststellen, ob eine eingetippte Adresse existiert. Ein Tippfehler in der eigenen Adresse sieht aus wie eine gültige Eingabe. Erst der Versuch, dorthin zu antworten, bringt es heraus — und ohne Protokoll erfährst du auch das nie.

Solche Meldungen lassen sich automatisch entgegennehmen, statt sie in einer Oberfläche zu suchen. Dann bekommst du Bescheid, wenn eine Antwort nicht zustellbar war, statt es für einen Kunden zu halten, der sich nicht mehr meldet.

Wie du das in zwanzig Minuten selbst eingrenzt

Der Reihe nach, und die Reihenfolge ist keine Willkür — sie geht vom Billigsten zum Aufwendigsten.

Erstens: Spam-Ordner und Filterregeln. Kostet zwei Minuten und erklärt einen Teil aller Fälle.

Zweitens: Fülle das Formular von außen aus. Nicht angemeldet, nicht mit deiner eigenen Adresse als Absender, sondern so, wie ein Fremder es täte. Kommt etwas an?

Drittens: Sieh dir die Kopfzeilen der angekommenen Nachricht an. In den meisten Postfächern gibt es dafür eine Ansicht, die das Original zeigt. Dort steht, welcher Server verschickt hat und ob die Prüfungen bestanden wurden. Steht dort dreimal „bestanden", liegt es nicht am Versand.

Viertens: Sieh im Formular nach, was als Absender eingetragen ist. Steht dort die Adresse des Besuchers, hast du die Ursache gefunden.

Fünftens: Prüfe, welchen Versandweg die Website benutzt. Steht dort nichts, benutzt sie die eingebaute Funktion — und die ist der wahrscheinlichste Verdächtige.

Was zu tun ist

Absender auf die eigene Adresse, Besucheradresse ins Antwort-an-Feld. Kostet nichts und behebt einen ganzen Fehlerfall.

Vom eingebauten Versand auf einen echten Mailserver umstellen. Der Standardweg, in wenigen Minuten erledigt, und er löst die Mehrzahl der übrigen Fälle.

Prüfen, ob die Einträge bei der Domain zum gewählten Versandweg passen. Das ist der Punkt, an dem eine sauber eingerichtete Domain trotzdem scheitern kann, wenn ein neuer Versandweg nicht eingetragen wurde.

Wenn Anfragen dein Geschäft sind: einen Versanddienst mit Protokoll nehmen. Nicht wegen der Geschwindigkeit, sondern weil du dann merkst, wenn etwas nicht ankommt — statt es nicht zu merken.

Und dann eine Erinnerung im Kalender. Ein Formular, das ein Jahr lang funktioniert hat, kann nach einem Serverumzug, einem Hosterwechsel oder einer Änderung an den Domain-Einträgen still aufhören zu funktionieren. Einmal im Quartal von außen ausfüllen dauert eine Minute.

Der Kern

Ein Kontaktformular ist keine abgeschlossene Sache, die man einmal einbaut. Es ist der Anfang einer Kette, deren restliche Glieder außerhalb der Website liegen.

Und es ist die einzige Funktion deiner Website, bei der ein Ausfall vollkommen lautlos ist. Eine kaputte Seite sieht man. Ein kaputtes Formular meldet „Vielen Dank".

Quellen

• Atlas, php/udemy-sending-email-with-php-from-basic-to-advanced/02 — dass die eingebaute Versandfunktion einen lokalen Maildienst voraussetzt, der nicht auf jedem System vorhanden ist; dass ihre Konfiguration Zugriff auf Serverdateien verlangt, über den man nicht immer verfügt; dass sie Zeilenumbrüche und Kopfzeilen von Hand erwartet, Anhänge umständlich macht und leicht Sicherheitslücken erzeugt; dass von ihrer direkten Verwendung abgeraten wird und verbreitete Systeme deshalb Versandbibliotheken einsetzen; sowie die Bestandteile einer Anmeldung an einem Mailserver — Adresse, Anschluss, Zugangsdaten und verschlüsselte Verbindung — und die Möglichkeit, bei Verbindungsproblemen eine ausführliche Protokollausgabe einzuschalten.
• Atlas, php/udemy-sending-email-with-php-from-basic-to-advanced/07 — dass ein Versanddienst neben der Anmeldung an einem Mailserver auch eine Schnittstelle anbietet, die schneller ist und besser skaliert; dass der Versand unter der eigenen Domain über diesen Weg das Setzen von Einträgen bei der Domain voraussetzt und dieser Teil aufwendig ist; dass ein Mailserver allein keine Nachverfolgung liefert, ein Versanddienst dagegen Zustellung, Ablehnung und Unzustellbarkeit protokolliert; dass eine harte Ablehnung bedeutet, dass die Adresse nicht existiert; und dass solche Ereignisse automatisch an eine eigene Adresse gemeldet werden können, statt sie in einer Oberfläche zu suchen.
• Atlas, services/email-deliverability/dmarc.md — dass die Prüfung nur dann besteht, wenn eine der beiden Freigaben besteht und die freigebende Domain zur sichtbaren Absenderdomain passt; dass eine bestandene Freigabe für die technische Absenderadresse trotzdem zu einem Fehlschlag führt, wenn sie nicht zur sichtbaren Absenderadresse passt; und dass genau diese Nichtübereinstimmung entsteht, wenn ein Versender unter seiner eigenen technischen Adresse verschickt, während im sichtbaren Absenderfeld eine andere Domain steht.
• Verweis statt Wiederholung — welche drei Einträge bei einer Domain den Versand freigeben und wie sie zusammenwirken, steht im Artikel über Mails, die im Spam landen. Warum ein Formular beim Ausfüllen grundsätzlich nicht feststellen kann, ob eine Adresse existiert, steht im Artikel über den Aufbau von Formularen.
• Eigene Prüfpraxis — die Reihenfolge der Eingrenzung vom Billigsten zum Aufwendigsten, der Hinweis zuerst im Spam-Ordner und in den Filterregeln nachzusehen, die Prüfung von außen mit fremder Adresse, das Lesen der Kopfzeilen der angekommenen Nachricht, und die vierteljährliche Wiederholung, weil ein Formular nach einem Umzug oder einer Änderung an den Domain-Einträgen still aufhören kann zu funktionieren.