Anleitungen
Anleitung

Dafür sorgen, dass Ihre Shop-E-Mails ankommen

PrestaShop-E-Mails landen im Spam? Die Anleitung für PS 8/9: SMTP auf Shared Hosting, SPF/DKIM/DMARC und Transaktionsmail-Dienste.

Bestellbestätigungen landen im Spam: die häufigste E-Mail-Beschwerde, die wir hören

Ein Kunde bezahlt. Das Mail-Protokoll von PrestaShop meldet „gesendet". Die Bestätigungs-E-Mail trifft nie ein, oder sie landet im Reiter „Werbung", oder sie liegt sechs Stunden lang im Spam. Der Kunde gerät in Panik, eröffnet eine Rückbuchung, hinterlässt eine Ein-Stern-Bewertung und schreibt den Support an mit der Frage „Haben Sie mein Geld eingezogen?". Wir haben das auf mehr Shops beobachtet, als wir zählen können, und 2026 ist es nach wie vor das mit Abstand häufigste E-Mail-Problem in PrestaShop.

Die Lösung liegt selten innerhalb von PrestaShop. Über die Zustellbarkeit entscheidet der empfangende Mailserver (Gmail, Outlook, Yahoo), und was er entscheidet, hängt davon ab, wie Sie sich authentifizieren, welche Reputation Ihre sendende IP hat und ob Ihr DNS die Wahrheit darüber sagt, wer als Ihre Domain senden darf. Die Aufgabe von PrestaShop besteht lediglich darin, die Nachricht sauber zu übergeben.

PHP mail() ist reine Show

Eine frische PrestaShop-Installation versendet über die mail()-Funktion von PHP. Das ist die Voreinstellung, und es ist die schlechteste Option, die uns für einen Produktiv-Shop einfällt:

  • Keine Authentifizierung. Die Nachricht trifft ohne jeden Nachweis ein, dass Sie sie autorisiert haben. Gmail und Outlook behandeln nicht authentifizierte Mail als schuldig, bis das Gegenteil bewiesen ist.
  • Geteilte IP, geteilte Reputation. Beim Shared Hosting verlässt Ihre Mail dieselbe IP wie 200 andere Websites. Wenn eine davon spammt, leiden alle anderen mit.
  • Keine DKIM-Signatur. mail() signiert kryptografisch nichts. Es gibt für den Empfänger nichts zu verifizieren.
  • Absolut minimale Header. Spamfilter werten das als verdächtig, noch bevor sie überhaupt einen Blick auf den Inhalt werfen.
Wenn Ihr Shop noch mail() verwendet, ist der Wechsel zu echtem SMTP die einzelne Änderung, die mehr Zustellbarkeitsprobleme behebt als alle anderen Schritte auf dieser Seite zusammen. Erledigen Sie das zuerst.

Was eine Nachricht tatsächlich als Spam markieren lässt

  • Absenderadresse passt nicht. Versand von noreply@yourstore.com, während Ihr DNS keinen SPF-Eintrag hat, der die IP Ihres Servers dazu berechtigt.
  • Bildlastige Vorlagen. Die Standardvorlagen von PrestaShop sind bilderreich. Ein schlechtes Verhältnis von Bild zu Text ist für sich genommen bereits ein Spam-Signal.
  • Fehlender Klartext-Teil. PrestaShop sendet standardmäßig im Multipart-Format, doch eigene Vorlagen und Übersetzungsmodule können die Klartext-Alternative klammheimlich zerstören.
  • Defekte Links. Spamfilter lösen die URLs in Ihrer Nachricht auf. Wenn Ihr Shop im Wartungsmodus ist, eine fehlerhafte SSL-Kette hat oder 500er-Fehler liefert, wird Ihre E-Mail markiert.
  • Kodierungs-Müll. Shops mit polnischen, tschechischen, deutschen oder französischen Sonderzeichen produzieren in dem Moment Mojibake, in dem ein Glied der Kette nicht UTF-8 ist.

E-Mail-Konfiguration in PrestaShop nach Version

E-Mail-Konfiguration im Administrationsbereich von PrestaShop 8.

Die Wahl zwischen sendmail und SMTP, das E-Mail-Format, der Protokoll-Schalter und die DKIM-Signierung. Wenn Ihre Bestellbestätigungen im Spam landen, ist dies der Ausgangspunkt.

E-Mail-Einstellungsseite im Administrationsbereich von PrestaShop 8 mit der Auswahl sendmail vs. SMTP, DKIM-Konfiguration und E-Mail-Protokollierung

Die Einstellungsseite ist in etwa an derselben Stelle geblieben. Die Bibliothek darunter hat sich in PS 9 vollständig geändert.

PrestaShop 1.6 und 1.7

Erweiterte Einstellungen → E-Mail. Wählen Sie „Eigene SMTP-Parameter festlegen" und geben Sie Server, Port, Verschlüsselung, Benutzername und Passwort ein. PS 1.6 nutzt die eigene SMTP-Verarbeitung von PHP; PS 1.7 hat Swift Mailer eingeführt. Verschlüsselungsoptionen:

  • TLS (Port 587): Der moderne Standard. STARTTLS, fast überall die richtige Wahl.
  • SSL (Port 465): Älteres implizites TLS. Manche Alt-Hoster verlangen es noch.
  • Keine (Port 25): Unverschlüsselt. Bitte nicht.

PrestaShop 8.x

Gleicher Bildschirm, gleiche Oberfläche. PS 8 liefert die finale Version von Swift Mailer mit besserer Fehlerberichterstattung aus, wenn SMTP fehlschlägt, erhalten Sie tatsächlich eine nützliche Zeile in var/logs/ statt eines stillen Verwerfens.

PrestaShop 9: Symfony Mailer

PS 9 verabschiedet sich von Swift Mailer (das upstream schon seit Jahren am Ende seines Lebenszyklus ist) und ersetzt ihn durch Symfony Mailer. Die Admin-Oberfläche sieht identisch aus, doch darunter hat sich alles geändert:

  • DSN-basierte Konfiguration. Intern ist der Transport ein URI: smtp://user:password@server:port.
  • TLS-Autoerkennung. Port 587 handelt STARTTLS automatisch aus. Das Auswahlfeld „Verschlüsselung" verhält sich nach einem Upgrade von 8 → 9 manchmal anders, erneut testen.
  • Strengere Validierung. Symfony Mailer legt Wert darauf, dass der Envelope-Absender mit dem From-Header übereinstimmt, und es validiert TLS-Zertifikate ordnungsgemäß.
  • Modul-Ausfälle. Jedes Modul, das Swift_Message oder Swift_SmtpTransport importiert, funktioniert unter PS 9 nicht mehr, bis es aktualisiert wird.
# Interne DSN-Beispiele für PS 9 (über die Admin-Oberfläche konfiguriert)
smtp://user:password@mail.example.com:587      # STARTTLS
smtps://user:password@mail.example.com:465     # Implizites TLS
smtp://your%40gmail.com:app-pass@smtp.gmail.com:587  # Gmail
native://default                                # PHP mail() (nicht empfohlen)
Testen Sie E-Mails nach jedem Upgrade von 8 → 9 immer erneut. Wir haben erlebt, dass selbstsignierte Zertifikate, ungewöhnliche Ports und nachlässig implementierte SMTP-Server allesamt in dem Moment den Dienst quittierten, in dem Symfony Mailer übernahm.

Die Schaltfläche „Test-E-Mail senden"

Jede Version hat sie. Sie ist nützlich, bestätigt aber nur eine einzige Sache: dass Ihr Shop eine SMTP-Verbindung aufbauen kann. Sie bestätigt nicht, dass die Nachricht einen Posteingang erreicht hat. Senden Sie echte Testbestellungen an eine Gmail-Adresse, eine Outlook-Adresse und eine Adresse auf Ihrer eigenen Domain, diese drei decken ungefähr 90 % dessen ab, was Ihre Kunden verwenden.

Domain-Authentifizierung: SPF, DKIM, DMARC

SPF, DKIM und DMARC sind drei DNS-Einträge, die gemeinsam belegen, dass Ihre Mail legitim ist. Gmail und Yahoo haben SPF und DKIM im Februar 2024 für Massenversender verpflichtend gemacht. Wir behandeln sie für jeden Versender als verpflichtend, ohne Ausnahme.

SPF (Sender Policy Framework)

Ein TXT-Eintrag auf Ihrer Domain, der die IPs und Dienste benennt, die als Sie senden dürfen.

# Basis: erlaubt Hosting + Google
v=spf1 include:_spf.google.com include:your-hosting-provider.com ~all

# OVH
v=spf1 include:mx.ovh.com ~all

# Hostinger
v=spf1 include:_spf.hostinger.com ~all

# Mit Mailgun
v=spf1 include:mailgun.org include:_spf.google.com ~all

Wo das schiefgeht:

  • Zwei SPF-Einträge. Pro Domain ist nur ein TXT-Eintrag als SPF gültig. Zwei Einträge heben sich gegenseitig auf. Fassen Sie die Dienste in einem einzigen Eintrag mit mehreren include:-Direktiven zusammen.
  • Zu viele Lookups. SPF erlaubt insgesamt 10 DNS-Lookups. Jedes include: zählt, und auch verschachtelte Includes zählen mit. Prüfen Sie Ihren Eintrag vor der Veröffentlichung mit einem Validator.
  • +all statt ~all. +all teilt aller Welt mit, dass jeder als Sie senden darf. Was genau das Gegenteil des Sinns ist. Beginnen Sie mit ~all (Softfail) und ziehen Sie es auf -all an, sobald Sie sich sicher sind.
  • Subdomains werden nicht vererbt. SPF für shop.example.com benötigt einen eigenen Eintrag. Die übergeordnete Domain deckt sie nicht ab.

DKIM

DKIM signiert jede ausgehende Nachricht kryptografisch. PrestaShop 1.6 und 1.7 signieren kein DKIM: das tut Ihr SMTP-Relay, Ihr Hosting-Anbieter oder Ihr transaktionaler Dienst. PrestaShop 8 und 9 können selbst signieren (Erweiterte Einstellungen → E-Mail, Bereich DKIM), mit einem Schlüsselpaar, das Sie erzeugen; wenn Sie über ein Relay oder einen transaktionalen Dienst senden, ist es meist einfacher, diesem Dienst das Signieren zu überlassen. Sie veröffentlichen deren öffentlichen Schlüssel im DNS, und sie signieren mit dem passenden privaten Schlüssel.

  • Shared Hosting (cPanel/Plesk): Meist ein Klick in cPanel → Email Deliverability.
  • Gmail / Google Workspace: Admin-Konsole → Gmail → E-Mail authentifizieren. Google händigt Ihnen einen TXT-Eintrag aus.
  • Transaktionale Dienste: Ihr Assistent zur Domainverifizierung sagt Ihnen genau, was zu veröffentlichen ist.
# Beispiel für einen DKIM-TXT-Eintrag
# Name: default._domainkey.yourstore.com (Selektor je nach Anbieter unterschiedlich)
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

DMARC

DMARC verknüpft SPF und DKIM und teilt dem empfangenden Server mit, was bei einer fehlgeschlagenen Authentifizierung zu tun ist.

# Stufe 1: Nur überwachen
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourstore.com;

# Stufe 2: Fehlschläge in Quarantäne
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourstore.com;

# Stufe 3: Fehlschläge ablehnen (maximaler Schutz)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourstore.com;

Sobald der Eintrag veröffentlicht ist, geben Sie Ihre Domain in den kostenlosen DMARC-Checker von Palisade ein: Er liest den veröffentlichten Eintrag und meldet Syntax- und Richtlinienfehler, ohne Registrierung (Seite auf Englisch).

Die rua-Adresse erhält aggregierte XML-Berichte. Eine tägliche Liste derjenigen, die versucht haben, als Ihre Domain Mail zu senden. Wir leiten unsere durch Postmarks kostenlose DMARC-Überwachung, denn rohes XML zu lesen ist nicht die Art, wie irgendjemand seinen Montagmorgen verbringen sollte.

Führen Sie DMARC in Stufen ein. Zwei bis vier Wochen bei p=none, während Sie die Berichte lesen und legitime Versender identifizieren, die durchfallen. Ziehen Sie für weitere zwei bis vier Wochen auf p=quarantine an. Erst dann wechseln Sie zu p=reject. Am ersten Tag direkt auf reject zu gehen blockiert Mail, von deren Existenz Sie nichts wussten, meist ein CRM oder ein Buchhalter, der in Ihrem Namen Rechnungen versendet.

SMTP beim Shared Hosting

Die meisten PrestaShop-Shops liegen auf Shared Hosting. Legen Sie ein dediziertes Postfach an (z. B. orders@yourstore.com) und verwenden Sie diese Zugangsdaten in PrestaShop, niemals Ihren persönlichen Posteingang.

Anbietereinstellungen

# Generisches cPanel
Server: mail.yourstore.com | Port: 587 | Verschlüsselung: TLS

# OVH
Server: ssl0.ovh.net | Port: 587 | Verschlüsselung: TLS

# Hostinger
Server: smtp.hostinger.com | Port: 587 | Verschlüsselung: TLS

# SiteGround
Server: yourstore.com | Port: 465 | Verschlüsselung: SSL

# Bluehost
Server: mail.yourstore.com | Port: 465 | Verschlüsselung: SSL

Gmail SMTP

SMTP-Konfigurationsfelder in PrestaShop 8.

Wenn „Eigene SMTP-Parameter festlegen" ausgewählt ist, erscheinen diese Felder: Server, Port, Benutzername, Passwort, Verschlüsselung. Hier richten Sie PrestaShop auf Gmail, SendGrid, Mailgun oder Ihren eigenen Mailserver aus.

SMTP-Konfiguration in PrestaShop 8 mit den Feldern Server, Port, Benutzername, Passwort und Verschlüsselung

Genau das verwenden wir selbst für mypresta.rocks, Gmail SMTP mit einem App-Passwort (Google-Konto → Sicherheit → Bestätigung in zwei Schritten → App-Passwörter). Günstig, zuverlässig, vernünftig für einen Shop mit geringem Volumen.

Server: smtp.gmail.com | Port: 587 | Verschlüsselung: TLS
Benutzername: your@gmail.com | Passwort: (16-stelliges App-Passwort)

Limits: kostenloses Gmail 500/Tag, Google Workspace 2.000/Tag. Wer zu schnell in Wellen versendet, wird von Google vorübergehend gedrosselt.

Gmail SMTP funktioniert für Shops mit ungefähr unter 30 Bestellungen pro Tag einwandfrei. Darüber stoßen Sie an die Obergrenze, und Kunden warten bis zu 24 Stunden auf ihre Bestätigung. Das ist der Moment, zu einem echten transaktionalen Dienst zu wechseln.

Microsoft 365 SMTP

Server: smtp.office365.com | Port: 587 | Verschlüsselung: TLS
Benutzername: your@yourstore.com | Passwort: Kontopasswort oder App-Passwort

Limit: 10.000 Empfänger/Tag, 30 Nachrichten/Minute. Microsoft besteht zunehmend auf OAuth statt einfacher SMTP-Authentifizierung, prüfen Sie vor dem Live-Gang die Richtlinie Ihres Mandanten.

Transaktionale E-Mail-Dienste

Wenn Sie aus dem Hosting-SMTP herauswachsen, bieten Ihnen transaktionale Dienste dedizierte Infrastruktur mit hoher Reputation, für Sie erledigte DKIM-Signierung, Bounce-Verarbeitung und ein Dashboard, das Ihnen sagt, was mit jeder einzelnen Nachricht tatsächlich passiert ist.

Wann der Wechsel ansteht

  • Sie stoßen an die Sendelimits Ihres Hosters.
  • E-Mails landen im Spam, obwohl SPF, DKIM und DMARC alle grün sind.
  • Sie benötigen Zustellungsnachverfolgung und Bounce-Verarbeitung.
  • Die Reputation Ihrer geteilten IP zieht Sie nach unten und Sie können nichts dagegen tun.

Wer sich lohnt

Mailgun: ab 15 $/Monat für 10.000 E-Mails. Preise und Grenzen der kostenlosen Tarife können sich ändern; prüfen Sie vor der Auswahl die aktuellen Bedingungen jedes Anbieters. Starke API, nützliche Analysen. SMTP unter smtp.mailgun.org:587.

Postmark: ab 15 $/Monat für 10.000 E-Mails. Die beste Posteingangsrate, die wir gemessen haben. Klare Trennung zwischen transaktionalem und Marketing-Strom, was genau die richtige Architektur ist. SMTP unter smtp.postmarkapp.com:587, Server API Token sowohl als Benutzername als auch als Passwort.

Amazon SES: 0,10 $ pro 1.000 E-Mails. Bei großem Volumen um eine Größenordnung das Günstigste. Erzeugen Sie die SMTP-Zugangsdaten innerhalb der SES-Konsole (nicht Ihre AWS-IAM-Schlüssel). Neue Konten starten im Sandbox-Modus, bis Sie den Produktivzugang beantragen. Regionsspezifischer Endpunkt, z. B. email-smtp.eu-west-1.amazonaws.com:587.

SendGrid: Gratis-Tarif 100/Tag, kostenpflichtig ab 19,95 $/Monat. Der Benutzername ist buchstäblich die Zeichenkette apikey, das Passwort ist Ihr API-Schlüssel. SMTP unter smtp.sendgrid.net:587. Der Gratis-Tarif teilt sich die IPs mit allen anderen im Gratis-Tarif, daher ist die Zustellbarkeit dort schlecht, kalkulieren Sie den kostenpflichtigen Tarif ein.

Brevo: Gratis-Tarif 300/Tag, kostenpflichtig ab 9 $/Monat. Integrierter Newsletter und CRM, mit Sitz in der EU (praktisch für die DSGVO). SMTP unter smtp-relay.brevo.com:587. Hat ein eigenes PrestaShop-Plugin, falls Sie eines möchten.

Unsere Standardempfehlungen: Brevo, wenn Sie Newsletter am selben Ort haben möchten. Postmark, wenn Ihnen die transaktionale Posteingangsrate wichtig ist. Amazon SES bei hohem Volumen mit knappem Budget. Mailgun als sicherer Allrounder.

Wie Sie sich verbinden

Alle sprechen schlichtes SMTP, kein Modul erforderlich. Verifizieren Sie die Domain, veröffentlichen Sie deren SPF- und DKIM-Einträge, erzeugen Sie die SMTP-Zugangsdaten, fügen Sie sie in PrestaShop ein und testen Sie.

Selbst gehostete Mail

Sie können Ihren eigenen Mailserver betreiben. Wir tun das, wir betreiben Mailcow für einen Teil unserer Infrastruktur. Es gibt Ihnen vollständige Kontrolle, keine Gebühren pro E-Mail, keine Dritten, die Ihre Kundendaten lesen. Der Preis ist echte, fortlaufende Sysadmin-Arbeit, und die Reputation von null aufzubauen dauert Wochen.

Wann es sich lohnt

  • Datenschutz. Die E-Mail-Daten der Kunden verlassen nie Ihre Maschinen. Wirklich nützlich bei strenger Auslegung der DSGVO.
  • Volumen. Ein 40-$-VPS ist bei mehr als 100.000 Nachrichten im Monat nicht automatisch günstiger: Amazon SES berechnet 10 $ pro 100.000 E-Mails zuzüglich etwaiger Zusatzkosten.
  • Kontrolle. Ihre Regeln, Ihre Limits, keine Kontosperren wegen „Richtlinienverstößen", die ein Roboter entschieden hat.

Wann nicht

  • Kein Sysadmin-Hintergrund. Ein falsch konfigurierter Mailserver ist schlimmer als Shared Hosting. Wenigstens hat die IP des Hosters eine gewisse Reputation.
  • Frische IP. Eine brandneue sendende IP ist für Empfänger unsichtbar. Reputation baut sich über Wochen auf. Transaktionale Dienste geben Ihnen am ersten Tag etablierte Reputation in die Hand.
  • Kein PTR-Eintrag. Ohne Reverse DNS lehnen die meisten Empfänger Ihre Mail rundheraus ab.
  • Wartung. Patches, Zertifikate, Blocklist-Überwachung, Log-Durchsicht, fortlaufend, nicht optional.

Was wir wählen würden

Mailcow: Docker-basiert, Webmail, Antispam, Antivirus, Autodiscover alles inklusive. 4 GB+ RAM. Das ist, was wir betreiben.

Mail-in-a-Box: Komplettlösung auf einem dedizierten Ubuntu-Host. Einfacher, aber es übernimmt die ganze Maschine.

iRedMail: Klassisches Postfix + Dovecot. Am flexibelsten, am leichtgewichtigsten, am manuellsten.

Versenden Sie drei Monate lang Ihre eigene Geschäftspost über einen neuen selbst gehosteten Server, bevor Sie auch nur eine einzige Kundenbestellung darüber leiten. Bauen Sie die Reputation langsam auf. Halten Sie die ganze Zeit einen transaktionalen Dienst als Ausweichlösung angeschlossen.

Die E-Mail-Typen, die PrestaShop versendet

Muss den Posteingang sofort erreichen

  • Bestellbestätigung (order_conf). Diejenige, die Rückbuchungen und schlechte Bewertungen nach sich zieht, wenn sie nicht ankommt. Schützen Sie diese vor allen anderen.
  • Zahlungsbestätigung (payment). Kunden sind nervös, bis sie sie sehen.
  • Passwort-Zurücksetzung (password_query). Zeitkritisch. Zehn Minuten zu spät und der Kunde hat bereits aufgegeben.
  • Kontoerstellung (account). Der erste Eindruck Ihres Shops in seinem Posteingang.

Sollte zügig eintreffen

  • Versandbenachrichtigung (shipping). Hier steht die Sendungsnummer.
  • Aktualisierungen zum Bestellstatus (order_changed). In Bearbeitung, versandt, zugestellt.
  • Rechnung und Erstattung. Entscheidend im B2B, beruhigend für alle.
Halten Sie transaktionale Mail und Newsletter auf verschiedenen Domains. Bestell-E-Mails gehen von Ihrer Hauptdomain aus; Newsletter von einer Subdomain wie news@mail.yourstore.com. An dem Tag, an dem ein Newsletter Spam-Beschwerden auslöst, reißt er nicht Ihre Bestellbestätigungen mit sich.

Die Vorlagen liegen in mails/{iso_code}/. Jede hat eine HTML- und eine Klartext-Version. Behalten Sie beide. Eine fehlende .txt ist für sich genommen ein Spam-Signal, und wir haben erlebt, dass Übersetzungsmodule sie während der Synchronisierung stillschweigend löschen.

Hosting und E-Mail

Was Shared Hosting nicht beheben kann

  • Reputation der geteilten IP. Sie teilen sich eine IP mit Hunderten anderer Websites und können nicht steuern, was diese versenden.
  • Sende-Obergrenzen. Typischerweise 100–500/Stunde, 500–5.000/Tag. Ein Blitzverkauf frisst das in Minuten auf.
  • Keine dedizierte IP. Zu diesem Preisniveau nicht im Angebot.
  • Eingeschränkte DNS-Kontrolle. Günstige Hoster lassen Sie manchmal keinen eigenen DKIM-, TXT- oder PTR-Eintrag veröffentlichen.
  • Ausgehender Port 587 blockiert. Ja, das kommt noch vor, und es hindert Sie daran, sich mit irgendeinem transaktionalen Dienst zu verbinden.

Was Ihnen ein VPS bietet

  • Eine dedizierte IP mit einer Reputation, die Ihnen allein gehört
  • Keine künstlichen Sendelimits
  • PTR (Reverse DNS): unverzichtbar für ernsthafte Zustellbarkeit
  • Volle DNS-Kontrolle, jeder Mailserver, den Sie möchten

Warnsignale beim Hosting

  • „Unbegrenzte E-Mails". Gibt es beim Shared Hosting nicht. Werbetext, mehr nicht.
  • Keine DKIM-Unterstützung. Lassen Sie die Finger davon.
  • Port 587 blockiert. Sie können keinen transaktionalen Dienst nutzen.
  • IPs auf Blocklisten. Prüfen Sie es bei MXToolbox, bevor Sie sich anmelden, nicht danach.
Der beste Schachzug beim Shared Hosting besteht darin, die Mail des Hosters völlig zu ignorieren. Verbinden Sie einen transaktionalen Dienst über SMTP mit PrestaShop. Ihr Shop versendet über deren etablierte Reputation und das Problem der geteilten IP hört auf zu existieren.

Was sich in PrestaShop 8 und 9 geändert hat

PS 8: finaler Swift Mailer

Der letzte stabile Swift Mailer 6.x, mit besserer TLS-Aushandlung, nützlicheren Fehlerprotokollen in var/logs/ und ausgehenden Nachrichten-Metadaten, die in ps_mail festgehalten werden. CLI-Test von der Konsole aus: php bin/console prestashop:mail:test recipient@example.com.

PS 9: Symfony Mailer

Vollständiger Austausch des Transports. Wichtige Punkte:

  • Unterscheidet smtp:// (STARTTLS, Port 587) von smtps:// (implizites TLS, Port 465). Die beiden sind nicht mehr austauschbar.
  • Strenger, was die Übereinstimmung des Envelope-Absenders mit dem From-Header angeht, manche SMTP-Relays, die unter PS 8 funktionierten, nehmen keine Mail mehr an.
  • Strengere TLS-Zertifikatsvalidierung. Selbstsignierte Zertifikate, die sich unter PS 8 noch durchgemogelt haben, schlagen fehl.
  • Module, die Swift_Message oder Swift_SmtpTransport importierten, funktionieren unter PS 9 nicht mehr, bis der Entwickler sie aktualisiert.
# E-Mail in PS 9 über Umgebungsvariablen (fortgeschritten)
# .env.local: überschreibt die Einstellungen im Admin-Panel
MAILER_DSN=smtp://user:password@smtp.example.com:587
MAILER_DSN=smtp://user%40gmail.com:app-pass@smtp.gmail.com:587
# Sonderzeichen müssen URL-kodiert werden: @ = %40, : = %3A

Nur für die lokale Entwicklung, mit einem selbstsignierten Zertifikat:

# TLS-Überprüfung deaktivieren (NIEMALS in der Produktion)
MAILER_DSN=smtp://user:pass@host:587?verify_peer=0

Testen und Überwachen

Vor dem Start

mail-tester.com: Senden Sie eine Test-E-Mail an die Adresse, die Ihnen genannt wird, und erhalten Sie eine Bewertung von 10 mit zeilenweisen Hinweisen. Streben Sie 9+ an. Kostenlos für 3 Tests/Tag. Es prüft SPF, DKIM, DMARC, Blocklisten, HTML-Qualität, Header und Link-Erreichbarkeit.

MXToolbox: DNS-Diagnose. MX-Einträge, SPF-Gültigkeit und Lookup-Anzahl, DKIM-Auflösung, DMARC-Richtlinie, Blocklist-Status. Setzen Sie ein Lesezeichen.

MailSenpai DNS-Check: Geben Sie Ihre Domain ein, und Sie erhalten per E-Mail einen kostenlosen Bericht (auf Englisch) zu Ihren SPF-, DKIM-, DMARC- und MX-Einträgen, mit den genauen Werten zum Einfügen in Ihre DNS-Verwaltung.

Sobald Sie live sind

Google Postmaster Tools: Spam-Rate, IP-Reputation, Domain-Reputation, Authentifizierungserfolg, alles aus Gmails eigener Perspektive. Kostenlos, erfordert die Verifizierung der Domain.

Lesen Sie die Header. In Gmail: Nachricht öffnen → drei Punkte → „Original anzeigen". Sie wollen sehen:

SPF: PASS with IP 1.2.3.4
DKIM: PASS (signature verified)
DMARC: PASS

Der Rhythmus, dem wir folgen: wöchentlicher Blick in ps_mail auf Fehlschläge und ein kurzer Blick auf die DMARC-Berichte. Monatliche mail-tester-Prüfung und Blocklist-Durchsicht. DNS nach jeder Änderung erneut verifizieren. E-Mail nach jedem PrestaShop-Core-Update testen. Die Upgrade-Skripte haben uns mehr als einmal die app/config/parameters.php überschrieben.

Häufige Probleme und was zuerst zu prüfen ist

„Die Test-E-Mail funktioniert, aber Kunden bekommen keine Bestell-E-Mails"

  • Smarty-Fehler in der Vorlage. Eine defekte Variable in der Bestellvorlage bringt den Versand stillschweigend zum Erliegen. Prüfen Sie var/logs/.
  • Fehlende Sprachvorlage. Gibt es keine mails/{lang_iso}/order_conf.html für die Sprache des Kunden, sendet PrestaShop nichts.
  • SMTP-Zeitüberschreitung. Eine Bestellung mit 30 Zeilen samt Bildern kann lange genug zum Rendern brauchen, dass langsame SMTP-Server die Verbindung abbrechen.
  • Ablehnung der Absenderadresse. Manche Relays verweigern den Versand, sofern der From-Header nicht mit dem authentifizierten Benutzer übereinstimmt.

Ratenbegrenzung

Sie importieren 200 Bestellungen oder versenden einen Newsletter an tausend Kunden? Ihr SMTP-Server nimmt die erste Charge an und verweigert den Rest. Verteilen Sie die Sendungen zeitlich, prüfen Sie die Obergrenzen des Anbieters oder wechseln Sie zu einem transaktionalen Dienst, der für Sie in eine Warteschlange stellt.

Kodierungsprobleme (Sonderzeichen in PL, CZ, DE, FR)

  • Betreffzeile verstümmelt. Ihre Installation muss durchgehend UTF-8 sein. Betreffzeilen werden als RFC 2047 kodiert.
  • Nachrichtentext verstümmelt. Die E-Mail-Vorlagendateien müssen UTF-8 ohne BOM sein. Notepad unter Windows speichert gern als ANSI, verwenden Sie VS Code.
  • Datenbank-Diskrepanz. Die Tabellen sollten utf8mb4 sein. Prüfen Sie es mit SHOW CREATE TABLE ps_product_lang;

Mail nach einer Servermigration blockiert

  • SPF zeigt noch auf die alte IP
  • DKIM-Schlüsseldiskrepanz, weil der neue Host ein neues Schlüsselpaar geprägt hat
  • Die neue IP hat null Reputation: wärmen Sie sie über zwei Wochen schrittweise auf
  • Port 587 auf dem neuen Host blockiert
  • DNS-Propagierung: geben Sie ihr nach dem Ändern der Einträge 24–48 Stunden

Nachrichten aus dem Kontaktformular kommen nicht an

Manche Module setzen die E-Mail-Adresse des Kunden als From-Adresse des Kontaktformulars. Das fällt sofort durch SPF. Ihr Server ist nicht berechtigt, als customer@gmail.com zu senden. Der From-Header sollte immer die Domain Ihres Shops sein, mit dem Kunden im Reply-To. Wir haben das auf mehr Kontaktformular-Modulen behoben, als uns lieb ist.

Zustellbarkeits-Checkliste

Schritt 1: Fundament

  • ☐ PHP mail() abschalten und auf echtes SMTP umstellen
  • ☐ Ein dediziertes Sende-Postfach anlegen (z. B. orders@yourstore.com)
  • ☐ Testversand an Gmail und Outlook: beide müssen den Posteingang erreichen

Schritt 2: DNS-Authentifizierung

  • ☐ Einen SPF-Eintrag veröffentlichen: bei MXToolbox verifizieren, unter 10 Lookups
  • ☐ DKIM aktivieren und den öffentlichen Schlüssel veröffentlichen
  • ☐ Einen DMARC-Eintrag bei p=none mit rua-Berichterstattung hinzufügen
  • ☐ Eine zugestellte Nachricht öffnen und bestätigen, dass SPF, DKIM, DMARC alle PASS anzeigen

Schritt 3: Qualität

  • ☐ 9+ Punkte auf mail-tester.com erreichen
  • ☐ Sendende IP auf keiner Blocklist
  • ☐ Vorlagen für jede Sprache vorhanden, sowohl HTML als auch Klartext

Schritt 4: Test unter realen Bedingungen

  • ☐ Eine Testbestellung aufgeben: die Bestätigung erreicht den Posteingang in Sekunden
  • ☐ Sie durch jeden Bestellstatus führen: jede Status-E-Mail trifft ein
  • ☐ Passwort-Zurücksetzung, Kontoerstellung und Kontaktformular testen

Schritt 5: Überwachen

  • ☐ Bei Google Postmaster Tools registrieren
  • ☐ Die Verarbeitung der DMARC-Berichte einrichten
  • ☐ DMARC nach 2–4 Wochen auf p=quarantine setzen, dann auf p=reject
  • ☐ Monatliche Zustellbarkeitsprüfung im Kalender

Schritt 6: Fortgeschritten

  • ☐ Zu einem transaktionalen Dienst wechseln, sobald Sie an die Hosting-Limits stoßen
  • ☐ Transaktionales und Marketing auf getrennte Domains aufteilen
  • ☐ PTR-Eintrag gesetzt, falls Sie auf VPS/Dedicated sind
  • ☐ Bounce-Verarbeitung eingerichtet

Jede Schicht (SMTP, SPF, DKIM, DMARC, saubere Vorlagen, eine seriöse sendende IP) baut auf den vorherigen auf. Lassen Sie eine aus, und das gesamte Gefüge wird schwächer. Arbeiten Sie die Checkliste der Reihe nach durch, testen Sie nach jeder Änderung erneut, und Ihre Bestellbestätigungen erreichen den Posteingang, wo sie hingehören. Für umfassendere Diagnosen siehe unseren Leitfaden zur Fehlerbehebung.

Weiterführende Lektüre

Verwandte Module

Passende Fragen

Nach oben