PHP vs. Serverless Forms: Warum Du Form-to-Email-Dienste wählen solltest

Wer schon mal ein Kontaktformular auf einer Website eingebunden hat, kennt den klassischen Weg: ein PHP-Kontaktformular schreiben, die Mail-Einstellungen auf dem Server konfigurieren, Validierung implementieren, Spam bekämpfen und debuggen, warum E-Mails im Junk-Ordner landen. Irgendwann funktioniert es – aber der Weg dorthin ist selten so einfach, wie er klingt. Dieser Artikel zeigt dir, was das Erstellen von PHP-Formularen von Grund auf wirklich kostet – im Vergleich zu einem modernen serverlosen Formular-zu-E-Mail-Dienst. Mit einem konkreten Beispiel wird deutlich, wo die eigentliche Reibung entsteht.

Wie ein PHP-Mailformular wirklich funktioniert

Die PHP-Funktion mail() ist seit Jahrzehnten die Standardantwort auf die Frage „Wie versende ich Formulareinträge per E-Mail?". Der grundlegende Ablauf sieht so aus:

1. Der Nutzer füllt ein HTML-Formular aus und sendet es ab.
2. Das action-Attribut des Formulars verweist auf ein PHP-Skript auf dem Server.
3. Das PHP-Skript liest die POST-Daten, bereinigt sie und ruft mail() auf.
4. Der Mail Transfer Agent (MTA) des Servers versucht, die Nachricht zuzustellen.

In der Theorie klingt das simpel. In der Praxis birgt jeder dieser vier Schritte einen potenziellen Fehlerpunkt.

Ein minimales PHP-Mail-Skript

So sieht ein abgespeckter PHP-Kontaktformular-Handler aus:

<?php
if ($_SERVER["REQUEST_METHOD"] == "POST") {
    $name    = strip_tags(trim($_POST["name"]));
    $email   = filter_var(trim($_POST["email"]), FILTER_SANITIZE_EMAIL);
    $message = strip_tags(trim($_POST["message"]));

    if (empty($name) || empty($message) || !filter_var($email, FILTER_VALIDATE_EMAIL)) {
        http_response_code(400);
        echo "Please complete the form and try again.";
        exit;
    }

    $to      = "[email protected]";
    $subject = "New contact from $name";
    $body    = "Name: $name\nEmail: $email\nMessage:\n$message";
    $headers = "From: [email protected]\r\nReply-To: $email";

    if (mail($to, $subject, $body, $headers)) {
        http_response_code(200);
        echo "Thank you! Your message has been sent.";
    } else {
        http_response_code(500);
        echo "Oops! Something went wrong.";
    }
}
?>

Das Skript umfasst rund 20 Zeilen und wirkt überschaubar. Aber das ist nur der Idealfall. CSRF-Schutz, Honeypot-Felder, Rate Limiting und Zustellbarkeitskonfiguration fehlen völlig. Wer das alles ergänzt, verdreifacht schnell Codelänge und Komplexität.

Die versteckten Kosten von PHP-Kontaktformularen

Serverseitige Formularverarbeitung mit PHP bringt eine Reihe von Aufwänden mit sich, die man vor dem Start leicht unterschätzt – und nach der Inbetriebnahme schmerzhaft zu spüren bekommt.

1. Servervoraussetzungen

Die Hosting-Umgebung muss PHP installiert und einen funktionierenden MTA konfiguriert haben. Auf Shared Hosting ist das oft standardmäßig vorhanden, aber auf VPS, Cloud-Plattformen (Netlify, Vercel, Cloudflare Pages) oder statischen Hosting-Diensten gibt es schlicht keine PHP-Runtime. PHP-Kontaktformulare sind dort ohne einen zusätzlichen Backend-Dienst keine Option.

2. E-Mail-Zustellbarkeit

Die PHP-Funktion mail() versendet E-Mails über den lokalen MTA des Servers. Solche E-Mails landen häufig im Spam-Ordner, weil SPF-, DKIM- und DMARC-Einträge fehlen oder falsch konfiguriert sind. Viele Entwickler verbringen Stunden damit zu debuggen, warum Formular-E-Mails nie ankommen – nur um festzustellen, dass das Problem in der DNS-Konfiguration liegt und nicht im PHP-Code.

3. Spam und Missbrauch

Ohne Spam-Schutz ist ein öffentliches Formular ein leichtes Ziel. Ein Honeypot-Feld einzubauen, CSRF-Tokens zu implementieren oder einen CAPTCHA-Dienst zu integrieren erfordert zusätzlichen Code, zusätzliche Abhängigkeiten und laufende Pflege. Einen Überblick über bewährte Methoden zum Schutz vor Formular-Spam findest du in unserem Leitfaden zum Spam-Schutz für Formulare.

4. Wartungsaufwand

PHP-Versionen ändern sich. Funktionen werden als veraltet markiert. Sicherheitslücken in Formularverarbeitungs-Skripten sind eine reale Kategorie von Web-Exploits. Jedes PHP-Skript, das du betreibst, muss regelmäßig überprüft, aktualisiert und getestet werden.

5. Kein eingebauter Feedback-Mechanismus

Die einfache PHP-Mail-Funktion bietet keine Zustellbestätigung, kein Einsende-Protokoll und keinen Wiederholungsmechanismus. Schlägt eine E-Mail lautlos fehl – was durchaus vorkommt – erfährst du davon nichts, es sei denn, du baust selbst ein Logging ein.

Der serverlose Ansatz für die Formularverarbeitung

Serverlose Formularverarbeitung dreht das Modell um. Anstatt ein eigenes Formularverarbeitungs-Skript zu betreiben, lässt du dein HTML-Formular auf einen Drittanbieter-Endpoint zeigen, der die Einsendung entgegennimmt und an deine E-Mail-Adresse weiterleitet. Kein Server muss konfiguriert, keine PHP-Runtime verwaltet und kein MTA debuggt werden.

Dieser Ansatz eignet sich besonders gut für statische Websites und JAMstack-Projekte. Wer mit Hugo, Gatsby, Astro oder einem anderen Static-Site-Generator baut, hat per Definition kein Backend. Ein serverloser Formular-Endpoint ist die naheliegende Lösung. Einen umfassenderen Blick auf diese Architektur bietet der ultimative Leitfaden zur serverlosen Formularverarbeitung für statische Websites.

Was sich in der Praxis ändert

Bei einem serverlosen Formular-zu-E-Mail-Dienst ändert sich an deinem HTML-Formular genau eine Stelle: das action-Attribut. Alles andere – Feldnamen, Validierungslogik, Weiterleitungsverhalten – bleibt unverändert. Der Dienst übernimmt Zustellung, Spam-Filterung und Protokollierung auf seiner Seite.

PHP vs. Serverless: Direkter Vergleich

Konkretes Beispiel: Vom PHP-Skript zum serverlosen Endpoint

Angenommen, du hast eine Kontaktseite auf einer statischen Website und möchtest Formulareinträge an [email protected] erhalten. So unterscheiden sich die beiden Ansätze in konkreten Schritten.

Der PHP-Weg

1. Sicherstellen, dass das Hosting PHP unterstützt (auf Netlify, Vercel, GitHub Pages oder Cloudflare Pages ist das nicht möglich).
2. Das PHP-Skript schreiben (siehe Beispiel oben, plus CSRF-Tokens und ein Honeypot-Feld ergänzen).
3. Das Skript auf den Server hochladen.
4. Den MTA des Servers konfigurieren oder SMTP-Zugangsdaten mit einer Bibliothek wie PHPMailer einrichten.
5. DNS-Einträge (SPF, DKIM) setzen, um die Zustellbarkeit zu verbessern.
6. Testen, debuggen, erneut testen.
7. Spam-Missbrauch überwachen und das Skript bei Bedarf aktualisieren.

Realistischer Zeitaufwand für einen Entwickler, der das zum ersten Mal sauber umsetzt: 2 bis 4 Stunden – zukünftige Wartung nicht eingerechnet.

Der serverlose Weg mit Sendform.net

1. Kostenloses Konto auf Sendform.net anlegen und E-Mail-Adresse bestätigen.
2. Die einzigartige Formular-Endpoint-URL kopieren.
3. Das action-Attribut des HTML-Formulars auf diesen Endpoint aktualisieren.
4. Einen Test-Formulareintrag absenden.
5. Den Posteingang prüfen.

Dein HTML-Formular ändert sich von diesem:

<form action="contact.php" method="POST">
  <input type="text" name="name" placeholder="Your name" required>
  <input type="email" name="email" placeholder="Your email" required>
  <textarea name="message" placeholder="Your message" required></textarea>
  <button type="submit">Send</button>
</form>

Zu diesem:

<form action="https://sendform.net/en/!your-form-id" method="POST">
  <input type="text" name="name" placeholder="Your name" required>
  <input type="email" name="email" placeholder="Your email" required>
  <textarea name="message" placeholder="Your message" required></textarea>
  <button type="submit">Send</button>
</form>

Das ist eine einzige Zeile Änderung. Kein PHP. Kein Server. Keine MTA-Konfiguration. Wer lieber JavaScript statt eines einfachen HTML-Formular-Posts nutzt, kann den fetch()-Ansatz für Formulareinträge genauso gut mit einem serverlosen Endpoint verwenden.

Wann PHP-Formularverarbeitung noch sinnvoll ist

Es gibt durchaus Situationen, in denen eine eigene PHP-Formularverarbeitung die richtige Wahl ist:

• Komplexe Geschäftslogik: Wenn ein Formulareintrag Datenbankschreibvorgänge auslösen, Nutzerkonten anlegen oder tief mit einem eigenen Backend integriert werden muss, bietet ein PHP-Skript volle Kontrolle.
• Datensouveränitätsanforderungen: Manche Organisationen verlangen, dass alle Formulardaten ausschließlich in ihrer eigenen Infrastruktur verbleiben und keinen Drittanbieter-Dienst durchlaufen dürfen.
• Bestehende PHP-Anwendungen: Wer bereits eine Laravel- oder Symfony-Anwendung betreibt, hat die Formularverarbeitungs-Infrastruktur wahrscheinlich schon an Bord – ein Kontaktformular hinzuzufügen ist dann trivial.

Außerhalb dieser Szenarien rechtfertigt der Aufwand für das Schreiben und Warten von PHP-Kontaktformularen selten den Mehrwert gegenüber dem, was ein serverloser Dienst bietet. Für Entwickler, die an statischen Websites oder Projekten ohne bestehendes Backend arbeiten, lohnt es sich fast nie. Wie das in breitere Arbeitsabläufe passt, zeigt unser Beitrag zur Automatisierung von Formular-Workflows mit Webhooks und APIs.

Fazit

Ein PHP-Mailformular von Grund auf zu bauen ist lösbar – aber es kostet Entwicklerzeit, die anderswo sinnvoller eingesetzt wäre. Zwischen Serverkonfiguration, Zustellbarkeitsproblemen, Spam-Schutz und langfristiger Wartung ist der tatsächliche Aufwand deutlich höher, als die anfänglichen 20 Codezeilen vermuten lassen. Serverlose Formular-zu-E-Mail-Dienste nehmen diese gesamte Komplexitätsebene weg. Für die meisten Kontaktformular-Anwendungsfälle lautet die bessere Frage nicht „Wie baue ich das?", sondern „Warum sollte ich das bauen, wenn ich es nicht muss?" Wer sehen möchte, wie unkompliziert die Einrichtung wirklich ist, findet im Leitfaden zum Einrichten von Kontaktformularen ohne Code den vollständigen Prozess Schritt für Schritt erklärt.

Schluss mit dem Kampf gegen PHP-Mail-Funktionen

Mit Sendform.net fügst du deiner Website in unter 2 Minuten ein funktionierendes Kontaktformular hinzu. Kein Server, kein Backend-Code, kein Aufwand. Einfach deinen Endpoint einfügen – fertig.

Kostenlos loslegen auf Sendform.net →