Website-Anfragen verschwinden im Spam-Ordner oder kommen gar nicht erst an – ohne dass der Absender oder der Betreiber es merkt. Das Problem liegt fast immer im Versandweg, nicht beim Empfänger. Wer die technischen Stolperfallen kennt, kann den Zustellweg gezielt prüfen und absichern.
Das typische Szenario: Anfrage abgeschickt, aber nichts passiert
Ein potenzieller Kunde füllt das Kontaktformular aus, drückt auf Absenden, sieht eine Bestätigungsmeldung – und geht davon aus, seine Anfrage sei angekommen. Auf Empfängerseite passiert jedoch nichts. Keine E-Mail im Posteingang, nichts im Spam-Ordner. Erst wenn der Absender nachfragt oder gar nie wieder von sich hören lässt, wird das Problem sichtbar.
Dieses Szenario ist keine Seltenheit. Besonders gravierend: Die Betreiber merken den Verlust oft Monate nicht, weil keine Fehlermeldung generiert wird. Das Formular arbeitet scheinbar korrekt, der Versand schlägt aber auf technischer Ebene fehl oder die E-Mail wird vom empfangenden Server stillschweigend abgelehnt.
PHP mail(): Die bequeme Standardlösung, die oft versagt
Die Funktion `mail()` in PHP ist die einfachste Methode, E-Mails von einer Website zu versenden. Viele Content-Management-Systeme und Formular-Plugins nutzen sie als Standard, weil keine weitere Konfiguration nötig ist. Genau darin liegt das Problem.
`mail()` übergibt die E-Mail an das lokale Mail-System des Servers. Dieser Versandweg hat mehrere Schwachstellen:
- Keine Authentifizierung: Die E-Mail kommt ohne gültige Anmeldedaten daher, was Empfängerserver misstrauisch stimmt.
- Fehlende Verschlüsselung: Der Transport erfolgt oft unverschlüsselt.
- Variable Absenderadresse: Viele Formulare tragen die E-Mail-Adresse des Anfragers als Absender ein – eine Technik, die massiv mit Spam-Phishing assoziiert wird.
- Keine Fehlerbehandlung: `mail()` liefert selbst bei Ablehnung durch den Zielserver oft ein positives Ergebnis zurück.
Empfängerserver wie Gmail, Outlook oder geschäftliche Mail-Gateways bewerten solche E-Mails zunehmend als verdächtig. Das Ergebnis: Zustellung ins Spam-Postfach oder komplette Ablehnung ohne Benachrichtigung.
SMTP-Versand: Zuverlässiger, aber nicht automatisch fehlerfrei
Der Versand über SMTP (Simple Mail Transfer Protocol) ist der professionellere Weg. Hier meldet sich die Website mit einem definierten Benutzernamen und Passwort bei einem Mail-Server an und überträgt die E-Mail authentifiziert.
Der Unterschied zu `mail()` ist gravierend:
- Der Versandweg ist nachvollziehbar und verschlüsselbar
- Der sendende Server ist identifizierbar
- Fehler werden tatsächlich zurückgemeldet
Doch SMTP allein garantiert keine Zustellung. Wer einen Standard-Mailaccount des Webhosters verwendet, ohne die Domain-Authentifizierung zu konfigurieren, verschiebt das Problem nur. Die E-Mail kommt zwar vom richtigen Server, fehlende DNS-Einträge führen dennoch zur Spam-Einstufung.
Domain-Authentifizierung: Was SPF, DKIM und DMARC bewirken
Hier liegt die technisch entscheidende Ebene, die viele Ratgeber und sogar Entwickler übersehen. Selbst korrekt konfiguriertes SMTP versagt, wenn die Domain nicht gegen Missbrauch abgesichert ist.
SPF (Sender Policy Framework): Ein DNS-Eintrag, der festlegt, welche Server E-Mails für eine Domain verschicken dürfen. Ohne SPF kann jeder Server im Namen der Domain senden – Empfänger wissen nicht, ob die E-Mail legitim ist.
DKIM (DomainKeys Identified Mail): Eine kryptografische Signatur, die jede ausgehende E-Mail trägt. Der empfangende Server kann prüfen, ob die E-Mail unterwegs verändert wurde und ob der Absender berechtigt ist.
DMARC (Domain-based Message Authentication): Verknüpft SPF und DKIM mit einer Handlungsanweisung für Empfängerserver. Es definiert, wie mit E-Mails verfahren werden soll, die die Prüfung nicht bestehen – und liefert Berichte über Fehlversuche.
Wer Kontaktformulare mit eigener Domain-Adresse (zum Beispiel `[email protected]`) betreibt, muss diese drei Mechanismen implementiert haben. Fehlt nur einer, reicht das für eine Spam-Einstufung bei strengen Empfängern. Die Konfiguration erfolgt im DNS-Verwaltungsbereich des Domain-Hosters, nicht im Website-Backend.
Webhoster und Shared Hosting: Warum der eigene Server blockiert wird
Viele Unternehmen nutzen Shared-Hosting-Pakete, bei denen hunderte Websites auf einem physischen Server laufen. Die IP-Adresse dieses Servers teilen sich alle Kunden – und wenn einer davon Spam versendet oder kompromittiert wurde, landet die gesamte IP auf Sperrlisten.
Folgende Probleme treten typischerweise auf:
- Der Host hat die ausgehende E-Mail-Funktion für `mail()` eingeschränkt oder deaktiviert
- Tägliche Versandlimits blockieren höhere Anfragenvolumina
- Die Server-IP steht auf öffentlichen Blacklists wie Spamhaus oder Barracuda
- Reverse-DNS-Einträge fehlen oder stimmen nicht mit der Domain überein
Besonders bei günstigen Hosting-Paketen ist der E-Mail-Versand Nebensache. Die Priorität liegt auf Website-Verfügbarkeit, nicht auf Mail-Zustellbarkeit. Wer hier nicht testet, betreibt ein Kontaktformular mit ungewissem Ausgang.
Formular-Plugins und Baukästen: Versteckte Fallstricke
Content-Management-Systeme wie WordPress mit Plugins wie Contact Form 7, WPForms oder Elementor-Pro-Formularen vereinfachen die Erstellung – nicht aber den Versand. Viele Plugins nutzen standardmäßig `mail()` und verlagern die SMTP-Konfiguration in separate Erweiterungen oder kostenpflichtige Add-ons.
Baukastensysteme wie Wix, Squarespace oder Jimdo abstrahieren die Technik vollständig. Hier hat der Betreiber keinen Einblick in Versandwege oder Domain-Authentifizierung. Die Zustellrate liegt im Ermessen des Anbieters, Änderungen sind nicht möglich.
Ein besonderer Fallstrick: Viele Formular-Plugins erlauben die Konfiguration des Absenderfeldes. Trägt das Plugin die E-Mail des Formular-Ausfüllers als Absender ein, verstößt das gegen gängige Sicherheitsrichtlinien. Die E-Mail kommt technisch vom Webserver, behauptet aber, vom privaten Gmail- oder T-Online-Account des Absenders zu stammen. Das ist für Empfängerserver ein klassisches Phishing-Merkmal.
Selbsttest: So prüfen Sie Ihre eigene Website
Zuverlässige Zustellung lässt sich nicht vermuten, sondern muss getestet werden. Ein pragmatischer Testablauf:
1. Test-Einsendung durchführen: Mehrere Formulare auf verschiedenen Endgeräten absenden, inklusive Mobilgeräten.
2. Empfängerseite prüfen: Posteingang, Spam-Ordner und bei geschäftlichen Accounts die Quarantäne-Übersicht kontrollieren. Mindestens 15 Minuten Wartezeit einplanen, manche Server verzögern.
3. Header-Analyse: Bei angekommenen E-Mails die vollständigen Header einsehen. Dort ist der Versandweg nachvollziehbar, inklusive SPF- und DKIM-Prüfungsergebnissen.
4. Externe Testtools nutzen: Dienste wie Mail Tester (mail-tester.com) liefern eine Bewertung der Domain-Konfiguration und des Versandverhaltens. Die E-Mail wird an eine spezielle Adresse gesendet, der Test erfolgt automatisiert.
5. Server-Logs einsehen: Wer Zugriff auf das Hosting hat, findet im Mail-Log des Servers Fehlermeldungen zu abgelehnten Verbindungen. Diese sind aussagekräftiger als das Verhalten des Formulars selbst.
6. Blacklist-Prüfung: Die IP-Adresse des eigenen Servers auf öffentlichen Blacklists prüfen (zum Beispiel über MXToolbox).
Wer diese Schritte nicht selbst durchführen kann oder möchte, sollte die technische Dokumentation der Website regelmäßig aktualisieren – das erleichtert spätere Fehlersuche und Weiterentwicklung erheblich.
Wann ein E-Mail-Dienst wie SendGrid oder Postmark sinnvoll wird
Für Unternehmen mit regelmäßigen Anfragenvolumina oder geschäftskritischem Kontaktformular lohnt sich der Einsatz eines spezialisierten Transaktionsmail-Dienstes. Diese Anbieter betreiben eigene, gepflegte Server-Infrastrukturen mit etablierten Reputationen bei Empfängern.
Entscheidende Unterschiede zum Eigenversand:
- Domain-Authentifizierung wird aktiv unterstützt und überwacht
- Bounce- und Zustellungsprobleme werden protokolliert
- Server-IPs sind nicht durch andere Kunden kompromittiert
- API-Integration ermöglicht zuverlässigeren Versand als SMTP
Kosten entstehen ab etwa 100.000 E-Mails pro Monat bei den meisten Anbietern, darunter gibt es kostenlose Kontingente. Für ein durchschnittliches Kontaktformular mit wenigen hundert Anfragen jährlich ist das zunächst übertrieben – solange der eigene Versandweg stabil läuft. Steigen die Ausfälle oder das Geschäftsrisiko durch verlorene Anfragen, verschiebt sich die Kosten-Nutzen-Rechnung.
Wichtig: Auch diese Dienste erfordern korrekte SPF- und DKIM-Konfiguration. Die Einrichtung ist nicht automatisch, sondern muss in den DNS-Einstellungen vorgenommen werden.
Alternative: Kontaktformular ohne E-Mail – direkt ins CRM oder Ticketsystem
Die radikalste und zugleich zuverlässigste Lösung besteht darin, den E-Mail-Transport als solchen zu umgehen. Moderne Formular-Lösungen können Daten direkt per API in Geschäftssysteme übertragen:
- CRM-Systeme: HubSpot, Pipedrive, Salesforce und vergleichbare Anbieter bieten native Formular-Integrationen oder API-Schnittstellen.
- Ticketsysteme: Zendesk, Freshdesk, Jira Service Management und Open-Source-Alternativen empfangen Anfragen strukturiert.
- Datenbank-gestützte Lösungen: Formulardaten landen direkt in einer Datenbank, Benachrichtigungen erfolgen über interne Systeme oder Messenger.
Der Vorteil liegt auf der Hand: Kein SMTP-Server, keine Spam-Filter, keine Zustellprobleme. Die Anfrage existiert sofort als strukturierter Datensatz. Der Nachteil: Höherer Einrichtungsaufwand, Abhängigkeit von der Verfügbarkeit des Zielsystems, möglicherweise höhere laufende Kosten.
Für Unternehmen, die ohnehin ein CRM oder Ticketsystem nutzen, ist dieser Weg die konsequentere Option. Wer lediglich ein einfaches Kontaktformular betreibt, ohne weitere Systemlandschaft, wird den Aufwand als unverhältnismäßig empfinden.
Checkliste: So stellen Sie zuverlässigen Versand sicher
- [ ] Versandweg identifizieren: Nutzt das Formular `mail()`, SMTP oder eine API?
- [ ] Bei SMTP: Zugangsdaten korrekt, Verschlüsselung aktiv (TLS/SSL), Port passend
- [ ] SPF-Eintrag im DNS vorhanden und auf alle versendenden Server ausgedehnt
- [ ] DKIM-Schlüssel generiert und im DNS hinterlegt
- [ ] DMARC-Richtlinie mit Reporting-Adresse konfiguriert
- [ ] Absenderadresse des Formulars auf eigene Domain festgelegt, nicht auf Adresse des Ausfüllers
- [ ] Server-IP auf Blacklists geprüft
- [ ] Test-E-Mails an verschiedene Empfänger (Gmail, Outlook, geschäftliche Domain) versendet und Ergebnisse dokumentiert
- [ ] Bei wiederholten Problemen: Wechsel auf spezialisierten Transaktionsmail-Dienst prüfen
- [ ] Langfristig: Direkte API-Anbindung an CRM oder Ticketsystem als Zielarchitektur erwägen
---
Wer Anfragen aus dem Kontaktformular nicht mehr dem Zufall überlassen möchte, kann die technische Infrastruktur gezielt durchleuchten lassen. Die kostenfreie Erstberatung prüft Versandwege, Domain-Konfiguration und Formular-Setup auf Schwachstellen – ohne Verpflichtung, mit konkretem Handlungsplan.
