Zuletzt geprüft im Juni 2026, berücksichtigt die Authentifizierungsregeln für Gmail-/Yahoo-Massenversender, die 2024 in Kraft getreten sind. Anbieterlimits und Preise ändern sich, prüfen Sie aktuelle Werte daher direkt beim jeweiligen Anbieter. Backoffice-Pfade wurden mit PrestaShop 1.7, 8.x und 9.x verifiziert.
"Meine Kunden erhalten keine Bestellbestätigungen." Das ist eines der häufigsten Support-Tickets, die ein PrestaShop-Händler je eröffnet, und fast nie ist ein PrestaShop-Fehler die Ursache. E-Mail wirkt wie der einfachste Teil eines Shops, die Plattform sendet eine Bestätigung, sobald eine Bestellung aufgegeben wird, , doch der Weg dieser Nachricht von Ihrem Server bis in den Posteingang des Kunden führt durch Hosting-Beschränkungen, Authentifizierungseinträge und Spamfilter, die alle still scheitern können. Die Bestellung geht durch, das Geld wird eingezogen, und der Kunde hört nichts. Also schreibt er Ihnen, oder schlimmer: Er geht davon aus, dass der Kauf nicht funktioniert hat, und reklamiert die Zahlung. In diesem Leitfaden geht es gezielt darum, eine zuverlässige E-Mail-Zustellung aus PrestaShop heraus einzurichten: die genauen Backoffice-Einstellungen, die relevanten SMTP-Anbieteroptionen, die DNS-Einträge, die Sie aus dem Spamordner heraushalten, und wie Sie nachweisen, dass alles wirklich funktioniert, bevor ein echter Kunde herausfindet, dass es nicht funktioniert.
Die zwei E-Mail-Methoden in PrestaShop, und warum eine davon Sie in falscher Sicherheit wiegt
Öffnen Sie in Ihrem Backoffice Erweiterte Einstellungen → E-Mail. Dort bietet PrestaShop zwei Möglichkeiten zum E-Mail-Versand: die integrierte PHP-Funktion mail() und "Eigene SMTP-Parameter festlegen". Die PHP-Option mail() übergibt Ihre Nachricht an den lokalen Mail-Agenten (Sendmail oder Postfix) auf Ihrem Webserver. Auf dem Papier funktioniert das. In der Praxis ist es auf Shared- und Managed-Hosting, auf dem die meisten PrestaShop-Shops laufen, die mit Abstand häufigste Ursache für "meine E-Mails sind verschwunden":
- Hoster deaktivieren sie. Viele Anbieter schalten
mail()komplett ab, um Spam-Missbrauch durch kompromittierte Websites zu verhindern. PrestaShop sieht dann unter Umständen nur eine erfolgreiche lokale Übergabe, endgültige Zustellfehler erscheinen oft nur in Server- oder Anbieter-Logs, nicht im Backoffice. - Oft fehlt eine saubere Authentifizierung. PHP
mail()authentifiziert selbst nicht. Wenn Server/MTA und DNS also nicht gezielt konfiguriert sind, fehlt einer so versendeten Nachricht häufig die korrekte SPF-, DKIM- oder DMARC-Ausrichtung, und moderne Gmail-, Outlook- und Yahoo-Systeme behandeln nicht authentifizierte Massenmails standardmäßig als Spam. (Gmail und Yahoo haben diese Anforderungen für Massenversender 2024 offiziell verschärft.) - Sie erhalten kein echtes Zustellfeedback. Die Funktion gibt true oder false für die Übergabe zurück, nicht für die Zustellung. "True" bedeutet nur, dass der Server die Nachricht angenommen hat, aber nichts darüber, ob sie im Posteingang gelandet, zurückgewiesen oder gefiltert wurde.
- Sie erbt die Reputation einer gemeinsam genutzten IP. Auf Shared Hosting senden Sie über eine IP, die Dutzende andere Websites ebenfalls verwenden; wenn eine davon Spam verschickt, zahlen Ihre Bestellbestätigungen den Preis.
Die praktische Konsequenz ist einfach: Verwenden Sie immer SMTP, angebunden an einen echten E-Mail-Dienst. Der Rest dieses Leitfadens zeigt, wie Sie das richtig einrichten.
SMTP-Konfiguration in PrestaShop, Feld für Feld
Wählen Sie unter Erweiterte Einstellungen → E-Mail die Option "Eigene SMTP-Parameter festlegen". Danach fragt PrestaShop die folgenden Werte ab. Jeder unten genannte Anbieter füllt dieselben Felder, nur die Werte unterscheiden sich:
- SMTP-Server, der Hostname des Anbieters (zum Beispiel
smtp.gmail.com). - SMTP-Benutzername, in der Regel die vollständige Absenderadresse, auch wenn manche Dienste einen festen Literalwert verwenden (SendGrid erwartet das Wort
apikey). - SMTP-Passwort, je nach Anbieter das Postfachpasswort, ein App-spezifisches Passwort oder ein API-Schlüssel.
- Verschlüsselung, TLS (Port 587) oder SSL (Port 465). Wählen Sie niemals "Aus"; damit würden Ihre Zugangsdaten unverschlüsselt durchs Internet gesendet.
- SMTP-Port,
587für TLS (der moderne Standard) oder465für SSL.
Was bringt es Ihnen, diese Werte korrekt einzutragen? Eine Verbindung, die Sie als legitimen Absender authentifiziert, und genau das ist die Voraussetzung für alles Weitere: DKIM-Signierung, Platzierung im Posteingang und ein Anbieter-Dashboard, das Ihnen tatsächlich zeigt, was mit jeder Nachricht passiert ist. Im Folgenden finden Sie die drei Anbieterklassen, bei denen die meisten PrestaShop-Shops landen.
Gmail SMTP, ausreichend für einen kleinen Shop, aber mit harter Obergrenze
Gmail ist oft die erste Wahl, weil der Shopbetreiber das Konto bereits hat. Die Einstellungen:
| Feld | Wert |
|---|---|
| SMTP-Server | smtp.gmail.com |
| Port | 587 |
| Verschlüsselung | TLS |
| Benutzername | Ihre vollständige Gmail- / Workspace-Adresse |
| Passwort | ein 16-stelliges App-Passwort, nicht Ihr normales Login-Passwort |
So erzeugen Sie das App-Passwort: Gehen Sie in Ihrem Google-Konto zu Sicherheit → Bestätigung in zwei Schritten → App-Passwörter, erstellen Sie eines für "Mail" / "Andere (benutzerdefinierter Name)" mit der Bezeichnung "PrestaShop" und fügen Sie die 16-stellige Zeichenfolge in PrestaShops Feld für das SMTP-Passwort ein. Die Bestätigung in zwei Schritten muss vorher aktiviert sein, sonst zeigt Google die Option für App-Passwörter nicht an.
Der Haken ist das Volumen. Ein kostenloses Gmail-Konto ist auf ungefähr 500 Empfänger pro Tag begrenzt; Google Workspace hebt diese Grenze auf etwa 2.000 an. Jede PrestaShop-Bestellung löst typischerweise zwei oder drei E-Mails aus, Kundenbestätigung, Ihre Admin-Benachrichtigung und später eine Versandbenachrichtigung, , sodass ein Shop mit 100+ Bestellungen pro Tag bereits an die Grenze eines kostenlosen Gmail-Kontos stoßen kann. Sobald diese überschritten ist, werden E-Mails verzögert oder abgelehnt, ohne dass im Backoffice ein klares Signal erscheint. Gmail ist ein Einstieg, aber keine Dauerlösung.
Outlook / Microsoft 365 SMTP
| Feld | Wert |
|---|---|
| SMTP-Server | smtp.office365.com |
| Port | 587 |
| Verschlüsselung | TLS (STARTTLS) |
| Benutzername | Ihre Postfachadresse |
| Passwort | Ihr Postfachpasswort |
Microsoft schränkt die einfache SMTP-Authentifizierung seit einiger Zeit immer weiter ein. In vielen Tenants müssen Sie daher im Exchange Admin Center für das Postfach ausdrücklich Authentifiziertes SMTP aktivieren, bevor PrestaShop eine Verbindung herstellen kann. Wenn der Verbindungstest bei Microsoft 365 trotz ansonsten korrekter Zugangsdaten fehlschlägt, ist dieser Schalter meist der Grund.
Transaktionale E-Mail-Dienste, die richtige Antwort bei echtem Volumen
Ab einigen hundert Nachrichten pro Tag sollten Sie zu einem Dienst wechseln, der für transaktionalen Versand gebaut ist: SendGrid, Mailgun, Brevo oder Amazon SES. Diese Anbieter liefern eine eigene Versandreputation, automatische Verarbeitung von Bounces und Beschwerden sowie ein Zustell-Dashboard. Genau die Dinge, die Gmail nicht leisten kann. SendGrid als Beispiel:
| Feld | Wert |
|---|---|
| SMTP-Server | smtp.sendgrid.net |
| Port | 587 |
| Verschlüsselung | TLS |
| Benutzername | das Literalwort apikey |
| Passwort | Ihr SendGrid-API-Schlüssel |
Preise und Limits kostenloser Tarife ändern sich, prüfen Sie daher die aktuelle Seite des Anbieters, statt einer Zahl in einem Blogbeitrag zu vertrauen. Der strukturelle Vorteil bleibt aber gleich: eine Versand-IP, deren Reputation Sie (und der Anbieter) aktiv steuern, Bounce-Daten, die an Sie zurückfließen, und ein Zustellstatus pro Nachricht. Für jeden Shop, in dem eine verpasste Bestellbestätigung ein Support-Ticket oder eine Rückbuchung kostet, ist genau diese Transparenz der entscheidende Punkt.
E-Mail-Authentifizierung: SPF, DKIM und DMARC
Korrekte SMTP-Einstellungen bringen die Nachricht hinaus. Drei DNS-Einträge entscheiden, ob der empfangende Server ihr genug vertraut, um sie in den Posteingang zu legen. Ohne diese Einträge landet selbst perfekt konfiguriertes SMTP im Spam. Das ist nach "es wird gar nichts gesendet" die zweithäufigste E-Mail-Beschwerde. Anders als PrestaShop-Einstellungen liegen diese Einträge nicht im Backoffice, sondern im DNS Ihrer Domain.
SPF. Wer in Ihrem Namen senden darf
SPF (Sender Policy Framework) ist ein DNS-TXT-Eintrag, der die Server auflistet, die E-Mails für Ihre Domain senden dürfen. Ein empfangender Server prüft ihn, um zu bestätigen, dass die Nachricht aus einer autorisierten Quelle stammt. Ein typischer Eintrag für einen Shop, der über Google plus SendGrid sendet:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Nehmen Sie nur Dienste auf, über die Sie wirklich senden, jedes zusätzliche Include schwächt den Eintrag leicht, und SPF hat ein hartes Limit von 10 DNS-Abfragen, bevor die Prüfung vollständig fehlschlägt.
DKIM. Eine Signatur, die beweist, dass nichts manipuliert wurde
DKIM (DomainKeys Identified Mail) hängt an jede Nachricht eine kryptografische Signatur an. Sie belegt, dass die E-Mail von Ihrer Domain stammt und unterwegs nicht verändert wurde. Ihr Anbieter erzeugt den Schlüssel; Sie veröffentlichen ihn als TXT- oder CNAME-Eintrag. Für Google Workspace auf einer eigenen Domain aktivieren Sie DKIM unter Apps → Google Workspace → Gmail → E-Mail authentifizieren. Bei SendGrid verwenden Sie Settings → Sender Authentication → Authenticate Your Domain; dort erhalten Sie CNAME-Einträge, die Sie im DNS hinzufügen.
DMARC. Was mit E-Mails passieren soll, die die ersten beiden Prüfungen nicht bestehen
DMARC verbindet SPF und DKIM miteinander und teilt Empfängern mit, wie sie mit Nachrichten umgehen sollen, die durchfallen. Starten Sie im Überwachungsmodus, damit nichts kaputtgeht:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
Damit werden Fehler an Sie gemeldet, ohne etwas zu blockieren. Nach einigen Wochen sauberer Berichte verschärfen Sie auf p=quarantine (Fehlschläge in den Spamordner leiten) und schließlich auf p=reject (blockieren). Direkt auf p=reject zu wechseln, bevor Sie bestätigt haben, dass Ihre legitimen E-Mails bestehen, ist genau der Weg, wie Shops versehentlich ihre eigenen Bestellbestätigungen blockieren.
Die richtige "Von"-Adresse festlegen (ein stiller Zustellbarkeitskiller)
Die Absenderadresse von PrestaShop wird unter Shop-Einstellungen → Kontakt → Geschäfte gesetzt (sowie über die Kontakt-E-Mail pro Shop). Ein subtiler, aber sehr häufiger Fehler: Diese "Von"-Adresse muss zur Domain passen, die Sie für SMTP authentifiziert haben. Wenn Sie als info@yourstore.com senden, sich aber über smtp.gmail.com mit einer @gmail.com-Identität authentifizieren, entsteht ein Authentifizierungsbruch, den SPF/DMARC markieren, und Ihre E-Mail landet im Spam, obwohl jede einzelne Einstellung "korrekt" aussieht. Halten Sie Versanddomain, SMTP-Identität und Authentifizierungseinträge konsequent auf dieselbe Domain ausgerichtet.
Nachweisen, dass es funktioniert, bevor ein Kunde nachweist, dass es nicht funktioniert
Vertrauen Sie keinem Einstellungsbildschirm, nur weil dort "gespeichert" steht. Testen Sie den tatsächlichen Zustellweg:
- Der integrierte PrestaShop-Test. Auf der Seite Erweiterte Einstellungen → E-Mail gibt es ein Feld "Test-E-Mail senden", senden Sie eine an sich selbst und prüfen Sie, ob sie im Posteingang landet, nicht im Spam.
- mail-tester.com. Senden Sie eine Nachricht an die dort angezeigte Adresse; der Dienst bewertet SPF, DKIM, DMARC, Inhalt und Blacklist-Status mit bis zu 10 Punkten. Zielen Sie auf 9+ Punkte, bevor Sie die Einrichtung als fertig betrachten.
- Über mehrere Anbieter testen. Senden Sie getrennt an Gmail, Outlook/Hotmail und Yahoo, ihre Spamregeln unterscheiden sich, und ein bestandener Test bei einem Anbieter bedeutet nicht, dass alle drei bestehen.
- Header lesen. Öffnen Sie in einer empfangenen Gmail-Nachricht drei Punkte → Original anzeigen und suchen Sie nach
SPF: PASS,DKIM: PASSundDMARC: PASS. Wenn irgendwo FAIL oder NONE steht, korrigieren Sie den passenden DNS-Eintrag, bevor Sie live gehen.
Transaktionale E-Mails und Marketing-E-Mails, halten Sie sie auf getrennten Schienen
Dieser Leitfaden behandelt transaktionale E-Mails: Bestellbestätigungen, Versandmitteilungen, Passwort-Resets, also Nachrichten, die PrestaShop automatisch als direkte Folge einer Kundenaktion versendet. Behandeln Sie diese als separaten Strom neben Marketing-Newslettern und Aktionen, denn eine Vermischung kostet Sie:
- Reputationsverschmutzung. Wenn Ihr Newsletter Spam-Beschwerden auslöst und dieselbe IP/Domain wie Ihre Bestellbestätigungen nutzt, zieht er die Bestellbestätigungen mit nach unten.
- Unterschiedliche rechtliche Regeln. Transaktionale E-Mails benötigen keinen Abmeldelink (sie sind zur Kaufabwicklung erforderlich); Marketing-E-Mails schon. Eine Trennung hält die Compliance-Grenze sauber.
- Volumenspitzen. Ein Newsletter-Versand an 50.000 Empfänger kann eine gemeinsam genutzte SMTP-Verbindung auslasten und die zeitkritische Bestellbestätigung verzögern, auf die ein Kunde wartet.
Bewährte Praxis: Senden Sie die transaktionalen E-Mails von PrestaShop über Ihren SMTP-Dienst und verschicken Sie Newsletter über eine spezialisierte Plattform (Mailchimp, Brevo, Klaviyo). Wenn diese beiden Welten verbunden werden sollen, etwa um einen neuen PrestaShop-Kunden automatisch in Ihre Newsletter-Liste zu übernehmen, , koppeln Sie sie über eine Automatisierungsebene, statt die Versandströme zu vermischen. Den No-Code-Weg dafür beschreiben wir in Zapier und Make für PrestaShop und, speziell für Workflow-Trigger, in PrestaShop und Zapier ohne Programmierung.
Die Fehlerliste für "E-Mail wird nicht gesendet"
Das sind die Fälle, die uns am häufigsten begegnen, wenn Händler uns bitten, defekte PrestaShop-E-Mails zu prüfen, ungefähr in der Reihenfolge, in der es sich lohnt, sie abzuarbeiten.
Es wird gar nichts gesendet
- Lesen Sie zuerst das E-Mail-Protokoll. Wenn die Protokollierung aktiviert ist, listet Erweiterte Einstellungen → E-Mail die Nachrichten auf, die PrestaShop zu senden versucht hat (Empfänger, Vorlage, Betreff, Uhrzeit). Wenn Nachrichten protokolliert werden, aber nicht ankommen, erzeugt PrestaShop sie und übergibt sie weiter, doch später im Zustellweg scheitert die Zustellung (Authentifizierung oder Spam). Wenn gar nichts protokolliert wird, schlägt der Versand schon vorher fehl, prüfen Sie SMTP-Host, Port und Zugangsdaten erneut und bestätigen Sie, dass die Protokollierung selbst eingeschaltet ist.
- Zugangsdaten direkt erneut testen. Melden Sie sich mit genau dem Benutzernamen und Passwort im Postfach oder in der Anbieter-Konsole an, die Sie in PrestaShop eingefügt haben. Wenn Sie sich damit nicht anmelden können, kann PrestaShop es auch nicht.
- Prüfen, ob der Port durch eine Firewall blockiert wird. Manche Hoster blockieren ausgehende Verbindungen über 587/465. Wenn der Verbindungstest in einen Timeout läuft, bitten Sie Ihren Hoster zu bestätigen, dass diese Ports für ausgehenden Traffic offen sind.
E-Mails werden gesendet, landen aber im Spam
- Fehlendes oder fehlerhaftes SPF/DKIM. Prüfen Sie mit mxtoolbox.com, ob beide Einträge für Ihre Domain existieren und bestehen.
- Abweichende Von-Adresse. Siehe den Abschnitt zur "Von"-Adresse oben. Das ist eine der am häufigsten übersehenen Spamursachen.
- Spamverdächtige Vorlageninhalte. Zu viel Sprache wie "gratis / Rabatt / jetzt handeln" und ein schlechtes Text-Bild-Verhältnis in angepassten Vorlagen lösen Inhaltsfilter aus.
Sporadische Fehler
- Ratenbegrenzung. Sie überschreiten das tägliche Versandlimit des Anbieters; vergleichen Sie Ihr reales Volumen mit dem Limit Ihres Tarifs und wechseln Sie auf einen höheren Tarif oder Anbieter, wenn Sie herausgewachsen sind.
- Verbindungs-Timeouts. Ein langsamer SMTP-Server kann PrestaShops Standard-Timeout für Verbindungen überschreiten, eine Erhöhung (zum Beispiel von 5 auf 20 Sekunden) behebt wackelige Zustellungen oft.
Erfolgreich gesendet, aber der Kunde sagt, es sei nichts angekommen
Prüfen Sie die Kundenadresse auf einen Tippfehler, sehen Sie im Bounce-Protokoll Ihres Anbieters nach und bitten Sie den Kunden, im Spamordner zu suchen und Ihre Absenderadresse auf die Whitelist zu setzen. "Gesendet" in PrestaShop bedeutet nur, dass der SMTP-Server die Nachricht angenommen hat. Ob sie zurückgewiesen wurde, sehen Sie im Anbieter-Dashboard. Sobald Sie bestätigt haben, dass die Adresse stimmt und die Ursache der Zustellbarkeitsprobleme behoben ist, sollten Sie genau diese Bestätigung erneut senden, statt den Kunden ohne Nachricht stehen zu lassen: Unser Modul Resend Order Confirmation löst die Bestellbestätigung direkt von der Bestellseite aus erneut aus, sodass aus einem einmaligen Zustellfehler kein manueller Neuaufbau der E-Mail wird.
E-Mail-Vorlagen in PrestaShop anpassen

Die E-Mail-Vorlagen von PrestaShop können je nach Version, Theme und installierten Modulen an mehreren mails/<language_code>/-Orten liegen, im Core, im Theme und in Modul-Mailverzeichnissen, , jeweils als HTML-Datei plus TXT-Fallback für reinen Text. Neuere Versionen (1.7/8/9) lassen Sie außerdem das Erscheinungsbild unter Design → E-Mail-Theme bearbeiten. Ein paar Regeln sorgen dafür, dass angepasste Vorlagen überall sauber dargestellt werden:
- Verwenden Sie Inline-CSS, viele E-Mail-Clients entfernen
<style>-Blöcke. - Arbeiten Sie mit Tabellen; HTML-Rendering in E-Mails steckt praktisch im Jahr 2005 fest.
- Halten Sie die Breite für mobile Geräte unter 600px.
- Testen Sie in mehreren Clients (Gmail Web, Outlook Desktop, Apple Mail, mobil).
- Löschen Sie niemals Platzhalter wie
{firstname},{lastname}oder{order_name}, PrestaShop ersetzt sie beim Versand durch echte Daten, und wenn sie fehlen, bricht die Zusammenführung.
Protokollierung und echtes Zustellmonitoring
Wenn die E-Mail-Protokollierung aktiviert ist, zeichnet PrestaShop jeden Versandversuch in seiner Datenbank auf. Sichtbar ist das unter Erweiterte Einstellungen → E-Mail, mit Empfänger, verwendeter Vorlage, Sprache, Betreff und Versandzeit. Aber behalten Sie im Kopf, was ein Eintrag in dieser Liste bedeutet: PrestaShop hat die Nachricht an den SMTP-Server übergeben. Es ist kein Beweis für die Zustellung im Posteingang, und das Protokoll enthält keinen zugestellt-/zurückgewiesen-Status pro Nachricht. Diese Wahrheit liefert das Dashboard Ihres Anbieters, SendGrid, Mailgun und Amazon SES melden zugestellte, zurückgewiesene, verzögerte und beanstandete Nachrichten pro E-Mail. Schauen Sie dort wöchentlich hinein; eine langsam steigende Bounce-Rate ist das frühe Warnsignal, dass sich ein Zustellbarkeitsproblem bildet, bevor Kunden es bemerken.
Häufig gestellte Fragen
Warum werden meine PrestaShop-Bestellbestätigungen nicht zugestellt?
Die häufigste Ursache ist die Verwendung von PHP mail() auf Hosting, das diese Funktion deaktiviert oder nicht authentifiziert sendet, moderne Gmail-, Outlook- und Yahoo-Systeme verschieben nicht authentifizierte Massenmails in den Spam. Wechseln Sie unter Erweiterte Einstellungen → E-Mail zu "Eigene SMTP-Parameter festlegen", verbinden Sie PrestaShop mit einem echten E-Mail-Dienst und veröffentlichen Sie SPF-, DKIM- und DMARC-Einträge. Prüfen Sie den Weg anschließend mit einem Test, bevor Sie ihn für Live-Bestellungen nutzen.
Welchen SMTP-Port und welche Verschlüsselung sollte ich verwenden?
Port 587 mit TLS ist der moderne Standard und die Empfehlung der meisten Anbieter; Port 465 mit SSL ist die ältere Alternative und funktioniert weiterhin. Wählen Sie niemals "Aus", dadurch würden Ihre Zugangsdaten unverschlüsselt gesendet. Wenn ein Verbindungstest auf einem der beiden Ports in einen Timeout läuft, blockiert Ihr Hoster möglicherweise ausgehendes SMTP, und Sie müssen ihn bitten, es freizugeben.
Kann ich einfach mein Gmail-Konto verwenden, um Shop-E-Mails zu senden?
Für einen kleinen Shop ja, verwenden Sie smtp.gmail.com auf Port 587/TLS mit einem 16-stelligen App-Passwort (nicht Ihrem Login-Passwort; die Bestätigung in zwei Schritten muss vorher aktiviert sein). Ein kostenloses Gmail-Konto ist jedoch auf ungefähr 500 Empfänger/Tag begrenzt, Workspace auf etwa 2.000. Da jede Bestellung zwei oder drei E-Mails auslöst, stößt ein Shop ab ungefähr 100 Bestellungen/Tag an diese Grenze, und E-Mails werden still verzögert. Gmail ist ein Einstieg, aber keine Dauerlösung, wechseln Sie bei Volumen zu SendGrid, Mailgun, Brevo oder Amazon SES.
Meine E-Mail wird gesendet, landet aber im Spam, was ist falsch?
Fast immer fehlt eine Authentifizierung, sie schlägt fehl, oder die Von-Adresse passt nicht. Prüfen Sie, ob SPF und DKIM existieren und bestehen (mxtoolbox.com), und stellen Sie sicher, dass die Domain Ihrer "Von"-Adresse zu der Domain passt, über die Sie SMTP authentifizieren, wenn Sie als info@yourstore.com senden, sich aber als @gmail.com-Identität authentifizieren, wird das von SPF/DMARC markiert und im Spam abgelegt, selbst wenn jede Einstellung "korrekt" aussieht.
Ein Kunde sagt, er habe seine Bestätigung nie erhalten, was nun?
Prüfen Sie zuerst, ob es wirklich ein Zustellfehler ist: Kontrollieren Sie die Adresse auf einen Tippfehler und das Bounce-Protokoll Ihres Anbieters ("Gesendet" in PrestaShop bedeutet nur, dass der SMTP-Server die Nachricht angenommen hat, nicht dass sie zugestellt wurde). Beheben Sie die zugrunde liegende Zustellbarkeitsursache und senden Sie dann genau diese Bestätigung erneut, statt den Kunden ohne Nachricht stehen zu lassen, Resend Order Confirmation löst sie mit einem Klick direkt von der Bestellseite erneut aus.
Sollten Bestellbestätigungen und mein Newsletter über denselben Dienst laufen?
Nein, halten Sie sie auf getrennten Schienen. Wenn Ihr Newsletter Spam-Beschwerden auslöst und sich eine IP/Domain mit Ihren transaktionalen E-Mails teilt, zieht er Ihre Bestellbestätigungen mit nach unten. Senden Sie transaktionale E-Mails über Ihren SMTP-Dienst und verschicken Sie Newsletter über eine spezialisierte Plattform (Mailchimp, Brevo, Klaviyo). Verbinden Sie beide bei Bedarf über eine Automatisierungsebene, statt Versandströme zu vermischen.
Wo E-Mail in einem Shop steht, der aus manueller Arbeit herauswächst
Zuverlässige transaktionale E-Mails sind die Grundlage, aber selten die einzige Stelle, an der ein wachsender Shop Zeit und Informationen verliert. Dasselbe Bestellereignis, das eine Bestätigungs-E-Mail auslöst, muss meist auch Ihr Buchhaltungssystem und irgendwann Ihr ERP erreichen, und diese Daten von Hand zu kopieren, ist genau die Art manueller Arbeit, die bei Volumen bricht. Wenn Sie an dem Punkt sind, an dem Bestell-E-Mails geklärt sind, der Rest Ihres Backoffice aber noch mit Copy-Paste läuft, sind das die nächsten Dominosteine:
- Buchhaltung. Rechnungsdaten jeder Bestellung automatisch in Xero oder QuickBooks übertragen, statt sie erneut einzutippen, siehe PrestaShop mit Ihrer Buchhaltungssoftware verbinden.
- ERP. Wenn Lagerbestände, Bestellungen und Kunden mit einem Backoffice-System synchron bleiben müssen, finden Sie die Integrationsmuster, die in der Praxis tragen, in Integrationsmuster zwischen PrestaShop und ERP, und die Signale, dass es Zeit dafür ist, in wenn Ihr Shop aus manueller Arbeit herauswächst.
- No-Code-Verbindungen. Für leichtere Anbindungen, einen neuen Kunden in eine Liste übernehmen, eine Bestellung an ein Tool senden, siehe Zapier und Make für PrestaShop.
E-Mail-Zustellbarkeit ist unspektakulär, und genau deshalb wird sie oft vernachlässigt, bis ein Kunde, der nie eine Bestätigung erhalten hat, einen Streitfall eröffnet. Stellen Sie SMTP auf einen echten Anbieter um, veröffentlichen Sie Ihre SPF-, DKIM- und DMARC-Einträge, richten Sie Ihre "Von"-Adresse sauber aus und testen Sie den gesamten Weg, bevor Sie ihn Live-Bestellungen anvertrauen. Module, die PrestaShops Shop-Management- und Integrationsfunktionen erweitern, gebaut, um PrestaShop- und PHP-Versionsupgrades zu überstehen, statt beim nächsten Update zu brechen, finden Sie im Katalog unter mypresta.rocks.
Kommentare
Kommentar schreiben
Teilen Sie eine Frage, ein Installationsdetail oder Feedback, das anderen Lesern helfen kann.