Warum Kontaktformular-E-Mails nicht ankommen und wie man das behebt

1. Executive Summary

Wenn die Benachrichtigungs-E-Mail eines Kontaktformulars „erfolgreich gesendet wird, aber nicht ankommt“, liegt die Ursache meist nicht im Code des E-Mail-Versands, sondern im Design des Absenders. Das Fazit besteht aus drei Punkten.

1. From: fest auf die eigene Website-Domain setzen und die Adresse des Formularnutzers in Reply-To: eintragen. Damit werden sichtbarer Absender und tatsächlich authentifizierte Domain aufeinander abgestimmt.
2. SPF und DKIM beide einrichten. Weiterleitung bricht SPF leicht; verlässt man sich nur auf SPF, fallen selbst legitime E-Mails durch.
3. DMARC mit p=none zur Beobachtung beginnen und stufenweise auf quarantine / reject hochstufen. Ein sofortiger Sprung zu reject blockiert auch die eigenen regulären E-Mails.

Begründung und Belege folgen ab Kapitel 2. Wer eine aktuelle Nichtzustellung zunächst eingrenzen möchte, kann auch direkt bei den Diagnoseschritten in Kapitel 4 einsteigen.

Zielgruppe und vorausgesetzte Umgebung

Dieser Artikel richtet sich an alle, die das Problem haben, dass Benachrichtigungs-E-Mails vom Kontaktformular der eigenen Website nicht ankommen.

DNS-Einträge (SPF / DKIM / DMARC) und das Header-Design sind unabhängig davon, ob der Webserver unter Windows oder Linux läuft und ob der Versand über eine eigene MTA oder einen externen Dienst erfolgt. Auch bei unterschiedlichen Implementierungssprachen ändert sich nur, wo die Header zusammengebaut werden und wo der Envelope-Absender angegeben wird.

In diesem Artikel verwendete Begriffe

Vorab eine Zusammenstellung der Begriffe, die im Text ohne weitere Erklärung verwendet werden.

Aufbau dieses Artikels

1. Executive Summary (dieses Kapitel)
2. Die Rollen von SPF, DKIM, DMARC und dem From-Header ── das Prinzip verstehen
3. Typische Fehlerszenarien bei Kontaktformularen
4. Diagnoseschritte und Befehle ── Header, DNS, SMTP, realer Versand
5. Empfohlene From-Design-Muster
6. Konfigurationsleitfaden nach Aufbau (externes SMTP / Shared Hosting / PHP)
7. Troubleshooting-Checkliste

2. Die Rollen von SPF, DKIM, DMARC und dem From-Header

Bei der E-Mail-Zustellung müssen Envelope und Header getrennt betrachtet werden. Was SPF in erster Linie prüft, ist das MAIL FROM während der SMTP-Sitzung — der Absender auf Zustellungsebene. Bei der endgültigen Zustellung sollte davon genau ein Rückweg als Return-Path erhalten bleiben; das sendende SMTP-System sollte von vornherein keine Nachricht mit einem eigenen Return-Path-Header erzeugen. From: dagegen zeigt auf der Header-Seite, „von wem die Mail zu kommen scheint“, Reply-To: gibt das Antwortziel an, und Sender: bezeichnet die tatsächlich sendende Instanz.

RFC 5322 definiert From: als Verfasser der Nachricht und Sender: als tatsächlich sendende Instanz. Sind Verfasser und sendende Instanz identisch, sollte Sender: nicht verwendet werden; soll das Antwortziel vom Verfasser abweichen, ist Reply-To: das richtige Mittel. RFC 5322 hält zudem ausdrücklich fest, dass in From: keine Adresse stehen sollte, die nicht dem Verfasser gehört. Eine Kontaktformular-Benachrichtigung wird normalerweise nicht vom Nutzer selbst über ein MUA gesendet, sondern ist eine vom System der Website erzeugte Benachrichtigung — ein Design, das die Nutzeradresse in From: einträgt, weicht daher auch vom Sinn der Spezifikation ab.

DKIM versieht einen Teil der Header und den Text der Nachricht mit einer Signatur, die die Empfängerseite anhand eines öffentlichen Schlüssels aus dem DNS prüft. Die signierende Domain steht im d= der DKIM-Signature, der öffentliche Schlüssel wird über einen Selektor abgerufen, etwa als selector._domainkey.example.com. DKIM gilt als Authentifizierung, die „eine Weiterleitung vergleichsweise gut übersteht“; werden jedoch Text oder signierte Header unterwegs verändert, schlägt entweder der Text-Hash bh= oder die Signaturprüfung fehl.

DMARC prüft nicht nur, ob SPF und DKIM erfolgreich sind, sondern auch, ob deren authentifizierte Domains mit der From:-Domain übereinstimmen. Das ist der entscheidende Punkt. Selbst wenn SPF durchgeht, aber MAIL FROM=bounces.vendor.net bei From: contact@example.com steht, scheitert das SPF-Alignment. Geht DKIM mit d=example.com durch, kann DMARC bestehen — fehlt aber auch DKIM, scheitert DMARC. DMARC definiert über adkim / aspf die Alignment-Modi strict / relaxed, über p=none|quarantine|reject die Policy sowie über rua / ruf die Empfänger für Reports.

Googles aktuelle Richtlinien übersetzen diesen Designgedanken direkt in Betriebsanforderungen. Google verlangt ausdrücklich, „den From:-Header nicht zu fälschen“ und dass „bei Direktmail die Domain im From:-Header mit der SPF-Domain oder der DKIM-Domain übereinstimmt“. Eine Kontaktformular-Benachrichtigung ist keine Marketing-Mail, aber die Grundlogik der empfängerseitigen Filter ist dieselbe, sodass ein Ignorieren dieses Prinzips die Zustellrate senkt.

sequenceDiagram
    participant User as Formularnutzer
    participant App as Web-App
    participant SMTP as sendende MTA / SMTP-Dienst
    participant DNS as DNS
    participant MX as empfangende MX

    User->>App: Formular absenden
    App->>App: From / Reply-To / Sender festlegen
    App->>SMTP: SMTP-Sendeanfrage
    SMTP->>SMTP: DKIM-Signatur anbringen
    SMTP->>MX: MAIL FROM / RCPT TO / DATA
    MX->>DNS: SPF-Abfrage (MAIL FROM)
    MX->>DNS: DKIM-Public-Key-Abfrage (selector._domainkey)
    MX->>DNS: DMARC-Abfrage (_dmarc + From-Domain)
    MX->>MX: Alignment-Bewertung
    MX-->>App: Zugestellt / Spam / Abgelehnt / Bounce

Wichtig an diesem Ablauf ist, dass die DMARC-Bewertung bis zuletzt auf der From:-Domain zentriert bleibt. Da die App-Seite From:, die SMTP-Seite MAIL FROM und die DNS-Seite SPF/DKIM/DMARC jeweils getrennt betrifft, löst das Korrigieren nur eines dieser Punkte die Nichtzustellung nicht.

3. Typische Fehlerszenarien bei Kontaktformularen

Am häufigsten ist der Fall, dass die Adresse des Formularnutzers in From: eingetragen wird. Wird zum Beispiel vom SMTP der Website aus mit From: taro@gmail.com gesendet, bestehen SPF und DKIM normalerweise für die Website-Domain, nicht für die Gmail-Domain. Das Ergebnis ist die Diskrepanz, dass From: Gmail zeigt, während die authentifizierte Domain example.com ist — die DMARC-Alignment scheitert. Auch Google selbst fordert, From:-Fälschung zu vermeiden und From: mit der SPF-/DKIM-Domain in Einklang zu bringen.

Als Nächstes häufig ist der Fall, dass SPF durch Weiterleitung bricht. Bei E-Mail-Weiterleitung wird die vom letzten Empfänger gesehene Absender-IP häufig zu einem „Relay-Server, der nicht im SPF-Eintrag der ursprünglichen Sendedomain steht“, sodass selbst legitime E-Mails an SPF scheitern. Auch Google weist darauf hin, dass „weitergeleitete E-Mails leicht an SPF scheitern, weshalb unbedingt DKIM eingesetzt werden sollte“. Fügt die weiterleitende Stelle zusätzlich Text, Betreffpräfixe oder eine Fußzeile hinzu, bricht auch DKIM.

Typisch ist auch eine unvollständige Erstkonfiguration beim Einsatz eines externen SMTP-Dienstes. Bei SendGrid gibt es Fälle, in denen ohne konfigurierte Domain Authentication gar nicht gesendet werden kann; wird Automated Security aktiviert, werden CNAME-basierte Authentifizierungseinträge erzeugt, und bei Bedarf lassen sich Custom Return Path oder Custom DKIM Selector einrichten. Bei SES wird standardmäßig das MAIL FROM von amazonses.com verwendet, wodurch SPF implizit erfüllt ist — will man aber SPF-Alignment mit der eigenen Website-Domain, muss ein benutzerdefiniertes MAIL FROM eingerichtet werden. Auch bei Mailgun kommt ohne eingerichtetes SPF/DKIM der Sendedomain und die nötigen MX-Einträge keine korrekte Sendesignatur zustande.

Die lokale MTA von Shared Hosting ist eine leicht übersehene Falle. Selbst wenn die eigene Website authentifiziert ist, sinkt die Zustellrate, wenn die tatsächlich ausgehende IP eine geteilte IP mit schlechter Reputation ist, kein PTR vorhanden ist oder das Hosting kein DKIM anbringt. Google macht den PTR der sendenden IP zur Anforderung und weist darauf hin, dass eine schlechte Reputation einer geteilten IP zu Fehlern der Klasse 5.7.1 führen kann.

Auch die Verwendung von PHPs mail() oder von Versandbibliotheken ist eine häufige Fehlerquelle. Das PHP-Handbuch erklärt, dass mail() einen From-Header benötigt und dass sich über zusätzliche Parameter mittels sendmail -f der Envelope-Absender angeben lässt. Das heißt: Statt selbst einen Return-Path:-Header zusammenzubauen, sollte man den Envelope-Absender an die MTA übergeben. Wird das missverstanden, weichen der für die SPF-Prüfung verwendete Absender und der von der App angenommene Absender voneinander ab.

Schließlich gibt es den Fall, dass Sender oder From angepasst werden, wo eigentlich Reply-To gehört. Soll lediglich das Antwortziel auf den Nutzer gerichtet werden, genügt Reply-To. Sender ist der Header, um ausdrücklich zu zeigen, dass „Verfasser und tatsächlich sendende Instanz voneinander abweichen“ — kein Header, der bei Kontaktformularen regelmäßig verwendet werden sollte. Trennt man die Zielsetzung des Designs — „soll die Antwort an den Nutzer zurückgehen“ oder „soll die verantwortliche Instanz der Benachrichtigung angezeigt werden“ — voneinander, sinkt die Fehleranfälligkeit.

4. Diagnoseschritte und Befehle

Als Erstes sollte man die rohen E-Mail-Header ansehen, bevor man in den Code schaut. In Gmail über „Original anzeigen“, in Outlook über „Nachrichtendetails“ oder „Internetheader“ lassen sich Authentication-Results, Return-Path, From, Reply-To, DKIM-Signature und Received prüfen. Damit lässt sich mit hoher Genauigkeit eingrenzen, ob das Problem „es wird nicht gesendet“ oder „Authentifizierung und Alignment sind gestört“ ist.

Worauf im Header zuerst zu achten ist

Oberste Priorität haben diese fünf Punkte.

1. Welche Domain steht in From:
2. Welche Domain steht in Return-Path:
3. Zeigt Authentication-Results: spf=pass / dkim=pass / dmarc=pass
4. Bei dkim=pass: welche Domain steht in header.i= oder d=
5. Bei dmarc=fail: liegt der Grund in einem Authentifizierungsfehler oder in einer Alignment-Verletzung

Auch Googles DMARC-Troubleshooting hält ausdrücklich fest, dass eine Nachricht andere Authentifizierungen bestehen und trotzdem an DMARC scheitern kann, wenn die Header nicht aligned sind.

Befehle zur DNS-Prüfung

dig ist das Standardwerkzeug für DNS-Troubleshooting; auch das BIND-Handbuch beschreibt es als DNS-Abfragewerkzeug mit flexibler, klarer Ausgabe. nslookup ist ein leichteres Prüfwerkzeug, das auch im nicht-interaktiven Modus funktioniert. Bei der Authentifizierungsprüfung eines Kontaktformulars sollten mindestens diese drei Einträge abgefragt werden: SPF, DKIM und DMARC.

# SPF
dig +short TXT example.com

# DKIM
dig +short TXT form2026._domainkey.example.com

# DMARC
dig +short TXT _dmarc.example.com

# unter Windows
nslookup -type=txt example.com
nslookup -type=txt _dmarc.example.com
nslookup -type=txt form2026._domainkey.example.com

Eine typische erwartete Ausgabe sieht so aus.

"v=spf1 include:sendgrid.net include:mailgun.org ip4:203.0.113.10 -all"
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."
"v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-afrf@example.com; adkim=r; aspf=r; fo=1"

Zu prüfen ist hier, ob der SPF-Eintrag in einem einzigen Datensatz zusammengefasst ist, ob sich der DKIM-Public-Key auflösen lässt und ob DMARC ein p= besitzt. RFC 7208 begrenzt die Mechanismen von SPF, die eine DNS-Abfrage auslösen, auf insgesamt 10; wird das überschritten, führt das zu permerror.

Prüfung von SMTP-Verbindung und TLS

openssl s_client ist der universelle SSL/TLS-Client von OpenSSL und praktisch, um STARTTLS und die Zertifikatskette eines SMTP-Servers zu prüfen. Mit -starttls smtp wird STARTTLS für SMTP gestartet, mit -showcerts lässt sich die vom Server zurückgegebene Zertifikatsliste einsehen.

printf 'QUIT\r\n' | openssl s_client \
  -connect smtp.example.com:587 \
  -starttls smtp \
  -servername smtp.example.com \
  -showcerts \
  -brief

Ein Beispiel für die Ausgabe.

CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Verification: OK
250 CHUNKING

Damit lässt sich zumindest sehen, ob eine Verbindung zum SMTP-Server möglich ist, ob STARTTLS aktiv ist und ob die Zertifikatsprüfung keine offensichtliche Auffälligkeit zeigt. Google verlangt von Sendern ab einer bestimmten Größenordnung TLS; fehlendes TLS kann Ursache für 5.7.29 sein.

Reproduktionstest mit realem Versand

swaks ist ein praktisches Werkzeug speziell für SMTP-Tests, das Versand einschließlich TLS, Authentifizierung und SMTP-Erweiterungen flexibel nachbilden kann. Bei der Untersuchung nicht zugestellter Kontaktformular-E-Mails ist es wirksam, „ohne die App, mit demselben SMTP, demselben From, demselben Reply-To und demselben Empfänger“ eine einzelne E-Mail zu senden, um den Fehler zu reproduzieren.

swaks \
  --server smtp.example.com \
  --port 587 \
  --tls \
  --auth LOGIN \
  --auth-user contact@example.com \
  --auth-password '********' \
  --from bounce@example.com \
  --to yourtest@gmail.com \
  --h-From "Website-Benachrichtigung <contact@example.com>" \
  --h-Reply-To "Max Mustermann <visitor@gmail.com>" \
  --header "Subject: swaks test" \
  --body "This is a test"

Bei erfolgreichem Versand sieht das typischerweise so aus.

=== Trying smtp.example.com:587...
=== Connected to smtp.example.com.
<-  250-STARTTLS
<-  250-AUTH LOGIN PLAIN
->  STARTTLS
<-  220 Ready to start TLS
...
<-  250 2.0.0 Ok: queued as ABC123DEF

Schlägt der Versand über die App fehl, funktioniert aber über swaks, liegt die Ursache mit hoher Wahrscheinlichkeit beim Header-Aufbau der Bibliothek oder bei der Konfiguration des Envelope-Absenders. Scheitert es dagegen auch mit swaks in gleicher Weise, lässt sich die Ursache auf DNS, SMTP oder die Policy der Empfängerseite eingrenzen.

Externe Diagnose mit mail-tester

mail-tester ist ein Dienst, der eine E-Mail an eine zufällig ausgegebene Testadresse senden lässt und Nachricht, sendenden Server und sendende IP analysiert, um einen detaillierten Bericht zurückzugeben. Er eignet sich gut als erste Diagnose bei „irgendwie kommt es einfach nicht an“-Fällen auf lokalen MTAs oder Shared Servern.

Die Nutzung ist einfach.

1. Die von mail-tester ausgegebene Testadresse abrufen
2. Über denselben Weg wie das Kontaktformular eine E-Mail senden
3. Den Score sowie die Hinweise zu SPF / DKIM / DMARC / Rückwärtsauflösung / Blacklists / Textaufbau ansehen

Der mail-tester-Score allein sollte nicht über die Produktionszustellung entscheiden, aber zumindest Dinge wie „SPF ist gar nicht sichtbar“, „der DKIM-Public-Key lässt sich nicht auflösen“ oder „Text oder Absenderaufbau wirken unnatürlich“ lassen sich damit schnell finden.

Beispiele für die Header-Analyse

Ein fehlgeschlagenes Beispiel.

Return-Path: <bounce-123@vendor.example.net>
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce-123@vendor.example.net designates 198.51.100.10 as permitted sender) smtp.mailfrom=vendor.example.net;
       dkim=none;
       dmarc=fail (p=quarantine sp=quarantine dis=none) header.from=gmail.com
From: Max Mustermann <visitor@gmail.com>
Reply-To: Max Mustermann <visitor@gmail.com>
Subject: Kontaktanfrage

Bei dieser E-Mail besteht SPF zwar, aber DMARC scheitert, weil From: gmail.com lautet. Das ist der typische Bruch, wenn beim Kontaktformular die Nutzeradresse in From: eingetragen wird.

Ein erfolgreiches Beispiel sieht so aus.

Return-Path: <bounce@example.com>
Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=example.com;
       dkim=pass header.i=@example.com header.s=form2026;
       dmarc=pass header.from=example.com
From: Example Site <contact@example.com>
Reply-To: Max Mustermann <visitor@gmail.com>
Subject: Benachrichtigung über eine Kontaktanfrage

In dieser Form bleibt das einfache Antworten an den Nutzer über Reply-To: erhalten, während sowohl sichtbarer als auch authentifizierter Absender auf example.com liegen — die Zustellrate wird dadurch deutlich stabiler.

5. Empfohlene From-Design-Muster

Das Prinzip, das bei Kontaktformularen nicht wanken sollte, ist, „die für die Authentifizierung verwendete Domain“ und „die dem Empfänger gezeigte From-Domain“ aufeinander abzustimmen. Das Antwortziel wird dabei allein über Reply-To: herausgeführt. Teilt man das Design in drei Schichten — Sender: nur bei Bedarf, Return-Path über den Envelope gesetzt —, wird es stabil.

Die Grundlage dieser Tabelle sind die Bedeutungen von From / Sender / Reply-To in RFC 5322, der Umgang mit Return-Path in RFC 5321 sowie die Spezifikation, dass DMARC anhand von From: die Übereinstimmung bewertet. Als Standard für Formular-Benachrichtigungen genügt das „empfohlene Muster“ in der ersten Zeile. Auch wenn man versucht ist, die Nutzeradresse in From: einzutragen, lässt sich das Ziel erreichen, indem man das Antwortziel in Reply-To: einträgt.

Besonders wichtig zu behalten: Return-Path ist kein „zu bearbeitender Header“, sondern „das Ergebnis des bei der Zustellung verwendeten Envelope-Absenders“. Bei PHP mail() ist das -f, bei einem SMTP-Dienst sind es Einstellungen wie Custom MAIL FROM / Return Path / Bounce-Domain — das ist die korrekte Implementierung.

6. Konfigurationsleitfaden nach Aufbau

Ab hier werden für die drei in der Praxis häufigsten Konstellationen die Grundgedanken der Konfiguration geordnet dargestellt. Als Voraussetzung gilt: Die tatsächlich in DNS einzutragenden Werte sollten immer aus dem Verwaltungsbereich des jeweiligen Dienstes entnommen werden. Die folgenden Beispieleinträge dienen dem Verständnis der Struktur.

Wenn die Website einen externen SMTP-Dienst nutzt

Der wichtigste Punkt bei externem SMTP ist, zuerst die Authentifizierung der eigenen Domain abzuschließen. Auch Google rät, bei Nutzung eines E-Mail-Dienstanbieters zu prüfen, ob dieser Dienst SPF und DKIM der eigenen Domain authentifiziert.

Empfohlene Konfiguration

• From: ist contact@example.com oder contact@form.example.com
• Reply-To: ist die Adresse des Formularnutzers
• Return-Path / MAIL FROM ist eine selbst verwaltete Subdomain für Bounces, etwa bounce.example.com
• DKIM signiert mit example.com oder der Sende-Subdomain
• DMARC liegt auf der sichtbaren From:-Domain

Typische SendGrid-Konfiguration

Bei SendGrid wird Domain Authentication vorausgesetzt; ist Automated Security aktiviert, werden drei CNAMEs erzeugt. Ist es deaktiviert, werden ein MX und zwei TXT-Einträge erzeugt, zusätzlich lassen sich Custom Return Path und Custom DKIM Selector einrichten.

; Beispiel: SendGrid (die tatsächlichen Werte aus dem Verwaltungsbereich verwenden)
em123.example.com.           CNAME   u123456.wl.sendgrid.net.
s1._domainkey.example.com.   CNAME   s1.domainkey.u123456.wl.sendgrid.net.
s2._domainkey.example.com.   CNAME   s2.domainkey.u123456.wl.sendgrid.net.

_dmarc.example.com.          TXT     "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com"

Eine häufige Falle bei SendGrid ist der Zustand „nur SMTP-Authentifizierung eingerichtet, Domain Authentication nicht konfiguriert“. In diesem Zustand funktioniert der Versand zwar, aber aus Empfängersicht ist die Beziehung zwischen From: und der authentifizierten Domain schwach. Grundsätzlich sollte Domain Authentication abgeschlossen und darauf aufbauend bei Bedarf Custom Return Path eingerichtet werden.

Typische SES-Konfiguration

SES verwendet standardmäßig ein MAIL FROM unter der Subdomain amazonses.com, wodurch SPF implizit erfüllt ist. Will man aber SPF-Alignment mit der eigenen Website-Domain, verwendet man ein benutzerdefiniertes MAIL FROM. SES verlangt dafür für die benutzerdefinierte MAIL-FROM-Domain einen SPF-TXT-Eintrag und einen MX-Eintrag, wobei genau ein MX-Eintrag vorhanden sein muss. Zudem fügt Easy DKIM drei CNAMEs zum DNS hinzu.

; Beispiel: SES Easy DKIM
abcde12345._domainkey.example.com.   CNAME   abcde12345.dkim.amazonses.com.
fghij67890._domainkey.example.com.   CNAME   fghij67890.dkim.amazonses.com.
klmno54321._domainkey.example.com.   CNAME   klmno54321.dkim.amazonses.com.

; Beispiel: SES custom MAIL FROM
bounce.example.com.                  MX      10 feedback-smtp.ap-northeast-1.amazonses.com.
bounce.example.com.                  TXT     "v=spf1 include:amazonses.com -all"

_dmarc.example.com.                  TXT     "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com"

Wichtig beim SES-Design ist, dass die MAIL-FROM-Domain eine eigene Subdomain nur für Bounces ist, nicht die sendende From:-Domain selbst. Auch AWS rät, für MAIL FROM eine Subdomain zu verwenden statt der Domain, von der tatsächlich gesendet wird.

Typische Mailgun-Konfiguration

Bei Mailgun sind für die Verifizierung der Sendedomain ein TXT-Eintrag für SPF und ein TXT-Eintrag für DKIM nötig, dazu zwei zusätzliche MX-Einträge. Existiert bereits ein SPF-Eintrag, sollte nicht ein neuer angelegt, sondern include:mailgun.org in den bestehenden eingefügt werden. Es können mehrere DKIM-Schlüssel sichtbar sein; solange der aktuell verwendete Schlüssel korrekt im DNS steht, ist der Versand möglich.

; Beispiel: Mailgun auf einer Subdomain
mg.example.com.                      TXT     "v=spf1 include:mailgun.org ~all"
mx._domainkey.mg.example.com.        TXT     "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."
mg.example.com.                      MX      10 mxa.mailgun.org.
mg.example.com.                      MX      10 mxb.mailgun.org.
email.mg.example.com.                CNAME   mailgun.org.

_dmarc.example.com.                  TXT     "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com"

Mailgun eignet sich gut für den Betrieb auf einer Subdomain; richtet man eine eigene Sende-Subdomain wie mg.example.com ein, lassen sich Formular- und Transaktionsbenachrichtigungen leichter verwalten.

Wenn die Website über die lokale MTA von Shared Hosting sendet

Bei Shared Hosting sollte zuerst nicht die eigene App, sondern die Qualität der Versandinfrastruktur des Hosters geprüft werden. Ist der PTR der sendenden IP, die DKIM-Unterstützung, die Reputation der geteilten IP oder die Einsicht in Versandprotokolle schwach, ist dieser Aufbau von vornherein im Nachteil. Auch Google legt Wert auf den PTR der sendenden IP und weist darauf hin, dass eine schlechte Reputation einer geteilten IP eine Ursache für Blockierungen sein kann.

In der Praxis ist es sicherer, in dieser Reihenfolge vorzugehen.

1. Prüfen, ob der Hosting-Anbieter SPF/DKIM/PTR über die Verwaltungsoberfläche oder den Support konfigurierbar macht
2. From: unbedingt fest auf die eigene Domain setzen
3. Die sendenden IPs des Hostings oder die erlaubte Sendedomain in SPF aufnehmen
4. DKIM über die Hosting-Funktion aktivieren. Fehlt sie, auf externes SMTP wechseln
5. Wenn möglich, die Bounce-Adresse für MAIL FROM als eigene Subdomain wie bounce.example.com abtrennen

Bei Shared-Hosting-Servern zuerst beim Anbieter nachfragen

Bei Shared-Hosting-Servern ist der Bereich, in dem sich die Versandinfrastruktur selbst anpassen lässt, begrenzt. Bevor man selbst Hand anlegt, sollte über Verwaltungsoberfläche, Handbuch oder Support Folgendes geklärt werden.

Davon sind die Möglichkeit einer DKIM-Signatur und die Möglichkeit, Zustellprotokolle einzusehen, entscheidend dafür, ob sich in dieser Umgebung überhaupt untersuchen und verbessern lässt. Ist beides „nicht möglich“, ist es der schnellste Weg, zumindest die Formular-Benachrichtigung auf externes SMTP umzustellen. Formular-Benachrichtigungen haben ein geringes Sendevolumen und einen begrenzten Wirkungskreis beim Umstieg, weshalb sie sich gut als erstes Migrationsziel eignen.

Als typisches Beispiel für das eigenständige Erzeugen von DKIM auf Shared Hosting lässt sich mit opendkim-genkey aus der OpenDKIM-Familie der private Schlüssel und der TXT-Eintrag für DNS erzeugen. Die Struktur, den öffentlichen DKIM-Schlüssel mit Selektor unter selector._domainkey.example.com abzulegen, entspricht RFC 6376.

mkdir -p /etc/opendkim/keys/example.com
opendkim-genkey -D /etc/opendkim/keys/example.com -d example.com -s form2026
chown opendkim:opendkim /etc/opendkim/keys/example.com/form2026.private
chmod 600 /etc/opendkim/keys/example.com/form2026.private

Das Ergebnis sieht danach etwa so aus.

form2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

# /etc/opendkim/KeyTable
form2026._domainkey.example.com example.com:form2026:/etc/opendkim/keys/example.com/form2026.private

# /etc/opendkim/SigningTable
*@example.com form2026._domainkey.example.com

Lassen sich PTR oder das ausgehende Relay auf Shared Hosting jedoch nicht selbst steuern, ist der Umstieg auf externes SMTP der schnellere Weg. Selbst bei geringem Sendevolumen wie Kontaktformular-Benachrichtigungen ist eine schwach authentifizierte lokale MTA gegenüber Gmail und Unternehmens-E-Mail im Nachteil.

Wenn die Website PHP mail() oder eine SMTP-Bibliothek verwendet

PHP mail() ist praktisch, hängt in Bezug auf Authentifizierung und Zustellrate aber davon ab, „was für eine MTA dahintersteckt“. Das PHP-Handbuch erklärt, dass E-Mails einen From-Header benötigen und dass sich beim Versand über sendmail_path der Envelope-Absender über zusätzliche Parameter angeben lässt. Umgekehrt bedeutet das: Die Verwendung von mail() bringt SPF/DKIM/DMARC nicht automatisch in Ordnung.

Zunächst sollte mindestens Folgendes gestaltet werden.

• From: ist contact@example.com
• Reply-To: ist der Formularnutzer
• Der Envelope-Absender ist bounce@example.com
• Die Adresse des Nutzers wird zusätzlich im Text angegeben
• Wenn möglich, statt mail() authentifiziertes SMTP verwenden

Minimalbeispiel für mail()

Nutzereingaben direkt in Header einzutragen ist gefährlich. Mischen sich CR/LF in $name oder $email, kann ein Angreifer zusätzliche Header wie Bcc: einschleusen und das Formular so zum Spam-Relay machen. Auch das PHP-Handbuch verlangt, dass externe Eingaben, die in Headern verwendet werden, immer validiert bzw. normalisiert werden. Im folgenden Beispiel werden alle in Header einfließenden Werte vorab bereinigt, einschließlich des Envelope-Absender-Arguments (additional_params).

<?php

// Gibt nur Werte zurück, die im Header verwendet werden dürfen. Enthält der Wert CR/LF/NUL, wird abgelehnt.
function sanitize_header_value(string $value): string {
    if (preg_match('/[\r\n\0]/', $value)) {
        throw new InvalidArgumentException('Invalid characters in header value');
    }
    return trim($value);
}

// Prüft die E-Mail-Adresse RFC-konform.
function sanitize_email(string $email): string {
    $clean = sanitize_header_value($email);
    if (!filter_var($clean, FILTER_VALIDATE_EMAIL)) {
        throw new InvalidArgumentException('Invalid email address');
    }
    return $clean;
}

$to = 'ops@example.com';
$subject = sanitize_header_value('Benachrichtigung über eine Kontaktanfrage');

// $name / $email / $message sind Formulareingaben. $message steht im Textkörper, daher ist dort CR/LF erlaubt,
// während $name / $email im Header verwendet werden und CR/LF deshalb immer abgelehnt werden muss.
$safeName  = sanitize_header_value($name);
$safeEmail = sanitize_email($email);

$body = <<<TEXT
Name: {$safeName}
Email: {$safeEmail}

{$message}
TEXT;

$headers = [
    'From' => 'Example Site <contact@example.com>',
    'Reply-To' => sprintf('%s <%s>', $safeName, $safeEmail),
    'Content-Type' => 'text/plain; charset=UTF-8',
];

// additional_params landet ebenfalls in der Shell, daher nur feste Werte verwenden, keine dynamischen Eingaben mischen.
mail($to, $subject, $body, $headers, '-fbounce@example.com');

Die zwei wichtigen Punkte an diesem Beispiel: Erstens wird Return-Path: nicht als Header geschrieben, sondern der Envelope-Absender über -f im fünften Argument übergeben. Zweitens durchlaufen Nutzereingaben, die in Header wie Reply-To: einfließen, eine Bereinigungsfunktion, die CR/LF abweist. Baut man Header ohne diese Bereinigung zusammen, kann ein Angreifer eine Zeichenfolge wie \r\nBcc: victim@example.com einschleusen und so zusätzliche Header einfügen — deshalb gilt im PHP-Handbuch die Validierung externer, im Header verwendeter Eingaben als zwingend. Da auch additional_params letztlich an die Shell übergeben wird, sollten hier nur feste Werte verwendet werden, niemals Nutzereingaben.

Beispiel mit einer SMTP-Bibliothek

<?php
$mail->isSMTP();
$mail->Host = 'smtp.example.com';
$mail->Port = 587;
$mail->SMTPAuth = true;
$mail->SMTPSecure = 'tls';
$mail->Username = getenv('SMTP_USER');
$mail->Password = getenv('SMTP_PASS');

$mail->setFrom('contact@example.com', 'Example Site');
$mail->addAddress('ops@example.com');
$mail->addReplyTo($email, $name);

// Je nach Bibliothek lassen sich Sender / Return-Path getrennt einstellen
$mail->Sender = 'bounce@example.com';

$mail->Subject = 'Benachrichtigung über eine Kontaktanfrage';
$mail->Body = $body;

$mail->send();

Der Vorteil einer SMTP-Bibliothek ist, dass sich Header-Absender und Envelope-Absender leicht getrennt steuern lassen. Für Kontaktformulare eignet sich das am besten für das Design, From: fest auf die Website-Domain zu setzen und nur das Antwortziel in Reply-To: einzutragen.

Konkrete Beispiele für SPF, DKIM und DMARC

Grundbeispiel für SPF

example.com. TXT "v=spf1 ip4:203.0.113.10 include:sendgrid.net -all"

SPF muss alle tatsächlich sendenden Quellen enthalten. Bei Nutzung eines Drittanbieters verlangt auch Google, zu prüfen, ob dieser Absender durch das eigene SPF und DKIM authentifiziert ist. Zudem ist SPF in der Anzahl der DNS-Abfragen begrenzt, weshalb bei zu vielen include-Einträgen Vorsicht geboten ist.

Grundbeispiel für DKIM

form2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

Selektoren dienen der Schlüsselrotation und erlauben es, mehrere öffentliche Schlüssel gleichzeitig auf derselben Domain zu betreiben. Im Betrieb ist ein Name, der nach Zweck oder Zeitraum unterscheidbar ist, im Nachhinein leichter lesbar als default.

Einführungsbeispiele für DMARC

Zunächst der Beobachtungsmodus.

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-afrf@example.com; adkim=r; aspf=r; fo=1"

Als Nächstes, wenn ein Teil unter Quarantäne gestellt werden soll.

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-agg@example.com; adkim=r; aspf=r"

Schließlich der strikte Betrieb.

_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-agg@example.com; adkim=s; aspf=s"

p=none bedeutet reine Beobachtung, quarantine empfiehlt Quarantäne, reject empfiehlt Ablehnung während der SMTP-Sitzung. adkim und aspf schalten zwischen strict und relaxed um. Statt sofort zu reject zu wechseln, ist es sicherer, zunächst mit none Volumen und legitime Absenderquellen zu beobachten und dann stufenweise hochzustufen.

Werden rua / ruf zusätzlich an einen externen Aggregationsdienst gesendet, verlangt RFC 7489 einen zusätzlichen DNS-Eintrag auf Seiten des Dritten. Sollen zum Beispiel die Reports für example.com an thirdparty.example.net gesendet werden, muss die Empfängerseite example.com._report._dmarc.thirdparty.example.net TXT "v=DMARC1" veröffentlichen.

7. Troubleshooting-Checkliste

Zum Abschluss eine Prüfreihenfolge, die sich in der Praxis direkt verwenden lässt. Bei nicht zugestellten Kontaktformular-E-Mails ist es am schnellsten, von oben nach unten abzuarbeiten.

Zuerst prüfen

• Ist From: die eigene Domain
• Steht die Nutzeradresse in Reply-To:
• Zeigt Authentication-Results spf=pass oder dkim=pass und zusätzlich dmarc=pass
• Bei dmarc=fail: Authentifizierungsfehler oder Alignment-Verletzung
• Ist SPF in einem Eintrag zusammengefasst
• Ist die Anzahl der SPF-Abfragen nicht zu hoch
• Lässt sich der DKIM-Public-Key auflösen
• Besitzt DMARC ein p=
• Sind PTR und Rückwärtsauflösung der sendenden IP plausibel
• Wird eine geteilte IP verwendet, und hat sich deren Reputation verschlechtert

Wo in Bounces und Protokollen nachzusehen ist

Kommen Bounce-Mails an, sind Final-Recipient, Status, Action und Diagnostic-Code innerhalb des DSN im Format message/delivery-status wichtig. RFC 3464 definiert diese maschinenlesbaren Informationen zu Zustellfehlern. Eine Zeile wie Diagnostic-Code: smtp; 550 relay not permitted bedeutet eine Ablehnung auf SMTP-Ebene, nicht auf Anwendungsebene.

Serverseitig sollte man sich zumindest die Zustellprotokolle der MTA ansehen. Bei Postfix zeigen sich Zustellerfolge und -fehler, Warteschlangenstau, Relay-Ablehnungen, DNS-Auflösungsfehler und Warnungen des DKIM-Milters. Bei Exim ist es ähnlich. Repräsentative Prüfbefehle:

# Beispiel: Postfix
journalctl -u postfix -n 200 --no-pager
postqueue -p

# Beispiel: Exim
exim -bp

Da sich Protokollpfade und Befehlsrechte je nach Hosting unterscheiden, sollte zuerst geklärt werden, ob man „die Protokolle der E-Mail-Zustellung“ und nicht nur „die Protokolle der App“ einsehen kann. In Umgebungen, in denen das nicht sichtbar ist, lässt sich die Ursache leichter analysieren, wenn man auf externes SMTP umstellt.

Wie man es sich in Gmail und Outlook ansieht

In Gmail über „Original anzeigen“, bei Microsoft Outlook über „Nachrichtendetails“ oder „Internetheader“ lassen sich die rohen Header einsehen. Bei der Untersuchung nicht zugestellter Kontaktformular-E-Mails ist es wirksamer, den vollständigen Header-Text zu speichern und zu vergleichen, statt Screenshots zu verwenden.

Empfängerseitige Fehler erkennen

Bei Gmail-Fehlern lässt sich die Ursache gut aus dem Code ablesen.

Auch in Googles FAQ sind diese Fehler und die zugehörigen Maßnahmen dokumentiert. Bei Kontaktformularen besonders häufig ist 4.7.32, die Alignment-Diskrepanz.

Das letzte Kriterium

Sind die folgenden drei Bedingungen gleichzeitig erfüllt, lässt sich das Design der Kontaktformular-Benachrichtigung als solide bezeichnen.

1. From: liegt unter example.com
2. Reply-To: ist die Adresse des Formularnutzers
3. Authentication-Results zeigt dmarc=pass

Sind diese drei Punkte erfüllt, ist das Design stimmig — unabhängig davon, ob SendGrid, SES, Mailgun, Shared Hosting oder eine SMTP-Bibliothek verwendet wird. Fehlt umgekehrt auch nur einer dieser Punkte, ist es der schnellste Weg, zuerst das From:-Design in Zweifel zu ziehen.

Referenzlinks

Primärquellen zu Spezifikationen und den einzelnen Diensten. Die tatsächlich in DNS einzutragenden Werte sollten immer aus den Angaben des jeweils genutzten Dienstes stammen.

Spezifikationen (RFC)

• RFC 5321 - Simple Mail Transfer Protocol ─ Umgang mit Envelope, MAIL FROM, Return-Path
• RFC 5322 - Internet Message Format ─ Bedeutung von From: Sender: Reply-To:
• RFC 7208 - Sender Policy Framework (SPF) ─ SPF-Spezifikation einschließlich der Obergrenze für DNS-Abfragen
• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures ─ Selektor, d=, signierte Elemente
• RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC) ─ Alignment, p=, externe Report-Ziele
• RFC 3464 - An Extensible Message Format for Delivery Status Notifications ─ Lesen von Bounces (DSN)

Richtlinien der Empfängerseite

• Richtlinien für E-Mail-Absender - Gmail-Hilfe ─ SPF / DKIM / DMARC, PTR, Übereinstimmungsanforderung für From:
• SMTP-Fehler und -Codes von Gmail - Hilfe für Google Workspace-Administratoren ─ Bedeutung und Maßnahmen zu 5.7.x / 4.7.x

Versanddienste und Implementierung

• How to Set Up Domain Authentication - SendGrid ─ CNAME-Verfahren, Custom Return Path
• Configuring a custom MAIL FROM domain - Amazon SES ─ Anforderungen an MX und SPF
• Easy DKIM in Amazon SES ─ die drei CNAMEs
• Domains - Mailgun Documentation ─ für die Verifizierung der Sendedomain nötige Einträge
• PHP: mail - Manual ─ Umgang mit Headern und additional_params (-f)
• swaks - Swiss Army Knife for SMTP ─ Test für den realen Versand

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist die häufigste Ursache dafür, dass E-Mails von Kontaktformularen nicht ankommen?

Nicht die SMTP-Verbindung selbst, sondern eine Unstimmigkeit zwischen dem sichtbaren Absender (`From:`) und dem tatsächlich authentifizierten Absender (SPFs `MAIL FROM` / DKIMs `d=`). Besonders häufig ist ein Design, das die Gmail-Adresse des Formularnutzers direkt in `From:` einträgt. Wird vom SMTP der Website aus mit `From: taro@gmail.com` gesendet, wird zwar die Website-Domain authentifiziert, `From:` zeigt aber auf Gmail — diese Diskrepanz führt zum Scheitern der DMARC-Alignment.

Wie sollte das From bei Benachrichtigungs-E-Mails von Kontaktformularen gesetzt werden?

Grundsätzlich sollte `From:` fest auf die eigene Website-Domain gesetzt und die Adresse des Formularnutzers in `Reply-To:` eingetragen werden. So bleibt das Antworten einfach, während sichtbarer und authentifizierter Absender auf derselben Domain liegen, was die Zustellrate stabilisiert. `Sender:` wird nur verwendet, wenn Verfasser und tatsächlich sendende Instanz voneinander abweichen, und `Return-Path` wird nicht als handgeschriebener Header, sondern als Envelope-Absender bei der MTA oder dem E-Mail-Dienst konfiguriert.

Womit sollte die Untersuchung einer nicht zugestellten E-Mail beginnen?

Bevor man in den Code schaut, sollte man sich die rohen Header der zugestellten E-Mail ansehen. Bei Gmail über „Original anzeigen“ prüft man Authentication-Results, Return-Path, From und DKIM-Signature. Oberste Priorität haben die Domain von From:, die Domain von Return-Path: sowie die Frage, ob spf / dkim / dmarc mit pass durchgehen. Bei dmarc=fail unterscheidet man, ob es sich um einen Authentifizierungsfehler oder eine Alignment-Verletzung handelt. Auf DNS-Seite prüft man mit dig oder nslookup die drei Einträge SPF, DKIM und DMARC.

Darf DMARC gleich auf reject gesetzt werden?

Es ist sicherer, nicht sofort auf reject zu gehen, sondern zunächst im Beobachtungsmodus p=none das Volumen und die legitimen Absenderquellen zu prüfen und erst danach stufenweise auf quarantine und reject hochzustufen. p=none bedeutet reine Beobachtung, quarantine empfiehlt Quarantäne, reject empfiehlt Ablehnung während der SMTP-Sitzung. Da Weiterleitung SPF leicht bricht und ein Umschreiben von Text oder Headern bei der Weiterleitung auch DKIM zerstören kann, ist es außerdem wichtig, sich nicht allein auf SPF zu verlassen, sondern DKIM stets zu aktivieren.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.