Ihre Kundschaft meldet, dass Bestell- oder Versandmails fehlen oder im Spam liegen.
Schnellste Lösung: Prüfen Sie zuerst im Protokoll Ihres E-Mail-Dienstes, ob die Nachricht tatsächlich versendet wurde. Erst bei einem belegten Versand untersuchen Sie die für diesen Dienst eingerichteten SPF- und DKIM-Daten, den Abgleich mit der From-Domain und anschließend die DMARC-Richtlinie. Ein erfolgreicher Authentifizierungstest garantiert keinen Posteingang.
Geeignet ist diese Anleitung für Shopbetreiber, die fehlende Bestellbestätigungen oder Versandbenachrichtigungen einordnen müssen.
Sie richtet sich auch an technische Verantwortliche, die einen Drittanbieter für den E-Mail-Versand eingerichtet oder DNS-Daten geändert haben.
Wenn Sie mehrere Geschäftsdomainnamen betreuen, prüfen Sie jeden Absender und jede Versandquelle getrennt, statt den Fehler pauschal dem Server zuzuschreiben.
Zuletzt aktualisiert am 05.11.2026; geprüft anhand der Gmail-Absenderanforderungen, des RFC 9989 und der WooCommerce-E-Mail-Dokumentation.
Erst Versand belegen, dann DNS ändern
Was ist zu prüfen, wenn Shop-Bestellmails im Spam landen? Beginnen Sie nicht mit einer Änderung am SPF-Eintrag. Suchen Sie zuerst einen konkreten Auftrag im Shop, prüfen Sie, ob der passende Benachrichtigungstyp aktiviert ist, und gleichen Sie anschließend den Zeitpunkt mit dem Versandprotokoll Ihres E-Mail-Dienstes ab. WooCommerce unterscheidet in seiner Fehlerhilfe für E-Mails unter anderem zwischen dem Auslösen einer Nachricht, dem Versand über die Hostingumgebung und der Annahme oder Filterung durch den empfangenden Dienst.
Das ist wichtig, weil „nicht angekommen“ mehrere unterschiedliche Fehlerlagen beschreibt. Fehlt der Eintrag bereits in den Anwendungs- oder Versandprotokollen, kann die Nachricht gar nicht erzeugt oder an den Dienst übergeben worden sein. Ist der Versand protokolliert, aber die Nachricht wird abgewiesen oder in den Spamordner verschoben, kommen Transport, Authentifizierung, Richtlinien und Nachrichteninhalt ins Spiel.
| Beobachtung | Was sie belegt | Nächster Prüfschritt |
|---|---|---|
| Kein Eintrag zur Nachricht im Shop- oder Versandprotokoll | Ein Versand ist bislang nicht nachgewiesen | Bestellstatus, Benachrichtigung und Übergabe an den E-Mail-Dienst prüfen |
| Versanddienst protokolliert eine Übergabe | Die Anwendung hat die Nachricht zumindest an den Dienst übergeben | Zustellstatus, Antwort des Empfängers und Ereignisprotokoll untersuchen |
| Empfänger meldet Spam oder Quarantäne | Die Nachricht kann angekommen sein, wurde aber gefiltert | Nachrichtenkopf, Authentifizierung und Richtlinien prüfen |
| SPF oder DKIM schlägt im Nachrichtenkopf fehl | Mindestens ein Authentifizierungspfad passt nicht zur tatsächlichen Konfiguration | DNS und Versanddienst anhand ihrer jeweiligen Vorgaben abgleichen |
Die Bestellung ist abgeschlossen, aber die Nachricht fehlt. Wie grenzen Sie das ein? Notieren Sie Bestellkennung, Zeitpunkt und erwarteten Nachrichtentyp. Kontrollieren Sie im Shop, ob die Benachrichtigung für diesen Status aktiviert ist. Vergleichen Sie diese Angaben mit dem Protokoll des Drittanbieters. Ohne Eintrag beim Versanddienst ist ein SPF-Fehler noch keine belegte Ursache.
SPF und DKIM getrennt nachweisen
Muss SPF und DKIM auch bei einem Drittanbieter für den E-Mail-Versand eingerichtet sein? Prüfen Sie die Anleitung des tatsächlich verwendeten Dienstes. Ob und welche DNS-Einträge erforderlich sind, hängt von dessen Versandverfahren und der Absenderdomain ab. Die WooCommerce-Dokumentation zu E-Mail-Dienstleistern beschreibt die Einbindung externer Versanddienste; die konkreten Einträge müssen Sie jedoch aus der Konfiguration Ihres eigenen Dienstes übernehmen. Kopieren Sie weder fremde include-Werte noch einen DKIM-Schlüssel aus einem Beispiel.
SPF autorisiert Versandquellen für eine Domain. Mehrere SPF-TXT-Einträge für dieselbe Domain sind kein Ersatz für eine abgestimmte Richtlinie: Erfassen Sie zuerst sämtliche weiterhin genutzten Versandquellen und prüfen Sie die veröffentlichte Konfiguration. Der RFC 7208 für SPF begrenzt die Zahl bestimmter DNS-Abfragen, die eine SPF-Auswertung auslösen darf, auf zehn. Werden durch verschachtelte Einbindungen mehr Abfragen notwendig, kann das die Prüfung scheitern lassen. Zählen Sie daher nicht nur sichtbar eingetragene include-Anweisungen, sondern klären Sie bei Bedarf mit dem Versanddienst, wie seine Vorgabe ausgewertet wird.
DKIM prüft eine kryptografische Signatur der Nachricht. Der Nachrichtenkopf kann anzeigen, ob diese Prüfung erfolgreich war und welche Domain die Signatur verwendet. Das ist jedoch ein anderer Befund als die Frage, ob die Signaturdomain zur sichtbaren Absenderdomain passt. Der DKIM-Standard RFC 6376 beschreibt die Signaturprüfung; für die praktische Fehlersuche müssen Sie zusätzlich den sichtbaren From-Absender und die DMARC-Ausrichtung berücksichtigen.
| Prüffeld | Was Sie im Nachrichtenkopf oder DNS suchen | Was ein positiver Befund nicht beweist |
|---|---|---|
| SPF | Ergebnis der SPF-Prüfung und die tatsächlich geprüfte Domain | Dass DKIM ebenfalls funktioniert oder die From-Domain ausgerichtet ist |
| DKIM | Ergebnis der Signaturprüfung sowie die signierende Domain | Dass die Signaturdomain mit dem sichtbaren Absender übereinstimmt |
| From | Domain im für den Empfänger sichtbaren Absender | Dass der Versanddienst diese Domain autorisiert oder signiert |
| DMARC | Richtlinie und Ergebnis der SPF- und DKIM-Ausrichtung | Dass der empfangende Dienst die Nachricht in den Posteingang zustellt |
Zur ersten DNS-Kontrolle können Sie die Domain des Absenders abfragen. Ersetzen Sie example.com durch Ihre tatsächliche Domain; die Beispielausgabe ist keine Empfehlung für einen konkreten Eintrag.
dig TXT example.com
dig TXT _dmarc.example.com
Eine Ausgabe mit v=spf1 weist auf einen SPF-TXT-Eintrag hin. Eine DMARC-Richtlinie beginnt mit v=DMARC1. Für DKIM benötigen Sie den Selektor, den Ihr Versanddienst vorgibt; daraus ergibt sich der abzufragende DNS-Name. Verwechseln Sie nicht den DNS-Nachweis mit dem Test einer real versendeten Nachricht: Ein korrekt aussehender Eintrag allein belegt nicht, dass der Dienst tatsächlich mit der erwarteten Domain sendet.
DKIM-Erfolg ist nicht gleich DMARC-Ausrichtung
DKIM besteht den Test, aber die Nachricht wird dennoch abgewiesen oder gefiltert. Was bedeutet das? Lesen Sie im vollständigen Nachrichtenkopf zunächst das DKIM-Ergebnis und die Domain der Signatur. Vergleichen Sie diese Domain anschließend mit der Domain im sichtbaren From-Feld. Ein positives Signaturergebnis belegt die Prüfung der Signatur, nicht automatisch die für DMARC erforderliche Ausrichtung.
DMARC bewertet, ob SPF oder DKIM zur sichtbaren Absenderdomain ausgerichtet ist. Für die Beurteilung reicht daher ein isoliertes „DKIM: pass“ nicht aus. Halten Sie fest, welche From-Domain beim Empfänger angezeigt wird, welche Domain SPF geprüft hat und welche Domain DKIM signiert hat. Die aktuelle Gmail-Anleitung für Absender nennt Anforderungen für unterschiedliche Absendergruppen und erläutert SPF, DKIM, DMARC sowie die Ausrichtung. Laut dieser Anleitung gelten zusätzliche Anforderungen für Absender, die täglich mehr als 5.000 Nachrichten an Gmail senden. Wenden Sie diese Schwelle nicht ungeprüft auf alle Empfängerdienste an: Die Vorgaben sind anhand der jeweiligen offiziellen Regeln und Ihrer tatsächlichen Versandmenge zu bewerten.
Eine plausible Fehlersuche vergleicht die drei Domains, statt nur nach einem roten oder grünen Prüfzeichen zu suchen:
From: bestellung@shop.example
SPF-Ergebnis: pass; geprüfte Domain = mail.example
DKIM-Ergebnis: pass; signierende Domain = versand.example
Das ist eine illustrative Ausgabe, kein verbindlicher Test eines bestimmten Versanddienstes. Entscheidend ist, ob die jeweils tatsächlich ausgewertete Domain nach der geltenden DMARC-Regel zur sichtbaren Absenderdomain ausgerichtet ist. Prüfen Sie dafür die vollständige Nachricht und die Dokumentation Ihres Dienstes; übernehmen Sie keine Beispieldomains in Ihre produktive Konfiguration.
DMARC wird als erfolgreich angezeigt, aber die Bestellmail landet weiter im Spam. Warum? Ein DMARC-Erfolg ist kein Versprechen auf Zustellung in den Posteingang. Er betrifft Authentifizierung und Ausrichtung, während der Empfängerdienst zusätzlich eigene Filter-, Reputations- und Inhaltsprüfungen vornehmen kann. Der RFC 9989 für DMARC wurde im Mai 2026 veröffentlicht und ersetzte RFC 7489 sowie RFC 9091. Daraus folgt nicht, dass jede Shopdomain ihre Versandkonfiguration automatisch ändern muss oder dass alle Empfänger dieselben zusätzlichen Anforderungen eingeführt haben.
DMARC erst nach einer Bestandsaufnahme verschärfen
Bevor Sie eine Richtlinie ändern, erfassen Sie alle legitimen Quellen, die mit Ihrer Domain Nachrichten versenden: Bestell- und Versandbenachrichtigungen, Newsletter, Supportsysteme oder andere externe Dienste. Bestätigen Sie für jede Quelle, welche Absenderdomain verwendet wird, ob SPF und DKIM eingerichtet sind und wer den Versand protokolliert. Fehlt eine Quelle in Ihrer Übersicht, kann eine strengere Richtlinie erwünschte Nachrichten beeinflussen.
| DMARC-Befund | Was Sie zuerst klären | Vorsichtiger nächster Schritt |
|---|---|---|
| Kein DMARC-Eintrag erkennbar | Ob die Domain tatsächlich über eine DMARC-Richtlinie verfügt und welche Versandquellen bestehen | Dokumentation des DNS-Verantwortlichen und des Versanddienstes abgleichen |
| Richtlinie vorhanden, aber legitime Quelle nicht zugeordnet | Welche From-, SPF- und DKIM-Domains diese Quelle verwendet | Quelle und Ausrichtung erfassen, bevor Sie die Richtlinie verändern |
| Berichte zeigen unbekannte oder nicht ausgerichtete Quellen | Ob es sich um eigene Systeme, vergessene Dienste oder nicht autorisierte Nutzung handelt | Quelle untersuchen und verantwortliche Teams einbeziehen |
| Alle bekannten Quellen authentifizieren, einzelne Nachrichten landen dennoch im Spam | Empfängerreaktion, Inhalt, Versandstatus und Protokolle | Beim Dienst mit konkretem Ereignis und Antwortdaten nachfragen |
Eine Richtlinie mit p=none dient typischerweise der Beobachtung, während p=quarantine oder p=reject unterschiedliche Maßnahmen für nicht bestandene Prüfungen angeben. Behandeln Sie diese Werte nicht als universelle Stufenfolge, die ohne Analyse automatisch verschärft werden sollte. Prüfen Sie ihre Bedeutung und Anwendung im RFC 9989 und stimmen Sie Änderungen mit den Personen ab, die alle legitimen Versandquellen verantworten.
Nach dem Test anhand der Fehlerlage entscheiden
Führen Sie nach jeder Änderung einen Test mit einer echten Shopbenachrichtigung durch. Verwenden Sie einen Testauftrag, prüfen Sie das Ergebnis bei mehreren von Ihnen kontrollierten Empfängeradressen und notieren Sie Zeitpunkt, Bestellstatus, Ereignisprotokoll des Versanddienstes sowie SPF-, DKIM- und DMARC-Ergebnis. Ein Test bei einem einzelnen Anbieter ist kein Beleg dafür, dass sich andere Empfängerdienste gleich verhalten.
| Fehlerbild | Belege, die Sie sichern sollten | Zuständiger nächster Schritt |
|---|---|---|
| Keine Versandaufzeichnung | Bestellstatus, aktive Benachrichtigung, Anwendungsprotokoll | Shopkonfiguration und Übergabe an den Dienst prüfen |
| Versand verzeichnet, SPF nicht bestanden | Vollständiger Nachrichtenkopf, SPF-Auswertung, DNS-Eintrag | Autorisierung anhand der offiziellen Vorgabe des tatsächlichen Dienstes korrigieren |
| DKIM nicht bestanden | Signaturergebnis, Selektor, veröffentlichter Schlüssel und Dienstprotokoll | Schlüssel und DNS-Konfiguration mit dem Dienst abgleichen |
| SPF und DKIM bestanden, DMARC-Ausrichtung fehlt | From-Domain sowie geprüfte SPF- und DKIM-Domains | Absender- und Signaturkonfiguration auf Ausrichtung prüfen |
| Authentifizierung bestanden, aber abgewiesen | Antwort des Empfängers, Ereignisprotokoll und Zeitpunkt | Mit diesen Belegen den Versanddienst kontaktieren |
| Nachricht angenommen, aber im Spam | Nachrichtenkopf, Empfängerfeedback und Inhalt | Filterentscheidung und Inhalt untersuchen; keinen Posteingangserfolg voraussetzen |
Entscheidungszweige für den nächsten Schritt:
- Wenn im Versanddienst kein Versandereignis vorhanden ist, prüfen Sie zuerst die Shopbenachrichtigung und die Anwendungsprotokolle; ändern Sie SPF oder DKIM erst, wenn ein Authentifizierungsfehler nachgewiesen wurde.
- Wenn ein Versandereignis vorhanden ist und SPF oder DKIM fehlschlägt, gleichen Sie DNS und Absenderkonfiguration mit der Dokumentation des tatsächlich verwendeten Dienstes ab.
- Wenn SPF und DKIM bestehen, aber die Domains nicht ausgerichtet sind, korrigieren Sie die Absender- oder Signaturkonfiguration und prüfen Sie anschließend DMARC erneut.
- Wenn Authentifizierung und Ausrichtung bestehen, der Empfänger die Nachricht aber blockiert, sichern Sie die konkrete Antwort und die Ereignisdaten und wenden Sie sich damit an den Versanddienst.
- Wenn die Nachricht angenommen wurde und dennoch im Spam landet, untersuchen Sie Empfängerfilter, Inhalt und Rückmeldungen; leiten Sie aus bestandenen Authentifizierungstests keine Zustellgarantie ab.
Eine Bestellmail ist als versendet markiert, kommt aber nicht an. Was sollte der Support erhalten? Geben Sie Zeitpunkt, Empfängeradresse, Bestellstatus, Versandereignis, vollständige Antwort des Empfängerdienstes und – soweit verfügbar – den Nachrichtenkopf weiter. Die Aussage „SPF und DKIM sind grün“ reicht nicht, wenn der Versanddienst nicht erkennen kann, welcher Empfänger die Nachricht angenommen oder abgewiesen hat.
Serverbetrieb und E-Mail-Versand sind getrennte Verantwortlichkeiten
Ein gemieteter Server ist nicht automatisch ein E-Mail-Versanddienst. Die Zustellbarkeit der Shopbenachrichtigungen hängt von der Anwendung, dem tatsächlich verwendeten Drittanbieter für den Versand, den DNS-Einträgen und der Bewertung des empfangenden Dienstes ab. Auch ein Umzug auf einen eigenständigen Server ändert diese Abhängigkeiten nicht automatisch.
Wenn Sie parallel die Shopinfrastruktur bewerten, trennen Sie die Anforderungen an den Betrieb vom Versandweg der Bestellmails. Lesen Sie die Leistungsabgrenzung von OSFP Cloud, bevor Sie Serverfunktionen mit Versand- oder Zustellleistungen gleichsetzen. Für die administrative Verbindung zu einer Linux-Umgebung finden Sie außerdem Hinweise zum SSH-Zugriff; SSH ersetzt weder die Integration eines Versanddienstes noch die Domainauthentifizierung.
Gemeinsam genutzte VPS- oder Cloudumgebungen können je nach Tarif durch geteilte Ressourcen, nicht vollständig transparente Versandgrenzen oder begrenzte Möglichkeiten bei der Systemkonfiguration unpassend werden, wenn Ihr Shopbetrieb eigene Anforderungen stellt. Eine dedizierte AMD-Servermiete von OSFP Cloud kann sinnvoller sein, wenn Sie langfristig eigene Rechenressourcen für den Shop benötigen und den Betrieb selbst verwalten möchten. Sie ist aber keine Lösung für SPF-, DKIM- oder DMARC-Fehler und verspricht weder eine bessere Absenderreputation noch eine Zustellung in den Posteingang.
Prüfen Sie zunächst anhand der Fehlerzweige, ob die Nachricht im Shop erzeugt, vom Drittanbieter versendet und vom Empfänger angenommen wurde. Wenn Sie zusätzlich einen Umzug der Shopinfrastruktur erwägen, vergleichen Sie die Anforderungen an Anwendung und Betrieb getrennt vom E-Mail-Versand, bevor Sie eine Serverlösung auswählen.
Betreiben Sie Ihren Shop auf eigener Hardware
OSFP Cloud stellt Ihnen einen vollständigen physischen Server in Tokio mit AMD EPYC 7543P und 32 Kernen bereit.
ab $462 / Monat