Kontaktformular-Mails kommen nicht an: Warum WordPress still scheitert – und wie Sie es beheben

Das Formular meldet „Vielen Dank“. Die Besucherin glaubt, ihre Anfrage sei raus. Im Unternehmen sieht sie niemand. Kein Fehler im Backend, kein Bounce, nichts im Posteingang. Die Anfrage ist weg – und niemand weiß, dass es sie je gab.

Drei Muster, die in Audits immer wieder auftauchen

Wenn mich jemand mit diesem Problem anspricht, sortiere ich zuerst das Symptom. Es gibt praktisch immer eines von drei Bildern, und jedes zeigt in eine andere Richtung.

• Gar nichts kommt an. Weder Benachrichtigung noch Autoresponder, auch nicht im Spam-Ordner. Das deutet auf den Sendeweg: Der Server gibt die Nachricht nie wirklich ab, oder sie wird direkt an der Tür abgewiesen.
• Gmail bekommt die Mail, Outlook und GMX nicht. Das klassische Authentifizierungsbild. Ein Empfänger ist noch nachsichtig, der nächste nicht mehr.
• Mal kommt sie, mal nicht. Sieht aus wie „das Internet spinnt gerade“. In der Praxis ist es meistens eine halbfertige Authentifizierung, die je nach Empfänger, Tageszeit und Absenderreputation anders bewertet wird – oder tatsächlich eine Störung auf der Empfängerseite.

Der Reflex der meisten Anleitungen lautet: SMTP-Plugin installieren, fertig. Das repariert einen Teil von Ursache vier und manchmal etwas von Ursache zwei. Die übrigen drei Ursachen bleiben unangetastet, und genau deshalb kommen Leute nach zwei Wochen mit demselben Problem zurück.

Warum der Fehler still ist

WordPress verschickt Mail über wp_mail(), und ohne zusätzliche Konfiguration landet das bei PHPs mail(). Diese Funktion übergibt die Nachricht an den lokalen Mail-Daemon des Servers und meldet Erfolg, sobald die Übergabe geklappt hat. Nicht, wenn die Nachricht ankommt.

mail() meldet Erfolg, sobald die Nachricht beim lokalen Mail-Daemon liegt – nicht, wenn sie ankommt. Was danach schiefgeht, erfährt WordPress nie.

Das ist der ganze Mechanismus hinter dem stillen Scheitern. Wenn der Empfängerserver die Nachricht Sekunden später ablehnt, geht die Fehlermeldung an die Adresse im Envelope zurück – und die ist auf typischem Shared Hosting eine serverlokale Adresse wie www-data@srv1234.hoster.tld, in die nie jemand hineinschaut. WordPress erfährt davon nichts, das Plugin zeigt ein grünes Häkchen, und der Formular-Dialog sagt „Vielen Dank“.

Ursache 1 – die Lüge im From-Header

Das ist der häufigste Einzelfehler, und er steckt in der Standardkonfiguration vieler Formular-Plugins: Die Adresse der Besucherin wird als Absender eingetragen. Im Header steht dann From: kunde@gmail.com, obwohl die Nachricht von Ihrem Webserver stammt.

Der Empfänger prüft nun, ob Ihr Server berechtigt ist, im Namen von gmail.com zu senden. Er ist es nicht. Gmail quittiert das mit einem Fehler der Klasse 550-5.7.26; SendLayer beschreibt diesen Code als reines Authentifizierungsurteil – DKIM schlägt fehl, SPF für die angegebene Domain ebenfalls – und ausdrücklich nicht als Inhaltsbewertung. Ihr Text ist also egal. Die Nachricht ist schon vor dem Spamfilter erledigt.

Das richtige Muster ist seit Jahren dasselbe und kostet fünf Minuten in den Plugin-Einstellungen:

From:       website@beispiel.de
Reply-To:   kunde@gmail.com
Return-Path: bounces@beispiel.de
Subject:    Neue Anfrage über das Kontaktformular

Absender ist Ihre eigene Domain, für die Sie die Berechtigung nachweisen können. Die Adresse der Besucherin wandert in Reply-To, damit „Antworten“ im Mailprogramm weiterhin bei ihr landet. Funktional ändert sich für Ihr Team nichts – für den Empfängerserver ändert sich alles.

Ursache 2 – der Envelope-Absender passt nicht zur Domain

Hier wird es unintuitiv, und deshalb übersehen es auch erfahrene Entwickler. SPF prüft nicht die Adresse, die der Empfänger sieht. SPF prüft die Domain im Envelope-Absender, also im Return-Path. MxToolbox formuliert es so: Der Return-Path ist die Adresse, über die der Mailserver den SPF-Eintrag ermittelt – und gleichzeitig die Adresse, an die Zustellfehler zurückgemeldet werden.

Auf Shared Hosting lautet dieser Envelope typischerweise www-data@srv1234.hoster.tld. Das Ergebnis: SPF besteht – für die Domain des Hosters. Für Ihre Domain ist damit nichts gewonnen. Suped bringt die Konsequenz auf den Punkt: SPF authentifiziert ausschließlich die Envelope-Domain; um die sichtbare From-Adresse abzusichern, braucht es DMARC darüber. Ein SPF-Pass auf fremde Domain ist also kein bisschen Schutz für Ihre eigene, sondern nur ein grünes Häkchen an der falschen Stelle.

Ein korrekter Envelope sieht aus wie oben: bounces@beispiel.de oder bounce@mail.beispiel.de – eine Subdomain, die Ihr Versanddienst kontrolliert und für die er die nötigen Einträge vorgibt. Entscheidend ist, dass die Domain im Return-Path mit der Domain im From-Header zusammenpasst. Erst dann ist SPF für DMARC verwertbar.

Ursache 3 – auf dem Sendeweg fehlt jede DKIM-Signatur

Mail, die direkt vom Webserver über mail() hinausgeht, ist in aller Regel unsigniert. Keine DKIM-Signatur, kein kryptografischer Nachweis, dass die Nachricht wirklich aus Ihrer Domain stammt.

Damit fällt die zweite von zwei möglichen Säulen weg. DMARC besteht, wenn entweder SPF oder DKIM passt und die jeweilige Domain zur From-Domain ausgerichtet ist. Ist SPF auf die Hoster-Domain ausgerichtet und DKIM gar nicht vorhanden, kann DMARC nicht bestehen. Bei einer Domain, die auf p=quarantine oder p=reject steht, weist die eigene Richtlinie also die eigenen Formular-Mails ab. Das ist der Fall, bei dem die Kundin sagt: „Wir haben doch alles für E-Mail-Sicherheit gemacht.“ Ja – und dabei den Webserver vergessen.

Die Schlüssel für DKIM generiert immer Ihr Mail- oder Relay-Anbieter. Sie kopieren den Wert in Ihre DNS-Zone und aktivieren die Signierung beim Anbieter. Eigene Schlüssel zu basteln ist unnötig und geht regelmäßig schief. RFC 8301 setzt 1024 Bit als Untergrenze an und empfiehlt 2048; wenn ein Dienst nur 1024 Bit anbietet, ist das eine Einschränkung des Anbieters, kein Konfigurationsfehler Ihrerseits.

Ursache 4 – der Hoster lässt den Versand gar nicht erst zu

Auf dieses Bild stoße ich vor allem bei Managed-WordPress-Hosting. WP Engine dokumentiert offen, dass ausgehende Mail über Port 25 plattformweit nicht möglich ist – die Infrastrukturanbieter erlauben es schlicht nicht. Jede SMTP-Lösung muss also einen alternativen Port oder eine API verwenden. Mehrere andere Managed- und Shared-Hoster handhaben das ähnlich restriktiv; prüfen Sie im Zweifel die Dokumentation Ihres eigenen Anbieters, statt es zu vermuten.

Das Symptom ist charakteristisch: Das SMTP-Plugin zeigt „konfiguriert“, der Testdialog dreht sich, ein Timeout, keine Nachricht. In zwei Minuten bestätigt:

1. Testversand im Plugin auslösen und den Fehlertext wörtlich lesen. „Connection timed out“ auf Port 25 oder 587 ist ein Netzwerkblock, „535 Authentication failed“ ist ein Zugangsdatenproblem – zwei völlig verschiedene Baustellen.
2. Die Support-Dokumentation des Hosters nach „outbound SMTP“ oder „Port 25“ durchsuchen. Steht dort eine Richtlinie, sparen Sie sich jedes weitere Debugging.
3. Auf Port 587 oder 465 mit STARTTLS beziehungsweise TLS umstellen – oder, wenn der Anbieter das nahelegt, auf die HTTP-API des Relays wechseln. Eine API geht durch jeden Port-Block hindurch, weil sie schlicht kein SMTP spricht.

Ursache 5 – es liegt nicht immer an Ihnen

Bevor Sie einen halben Tag in Ihre DNS-Zone investieren: Die Empfängerseite kann genauso die Quelle sein. Ende August 2026 verzögerte ein mehrtägiger Vorfall in Exchange Online, von Microsoft als EX1464935 geführt, Versand und Empfang von Nachrichten und erzeugte Authentifizierungsfehler; Microsoft führte das auf ein gemeinsames Fehlermuster bei Authentifizierung und Protokollverbindungen zurück und meldete die Behebung zum 3. September. Einen Tag später begann mit EX1467029 ein zweiter, davon getrennter Vorfall, der gezielt Mail von und zu externen Domains verzögerte – laut Microsoft verstärkten dabei Anti-Spam-Schutzmechanismen das Problem für einen Teil der betroffenen Konten.

Dazu kommen die hausgemachten Empfängerprobleme: Transportregeln im Tenant, Quarantäne, ein Junk-Ordner, in den seit Monaten niemand schaut, eine Weiterleitung, die unterwegs die Signatur bricht.

Unterscheiden lässt sich das an einer einzigen zugestellten Nachricht. Öffnen Sie in Gmail „Original anzeigen“ beziehungsweise in Outlook die Nachrichtenkopfzeilen und suchen Sie die Zeile Authentication-Results:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounces@beispiel.de designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounces@beispiel.de;
       dkim=pass header.i=@beispiel.de;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=beispiel.de

Stehen hier drei Mal pass und zeigt header.from auf Ihre Domain, ist Ihre Seite sauber. Was danach passiert – Regel, Quarantäne, Verzögerung beim Anbieter – gehört dem Empfänger. Steht irgendwo fail, softfail oder permerror, gehört es Ihnen. Ein 200 auf der Website sagt darüber übrigens gar nichts; er belegt nur, dass der Server geantwortet hat.

Die Architektur, die funktioniert

Unabhängig davon, welche der fünf Ursachen zuerst zuschlägt, sieht das Ziel immer gleich aus. Fünf Punkte, mehr nicht:

• Authentifiziertes Relay statt mail(). SMTP mit Zugangsdaten oder eine Versand-API. Der Webserver gibt Mail nicht mehr selbst ab.
• From auf Ihrer eigenen Domain – eine feste Adresse wie website@beispiel.de, nie die Adresse der Besucherin.
• Reply-To trägt die Besucherin. Antworten funktioniert wie vorher.
• Envelope-Absender ausgerichtet auf dieselbe Domain oder eine kontrollierte Subdomain davon.
• Eine Absenderidentität pro System. Website, Newsletter, CRM, Rechnungstool – jedes mit eigener Adresse oder eigenem Selector, damit ein Fehler zuordenbar bleibt.

Der letzte Punkt wird gern übersprungen und rächt sich später. Wenn alle vier Systeme als info@beispiel.de senden, sagt Ihnen kein DMARC-Report der Welt, welches davon gerade kaputt ist.

Die DNS-Hälfte – und was Sie vorher ansehen

Jede DNS-Änderung beginnt mit einem Blick auf den Ist-Stand. Diese Abfragen lesen nur, sie ändern nichts:

dig +short TXT beispiel.de
dig +short TXT _dmarc.beispiel.de
dig +short TXT selector1._domainkey.beispiel.de

# Windows:
nslookup -type=TXT _dmarc.beispiel.de

SPF: Der include-Mechanismus Ihres Relays kommt in den bestehenden Eintrag. Achten Sie dabei auf die Lookup-Grenze: RFC 7208 deckelt die Zahl der DNS-Abfragen pro Auswertung bei zehn, verschachtelte Includes eingerechnet. Wer darüber liegt, erhält einen permerror, den Empfänger als SPF-Fehlschlag werten – und der DMARC-Ausrichtung damit die Grundlage entzieht. Das merkt man nur, wenn man testet.

v=spf1 include:_spf.relay-anbieter.tld include:_spf.google.com ~all

Ein hartes -all setzt man erst, wenn jeder legitime Absender inventarisiert ist – jedes Newslettertool, jedes Shopsystem, jedes Rechnungsprogramm. Vorher ist ~all die ehrlichere Angabe.

DKIM: Den vom Anbieter erzeugten Schlüssel veröffentlichen und die Signierung im Anbieter-Dashboard tatsächlich aktivieren. Ein veröffentlichter, aber nicht ausgewählter Selector ist ein Klassiker: im DNS sichtbar, in der Nachricht abwesend.

DMARC: Beginnen Sie bei p=none mit einer Reportadresse, die jemand liest. Sendmarc beschreibt die Monitoring-Phase genau so – p=none mit konfiguriertem rua existiert, um Daten zu sammeln – und weist ebenso deutlich darauf hin, dass dauerhaftes Verharren bei p=none keinerlei Schutz vor Spoofing bietet.

v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de; fo=1

Der Weg von p=none über p=quarantine zu p=reject ist eine Rampe, kein Sprung: Reports lesen, jeden legitimen Absender in Ordnung bringen, dann erst anziehen. Das ist ein eigenes Projekt mit eigenem Zeitbedarf und gehört nicht in dieselbe Sitzung wie die Formular-Reparatur. Ein p=none „bittet die Empfänger um keine bestimmte Maßnahme“ bei Nachrichten, die durchfallen – es schützt nicht, und es tut auch nicht nichts.

Das Testprotokoll für eine Viertelstunde

1. Legen Sie sich drei Testadressen an: eine bei Gmail, eine bei Outlook.com, eine bei GMX. Drei verschiedene Bewertungsschulen, drei verschiedene Ergebnisse.
2. Füllen Sie das echte Formular auf der Live-Seite aus, nicht den Testdialog des Plugins. Der Testdialog umgeht oft genau den Pfad, der kaputt ist.
3. Öffnen Sie in Gmail „Original anzeigen“ und lesen Sie Authentication-Results. Sie suchen spf=pass, dkim=pass, dmarc=pass – und header.from auf Ihrer Domain.
4. Prüfen Sie die Ausrichtung mit eigenen Augen: Steht in smtp.mailfrom Ihre Domain oder die Ihres Hosters? Das ist der Unterschied zwischen „SPF besteht“ und „SPF hilft mir“.
5. Wiederholen Sie Schritt drei für Outlook und GMX. Unterschiedliche Ergebnisse bei identischer Nachricht sind das stärkste Indiz für eine halbfertige Authentifizierung.
6. Senden Sie dieselbe Formular-Nachricht an eine Adresse von mail-tester.com und lesen Sie den Score von 0 bis 10. Der Dienst prüft SPF, DKIM, DMARC, Blocklisten und Formatierung – und weist selbst darauf hin, dass der Wert Orientierung ist und keine Zustellgarantie.
7. Aktivieren Sie ein Mail-Logging-Plugin, senden Sie erneut und prüfen Sie, ob das Protokoll eine echte Übergabe mit Antwort des Relays dokumentiert – nicht nur einen Eintrag „gesendet“.

Wenn Schritt sieben leer bleibt oder nur ein nacktes „true“ zeigt, sind Sie noch auf mail(). Dann beginnt die Arbeit bei Ursache vier.

Monitoring, damit es beim nächsten Mal laut scheitert

Die eigentliche Lehre aus diesem Fehlerbild ist nicht die Reparatur, sondern die Sichtbarkeit. Vier Dinge, die wir bei den Seiten, die wir betreuen, zur Routine machen:

• Mail-Logging mit Aufbewahrungsfrist. Mindestens 30 Tage, damit die Frage „ist die Anfrage von letzter Woche rausgegangen?“ beantwortbar ist.
• DMARC-Aggregatreports monatlich ansehen. Nicht täglich – monatlich, aber wirklich. Dort steht, welches System als Ihre Domain sendet und ob es ausgerichtet ist.
• Eine geplante Testeinsendung pro Monat über das echte Formular an eine überwachte Adresse. Bleibt sie aus, wissen Sie es innerhalb eines Monats statt innerhalb eines Quartals.
• Ein Punkt in der Wartungsroutine, der nach jedem Plugin- oder Hoster-Wechsel den Testlauf auslöst.

Wer nennenswerte Mengen an Gmail-Adressen erreicht, sollte zusätzlich in die Google Postmaster Tools schauen. In Version 2 gibt es unter „Compliance status“ eine Rubrik „Deliverability analysis“, die die Rohsignale – Volumen, Spam-Schwelle, Interaktion, Authentifizierung – in eine verständliche Einschätzung samt Handlungsempfehlung übersetzt. Die Botschaft dahinter ist nützlich: Bestandene Authentifizierung ist die Eintrittskarte, nicht die Ziellinie.

Fünf Momente, an denen es wieder kaputtgeht

Das hier ist kein einmaliger Fix. Es ist eine Konfiguration, die an bestimmten Stellen zuverlässig zerbricht. Führen Sie das Testprotokoll nach jedem dieser Ereignisse erneut aus:

1. Domainumzug zu einem anderen Registrar.
2. Wechsel des Hosters oder des DNS-Anbieters – Nameserverwechsel nehmen MX, SPF, jeden DKIM-Selector und DMARC gern nicht mit. Prüfen Sie vorher, ob jeder Eintrag beim neuen Anbieter existiert; ist DNSSEC aktiv, klären Sie zuerst den DS-Eintrag beim Registrar.
3. Ein neues System, das als Ihre Domain sendet: CRM, Newslettertool, Buchungssoftware, Rechnungsdienst.
4. Ein Relaunch, bei dem die Seite migriert wird und die Mail-Einträge nicht.
5. Jede Verschärfung der DMARC-Richtlinie – von p=none auf p=quarantine oder weiter.

Häufige Fragen

Reicht ein SMTP-Plugin allein?

Nein. Es ersetzt den Versandweg, und das ist ein notwendiger Schritt. Es korrigiert aber nicht automatisch den From-Header, es veröffentlicht keine DNS-Einträge und es hilft nicht, wenn Ihr Hoster den Port blockiert. Das Plugin ist ein Werkzeug, keine Lösung.

Warum kommt meine Formular-Mail bei Gmail an, bei Outlook aber nicht?

Weil beide Anbieter dieselben Signale unterschiedlich gewichten. Eine Nachricht ohne DKIM-Signatur und mit falsch ausgerichtetem SPF kann bei einem Empfänger noch durchrutschen und beim nächsten abgewiesen werden. Die Antwort steht in der Zeile Authentication-Results der Nachricht, die angekommen ist – lesen Sie die, statt zu raten.

Darf die Adresse der Besucherin in den From-Header?

Technisch darf sie, funktional sollte sie nicht. Sie senden damit im Namen einer Domain, für die Sie keine Berechtigung nachweisen können – das ist genau das Muster, das moderne Authentifizierung unterbinden soll. Setzen Sie die Besucheradresse in Reply-To; der Komfort bleibt, die Zustellung wird verlässlich.

Blockiert DMARC mein eigenes Kontaktformular?

Das kann es, ja – und es ist ein häufiger Auslöser. Steht Ihre Domain auf p=quarantine oder p=reject und sendet der Webserver unsigniert mit fremdem Envelope, fällt die eigene Formular-Mail durch die eigene Richtlinie. Deshalb gehört der Webserver vor jeder Verschärfung auf die Liste der legitimen Absender.

Wie weise ich nach, dass eine Anfrage nie zugestellt wurde?

Rückwirkend nur mit einem Mail-Log, das den Übergabezeitpunkt und die Antwort des Relays festhält, plus – falls vorhanden – dem Bounce im Relay-Dashboard. Ohne Logging gibt es keinen Nachweis, nur Vermutungen. Das ist der eigentliche Grund, Logging einzuschalten, bevor der Streitfall da ist.

Zum Schluss

Das Testprotokoll oben ist eine Viertelstunde Arbeit und beantwortet die Frage, ob Sie ein Problem haben. Die Reparatur liegt je nach Ursache zwischen 30 Minuten und einem halben Tag; die DMARC-Rampe ist ein eigenes Projekt über Wochen. Wenn Sie das nicht selbst machen möchten: Wir prüfen die Zustellbarkeit von Formular- und Systemmails im Rahmen der Website-Pflege, und für einen einmaligen Blick darauf genügt eine kurze Nachricht.