Warum Ihr Kontaktformular Ihr größtes Spam-Risiko ist

Das Problem ist älter, als Sie denken

Kontaktformulare sind seit den frühen 2000er-Jahren ein Spam-Vektor, aber das Problem hat sich verschärft, seit E-Mail-Anbieter ihre Authentifizierungsanforderungen erhöht haben. Die meisten Kontaktformulare werden immer noch nach demselben Muster gebaut: Ein Benutzer füllt ein Formular aus, Ihr Server sendet eine E-Mail mit der Adresse des Benutzers im From-Header, und Sie warten auf Antworten.

Das ist eine klassische Schwachstelle für E-Mail-Spoofing. Spammer können Ihr Formular verwenden, um E-Mails zu senden, die scheinbar von jeder beliebigen Adresse stammen, die sie wählen, weitergeleitet über die IP-Adresse Ihres Servers. Wenn auf diese Weise genug Spam versendet wird, wird Ihre Domain markiert und Ihre legitimen Transaktions-E-Mails erreichen keine Posteingänge mehr.

Die Behebung ist unkompliziert, aber die meisten Tutorials machen es immer noch falsch.

Was Kontaktformulare so leicht ausnutzbar macht

Ein typisches Kontaktformular akzeptiert drei Felder: Name, E-Mail und Nachricht. Der serverseitige Handler nimmt diese E-Mail-Adresse und setzt sie direkt in den From-Header einer ausgehenden SMTP-Nachricht. Das ist praktisch für Antworten — Sie können in Ihrem Posteingang einfach auf "Antworten" klicken —, aber es ist auch ein Geschenk an Spammer.

Folgendes passiert, wenn ein Spammer Ihr Formular findet:

1. Er sendet das Formular mit der E-Mail-Adresse eines Opfers im "from"-Feld ab
2. Ihr Server sendet pflichtbewusst eine E-Mail mit der Adresse dieses Opfers im From-Header
3. Der Mailserver des Opfers sieht eine E-Mail, die angeblich von dessen Domain stammt, aber von Ihrer IP ausgeht
4. Wenn Ihrer Domain korrekte SPF/DKIM/DMARC-Einträge fehlen (oder selbst wenn sie vorhanden sind), kann die E-Mail trotzdem durchkommen, weil viele Server bei Kontaktformular-Traffic nachsichtig sind
5. Das Opfer erhält Spam, der scheinbar von seiner eigenen Adresse stammt, oder Ihre Domain wird wegen Spoofing markiert

Das ist kein theoretischer Angriff. Es passiert ständig. Wenn Sie ein Kontaktformular betreiben und Ihre Mailserver-Logs noch nie geprüft haben, werden Sie wahrscheinlich bereits auf diese Weise missbraucht.

Die richtige Art, Kontaktformular-E-Mails zu versenden

Die Lösung besteht darin, niemals Benutzereingaben in den From-Header zu setzen. Stattdessen:

• From: [email protected] (oder eine beliebige Adresse, die Sie kontrollieren)
• Reply-To: Die vom Benutzer angegebene E-Mail-Adresse
• Subject: Fügen Sie den Namen des Benutzers hinzu, wenn Sie möchten, aber niemals seine E-Mail-Adresse
• Body: Alle Formulardaten aufnehmen, klar beschriftet

So sendet Ihr Server E-Mails nur von Adressen, die Ihnen gehören und korrekt authentifiziert sind. Wenn Sie in Ihrem Posteingang auf "Antworten" klicken, geht die Antwort weiterhin an den Benutzer — genau dafür ist Reply-To da. Spammer können Ihr Formular aber nicht verwenden, um beliebige Adressen zu imitieren.

Die meisten E-Mail-Bibliotheken unterstützen das direkt. In PHPs PHPMailer:

$mail->setFrom('[email protected]', 'Contact Form');
$mail->addReplyTo($_POST['email'], $_POST['name']);

In Pythons smtplib mit email.mime:

msg['From'] = '[email protected]'
msg['Reply-To'] = form_data['email']

In Node.js mit Nodemailer:

const mailOptions = {
  from: '[email protected]',
  replyTo: req.body.email,
  // ...
};

Wenn Ihr Kontaktformular derzeit Benutzereingaben in den From-Header setzt, ist das eine Ein-Zeilen-Korrektur. Erledigen Sie sie heute.

Rate Limiting ist nicht optional

Selbst bei sauberer Header-Hygiene bleibt ein ungeschütztes Kontaktformular ein Spam-Vektor. Spammer werden Ihr Formular hunderte Male mit unterschiedlichen Nachrichtentexten absenden, und Ihr Posteingang füllt sich mit Müll.

Sie brauchen Rate Limiting auf mehreren Ebenen:

• Pro IP: Nicht mehr als 5 Einsendungen pro Stunde von derselben IP
• Pro E-Mail: Nicht mehr als 3 Einsendungen pro Tag von derselben E-Mail-Adresse
• Global: Nicht mehr als 50 Einsendungen pro Stunde über alle Benutzer hinweg (passen Sie das an Ihren Traffic an)

Rate Limiting gehört in Ihren Anwendungscode, nicht nur in die Konfiguration Ihres Webservers. Rate Limiting in Nginx und Apache kann helfen, arbeitet aber auf Request-Ebene und weiß nichts über E-Mail-Adressen oder formularspezifische Missbrauchsmuster.

Wenn Sie ein Framework verwenden, gibt es wahrscheinlich eine Rate-Limiting-Middleware, die Sie einfach einbinden können. Wenn Sie von Grund auf bauen, genügt ein einfacher Redis-Zähler mit ablaufenden Schlüsseln:

key = f"contact_form:{ip_address}"
count = redis.incr(key)
if count == 1:
    redis.expire(key, 3600)  # 1 hour
if count > 5:
    return error("Rate limit exceeded")

Das ist nicht kugelsicher — Spammer können IPs rotieren —, aber es erhöht die Kosten des Missbrauchs erheblich.

CAPTCHAs sind ein Kompromiss, keine Lösung

Googles reCAPTCHA v3 ist unsichtbar und bewertet Benutzer anhand ihres Verhaltens, was ideal klingt. In der Praxis blockiert es legitime Benutzer häufiger, als man erwarten würde, besonders Benutzer über VPNs, Tor oder gemeinsame Unternehmensnetzwerke.

reCAPTCHA v2 (die "I'm not a robot"-Checkbox) ist zuverlässiger, erzeugt aber Reibung. Honeypot-Felder — versteckte Formulareingaben, die Menschen nicht ausfüllen, Bots aber schon — fangen einfache Bots ohne jegliche Auswirkung auf Benutzer ab, sind für ernsthafte Spammer jedoch trivial zu umgehen.

Der beste Ansatz ist mehrschichtig:

1. Korrekte E-Mail-Header (nicht verhandelbar)
2. Rate Limiting (nicht verhandelbar)
3. Honeypot-Feld (einfacher Gewinn, kein Nachteil)
4. CAPTCHA nur, wenn Sie nach den obigen Maßnahmen weiterhin erheblichen Spam erhalten

Wenn Sie ein CAPTCHA hinzufügen, verwenden Sie reCAPTCHA v3 mit einem niedrigen Schwellenwert (0,5 oder niedriger) und einem Fallback auf v2 für Benutzer mit schlechtem Score. So bleibt die Reibung für die meisten Benutzer gering, während Bots dennoch blockiert werden.

Wann ein Drittanbieter-Formulardienst sinnvoll ist

Wenn Sie eine kleine Website betreiben und keine Formularinfrastruktur warten möchten, übernehmen Drittanbieter-Dienste wie Formspree, Tally oder Netlify Forms all das für Sie. Sie begrenzen Raten, validieren und senden E-Mails von ihren eigenen Domains, sodass Ihre Reputation sauber bleibt.

Der Nachteil ist, dass Sie Benutzerdaten an einen Dritten senden, was mit Ihrer Datenschutzerklärung oder Ihren DSGVO-Pflichten kollidieren kann. Daten clientseitig zu verarbeiten ist ein wachsender Trend für datenschutzbewusste Teams, aber Kontaktformulare erfordern grundsätzlich serverseitige Verarbeitung — Sie können keine E-Mails aus dem Browser senden, ohne Zugangsdaten offenzulegen.

Wenn Sie sensible Anfragen bearbeiten (rechtlich, medizinisch, finanziell), sollten Sie Ihre Formularinfrastruktur wahrscheinlich selbst betreiben. Für alles andere ist ein Drittanbieter-Dienst eine vernünftige Wahl.

Das DMARC-Problem

Selbst wenn Sie die Header Ihres Kontaktformulars korrigieren, sind Sie nicht sicher, wenn Ihrer Domain eine DMARC-Richtlinie fehlt. DMARC sagt empfangenden Mailservern, was sie mit E-Mails tun sollen, die SPF- oder DKIM-Prüfungen nicht bestehen. Ohne DMARC können Spammer weiterhin E-Mails senden, die scheinbar von Ihrer Domain stammen, selbst wenn sie nicht Ihre Server verwenden.

Die Einrichtung von DMARC sprengt den Rahmen dieses Artikels, aber wenn Ihnen E-Mail-Reputation wichtig ist, ist sie nicht verhandelbar. Beginnen Sie mit einer reinen Monitoring-Richtlinie (p=none) und wechseln Sie schrittweise zu p=quarantine oder p=reject, sobald Sie verifiziert haben, dass Ihre legitimen E-Mails korrekt authentifiziert sind.

Was ist mit Cookie-Einwilligung und Formular-Tracking?

Wenn Ihr Kontaktformular Analytics oder Marketing-Pixel verwendet, um Einsendungen zu tracken, unterliegen Sie wahrscheinlich den Regeln der DSGVO und der ePrivacy-Vorgaben. Die meisten Kontaktformulare brauchen kein Tracking — Sie wissen bereits, dass jemand das Formular abgeschickt hat, weil Sie die E-Mail erhalten haben —, aber wenn Sie etwas wie Facebook Pixel oder Google Analytics Events verwenden, benötigen Sie eine ausdrückliche Einwilligung, bevor diese Skripte geladen werden.

Der einfachste Ansatz ist, Einsendungen über Kontaktformulare gar nicht zu tracken. Wenn Sie sie tracken müssen, laden Sie Tracking-Skripte erst, nachdem der Benutzer eingewilligt hat, und stellen Sie sicher, dass Ihr Consent-Banner konform ist.

Wichtigste Erkenntnisse

• Setzen Sie niemals von Benutzern eingereichte E-Mail-Adressen in den From-Header. Verwenden Sie stattdessen Reply-To.
• Rate Limiting ist zwingend erforderlich. Implementieren Sie es auf Anwendungsebene, nicht nur auf dem Webserver.
• Honeypot-Felder sind ein kostenloser Gewinn. CAPTCHAs sollten das letzte Mittel sein.
• Drittanbieter-Formulardienste sind für kleine Websites eine vernünftige Wahl, bringen aber Datenschutz-Kompromisse mit sich.
• Wenn Sie E-Mails von Ihrer Domain senden, benötigen Sie eine DMARC-Richtlinie.

FAQ

Q: Kann ich das Kontaktformular einfach deaktivieren und stattdessen einen mailto-Link verwenden?

A: Das können Sie, aber mailto-Links legen Ihre E-Mail-Adresse für Scraper offen, und Sie verlieren die Möglichkeit, strukturierte Daten zu erfassen. Wenn Spam überwältigend ist, ist ein mailto-Link besser als ein kaputtes Kontaktformular, aber das Formular zu reparieren ist besser als beides.

Q: Was ist, wenn ich aus legitimen Gründen E-Mails von der Adresse des Benutzers senden muss?

A: Das müssen Sie mit an Sicherheit grenzender Wahrscheinlichkeit nicht. Wenn Sie glauben, dass Sie es müssen, versuchen Sie wahrscheinlich, ein Workflow-Problem zu lösen (etwa das Routing von Antworten), das Reply-To bereits löst. Wenn Sie wirklich E-Mails von beliebigen Adressen senden müssen, benötigen Sie einen dedizierten E-Mail-Dienst mit korrekter Authentifizierung, kein Kontaktformular.

Q: Woher weiß ich, ob mein Kontaktformular bereits missbraucht wird?

A: Prüfen Sie Ihre Mailserver-Logs auf ausgehende SMTP-Verbindungen. Wenn Sie ein hohes Volumen ausgehender E-Mails an Adressen sehen, die Sie nicht kennen, oder wenn Ihre Domain von Spam-Datenbanken wie Spamhaus markiert wurde, werden Sie wahrscheinlich als Relay missbraucht. Tools wie MXToolbox können die Reputation Ihrer Domain prüfen.

Q: Ist es sicher, einen kostenlosen CAPTCHA-Dienst zu verwenden?

A: Googles reCAPTCHA ist kostenlos und weit verbreitet, sendet aber Benutzerdaten an Google, was mit Ihrer Datenschutzerklärung kollidieren kann. hCaptcha ist eine datenschutzorientierte Alternative, die keine KI-Modelle mit Ihren Benutzern trainiert. Cloudflare Turnstile ist eine weitere Option, die weniger aufdringlich ist als klassische CAPTCHAs.

Q: Was ist der Unterschied zwischen SPF, DKIM und DMARC?

A: SPF listet auf, welche Mailserver E-Mails von Ihrer Domain senden dürfen. DKIM signiert ausgehende E-Mails kryptografisch, sodass Empfänger verifizieren können, dass sie nicht manipuliert wurden. DMARC verbindet beides und teilt Empfängern mit, was zu tun ist, wenn eine E-Mail SPF- oder DKIM-Prüfungen nicht besteht. Für eine ordnungsgemäße E-Mail-Authentifizierung benötigen Sie alle drei.

Quellen

• OWASP: Email Header Injection — Detaillierte Erklärung, wie Kontaktformulare für E-Mail-Spoofing ausgenutzt werden können.
• RFC 5322: Internet Message Format — Der technische Standard, der E-Mail-Header definiert, einschließlich From und Reply-To.
• DMARC.org: Overview — Offizielle Ressource zum Verständnis und zur Implementierung von DMARC-Richtlinien.
• Spamhaus: Domain Blocklists — Prüfen Sie, ob Ihre Domain wegen Spam markiert wurde, und verstehen Sie, wie Blocklists funktionieren.