„Gesendet“ ist nicht zugestellt: Warum SPF allein Ihre Website-Mails nicht rettet

Eine Website kann beim Absenden eines Formulars ein grünes Häkchen zeigen und trotzdem keine funktionierende E-Mail-Zustellung haben.

Das ist kein Widerspruch. „Formular erfolgreich verarbeitet“ bedeutet zunächst nur, dass Ihre Anwendung den eigenen Teil des Vorgangs abgeschlossen hat. Danach beginnt eine zweite Kette: Ihr Mail-Provider muss die Nachricht annehmen, der empfangende Mailserver muss sie akzeptieren, die Authentifizierung muss plausibel sein, und die Nachricht muss schließlich im erwarteten Postfach landen.

Gerade bei Kontaktformularen, Passwort-Resets, Buchungsbestätigungen, Rechnungen oder Account-Einladungen ist diese Unterscheidung geschäftskritisch. Eine Website kann technisch „online“ sein und trotzdem Leads, Logins oder Transaktionen verlieren.

Der häufigste Denkfehler: „SPF ist grün, also passt E-Mail“

SPF ist wichtig, aber SPF beantwortet nur einen Teil der Frage.

SPF autorisiert Hosts dafür, eine Domain in der SMTP-Identität zu verwenden. Für DMARC ist dabei die Domain im MAIL FROM relevant – häufig sichtbar als Return-Path. Das ist nicht automatisch dieselbe Domain, die ein Mensch im sichtbaren From:-Header sieht.

Genau hier entsteht ein typisches Problem mit Drittanbietern:

• Sichtbares From:: rechnung@beispiel.de
• Return-Path: eine Domain des Versanddienstes
• SPF: besteht für die Provider-Domain
• DKIM: signiert ebenfalls mit einer nicht ausgerichteten Provider-Domain

Technisch kann SPF also pass melden, während DMARC trotzdem scheitert. RFC 9989 macht diesen Punkt ausdrücklich: Für DMARC reicht ein authentifizierter Identifier nicht allein; er muss zur Domain im sichtbaren Absender ausgerichtet sein. Das nennt sich Alignment.

Ein grünes SPF-Ergebnis ist deshalb kein Zustellbeweis und auch kein DMARC-Beweis.

Was DKIM und DMARC zusätzlich leisten

DKIM versieht eine Nachricht mit einer kryptografischen Signatur. Die Signatur enthält unter anderem eine Signing-Domain im d=-Tag. Der Empfänger kann den öffentlichen Schlüssel über DNS abrufen und prüfen, ob die signierten Teile der Nachricht unverändert sind.

Für DMARC kann diese DKIM-Domain als authentifizierte Identität dienen – aber wiederum nur dann, wenn sie zum sichtbaren From: ausgerichtet ist.

DMARC verbindet damit zwei Dinge, die Website-Teams oft getrennt betrachten:

1. Welche Domain sieht der Empfänger als Absender?
2. Welche Domain wurde über SPF oder DKIM tatsächlich authentifiziert?

Google und Yahoo verlangen für große Absender bereits SPF, DKIM und DMARC und fordern Alignment zur sichtbaren From-Domain. Google empfiehlt die drei Mechanismen ausdrücklich auch allgemeiner für eine bessere Zustellbarkeit. Für kleine Unternehmen ist die sinnvolle Schlussfolgerung nicht „Die 5.000-Mails-Grenze betrifft uns nicht“, sondern: Die eigene Website sollte dieselben sauberen Identitäten verwenden, bevor Wachstum oder ein Providerwechsel die Schwachstellen sichtbar macht.

Der Kontaktformular-Anti-Pattern: Besucher als Absender

Eine überraschend häufige Implementierung sieht so aus:

Ein Besucher trägt person@gmail.com in das Kontaktformular ein. Die Website verschickt anschließend eine Nachricht mit From: person@gmail.com, damit die Antwort bequem an diese Adresse geht.

Das wirkt praktisch – ist aber technisch falsch modelliert. Ihre Website ist nicht Gmail und ist nicht autorisiert, im Namen der Domain des Besuchers zu senden.

Besser ist:

• From: verwendet eine Domain, die Sie kontrollieren, zum Beispiel website@beispiel.de.
• Die eingegebene Adresse des Besuchers landet in Reply-To:.
• Ihr Versanddienst authentifiziert Ihre eigene Domain korrekt per DKIM und/oder ausgerichtetem SPF.
• Eingaben werden weiterhin validiert und niemals ungeprüft in Mail-Header übernommen.

So bleibt der sichtbare Absender unter Ihrer Kontrolle und Antworten können trotzdem direkt an den Interessenten gehen.

Ein brauchbarer E-Mail-Audit beginnt nicht im DNS

Der erste Schritt ist eine Bestandsaufnahme aller Systeme, die im Namen Ihrer Domain senden.

Typische Kandidaten sind:

• Kontakt- und Anfrageformulare
• WordPress oder andere CMS
• Passwort-Reset und Login-Codes
• Rechnungen und Bestellbestätigungen
• Newsletter-Tools
• CRM- und Support-Systeme
• Terminbuchung
• Monitoring- und Systemalarme
• Staging- oder Testumgebungen
• manuelle Mailboxen wie Google Workspace oder Microsoft 365

Der klassische Fehler ist ein SPF-Eintrag, der vor drei Jahren für „den Mailanbieter“ eingerichtet wurde, während inzwischen fünf weitere Systeme senden.

Ein Audit fragt deshalb nicht nur: Gibt es SPF? Sondern: Welche realen Nachrichten entstehen heute – und welche Domain authentifiziert jede einzelne davon?

Prüfen Sie echte Header, nicht nur DNS-Checker

DNS-Checker sind hilfreich, aber sie sehen keine konkrete Nachricht.

Für eine realistische Prüfung senden Sie Testnachrichten aus jedem relevanten Versandweg an kontrollierte Postfächer und analysieren anschließend die empfangenen Header. Besonders wichtig sind:

• sichtbares From:
• Return-Path
• DKIM-d= und Selector
• Authentication-Results
• SPF-Ergebnis
• DKIM-Ergebnis
• DMARC-Ergebnis
• die Domain, gegen die jeweils geprüft wurde

Die Kernfrage lautet nicht einfach „steht überall pass?“, sondern:

Passt mindestens eine erfolgreich authentifizierte SPF- oder DKIM-Domain zur sichtbaren From-Domain im Sinne von DMARC?

Das ist der Unterschied zwischen „irgendetwas wurde authentifiziert“ und „diese sichtbare Absenderidentität wurde plausibel autorisiert“.

SPF: Die unscheinbaren roten Flaggen

Bei SPF finden wir regelmäßig Wartungsschulden, die lange unbemerkt bleiben:

Mehrere Systeme, aber unvollständige Autorisierung

Ein neues CRM oder Transaktionsmail-System wird angebunden, der DNS-Eintrag aber nicht angepasst. Einige Mails bestehen SPF, andere nicht.

Alte Anbieter bleiben für immer autorisiert

Entfernte Newsletter- oder Hostinganbieter stehen weiterhin in der SPF-Kette. Das ist mindestens unnötige Angriffs- und Betriebsfläche und erschwert die Frage, wer eigentlich senden darf.

Komplexe Include-Ketten

SPF hat Verarbeitungslimits für DNS-basierte Mechanismen. Mit jeder neuen Plattform kann ein scheinbar harmloses include: die Kette komplizierter machen. Ein Audit sollte deshalb nicht nur die sichtbare TXT-Zeile lesen, sondern die effektive Auswertung prüfen.

Die falsche Domain wird bewertet

Ein SPF-Pass auf der Provider-Return-Path-Domain klingt gut, hilft für DMARC aber nur, wenn diese Identität entsprechend ausgerichtet ist.

DKIM: Ist die Signatur wirklich Ihre?

Bei externen Versanddiensten lohnt sich ein Blick auf d=.

Wenn dort ausschließlich eine Domain des Providers steht, kann DKIM technisch gültig sein, ohne Ihre sichtbare Absenderdomain für DMARC zu legitimieren.

Sauber konfigurierte Dienste erlauben in der Regel eine authentifizierte Versanddomain mit eigenen DNS-Einträgen. Danach sollte eine reale Testmail zeigen, dass:

• die DKIM-Signatur valide ist,
• die erwartete Domain im d= verwendet wird,
• der Selector im DNS erreichbar ist,
• und die DKIM-Domain mit der sichtbaren From-Domain ausreichend ausgerichtet ist.

Nach DNS-Umzügen, Providerwechseln und Website-Migrationen sind kaputte oder vergessene DKIM-Selector besonders dankbare Fehler: Die Anwendung sendet weiter, aber die Authentifizierung ist plötzlich schwächer.

DMARC: Monitoring ist kein Häkchen zum Abhaken

Ein DMARC-Eintrag kann mit p=none zunächst beobachten, ohne Empfängern eine Quarantäne- oder Reject-Policy für fehlschlagende Nachrichten vorzugeben. RFC 9989 beschreibt Aggregate Reports ausdrücklich als Mittel, um Versandströme und Authentifizierung zu beobachten.

Das ist wertvoll – aber nur, wenn jemand die Reports auch auswertet.

Ein vernünftiger Ablauf ist:

1. alle legitimen Absender inventarisieren,
2. SPF und DKIM sauber konfigurieren,
3. DMARC mit Reporting beobachten,
4. unbekannte oder fehlerhafte Versandquellen bereinigen,
5. erst danach bewusst über strengere Policies entscheiden.

Blind p=reject einzuschalten, während Rechnungen, Passwort-Resets oder ein altes CRM noch falsch ausgerichtet senden, ist keine Härtung. Es ist ein selbst gebauter Zustellungsausfall.

„SMTP accepted“ ist noch immer nicht „im Posteingang“

Auch mit perfekter Authentifizierung bleibt Zustellung ein Betriebsprozess.

Mailbox-Provider können Nachrichten temporär zurückstellen, permanent ablehnen oder akzeptierte Nachrichten in Spam einsortieren. Yahoo dokumentiert beispielsweise 4xx-Fehler als temporäre Probleme, bei denen später erneut versucht werden kann, während 5xx-Fehler permanente Ablehnungen kennzeichnen.

Für Website-Systeme bedeutet das:

• temporäre Fehler brauchen kontrollierte Retries,
• permanente Bounces sollten nicht endlos erneut versendet werden,
• Authentifizierungs- und Reputation-Fehler müssen sichtbar werden,
• Provider-Webhooks oder Logs sollten nicht im Nirwana enden,
• und kritische Transaktionsmails brauchen Monitoring.

Ein Passwort-Reset, der dreimal hart gebounced ist, darf nicht weiterhin als „E-Mail gesendet“ behandelt werden.

Sieben Checks, die wir bei Website-Mails sehen wollen

1. Versand-Inventar

Jede Anwendung und jeder Dienst, der Ihre Domains im From: verwendet, ist dokumentiert.

2. Reale End-to-End-Tests

Nicht nur der API-Call ist erfolgreich. Eine Testnachricht kommt bei mindestens mehreren großen Empfängern an und die Header werden geprüft.

3. SPF stimmt mit der tatsächlichen Infrastruktur überein

Aktive Sender sind autorisiert, entfernte Dienste sind nicht unnötig enthalten, und die Auswertung läuft nicht in Limits oder Fehler.

4. DKIM signiert mit einer erwarteten, ausgerichteten Domain

Wir prüfen d=, Selector und Validierung an einer echten Nachricht.

5. DMARC besteht für den sichtbaren Absender

Mindestens SPF oder DKIM besteht und die authentifizierte Domain ist zur From-Domain ausgerichtet.

6. Bounces und Providerfehler werden verarbeitet

Temporär und permanent werden unterschieden. Zustellfehler sind beobachtbar und landen nicht nur in einem Provider-Dashboard, das niemand öffnet.

7. Formulare verwenden eine kontrollierte From-Adresse

Benutzeradressen gehören in Reply-To, nicht als vorgetäuschter Absender in From:.

Was Website-Pflichtencheck dabei prüft

Bei einem technischen Website-Check betrachten wir E-Mail nicht als isolierten DNS-Task. Wir verfolgen den tatsächlichen Weg einer Nachricht von der Website bis zum Empfang:

• Welche Funktion löst sie aus?
• Welcher Dienst verschickt sie?
• Welche Domain steht sichtbar im Absender?
• Welche Domain wird per SPF und DKIM authentifiziert?
• Besteht DMARC-Alignment?
• Was passiert bei Bounce, Timeout oder Providerfehler?
• Meldet die Oberfläche Erfolg, obwohl die Zustellung noch unbekannt ist?
• Gibt es Monitoring für geschäftskritische Mail-Flows?

Das Ziel ist keine theoretisch „perfekte“ DNS-Zone. Das Ziel ist ein Versandweg, dessen Fehler sichtbar sind und dessen Identitäten nachvollziehbar zusammenpassen.

Wenn Ihre Website Leads, Buchungen, Logins oder Bestellungen per E-Mail weiterführt, lohnt sich dieser Check besonders nach einem Relaunch, Hostingwechsel, Domainumzug oder Wechsel des Mailproviders.

Website-Pflichtencheck kann den kompletten Versandpfad technisch prüfen – vom Formular über DNS und Provider bis zu den empfangenen Authentifizierungs-Headern.