Das Kontaktformular zeigt „Vielen Dank“. Der Besucher geht davon aus, dass seine Anfrage angekommen ist. Ihr Unternehmen geht davon aus, dass keine Anfrage gestellt wurde. Und irgendwo zwischen diesen beiden Annahmen verschwindet ein potenzieller Kunde.
Eine E-Mail, die technisch erzeugt wurde und anschließend niemals im richtigen Postfach landet, fällt häufig überhaupt nicht auf.
Die Website funktioniert aus Sicht des Besuchers schließlich scheinbar perfekt.
Und genau deshalb lohnt es sich, Kontaktformulare nicht nur als Gestaltungselement oder WordPress-Funktion zu betrachten. Hinter einem simplen „Absenden“-Button steckt eine komplette technische Prozesskette. Jede einzelne Station kann funktionieren und trotzdem kann das Gesamtergebnis falsch sein.
Noch wichtiger ist allerdings eine andere Erkenntnis:
Eine Kontaktanfrage ist ein Geschäftsvorgang. Die E-Mail ist lediglich ein Transportweg dafür.
„Erfolgreich versendet“ bedeutet noch lange nicht „angekommen“
Beginnen wir mit dem vermutlich größten Missverständnis.
- Ein Besucher füllt ein Kontaktformular aus und klickt auf „Absenden“.
- Die Website verarbeitet die Eingaben. Das Formular übergibt die Daten an WordPress beziehungsweise an das verwendete Formularsystem. Anschließend wird eine E-Mail erzeugt und an die konfigurierte Versandfunktion übergeben.
- Danach erscheint: „Vielen Dank. Ihre Nachricht wurde erfolgreich versendet.“
- Für den Besucher ist die Sache damit erledigt.
- Technisch ist sie es noch lange nicht.
WordPress weist bei seiner eigenen Mailfunktion wp_mail() ausdrücklich darauf hin, dass eine erfolgreiche Rückgabe lediglich bedeutet, dass die verwendete Versandmethode die Anfrage ohne Fehler verarbeiten konnte. Sie bestätigt ausdrücklich nicht, dass der Empfänger die Nachricht tatsächlich erhalten hat.
Das ist ein gewaltiger Unterschied.
Die Erfolgsmeldung Ihres Formulars kann also vollkommen korrekt sein, obwohl die Nachricht später:
- vom sendenden Mailserver abgelehnt wird,
- eine fehlerhafte Absenderkonfiguration besitzt,
- bei einer Authentifizierungsprüfung scheitert,
- vom Empfängerserver zurückgewiesen wird,
- im Spam landet,
- in einer Quarantäne verschwindet,
- durch eine interne Filterregel aussortiert wird.
Die Website weiß davon häufig nichts mehr.
Sie hat ihren Teil der Arbeit bereits erledigt.
Das ist ein bisschen so, als würde ein Paketdienst „erfolgreich zugestellt“ melden, sobald das Paket im Lieferwagen liegt. Für die Logistik wäre das eine ausgesprochen kreative Definition von Erfolg.
Der tatsächliche Weg einer Kontaktanfrage
Ein Kontaktformular sieht im Frontend simpel aus. Technisch läuft im Hintergrund deutlich mehr ab.
Vereinfacht sieht der Weg so aus:
- Der Besucher füllt das Formular aus.
- Die Website validiert die Eingaben.
- WordPress oder das Formularplugin verarbeitet die Daten.
- Eine E-Mail wird erzeugt.
- Die Nachricht wird an einen Mailserver übergeben.
- Der sendende Server authentifiziert sich beziehungsweise die verwendete Domain.
- Der empfangende Mailserver prüft Nachricht, Absender und Reputation.
- Die Nachricht wird angenommen, gefiltert oder abgelehnt.
- Erst danach landet sie im eigentlichen Postfach.
Zwischen dem Klick auf „Absenden“ und dem sichtbaren Eingang im Postfach liegen damit mehrere voneinander unabhängige Systeme.
- Das Formular kann funktionieren, während der Mailversand falsch konfiguriert ist.
- Der Mailversand kann funktionieren, während DKIM fehlt.
- DKIM kann korrekt sein, während die verwendete Absenderdomain nicht sauber ausgerichtet ist.
- Und selbst eine vollständig authentifizierte E-Mail besitzt keine Garantie auf den Posteingang. Reputation, Inhalt, Serverkonfiguration und Empfängerfilter spielen ebenfalls eine Rolle.
Deshalb reicht die Frage:
„Funktioniert das Kontaktformular?“
für einen vernünftigen technischen Test schlicht nicht aus.
Die richtige Frage lautet:
„Können wir den vollständigen Weg einer Anfrage vom Absenden bis zum tatsächlichen Eingang nachvollziehen?“
Das ist ein vollkommen anderer Qualitätsanspruch.
Der wichtigste Architekturfehler passiert noch vor dem Mailversand
Bevor wir über SPF, DKIM oder SMTP sprechen, sollten wir über etwas Grundsätzlicheres reden.
Viele Websites behandeln die versendete E-Mail gleichzeitig als Datenspeicher. Der Besucher sendet ein Formular ab. Daraus entsteht eine E-Mail. Diese E-Mail ist anschließend die einzige vorhandene Kopie der Anfrage.
Kommt sie nicht an, existiert der Lead praktisch nicht mehr.
Das halte ich bei geschäftlich relevanten Formularen für die falsche Architektur.
Eine Anfrage sollte zuerst gespeichert werden
Bei einem vernünftig aufgebauten System sollte eine Kontaktanfrage zunächst serverseitig gespeichert werden, zum Beispiel:
- innerhalb eines geschützten WordPress-Bereichs,
- in einem CRM,
- in einem Ticketsystem,
- in einer dafür vorgesehenen Datenbankstruktur.
Erst anschließend sollte die E-Mail als Benachrichtigung verschickt werden.
Damit verändert sich die gesamte Risikostruktur.
- Scheitert der E-Mail-Versand, bleibt die Anfrage trotzdem erhalten.
- Ein Mitarbeiter kann sie weiterhin sehen.
- Der Versand kann erneut ausgelöst werden.
- Fehler lassen sich nachvollziehen.
Und vor allem verschwindet ein Lead nicht einfach aus dem Unternehmen, nur weil irgendein Mailserver an einem Dienstagmorgen schlechte Laune hatte.
Die E-Mail sollte Benachrichtigung sein, nicht Datenbank
Das ist für mich der zentrale Punkt dieses gesamten Themas:
Kontaktanfrage und Benachrichtigungs-E-Mail sind zwei verschiedene Dinge.
Die Kontaktanfrage ist ein Datensatz. Die E-Mail informiert darüber, dass dieser Datensatz eingegangen ist. Wer diese beiden Funktionen sauber trennt, kann einen großen Teil des Risikos bereits auf Architekturebene lösen. Natürlich müssen dabei Datenschutz, Aufbewahrungsdauer und Zugriffsrechte berücksichtigt werden. Genau deshalb gehört ein solches System sauber geplant.
Eine geschäftlich wichtige Anfrage ausschließlich einer E-Mail anzuvertrauen, ist technisch ungefähr so robust wie Buchhaltung auf Klebezetteln.
Warum WordPress beim E-Mail-Versand besondere Aufmerksamkeit braucht
WordPress ist ein Content-Management-System. Es ist kein Mailserver.
WordPress stellt mit wp_mail() eine Schnittstelle für den Versand bereit. Die eigentliche Zustellung hängt anschließend von der Mailumgebung des Servers beziehungsweise einer angebundenen Versandlösung ab. Die WordPress-Dokumentation beschreibt ausdrücklich, dass WordPress selbst keinen vollständigen Mail Transfer Agent bereitstellt.
Bei einer Standardinstallation kann der Versand über die Mailfunktion des Hostingservers erfolgen.
Das kann funktionieren.
Für geschäftskritische Formulare würde ich mich darauf allerdings nicht blind verlassen.
SMTP schafft einen kontrollierteren Versandweg
Deshalb werden WordPress-Websites häufig an einen definierten SMTP-Dienst oder einen spezialisierten Transaktionsmail-Anbieter angebunden.
Der Vorteil liegt weniger in den vier Buchstaben SMTP als in der nachvollziehbaren Infrastruktur dahinter.
Ein sauber eingerichtetes System kann beispielsweise:
- einen authentifizierten Versand ermöglichen,
- eine definierte Absenderdomain verwenden,
- Zustellversuche protokollieren,
- Fehlermeldungen sichtbar machen,
- Bounce-Rückmeldungen liefern,
- DKIM korrekt einsetzen.
Aber auch hier gilt:
Ein SMTP-Plugin allein löst das Problem nicht automatisch.
Wenn die DNS-Einträge falsch sind, die falsche Absenderdomain verwendet wird oder die Domainausrichtung bei DMARC scheitert, kann die schönste SMTP-Konfiguration der Welt nur begrenzt helfen.
Der Transportweg und die Identität des Absenders müssen zusammenpassen.
Und damit landen wir bei drei Abkürzungen, die Unternehmen wenigstens einmal verstanden haben sollten.
SPF, DKIM und DMARC verständlich erklärt
SPF, DKIM und DMARC werden gerne wie drei technische Zaubersprüche behandelt. Dabei verfolgen alle drei im Kern eine einfache Frage:
Darf diese E-Mail wirklich im Namen dieser Domain verschickt werden?
SPF: Wer darf für meine Domain senden?
SPF steht für Sender Policy Framework.
Im DNS einer Domain wird hinterlegt, welche Server beziehungsweise Versanddienste berechtigt sind, E-Mails für diese Domain zu versenden. Der Empfänger kann dadurch prüfen, ob der sendende Server überhaupt vorgesehen ist.
Das wird besonders wichtig, wenn mehrere Systeme E-Mails verschicken.
Zum Beispiel:
- Microsoft 365 für normale Mitarbeiter-E-Mails,
- ein Newsletter-System,
- ein CRM,
- ein Onlineshop,
- die WordPress-Website.
All diese Systeme müssen bei der Konfiguration berücksichtigt werden.
Ein SPF-Eintrag, der nur den normalen Firmen-Mailserver kennt, hilft wenig, wenn das Kontaktformular seine Nachrichten über einen vollkommen anderen Dienst verschickt.
DKIM: Wurde diese Nachricht autorisiert und verändert?
DKIM steht für DomainKeys Identified Mail.
Dabei versieht der sendende Mailserver die Nachricht mit einer kryptografischen Signatur. Der öffentliche Teil des Schlüssels liegt im DNS der Domain. Der Empfänger kann damit prüfen, ob die Signatur gültig ist und ob relevante Bestandteile der Nachricht nach dem Signieren verändert wurden. DKIM schafft damit eine überprüfbare Verbindung zwischen Nachricht und signierender Domain.
Für eine professionelle Mailinfrastruktur gehört DKIM heute schlicht zum technischen Fundament.
DMARC: Passt die sichtbare Absenderdomain zur Authentifizierung?
DMARC verbindet SPF und DKIM mit der Domain, die der Empfänger tatsächlich im sichtbaren Absender sieht.
Und genau an dieser Stelle passieren viele Fehler.
Eine Nachricht kann technisch über einen legitimen Mailserver versendet werden und trotzdem bei DMARC scheitern, wenn die beteiligten Domains nicht richtig zueinander passen.
Diese sogenannte Domain Alignment ist entscheidend.
DMARC ermöglicht außerdem eine Richtlinie dafür, wie Empfänger mit Nachrichten umgehen sollen, bei denen die Authentifizierung scheitert. Zusätzlich können Berichte bereitgestellt werden, die zeigen, welche Systeme überhaupt im Namen einer Domain E-Mails versenden.
Das ist nicht nur für die Zustellbarkeit interessant. Es schützt eine Domain gleichzeitig besser vor Missbrauch und Spoofing.
Google und Microsoft machen E-Mail-Authentifizierung zunehmend verbindlich
Die Entwicklung der letzten Jahre ist ziemlich eindeutig. Mailbox-Anbieter vertrauen einer E-Mail nicht mehr einfach deshalb, weil irgendwo eine Absenderadresse hineingeschrieben wurde.
Für Nachrichten an private Gmail-Adressen verlangt Google seit Februar 2024 auch von normalen Absendern mindestens SPF oder DKIM.
Wer mehr als 5.000 Nachrichten pro Tag an Gmail-Adressen versendet, muss SPF und DKIM einsetzen und zusätzlich DMARC konfigurieren.
Interessant für normale Unternehmenswebsites ist allerdings noch etwas anderes:
Google empfiehlt ausdrücklich, SPF, DKIM und DMARC grundsätzlich einzurichten und nennt dabei sogar explizit Domains, auf denen öffentliche Websites betrieben werden.
Das betrifft damit eben nicht nur Newsletter-Plattformen mit Millionen von Nachrichten. Eine Unternehmensdomain ist digitale Identität. Website, E-Mail und Domainreputation gehören technisch längst enger zusammen, als viele Websiteprojekte vermuten lassen.
Microsoft
Microsoft hat seine Anforderungen ebenfalls verschärft.
Für Domains, die mindestens 5.000 Nachrichten an Microsofts Consumer-Maildienste wie Outlook.com, Hotmail, Live.com oder MSN senden, gelten erhöhte Authentifizierungsanforderungen.
SPF und DKIM müssen bestehen. Zusätzlich wird ein DMARC-Eintrag verlangt und die Nachricht muss die notwendige DMARC-Ausrichtung erreichen. Microsoft dokumentiert inzwischen auch die Ablehnung entsprechender Nachrichten mit dem Fehler 550 5.7.515, wenn die erforderliche Authentifizierung nicht erfüllt wird. Eine normale Handwerksfirma mit drei Kontaktanfragen am Tag fällt dadurch selbstverständlich nicht plötzlich in die Kategorie der High-Volume-Sender.
Die Entwicklung zeigt trotzdem sehr deutlich, wohin sich E-Mail bewegt:
Absender müssen technisch beweisen können, dass sie wirklich die Absender sind, die sie vorgeben zu sein.
Darauf sollte eine Unternehmenswebsite vorbereitet sein.
So teste ich ein Kontaktformular sinnvoll
Ein vernünftiger Test beginnt immer dort, wo später auch der Kunde beginnt.
Schritt 1: Das echte Formular verwenden
Das Formular wird im Frontend ausgefüllt und vollständig abgesendet.
Dabei sollten auch Pflichtfelder, Datenschutzcheckboxen, Uploads und sonstige Funktionen genauso genutzt werden wie bei einer echten Anfrage.
Schritt 2: Prüfen, ob die Anfrage gespeichert wurde
Wenn das System Anfragen intern speichert, sollte jetzt unmittelbar ein Datensatz vorhanden sein.
Damit wissen Sie bereits:
Das Formular hat die Daten tatsächlich verarbeitet.
Schritt 3: Versandprotokoll kontrollieren
Das verwendete Mailsystem sollte idealerweise zeigen können:
- wann die Nachricht erzeugt wurde,
- an welche Adresse sie ging,
- welcher Versandweg genutzt wurde,
- ob der Server die Nachricht akzeptiert hat,
- ob ein Fehler zurückgemeldet wurde.
Ein Log ersetzt keine Zustellbestätigung.
Aber es macht den Prozess zumindest sichtbar.
Schritt 4: Mehrere Empfänger testen
Ein Test an die eigene Firmenadresse reicht kaum aus.
Ich würde mindestens unterschiedliche Mailumgebungen einbeziehen, beispielsweise:
- Gmail,
- Outlook beziehungsweise Microsoft,
- die eigene Unternehmensdomain.
Damit fallen Empfängerprobleme wesentlich schneller auf.
Schritt 5: Mailheader ansehen
Bei einer tatsächlich angekommenen Testmail lohnt sich ein Blick in die technischen Header.
Dort lassen sich unter anderem Ergebnisse für SPF, DKIM und DMARC erkennen.
Interessant sind dabei Werte wie:
spf=pass
dkim=pass
dmarc=pass
Das ist wesentlich aussagekräftiger als ein beliebiger Onlinecheck, der lediglich prüft, ob im DNS irgendwo entsprechende Einträge vorhanden sind.
Denn ein vorhandener DKIM-Eintrag beweist noch lange nicht, dass die konkrete E-Mail tatsächlich mit dem passenden Schlüssel signiert wurde.
Schritt 6: Spamordner und Quarantäne berücksichtigen
Eine E-Mail kann vom Empfänger angenommen worden sein und anschließend trotzdem durch lokale Regeln aussortiert werden.
Gerade Unternehmenssysteme besitzen häufig weitere Sicherheitslösungen vor dem eigentlichen Postfach.
Der Test endet deshalb erst dort, wo ein Mitarbeiter die Anfrage tatsächlich sehen kann.
Warum dieses Thema eigentlich Conversion-Optimierung ist
E-Mail-Zustellung klingt zunächst wie ein Thema für Administratoren.
Für mich gehört es genauso in die Conversion-Optimierung.
Denn was bringt eine Website, die:
- hervorragend rankt,
- Besucher über Google Ads einkauft,
- Vertrauen aufbaut,
- den Nutzer zum Kontaktformular führt,
wenn die Anfrage anschließend im letzten technischen Meter verloren geht?
Unternehmen beschäftigen sich ausführlich mit Buttonfarben, Headlines, Formularlängen und Call-to-Actions.
Alles sinnvoll.
Nur sollte die Conversion nach dem Klick auf „Absenden“ nicht plötzlich aufhören.
Eine Conversion ist erst dann wirklich abgeschlossen, wenn die Anfrage im Unternehmen angekommen ist und verarbeitet werden kann.
Der technische Prozess dahinter gehört deshalb genauso zur Customer Journey wie Landingpage, Formular und Dankeseite.
Eine robuste Kontaktstrecke braucht mehr als ein Formular
Für geschäftlich relevante Websites würde ich heute vier Ebenen voneinander trennen.
Ebene 1: Formular
Das Frontend nimmt die Daten sauber entgegen und validiert sie.
Ebene 2: Speicherung
Die Anfrage wird persistent gespeichert und erhält einen nachvollziehbaren Zeitstempel beziehungsweise Status.
Ebene 3: Benachrichtigung
Ein definierter SMTP- oder Transaktionsmail-Dienst informiert die zuständigen Personen.
Ebene 4: Überwachung
Fehler beim Versand werden protokolliert und können kontrolliert werden. Damit entsteht aus einem simplen Kontaktformular ein belastbarer Prozess.
Und genau das sollte das Ziel sein.
Denn sobald eine Website geschäftliche Anfragen erzeugen soll, ist das Formular kein dekoratives Element mehr. Es ist Teil Ihrer Vertriebsinfrastruktur.
Was Sie bei Ihrer Website konkret prüfen sollten
Sie müssen dafür kein Mailserver-Administrator werden.
Ein paar Fragen reichen bereits, um zu erkennen, ob Ihre aktuelle Lösung vernünftig aufgebaut ist:
- Werden Kontaktanfragen zusätzlich zur E-Mail gespeichert?
- Über welchen Dienst verschickt WordPress seine Nachrichten?
- Welche Adresse steht im From-Feld?
- Welche Adresse wird als Reply-To verwendet?
- Ist SPF für alle tatsächlichen Versanddienste korrekt eingerichtet?
- Werden Website-Mails mit DKIM signiert?
- Ist DMARC vorhanden und funktioniert die Domainausrichtung?
- Gibt es nachvollziehbare Versandlogs?
- Werden Fehlermeldungen und Bounces kontrolliert?
- Wurde das Formular zuletzt über die vollständige Benutzerstrecke getestet?
Wenn mehrere dieser Fragen mit „weiß ich nicht“ beantwortet werden, wäre ein technischer Blick auf die Konfiguration sinnvoll.
Fazit: Ihre wichtigste Kontaktanfrage könnte längst verloren gegangen sein
Das Schwierige an diesem Fehler ist seine Unsichtbarkeit.
Eine kaputte Website erzeugt Beschwerden.
Ein kaputtes Kontaktformular erzeugt häufig gar nichts.
Der Besucher sieht seine Erfolgsmeldung und wartet.
Das Unternehmen sieht keinen Eingang und wartet ebenfalls.
Beide Seiten glauben, die jeweils andere hätte sich einfach nicht mehr gemeldet.
Deshalb sollte ein professionelles Kontaktformular mehr leisten als Daten in eine E-Mail umzuwandeln.
Es sollte Anfragen sicher erfassen, nachvollziehbar speichern und anschließend über einen sauber authentifizierten Versandweg melden. SPF, DKIM und DMARC gehören dabei zur technischen Grundlage.
Der wichtigere Schritt kommt allerdings noch davor:
Bauen Sie Ihre Kontaktstrecke so, dass eine verlorene E-Mail niemals gleichzeitig eine verlorene Anfrage bedeutet.
Genau dort wird aus einem funktionierenden Formular ein zuverlässiger Geschäftsprozess.
Und wenn Sie gerade feststellen, dass Sie nicht genau wissen, was mit einer Anfrage nach dem Klick auf „Absenden“ auf Ihrer Website passiert, ist das ziemlich genau die Art technischer Baustelle, die wir uns bei SEO Wunderland ansehen.
Denn eine Website soll nicht nur Besucher bekommen. Sie soll dafür sorgen, dass aus diesen Besuchern auch tatsächlich Kunden werden.
FAQ
Warum zeigt mein Kontaktformular „erfolgreich versendet“, obwohl keine E-Mail ankommt?
Die Erfolgsmeldung bestätigt häufig nur, dass das Formular beziehungsweise die verwendete Mailfunktion die Nachricht ohne unmittelbaren Fehler verarbeitet hat. Sie bestätigt keine erfolgreiche Zustellung im Postfach des Empfängers. WordPress weist bei wp_mail() ausdrücklich auf diesen Unterschied hin.
Braucht eine kleine Unternehmenswebsite SPF, DKIM und DMARC?
Auch kleine Websites profitieren davon. Google verlangt für Nachrichten an Gmail mindestens SPF oder DKIM und empfiehlt grundsätzlich die Einrichtung von SPF, DKIM und DMARC. Google empfiehlt zudem ausdrücklich die E-Mail-Authentifizierung für Domains, auf denen öffentliche Websites betrieben werden.
Reicht ein SMTP-Plugin in WordPress aus?
Nein. SMTP kann einen kontrollierten und authentifizierten Versandweg schaffen. SPF, DKIM, DMARC, Absenderdomain und Domain Alignment müssen trotzdem korrekt eingerichtet sein. Zusätzlich sollte geprüft werden, ob das echte Kontaktformular tatsächlich diesen Versandweg nutzt.
Welche Absenderadresse sollte ein Kontaktformular verwenden?
Als From-Adresse sollte normalerweise eine Adresse der eigenen Domain verwendet werden. Die vom Besucher eingegebene E-Mail-Adresse gehört in das Reply-To-Feld. Dadurch kann geantwortet werden, ohne dass die Website technisch vorgibt, im Namen der Domain des Besuchers zu senden.
Sollte WordPress Kontaktanfragen speichern?
Bei geschäftlich relevanten Formularen ist eine zusätzliche Speicherung sinnvoll. Dadurch bleibt die Anfrage vorhanden, selbst wenn die Benachrichtigungs-E-Mail nicht zugestellt werden kann. Aufbewahrungsfristen, Datenschutz und Zugriffsrechte sollten dabei passend konfiguriert werden.
Wie erkenne ich, ob SPF, DKIM und DMARC wirklich funktionieren?
Am aussagekräftigsten ist eine echte Testmail über das tatsächliche Kontaktformular. In den Mailheadern lassen sich die Ergebnisse der Authentifizierungsprüfungen kontrollieren. Reine DNS-Checker zeigen dagegen hauptsächlich, ob entsprechende Einträge veröffentlicht wurden.
Warum landen Kontaktformular-E-Mails plötzlich im Spam?
Ursachen können unter anderem Änderungen am Hosting, der Domain, dem Mailserver oder den DNS-Einstellungen sein. Auch fehlende Authentifizierung, falsche Absenderkonfiguration, Domain Alignment, Serverreputation und Empfängerfilter können eine Rolle spielen.
Kann eine E-Mail trotz SPF, DKIM und DMARC im Spam landen?
Ja. Die drei Verfahren authentifizieren den Absender beziehungsweise die Domain. Sie garantieren keine Platzierung im Posteingang. Mailanbieter berücksichtigen zusätzlich Reputation, Versandverhalten, Inhalte und weitere Sicherheitssignale.
Wie oft sollte ein Kontaktformular getestet werden?
Mindestens nach technischen Änderungen an Website, Hosting, DNS, Mailserver oder Formularsystem. Bei Websites, deren Umsatz wesentlich von Anfragen abhängt, ist zusätzlich ein regelmäßiger Funktionstest sinnvoll.
Was ist die wichtigste Verbesserung für geschäftliche Kontaktformulare?
Die Anfrage sollte unabhängig von der E-Mail gespeichert werden. Dadurch wird die E-Mail zur Benachrichtigung und bleibt nicht länger der einzige Speicherort eines potenziellen Leads.
