Bestellbestätigung landet im Spam: So lösen Online-Shops das

Die Bestellung ist bezahlt, die Ware verschickt — aber die Bestellbestätigung landet im Spamordner des Kunden oder kommt gar nicht erst an. Die Folge sind verunsicherte Käufer, Support-Anfragen à la „Habe ich wirklich bestellt?" und im schlimmsten Fall Rückbuchungen wegen vermeintlicher Betrugsversuche. Bei Transaktions-Mails wie Bestellbestätigungen, Versandbenachrichtigungen oder Rechnungen ist das Problem besonders ärgerlich, weil der Kunde die Mail aktiv erwartet — trotzdem sortieren viele Filter sie aus. Der Grund liegt fast immer in der technischen Versandkonfiguration des Shopsystems, nicht im Inhalt der Mail.

Warum landen ausgerechnet Bestellbestätigungen im Spam?

Transaktions-Mails genießen bei Filtern eigentlich einen Vertrauensvorschuss — sie werden erwartet und selten als Massenmailing markiert. Trotzdem scheitern viele Shops an denselben drei Punkten:

Der Versand läuft über die Standardfunktion des Hosting-Servers (PHP mail() bzw. WordPress wp_mail()), nicht über einen dedizierten SMTP-Dienst.
Die versendende Domain hat keinen oder einen falsch konfigurierten SPF-Eintrag, sodass der Hosting-Server offiziell gar nicht als autorisierter Absender gilt.
DKIM ist nicht eingerichtet oder die Signatur passt nicht zur Absenderdomain (kein Alignment) — DMARC fehlt komplett.

Kommt dazu, dass viele Shared-Hosting-Server dieselbe IP-Adresse für hunderte Kunden nutzen, reicht oft schon der schlechte Ruf eines einzigen anderen Absenders auf derselben IP, um die eigenen Bestellbestätigungen in Sippenhaft zu nehmen.

Die typischen Ursachen bei Shopware, JTL-Shop und WooCommerce

Die drei Plattformen sind in DACH besonders verbreitet — und alle drei haben denselben blinden Fleck im Auslieferungszustand:

Shopware verschickt Transaktions-Mails standardmäßig über den Server, auf dem der Shop läuft. Ohne konfigurierten SMTP-Connector geht die Mail „im Namen" der Domain raus, ohne dass diese Domain den Hosting-Server als legitimen Absender autorisiert.
JTL-Shop verhält sich ähnlich: Läuft der Versand nicht über einen extern hinterlegten SMTP-Zugang, fehlt die Authentifizierungsbasis, auf der GMX, Web.de oder T-Online ihre Vertrauensentscheidung treffen.
WooCommerce nutzt über wp_mail() ebenfalls die Serverfunktion des Hosters. Ohne ein SMTP-Plugin (etwa WP Mail SMTP) mit korrekt verbundenem externen Versanddienst landet die Absenderadresse faktisch beim Hosting-Provider statt bei der eigenen Domain.

Auch Shopify-Shops sind betroffen, solange die eigene Domain nicht im Shop-Backend verifiziert wurde — erst danach darf tatsächlich über die eigene Domain und nicht über eine generische Shopify-Absenderadresse versendet werden.

Die Basis: SPF, DKIM und DMARC richtig einrichten

Der wichtigste Schritt ist, den Versand von der reinen Server-Standardfunktion auf einen externen SMTP-Dienst umzustellen — etwa einen deutschen ESP wie CleverReach, rapidmail, Brevo oder Mailjet, oder einen transaktionalen Versanddienst. Danach müssen SPF, DKIM und DMARC für die tatsächlich sendende Domain gesetzt sein, nicht nur für die Website-Domain im Browser.

Zusammenspiel von SPF, DKIM und DMARC bei der Zustellung von Transaktions-Mails

Ein SPF-Eintrag für eine an einen externen ESP ausgelagerte Domain sieht typischerweise so aus:

Beispiel eines SPF-Records für den Versand über einen externen SMTP-Provider

Der DMARC-Eintrag ergänzt das Ganze und sollte mindestens im Beobachtungsmodus stehen:

v=DMARC1; p=none; rua=mailto:dmarc-reports@dein-shop.de

Wichtig ist das Alignment: Die Domain in der From-Adresse, die Domain im DKIM-Selektor (d=) und die im SPF-Record autorisierte Domain müssen zusammenpassen. Genau daran scheitern viele Shop-Konfigurationen, bei denen der ESP zwar SPF/DKIM anbietet, die Bestellbestätigung aber trotzdem noch teilweise über den Hosting-Server verschickt wird.

Schritt-für-Schritt: So bringst du Bestellbestätigungen zurück in den Posteingang

Prüfen, welcher Server die Mail tatsächlich verschickt (im E-Mail-Header, Feld Received).
SMTP-Connector im Shopsystem (Shopware-Plugin, JTL-Shop-Einstellungen, WooCommerce-SMTP-Plugin) mit einem externen Versanddienst verbinden.
SPF-Record der Shop-Domain um den include des SMTP-Anbieters ergänzen.
DKIM-Signierung im Anbieter-Panel aktivieren und den CNAME/TXT-Eintrag beim Domain-Registrar setzen.
DMARC-Record mit p=none anlegen, Reports einige Tage beobachten, dann schrittweise auf p=quarantine anheben.
Testversand an mehrere Provider (GMX, Web.de, T-Online, Gmail, Outlook) durchführen und Zustellung, Header und Rendering prüfen.

Erst testen, dann live schalten

Nach jeder Umstellung des SMTP-Connectors lohnt sich ein Testversand über den kostenlosen Inbox-Placement-Test, bevor die Änderung produktiv geht. Das Tool zeigt pro Provider, ob die Mail im Posteingang, bei den Werbe-Tabs oder im Spamordner landet, inklusive SPF/DKIM/DMARC-Auswertung und Screenshot des tatsächlichen Renderings.

Rechtliche Seite: Absenderkennung nicht vergessen

Bestellbestätigungen sind vertragsnotwendige Transaktions-Mails — anders als Newsletter-Werbung nach UWG §7 brauchen sie keine separate Einwilligung, weil sie zur Abwicklung des Kaufvertrags gehören. Trotzdem gelten die üblichen Pflichten aus DSGVO und, für den Umgang mit Kontaktdaten in Telemedien, dem TTDSG: klare Absenderidentifikation, ein nachvollziehbarer Impressumsbezug und keine versteckten Tracking-Elemente ohne Rechtsgrundlage. Wer im selben Template auch werbliche Inhalte (Cross-Selling, Gutscheine) unterbringt, sollte diese sauber vom transaktionalen Teil trennen — sonst rutscht die Mail rechtlich wie technisch schnell in die Kategorie „Werbung" und braucht Double-Opt-in.

Testen statt hoffen: So prüfst du die Zustellung dauerhaft

Eine einmalige Konfiguration reicht nicht — IP- und Domain-Reputation verändern sich mit jedem Versandvolumen, jeder Beschwerderate und jedem neuen Filter-Update bei GMX, T-Online oder Gmail. Sinnvoll ist es, nach größeren Kampagnen oder Systemwechseln regelmäßig erneut zu testen und die Entwicklung von SPF-, DKIM- und DMARC-Adoption im breiteren Markt im Blick zu behalten, etwa über das laufende Deliverability-Datenset, das MX-Provider und Authentifizierungsraten regelmäßig neu scannt.

Trichter von Versand bis Posteingang bei schlecht konfigurierten Transaktions-Mails

Muss ich für Bestellbestätigungen eine Einwilligung nach UWG einholen?

Nein. Bestellbestätigungen sind zur Vertragserfüllung notwendig und fallen nicht unter die Einwilligungspflicht für Werbe-Mails nach UWG §7. DSGVO-Pflichten wie eine korrekte Absenderidentifikation gelten trotzdem weiter.

Warum kommt die Bestellbestätigung bei manchen Kunden an und bei anderen nicht?

Jeder Provider — GMX, Web.de, T-Online, Gmail, Outlook — bewertet Absenderreputation getrennt. Eine Domain kann bei Gmail sauber ankommen und bei T-Online im Spam landen, wenn dort die Beschwerdequote oder das Volumenmuster anders bewertet wird. Ein Test über mehrere Provider gleichzeitig zeigt solche Unterschiede.

Reicht ein SPF-Eintrag allein aus, um Bestellbestätigungen aus dem Spam zu holen?

Nein. SPF allein schützt nur vor Absenderfälschung auf Umschlagebene, sagt aber nichts über Inhaltsintegrität aus. Ohne DKIM und ein passendes DMARC-Alignment fehlt vielen Filtern das vollständige Vertrauenssignal, gerade bei strengeren Filtern wie T-Online.

Weiterführende Artikel