Kontaktformular ohne Drittanbieter: Eigenes SMTP

Sie haben Ihre Website von WordPress auf ein modernes Framework wie Astro umgestellt – und plötzlich funktioniert das Kontaktformular nicht mehr. Bei WordPress erledigt PHP mit wp_mail() den E-Mail-Versand im Hintergrund. Bei statischen Websites gibt es kein serverseitiges Backend. Das Formular steht da, sieht gut aus – aber die Anfragen kommen nie an.

Genau dieses Problem hatten wir bei SEOFX, als wir unsere eigene Website auf Astro umgestellt haben. Die Lösung, die wir nach einigen Umwegen gefunden haben, ist überraschend einfach: ein eigenes SMTP-Skript auf dem Webserver – ohne externe Dienste, ohne laufende Kosten, ohne Drittanbieter.

Das Problem: Statische Websites und E-Mail-Versand

Statische Websites – ob mit Astro, Hugo, Eleventy oder Next.js Static Export gebaut – bestehen aus fertigen HTML-Dateien. Der Server liefert sie direkt aus, ohne sie bei jedem Aufruf neu zu generieren. Das macht sie extrem schnell und sicher, bringt aber einen Nachteil mit sich: Es gibt kein serverseitiges Backend, das Formular-Eingaben verarbeiten könnte.

Ein normales HTML-Formular mit <form action="..."> braucht einen Endpunkt, der die Daten empfängt, validiert und als E-Mail weiterleitet. Ohne diesen Endpunkt passiert beim Klick auf „Absenden” schlicht nichts. Also braucht jede statische Website eine separate Lösung für den Kontaktformular-Versand.

Die gängigen Wege lassen sich in drei Kategorien einteilen: Formular-Dienste, Cloud-E-Mail-APIs und ein eigenes Skript auf dem Server.

Die gängigen Lösungen im Überblick

Formular-Dienste (Formspree, Getform, Basin)

Das Prinzip ist einfach: Sie setzen die action Ihres Formulars auf eine URL des Dienstleisters (z.B. https://formspree.io/f/abc123). Der Dienst empfängt die Daten, validiert sie und leitet sie per E-Mail an Sie weiter.

Vorteile: Kein eigener Code nötig, in fünf Minuten eingerichtet, funktioniert auf jeder Hosting-Plattform. Nachteile: Formulardaten werden an einen externen Server übertragen (meist in den USA), DSGVO-kritisch, laufende Kosten ab ca. 8 $/Monat für mehr als 50 Einreichungen, Branding auf dem Free Tier.

Cloud-E-Mail-APIs (AWS SES, Mailgun, SendGrid)

Hier ruft ein kleines Backend – etwa eine Serverless Function auf Vercel oder Netlify – die API des E-Mail-Dienstes auf, der die Mail dann versendet.

Vorteile: Hohe Zustellrate (Deliverability), skalierbar, professionelle Infrastruktur. Nachteile: Deutlich mehr Konfigurationsaufwand (DNS-Records, Domain-Verifizierung, API-Keys), Vendor Lock-in, laufende Kosten je nach Volumen, Overkill für 5–20 Kontaktanfragen pro Tag.

Eigenes SMTP-Skript auf dem Webserver

Ein kleines Skript (PHP, Python oder Node.js) auf dem eigenen Webserver empfängt die Formulardaten und versendet sie über den SMTP-Server des Hosters als E-Mail – direkt, ohne Umweg über externe Dienste.

Vorteile: Keine externen Dienste, keine laufenden Kosten, volle Kontrolle, Daten bleiben auf dem eigenen Server. Nachteile: Eigenverantwortung für Absicherung (Validierung, Spamschutz), Zustellrate hängt vom Hoster ab.

Vergleich auf einen Blick

Unsere Lösung: Ein SMTP-Skript auf dem eigenen Server

Nach dem Wechsel von WordPress auf Astro haben wir alle drei Varianten evaluiert. Formspree war schnell eingerichtet, aber die Formulardaten an einen US-Server zu schicken war für uns als deutsche Agentur keine Option. AWS SES und Mailgun hatten wir ebenfalls getestet – funktional einwandfrei, aber der Konfigurationsaufwand für DNS-Verifizierung, API-Integration und Monitoring stand in keinem Verhältnis zu unserem Volumen von wenigen Anfragen pro Tag.

Die Entscheidung fiel auf ein eigenes SMTP-Skript: ein schlankes PHP-Skript auf dem bestehenden Webserver, das den SMTP des Hosters nutzt. Keine zusätzlichen Dienste, keine API-Keys, keine monatlichen Rechnungen. Das Skript war in einem Nachmittag geschrieben und läuft seitdem zuverlässig.

So funktioniert der Aufbau

Frontend: Das HTML-Formular

Das Kontaktformular ist ein semantisches HTML-Formular mit den üblichen Feldern: Name, E-Mail-Adresse, Nachricht. Die action zeigt auf den Endpunkt des SMTP-Skripts auf dem eigenen Server.

Der entscheidende Baustein für den Spamschutz ist ein Honeypot-Feld – ein zusätzliches Formularfeld, das per CSS unsichtbar gemacht wird. Echte Besucher sehen es nicht und lassen es leer. Spam-Bots füllen automatisch alle Felder aus, auch das versteckte. Im Backend wird geprüft: Ist das Feld gefüllt, war es ein Bot – die Anfrage wird verworfen.

Für eine gute Nutzererfahrung sendet JavaScript die Daten per fetch im Hintergrund ab. So bleibt der User auf der Seite und sieht eine Erfolgsmeldung ohne Seitenreload. Das Formular funktioniert aber auch ohne JavaScript – dann als normaler POST-Request mit Redirect.

Backend: Das SMTP-Skript

Das Skript auf dem Server durchläuft bei jeder Anfrage diese Schritte:

• POST-Request empfangen. Nur POST-Anfragen werden akzeptiert, GET wird abgelehnt.
• Felder validieren. Name, E-Mail und Nachricht sind Pflichtfelder. Die E-Mail-Adresse wird auf gültiges Format geprüft.
• Honeypot prüfen. Ist das versteckte Feld ausgefüllt, wird die Anfrage sofort verworfen – ohne Fehlermeldung, damit der Bot nicht lernt.
• E-Mail zusammenbauen. Subject, Body und Header werden gesetzt. Das From-Feld nutzt eine Adresse der eigenen Domain, die Absender-E-Mail des Besuchers wird als Reply-To eingetragen.
• Über SMTP versenden. Das Skript nutzt den lokalen SMTP-Server des Hosters. Bei den meisten Webhostern ist ein Mailserver inklusive – ohne Zusatzkosten.
• Antwort zurückgeben. JSON-Response mit Erfolg oder Fehlermeldung, damit das Frontend reagieren kann.

Sicherheit und Spamschutz

Der Spamschutz ohne reCAPTCHA besteht aus zwei Schichten:

• Honeypot-Feld. Fängt den Großteil automatisierter Bots ab – einfach, unsichtbar, effektiv. In unserem Fall werden über 95 % der Spam-Bots bereits durch das Honeypot-Feld gestoppt.
• Serverseitige Validierung. E-Mail-Format prüfen, Pflichtfelder erzwingen, maximale Eingabelänge begrenzen, Header-Injection verhindern. Klingt selbstverständlich, wird aber erstaunlich oft vergessen.

Warum kein reCAPTCHA? Weil es die Nutzererfahrung verschlechtert („Klicken Sie alle Ampeln an”), Google-Tracking auf Ihrer Website einbindet und damit ein DSGVO-Thema ist. Für eine Firmenwebsite mit 5–30 Anfragen pro Tag ist Honeypot + Validierung völlig ausreichend.

Optional lässt sich als dritte Schicht ein Rate Limiting ergänzen – zum Beispiel maximal 3 Anfragen pro IP in 10 Minuten. Das braucht allerdings einen Speichermechanismus (Datei oder Datenbank) und ist für die meisten Websites nicht nötig.

DSGVO: Warum die eigene Lösung punktet

Für deutsche Websites ist die Datenschutz-Grundverordnung ein wichtiger Faktor bei der Wahl des Kontaktformular-Versands.

Bei Formspree, Mailgun oder AWS SES werden die Formulardaten an Server in den USA oder anderen Drittländern übertragen. Das bedeutet: Sie brauchen einen Auftragsverarbeitungsvertrag mit dem Anbieter, müssen den Dienst in Ihrer Datenschutzerklärung nennen und eine Rechtsgrundlage für den Drittland-Transfer dokumentieren.

Gerade für Branchen wie Ärzte, Anwälte oder Steuerberater – bei denen über das Kontaktformular sensible Informationen eingehen können – ist das ein nicht zu unterschätzender Vorteil.

Erfahrungsbericht: 12 Monate mit dem eigenen SMTP-Skript

Seit über einem Jahr läuft unser SMTP-Skript im Produktivbetrieb. Zeit für eine ehrliche Bilanz:

• Zuverlässigkeit. Keine einzige verlorene Anfrage – jede Kontaktanfrage wurde zugestellt.
• Performance. Die Antwortzeit des Skripts liegt bei unter 200 ms. Der Besucher sieht die Erfolgsmeldung quasi sofort.
• Kosten. 0 € laufende Kosten für den E-Mail-Versand. Der SMTP-Server ist beim Hoster inklusive.
• Wartungsaufwand. Praktisch null nach der Ersteinrichtung. Kein Update, kein API-Key-Refresh, keine Version die deprecated wird.
• Spamaufkommen. Das Honeypot-Feld fängt den allergrößten Teil ab. Die wenigen Spam-Mails die durchkommen, sind per Hand in Sekunden gelöscht.

Die einzige Einschränkung: Für Massenmails oder transaktionale E-Mails (Bestellbestätigungen, Newsletter) ist diese Lösung nicht gedacht. Dafür braucht man tatsächlich einen spezialisierten Dienst. Aber für Kontaktformulare auf Firmen-, Praxis- und Agenturseiten ist es die pragmatischste Lösung die wir kennen.

Für wen eignet sich welche Lösung?

Nicht jeder Ansatz passt für jedes Projekt. Eine ehrliche Einordnung:

• Formular-Dienste eignen sich für schnelle Prototypen und Landingpages, wenn kein eigener Server vorhanden ist und Datenschutz keine zentrale Rolle spielt.
• Cloud-E-Mail-APIs sind die richtige Wahl bei hohem E-Mail-Volumen, transaktionalen Mails oder wenn die Zustellrate geschäftskritisch ist – etwa im E-Commerce.
• Eigenes SMTP-Skript ist ideal für Firmenwebsites, Praxis-Websites und Agenturseiten – überall dort, wo 5–50 Kontaktanfragen pro Tag ausreichen, Datenschutz wichtig ist und Sie keine Abhängigkeit von externen Diensten wollen.

Fazit: Weniger Abhängigkeit, mehr Kontrolle

Ein eigenes SMTP-Skript auf dem Webserver ist nicht die einzig richtige Lösung – aber für die meisten statischen Firmenwebsites die pragmatischste. Kein Vendor Lock-in, keine laufenden Kosten, DSGVO-sicher, wartungsarm. Wir setzen selbst darauf und empfehlen es Kunden mit vergleichbaren Anforderungen.