Wissen / Hosting und E-Mail

Website-E-Mails kommen nicht an: Zustellung prüfen

Kurz gesagt: Wenn Website-E-Mails fehlen, prüfen Sie zuerst, an welcher Stelle der Versandweg endet: Formular, Anwendung, Mailserver oder Zielpostfach. Eine Erfolgsmeldung allein belegt keine Zustellung. Vergleichen Sie kontrollierte Testnachrichten, dokumentieren Sie Zeitpunkt und Fehlermeldung und lassen Sie Absenderkonfiguration sowie Authentisierung prüfen. Nach Hosting- oder Domainänderungen gehört der vollständige Weg erneut getestet.

Veröffentlicht am / Aktualisiert am / Redaktion: Ruhrstack / 11 Minuten Lesezeit

01 / VERSANDWEG

Zuerst feststellen, welche Nachricht fehlt.

Ein Formularhinweis, eine Benachrichtigung und eine Antwort können unterschiedliche Wege nehmen.

„Das Kontaktformular funktioniert, aber wir erhalten keine E-Mail“ ist ein guter Ausgangspunkt, noch keine technische Diagnose. Fragen Sie zuerst, was genau fehlt: die Nachricht an das Unternehmen, eine automatische Bestätigung an den Besucher oder die spätere persönliche Antwort. Diese Vorgänge können verschiedene Absender, Empfänger und Versanddienste verwenden. Ein funktionierender Teil sagt deshalb wenig über die anderen aus.

Skizzieren Sie den tatsächlichen Weg in vier Stationen: öffentliche Formularseite, verarbeitende Anwendung, eingesetzter Maildienst und empfangendes Postfach. Bei einer externen Formularlösung liegt die Verarbeitung möglicherweise außerhalb des Webhostings. Bei einer eigenen Anwendung kann der Versand direkt vom Server oder über einen getrennten Dienst erfolgen. Klären Sie den vorhandenen Aufbau mit der technischen Betreuung, bevor Sie einen Anbieterwechsel oder eine neue Erweiterung beauftragen.

SMTP nach RFC 5321 unterscheidet Annahme und weitere Verarbeitung: Eine positive Antwort nach vollständiger Nachrichtenübertragung übernimmt Verantwortung für Zustellung oder Weitergabe. Sie beweist keinen sichtbaren Posteingang. Spätere Fehlermeldungen können an den technischen Rückweg gehen; eine ausbleibende Fehlermeldung ist ebenfalls kein Zustellnachweis.

Halten Sie für die Untersuchung die sichtbare Meldung im Browser fest, ohne sie voreilig als Ergebnis des Mailservers zu lesen. Ob die Anwendung eine Nachricht gespeichert, den Versand nur angestoßen oder eine konkrete Rückmeldung ausgewertet hat, muss sich aus ihrer Umsetzung ergeben. Die Gestaltung der Oberfläche behandelt ergänzend unser Beitrag zu verständlichen Kontaktformularen. Hier geht es um die Strecke nach dem Absenden.

02 / ERSTE DIAGNOSE

Mit kleinen Vergleichstests die betroffene Strecke finden.

Ändern Sie zunächst keine Einstellungen, sondern sammeln Sie nachvollziehbare Beobachtungen.

Verwenden Sie eine ausdrücklich als Test gekennzeichnete Nachricht mit einem eindeutigen Kürzel. Vereinbaren Sie vorher ein kontrolliertes Empfängerpostfach und prüfen Sie auch Spamordner oder eine vorhandene Quarantäne. Notieren Sie, welche Ordner tatsächlich untersucht wurden. „Nicht gesehen“ und „vom empfangenden System abgelehnt“ sind unterschiedliche Befunde.

Eigene Diagnosehilfe: Was lässt sich als Nächstes prüfen?
BeobachtungNächste PrüfungNoch kein Beweis für
Schon der Browser meldet einen FehlerFormularaufruf und Verarbeitung der Testanfrage untersuchen lassenEine Ablehnung durch das Empfängerpostfach
Erfolgsmeldung, aber kein bekannter VersandnachweisDie Testanfrage in Anwendung und Versandprotokoll zuordnenEine bereits erfolgte Übergabe an einen Maildienst
Ein Zielpostfach erhält die Nachricht, ein anderes nichtDie beiden Empfangswege und vorhandene Fehlermeldungen vergleichenEine generell defekte Website
Nachricht liegt im SpamordnerDen konkreten Nachrichtenstand und die Empfangseinstufung dokumentierenEine unterbliebene technische Übertragung
Unternehmensnachricht kommt an, Besucherbestätigung fehltDen gesonderten Bestätigungsversand prüfenDass beide Nachrichten dieselbe Ursache haben

Vergleichen Sie bei Bedarf mit einer normalen E-Mail aus dem betrieblichen Mailprogramm. Kommt diese an, ist damit der Website-Versand nicht geprüft. Der Vergleich hilft nur, die betroffene Strecke genauer zu beschreiben. Dasselbe gilt für einen Test in einer Erweiterungsverwaltung: Er kann einen anderen Weg benutzen als die öffentliche Formularseite.

Verändern Sie pro Diagnoseversuch nur einen vereinbarten Punkt. Werden gleichzeitig Empfänger, Absender, Versanddienst und DNS angepasst, ist ein erfolgreiches Ergebnis schwer zu erklären. Bewahren Sie den vorherigen Stand und die Beobachtungen auf, damit eine fachlich begründete Korrektur von einem Zufallstreffer unterschieden werden kann.

03 / ABSENDERROLLEN

Absender, Antwortadresse und Empfänger getrennt betrachten.

Eine Besucheradresse muss nicht als technischer Absender der Website-Nachricht eingesetzt werden.

Im sichtbaren Postfach steht häufig nur ein Anzeigename. Für die Untersuchung reicht dieser nicht. Lassen Sie notieren, welche Adresse die Website als Absender verwendet, wohin Antworten gehen sollen und welches Postfach die Unternehmensnachricht tatsächlich empfängt. Dazu kommt der technische Rückweg für Zustellprobleme. Diese Angaben gehören nicht in ein einziges Feld mit der Bezeichnung „E-Mail“.

Der Nachrichtenstandard RFC 5322 beschreibt From als Angabe zur verantwortlichen Person oder zum verantwortlichen System. Reply-To kann einen anderen gewünschten Antwortweg benennen. Beide Felder erfüllen verschiedene Aufgaben. Ein frei gewählter Anzeigename bestätigt weder die Adresse noch ihre Verwendung durch den Versanddienst.

Eine praktikable Gestaltung für ein Kontaktformular kann eine vom Unternehmen kontrollierte Versandadresse und die geprüfte Besucheradresse als Antwortziel sein. Ob das im vorhandenen System korrekt umgesetzt ist, wird an einer echten Testnachricht geprüft. Lassen Sie nicht nur ein Einstellungsfenster zeigen, sondern kontrollieren Sie auch, welche Angaben die empfangene Nachricht enthält und wohin eine Antwort tatsächlich gerichtet wird.

Verwenden Sie beispielsweise zwei kontrollierte Testadressen für zwei Durchläufe und prüfen Sie jeweils die Antwortfunktion. So fällt auf, wenn eine feste Antwortadresse versehentlich alle Antworten an das Unternehmen zurückführt. Umgekehrt darf eine beliebige Besuchereingabe nicht ungeprüft technische Nachrichtenfelder verändern. Die konkrete sichere Verarbeitung bleibt Aufgabe der Anwendung; dieser Artikel liefert dafür keinen kopierbaren Versandcode.

04 / AUTHENTISIERUNG

SPF, DKIM und DMARC beantworten verschiedene Fragen.

Die Prüfung muss zu den tatsächlich eingesetzten Versanddiensten passen.

SPF nach RFC 7208 beschreibt, welche sendenden Systeme eine Domain für bestimmte SMTP-Absenderrollen verwenden dürfen. Die Prüfung betrifft insbesondere den technischen MAIL FROM, nicht automatisch die sichtbare From-Adresse. Ein vorhandener SPF-Eintrag allein bestätigt daher nicht jede angezeigte Absenderadresse.

DKIM nach RFC 6376 verbindet eine Nachricht durch eine prüfbare Signatur mit einer signierenden Domain. Diese Domain kann zu einem verantwortlichen Versanddienst gehören. Eine gültige Signatur ist keine Bestätigung, dass eine bestimmte natürliche Person die Nachricht verfasst hat.

DMARC nach RFC 9989 verlangt für ein positives Ergebnis eine erfolgreich authentisierte SPF- oder DKIM-Domain, die zur Domain im sichtbaren From passt. Dieses Verhältnis heißt Alignment. RFC 9989 wurde im Mai 2026 veröffentlicht und ersetzt die ältere Grundlage RFC 7489. Authentisierung ist keine Zusage einer Platzierung im Posteingang.

Für Unternehmen ist der wichtigste Arbeitsauftrag deshalb eine vollständige Liste der legitimen Versandwege. Dazu können Website-Formular, betriebliches Mailprogramm und weitere beauftragte Systeme gehören. Bitten Sie die Betreuung, diese Wege einzeln zu prüfen, statt einen Eintrag aus einer Anleitung pauschal zu übernehmen. Eine funktionierende Testnachricht des Mailprogramms deckt die Website weiterhin nicht ab.

Beauftragen Sie eine Verschärfung von Absenderregeln nicht ohne Prüfung der benötigten Nachrichtenwege. Dokumentieren Sie, was geändert wird, wer anschließend die relevanten Testnachrichten bewertet und wie ein unerwarteter Fehler behandelt wird. Die Begriffe im DNS und die Zuständigkeiten für die Einstellungen erklärt der Grundlagenartikel zu Domain, DNS, Hosting und TLS. Hier zählt die Überprüfung der konkreten Nachricht.

05 / EMPFÄNGERREGELN

Gmail-Anforderungen nach dem Senderumfang einordnen.

Vorgaben eines Empfangsdienstes ersetzen keine Untersuchung Ihres gesamten Versandwegs.

Die Gmail-Richtlinie für E-Mail-Absender betrifft private Gmail-Konten. Für alle Absender verlangt Google SPF oder DKIM. Für die dort beschriebenen Massensender mit mehr als 5.000 Nachrichten pro Tag an private Gmail-Konten gelten SPF und DKIM sowie DMARC. Google empfiehlt alle drei Verfahren auch allgemein. Mindestanforderung und Empfehlung sind zu unterscheiden.

Für eine kleine Firmenwebsite wäre es falsch, allein wegen eines selten versendeten Formulars sämtliche Regeln für einen großen Newsletterversand als identische Pflicht darzustellen. Ebenso wenig sollte ein Unternehmen annehmen, sein geringer Umfang mache eine Prüfung des Versandwegs unnötig. Klären Sie zuerst, welche anderen Systeme unter der betroffenen Domain senden und welche Empfangsdienste tatsächlich Probleme melden.

Eine einzelne Gmail-Testadresse ist ein brauchbarer Vergleichspunkt, aber keine vollständige Abnahme. Prüfen Sie außerdem den tatsächlich vorgesehenen Unternehmensweg. Erhält dieser Nachrichten über eine Weiterleitung, untersuchen Sie den unmittelbaren Eingang und den weitergeleiteten Eingang getrennt. Andere Empfangsdienste können eigene aktuelle Vorgaben verwenden; eine bestandene Prüfung bei einem Anbieter ist kein allgemeines Gütesiegel.

06 / NACH ÄNDERUNGEN

Nach Hosting- und Domainänderungen den Versand erneut zuordnen.

Eine erreichbare Website und ein funktionierendes Mailprogramm reichen als Nachweis nicht aus.

Bei einem Website-Umzug kann der öffentliche Seitenaufruf bereits funktionieren, während der Formularversand noch ungeklärt ist. Erstellen Sie deshalb vor der Änderung eine kurze Vergleichsliste: Welche öffentliche Formularseite wird benutzt? Welche Anwendung verarbeitet sie? Welcher Dienst versendet? Welche Absender- und Empfängeradressen sind vereinbart? Wer kann den jeweiligen Schritt kontrollieren? Halten Sie keine Passwörter in dieser Liste fest.

Wiederholen Sie dieselben abgestimmten Testfälle nach dem Wechsel. Nutzen Sie das tatsächlich ausgelieferte Formular und vermeiden Sie es, aus einer funktionierenden Vorschau auf die endgültige Konfiguration zu schließen. Notieren Sie, ob sich Hosting, Versanddienst, Domainname, Empfänger oder eine Weiterleitung geändert haben. Diese Trennung hilft auch, wenn Website und Postfächer bei verschiedenen Anbietern liegen.

Bei einer neuen Domain muss nicht nur die sichtbare Absenderbezeichnung angepasst werden. Lassen Sie die technische Betreuung die gesamte Zuordnung des Website-Versands zum neuen Stand kontrollieren. Eine Mischung aus alten Formularangaben und neuen Konten ist ein eigener Prüfpunkt. Stellen Sie dabei auch die Frage, wo mögliche Fehlermeldungen ankommen und wer sie nach dem Wechsel auswertet.

Vereinbaren Sie einen klaren Abschlussnachweis: Die Testanfrage wurde über die öffentliche Seite angenommen, ihr weiterer Weg wurde soweit technisch verfügbar nachvollzogen und der vorgesehene Empfänger hat die Nachricht erkannt. Wenn ein Teil nicht einsehbar ist, gehört diese Grenze in das Ergebnis. Ein grünes Symbol im Hostingportal ersetzt diesen Nachweis nicht. Allgemeine Kontrollaufgaben nach Veröffentlichung ordnet Website-Betrieb nach dem Launch ein.

07 / DIAGNOSEVORLAGE

Mit diesen Angaben wird eine Störungsmeldung bearbeitbar.

Die Vorlage verbindet eine Beobachtung mit einem konkreten nächsten Prüfauftrag.

Die folgende Liste ist eine eigene redaktionelle Arbeitshilfe. Sie ist bewusst kein Protokollexport und kein vollständiges technisches Inventar. Füllen Sie zunächst die Angaben aus, die Sie ohne Administrationszugang verlässlich beobachten können. Eine fachliche Betreuung ergänzt anschließend die verfügbaren Nachweise aus Anwendung und Versanddienst.

  1. Betroffener Vorgang: Öffentliche Formular-URL, Unternehmensnachricht oder Besucherbestätigung; bei mehreren Formularen das konkrete Formular nennen.
  2. Zeit und Kennzeichen: Testzeitpunkt mit Zeitzone, eindeutiges Testkürzel und die tatsächlich angezeigte Meldung festhalten.
  3. Erwarteter Weg: Kontrollierte Absender- und Empfängeradresse, bekannte Weiterleitung und gewünschtes Antwortziel benennen.
  4. Beobachteter Eingang: Posteingang, Spamordner oder Quarantäne geprüft? Nachricht gefunden? Welche Adresse wurde tatsächlich kontrolliert?
  5. Vergleich: Funktioniert eine andere kontrollierte Empfängeradresse oder nur eine normale Mail aus dem Mailprogramm? Beide Tests getrennt dokumentieren.
  6. Technischer Befund: Soweit vorhanden Nachrichtenkennung, Versandzeitpunkt und gekürzte Fehlermeldung durch die zuständige Betreuung ergänzen lassen.
  7. Letzte Änderung: Zeitpunkt und Art einer Änderung an Formular, Hosting, Domain, Versanddienst oder Empfänger notieren.
  8. Nächster Schritt: Verantwortliche Rolle, zu prüfende Station und vereinbarten Rückmeldeweg festhalten; offene Grenzen ausdrücklich nennen.

Eine hilfreiche Kurzmeldung lautet beispielsweise: „Kontaktseite, Test A17 am 8. Oktober um 10:20 Uhr deutscher Ortszeit; im Browser angenommen, im vorgesehenen Postfach und Spamordner nicht gefunden; seit dem Hostingwechsel betroffen; normale Mail separat erfolgreich.“ Damit sind Beobachtungen beschrieben. Die Ursache bleibt bis zur technischen Untersuchung offen.

Übermitteln Sie keine echten Kundennachrichten oder Zugangsdaten mit einer allgemeinen Störungsmeldung. Vollständige Nachrichtenheader und Protokolle können interne Angaben und personenbezogene Daten enthalten. Falls diese für die Diagnose erforderlich sind, stimmen Sie Empfänger, Umfang und Übermittlungsweg konkret ab. Für einen ersten Kontakt genügen die Website-Adresse und eine knappe Beschreibung der Störung.

08 / AUSWERTUNG

Ein erfolgreicher Test muss zur ursprünglichen Störung passen.

Eine nachvollziehbare Korrektur endet mit dem geprüften Nachrichtenweg und verbleibenden Grenzen.

Ein fiktiver Handwerksbetrieb zieht seine Website zu einem anderen Hostinganbieter um. Die Seite ist erreichbar, das Formular zeigt einen Erfolgshinweis, aber die Büronachricht fehlt. Eine Beschäftigte kann aus ihrem Mailprogramm weiterhin Nachrichten senden. Das Team dokumentiert diese Beobachtungen getrennt und lässt zunächst prüfen, ob die Anwendung den vorgesehenen Versanddienst überhaupt verwendet.

In diesem erfundenen Beispiel findet die technische Betreuung eine unpassende Versandkonfiguration. Nach deren Korrektur wird dieselbe öffentliche Formularseite erneut mit einer markierten Testanfrage benutzt. Der vorgesehene Empfänger kontrolliert den Eingang und das Antwortziel. Zusätzlich wird die Besucherbestätigung gesondert getestet. Das ist ein beschriebenes Prüfverfahren, keine dokumentierte Kundenarbeit und kein gemessenes Ergebnis von Ruhrstack.

Der Nutzen professioneller Unterstützung liegt hier in der Zuordnung der Systeme und Nachweise. Ein Webteam kann die Anwendung untersuchen; der Mailanbieter hat möglicherweise andere Einblicke in Übertragung und Empfang. Gute Zusammenarbeit benennt, welcher Befund vorliegt und welche Stelle den nächsten Schritt übernimmt. Ein neu installiertes Formularmodul hilft nur, wenn es das tatsächlich festgestellte Problem löst.

Vermerken Sie zum Abschluss die korrigierte Einstellung, den geprüften Stand und die erreichten Empfänger. Verallgemeinern Sie ein positives Einzelergebnis nicht zu „jede Nachricht kommt künftig garantiert an“. Die Tests geben Auskunft über den geprüften Weg zum geprüften Zeitpunkt. Wenn für eine Beobachtung weiterhin ein Nachweis fehlt, bleibt sie offen. Umfang, Zugriffe und Zusammenarbeit mit bestehenden Anbietern gehören bei einer Beauftragung ausdrücklich vereinbart.

09 / QUELLEN

Quellen und redaktioneller Stand.

Die Quellen wurden am 8. Oktober 2026 geprüft. Diagnosehilfe, Vorlage und fiktives Beispiel sind eigene redaktionelle Arbeitshilfen. Die technischen Standards beschreiben Grundlagen; konkrete Providerregeln und Einstellungen bleiben gesondert zu prüfen.

  1. IETF: RFC 5321, SMTP und Verantwortung nach der Nachrichtenannahme, abgerufen am 8. Oktober 2026.
  2. IETF: RFC 5322, Nachrichtenformat sowie From und Reply-To, abgerufen am 8. Oktober 2026.
  3. IETF: RFC 7208, Sender Policy Framework (SPF), abgerufen am 8. Oktober 2026.
  4. IETF: RFC 6376, DomainKeys Identified Mail (DKIM), abgerufen am 8. Oktober 2026.
  5. IETF: RFC 9989, aktuelle DMARC-Grundlage seit Mai 2026, abgerufen am 8. Oktober 2026.
  6. Google: Richtlinien für E-Mail-Absender an private Gmail-Konten, abgerufen am 8. Oktober 2026.

Redaktioneller Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Einzelfallprüfung. Trotz sorgfältiger Recherche wird keine Gewähr für Vollständigkeit und fortdauernde Aktualität übernommen. Eine Haftung nach zwingenden gesetzlichen Vorschriften bleibt unberührt. Redaktionelle Einordnung.

Fehlen Nachrichten von Ihrer Website?

Nennen Sie uns Ihre Website-Adresse und beschreiben Sie, welche Nachricht seit wann fehlt. Wir besprechen den betroffenen Versandweg und einen passenden Prüfungsumfang.

Website-Versand besprechen