Poradniki
Poradnik

Jak sprawić, żeby e-maile ze sklepu docierały

Dlaczego e-maile PrestaShop trafiają do spamu i jak rozwiązują to SMTP, SPF/DKIM/DMARC i usługi transakcyjne, wraz z ustawieniami poczty w PS 8/9.

Potwierdzenia zamówień trafiające do spamu: najczęstszy problem z e-mailami, o jakim słyszymy

Klient płaci. Dziennik poczty PrestaShop pokazuje „wysłano". E-mail z potwierdzeniem nigdy nie dociera, ląduje w zakładce Oferty albo przez sześć godzin siedzi w spamie. Klient wpada w panikę, otwiera reklamację obciążeniową, wystawia jednogwiazdkową opinię i pisze do wsparcia z pytaniem „czy pobraliście ode mnie pieniądze?". Obserwowaliśmy to na większej liczbie sklepów, niż jesteśmy w stanie zliczyć, i w 2026 roku jest to wciąż najczęstszy problem z pocztą w PrestaShop.

Rozwiązanie rzadko leży po stronie samego PrestaShop. O dostarczalności decyduje serwer odbierający pocztę (Gmail, Outlook, Yahoo), a jego decyzja zależy od tego, w jaki sposób przebiega uwierzytelnianie, jaką reputację ma wysyłający adres IP oraz czy DNS mówi prawdę o tym, kto ma prawo wysyłać w imieniu danej domeny. Zadaniem PrestaShop jest jedynie czyste przekazanie wiadomości dalej.

Funkcja PHP mail() to fikcja

Świeża instalacja PrestaShop wysyła pocztę za pomocą funkcji mail() w PHP. Jest to ustawienie domyślne i zarazem najgorsza opcja, jaką można sobie wyobrazić dla sklepu produkcyjnego:

  • Brak uwierzytelniania. Wiadomość przychodzi bez żadnego dowodu, że została autoryzowana. Gmail i Outlook traktują nieuwierzytelnioną pocztę jako winną, dopóki nie udowodni się jej niewinności.
  • Wspólny adres IP, wspólna reputacja. Na hostingu współdzielonym poczta wychodzi z tego samego adresu IP, co 200 innych witryn. Wystarczy, że jedna z nich rozsyła spam, a cierpią wszystkie.
  • Brak podpisu DKIM. Funkcja mail() niczego nie podpisuje kryptograficznie. Odbiorca nie ma nic, co mógłby zweryfikować.
  • Minimalny zestaw nagłówków. Filtry antyspamowe oceniają to jako podejrzane, zanim w ogóle spojrzą na treść.
Jeśli sklep wciąż korzysta z mail(), przejście na prawdziwy SMTP jest tą jedną zmianą, która rozwiąże więcej problemów z dostarczalnością niż wszystkie pozostałe kroki na tej stronie razem wzięte. Należy zrobić to w pierwszej kolejności.

Co tak naprawdę powoduje oznaczenie wiadomości jako spam

  • Niezgodność adresu nadawcy. Wysyłanie z noreply@yourstore.com, podczas gdy DNS nie zawiera rekordu SPF zezwalającego adresowi IP serwera na takie działanie.
  • Szablony przeładowane obrazami. Domyślne szablony PrestaShop są bogate w grafikę. Zły stosunek obrazu do tekstu sam w sobie jest sygnałem spamu.
  • Brak części tekstowej. PrestaShop domyślnie wysyła wiadomości typu multipart, jednak własne szablony i moduły tłumaczeń potrafią po cichu uszkodzić alternatywną wersję tekstową.
  • Niedziałające odnośniki. Filtry antyspamowe rozwiązują adresy URL zawarte w wiadomości. Jeśli witryna znajduje się w trybie konserwacji, ma uszkodzony łańcuch certyfikatów SSL lub zwraca błąd 500, e-mail zostaje oznaczony.
  • Bałagan w kodowaniu. Sklepy z polskimi, czeskimi, niemieckimi czy francuskimi znakami diakrytycznymi generują tzw. mojibake w chwili, gdy jakikolwiek element łańcucha przestaje być w UTF-8.

Konfiguracja poczty PrestaShop w zależności od wersji

Konfiguracja poczty w panelu administracyjnym PrestaShop 8.

Wybór pomiędzy sendmail a SMTP, format e-maili, przełącznik dziennika oraz podpisywanie DKIM. Jeśli potwierdzenia zamówień trafiają do spamu, to jest miejsce, od którego należy zacząć.

Strona ustawień poczty w panelu administracyjnym PrestaShop 8 z wyborem sendmail kontra SMTP, konfiguracją DKIM oraz rejestrowaniem e-maili

Strona ustawień pozostała mniej więcej w tym samym miejscu. To biblioteka pod spodem zmieniła się całkowicie w PS 9.

PrestaShop 1.6 i 1.7

Parametry zaawansowane → E-mail. Należy wybrać „Ustaw własne parametry SMTP" oraz wprowadzić serwer, port, szyfrowanie, nazwę użytkownika i hasło. PS 1.6 korzysta z własnej obsługi SMTP w PHP; PS 1.7 wprowadził Swift Mailer. Dostępne opcje szyfrowania:

  • TLS (port 587): Nowoczesny standard. STARTTLS, niemal wszędzie właściwy wybór.
  • SSL (port 465): Starszy, niejawny TLS. Niektóre wiekowe hostingi nadal go wymagają.
  • Brak (port 25): Bez szyfrowania. Tego należy unikać.

PrestaShop 8.x

Ten sam ekran, ten sam interfejs. PS 8 dostarcza ostatnią wersję Swift Mailer z lepszym raportowaniem błędów, gdy SMTP zawiedzie, w var/logs/ faktycznie pojawia się użyteczny wpis zamiast cichego porzucenia wiadomości.

PrestaShop 9: Symfony Mailer

PS 9 wycofuje Swift Mailer (od lat nie jest już rozwijany przez twórców) i zastępuje go biblioteką Symfony Mailer. Interfejs administracyjny wygląda identycznie, lecz wszystko pod spodem uległo zmianie:

  • Konfiguracja oparta na DSN. Wewnętrznie transport ma postać adresu URI: smtp://user:password@server:port.
  • Automatyczne wykrywanie TLS. Port 587 sam wynegocjuje STARTTLS. Lista rozwijana „szyfrowanie" zachowuje się czasem inaczej po aktualizacji z 8 → 9. Warto przeprowadzić ponowny test.
  • Surowsza walidacja. Symfony Mailer dba o zgodność nadawcy koperty z nagłówkiem From oraz prawidłowo weryfikuje certyfikaty TLS.
  • Awarie modułów. Każdy moduł importujący Swift_Message lub Swift_SmtpTransport przestaje działać w PS 9, dopóki nie zostanie zaktualizowany.
# Przykłady wewnętrznego DSN w PS 9 (konfigurowane przez panel administracyjny)
smtp://user:password@mail.example.com:587      # STARTTLS
smtps://user:password@mail.example.com:465     # niejawny TLS
smtp://your%40gmail.com:app-pass@smtp.gmail.com:587  # Gmail
native://default                                # PHP mail() (niezalecane)
Po każdej aktualizacji z 8 → 9 należy zawsze ponownie przetestować pocztę. Widzieliśmy, jak certyfikaty samopodpisane, niestandardowe porty oraz luźno zaimplementowane serwery SMTP przestawały działać w chwili, gdy przejmował je Symfony Mailer.

Przycisk „wyślij e-mail testowy"

Jest w każdej wersji. Bywa użyteczny, lecz potwierdza wyłącznie jedno: że sklep potrafi otworzyć połączenie SMTP. Nie potwierdza, że wiadomość dotarła do skrzynki odbiorczej. Warto wysyłać prawdziwe zamówienia testowe na adres Gmail, adres Outlook oraz adres we własnej domenie, te trzy obejmują mniej więcej 90% tego, z czego korzystają klienci.

Uwierzytelnianie domeny: SPF, DKIM, DMARC

SPF, DKIM i DMARC to trzy rekordy DNS, które wspólnie dowodzą, że poczta jest prawdziwa. Gmail i Yahoo uczyniły SPF oraz DKIM obowiązkowymi dla nadawców masowych w lutym 2024 roku. My traktujemy je jako obowiązkowe dla każdego nadawcy, bez wyjątku.

SPF (Sender Policy Framework)

Jeden rekord TXT w domenie, który wskazuje adresy IP oraz usługi mające prawo wysyłać w jej imieniu.

# Podstawowy: zezwala hostingowi + 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

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

Gdzie sprawy idą nie tak:

  • Dwa rekordy SPF. Dla danej domeny prawidłowy jest tylko jeden rekord TXT typu SPF. Dwa rekordy wzajemnie się znoszą. Należy połączyć usługi w jeden rekord z wieloma dyrektywami include:.
  • Zbyt wiele zapytań. SPF dopuszcza łącznie 10 zapytań DNS. Każdy include: się liczy, a zagnieżdżone wpisy include również. Przed publikacją warto przepuścić swój rekord przez walidator.
  • +all zamiast ~all. +all mówi całemu światu, że każdy może wysyłać w imieniu domeny. Co jest dokładnym przeciwieństwem celu. Należy zacząć od ~all (softfail), a po nabraniu pewności zaostrzyć do -all.
  • Subdomeny nie dziedziczą. SPF dla shop.example.com potrzebuje własnego rekordu. Domena nadrzędna go nie obejmuje.

DKIM

DKIM kryptograficznie podpisuje każdą wychodzącą wiadomość. PrestaShop 1.6 i 1.7 nie podpisują DKIM: robi to przekaźnik SMTP, dostawca hostingu lub usługa transakcyjna. PrestaShop 8 i 9 potrafią podpisywać samodzielnie (Parametry zaawansowane → E-mail, sekcja DKIM) własną parą kluczy; przy wysyłce przez przekaźnik lub usługę transakcyjną zwykle prościej zostawić podpisywanie tej usłudze. Klucz publiczny należy opublikować w DNS, a podpis powstaje przy użyciu pasującego klucza prywatnego.

  • Hosting współdzielony (cPanel/Plesk): Zwykle jedno kliknięcie w cPanel → Email Deliverability.
  • Gmail / Google Workspace: Konsola administracyjna → Gmail → Uwierzytelnij e-mail. Google przekazuje gotowy rekord TXT.
  • Usługi transakcyjne: Ich kreator weryfikacji domeny dokładnie wskazuje, co należy opublikować.
# Przykładowy rekord TXT dla DKIM
# Nazwa: default._domainkey.yourstore.com (selektor zależy od dostawcy)
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

DMARC

DMARC spina SPF i DKIM oraz mówi serwerowi odbierającemu, co zrobić, gdy uwierzytelnianie zawiedzie.

# Etap 1: tylko monitorowanie
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourstore.com;

# Etap 2: kwarantanna dla niepowodzeń
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourstore.com;

# Etap 3: odrzucanie niepowodzeń (maksymalna ochrona)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourstore.com;

Opublikowany rekord można sprawdzić w darmowym narzędziu DMARC od Palisade: wystarczy wpisać domenę, a narzędzie odczyta rekord i wskaże błędy składni oraz polityki, bez rejestracji (strona po angielsku).

Adres rua odbiera zbiorcze raporty XML, codzienną listę tych, którzy próbowali wysyłać pocztę w imieniu domeny. My przepuszczamy swoje przez darmowe monitorowanie DMARC od Postmark, ponieważ czytanie surowego XML to nie jest sposób, w jaki ktokolwiek powinien spędzać poniedziałkowy poranek.

DMARC należy wdrażać etapami. Dwa do czterech tygodni przy p=none, czytając raporty i identyfikując prawdziwych nadawców, którzy nie przechodzą weryfikacji. Następnie zaostrzenie do p=quarantine na kolejne dwa do czterech tygodni. Dopiero potem przejście na p=reject. Skok od razu na reject pierwszego dnia zablokuje pocztę, o której istnieniu nawet się nie wiedziało, zwykle jakiś CRM lub księgowy wystawiający faktury w imieniu firmy.

SMTP na hostingu współdzielonym

Większość sklepów PrestaShop działa na hostingu współdzielonym. Należy utworzyć dedykowaną skrzynkę (np. orders@yourstore.com) i użyć tych danych logowania w PrestaShop, nigdy własnej, prywatnej skrzynki.

Ustawienia dostawców

# Standardowy cPanel
Serwer: mail.yourstore.com | Port: 587 | Szyfrowanie: TLS

# OVH
Serwer: ssl0.ovh.net | Port: 587 | Szyfrowanie: TLS

# Hostinger
Serwer: smtp.hostinger.com | Port: 587 | Szyfrowanie: TLS

# SiteGround
Serwer: yourstore.com | Port: 465 | Szyfrowanie: SSL

# Bluehost
Serwer: mail.yourstore.com | Port: 465 | Szyfrowanie: SSL

Gmail SMTP

Pola konfiguracji SMTP w PrestaShop 8.

Po wybraniu „Ustaw własne parametry SMTP" pojawiają się te pola: serwer, port, nazwa użytkownika, hasło, szyfrowanie. To tutaj wskazuje się PrestaShop adres Gmail, SendGrid, Mailgun lub własnego serwera pocztowego.

Konfiguracja SMTP w PrestaShop 8 z polami serwera, portu, nazwy użytkownika, hasła oraz szyfrowania

To właśnie z tego korzystamy sami w przypadku mypresta.rocks, Gmail SMTP z hasłem aplikacji (Konto Google → Bezpieczeństwo → Weryfikacja dwuetapowa → Hasła do aplikacji). Tanio, niezawodnie, rozsądnie dla sklepu o niskim wolumenie.

Serwer: smtp.gmail.com | Port: 587 | Szyfrowanie: TLS
Nazwa użytkownika: your@gmail.com | Hasło: (16-znakowe hasło aplikacji)

Limity: darmowy Gmail 500/dzień, Google Workspace 2000/dzień. Zbyt szybki natłok i Google tymczasowo ograniczy przepustowość.

Gmail SMTP sprawdza się dobrze w sklepach przyjmujących mniej więcej do 30 zamówień dziennie. Powyżej tego progu zaczyna się trafiać w limit, a klienci czekają na potwierdzenie nawet 24 godziny. To moment, by przejść na prawdziwą usługę transakcyjną.

Microsoft 365 SMTP

Serwer: smtp.office365.com | Port: 587 | Szyfrowanie: TLS
Nazwa użytkownika: your@yourstore.com | Hasło: hasło konta lub aplikacji

Limit: 10 000 odbiorców dziennie, 30 wiadomości na minutę. Microsoft coraz mocniej nalega na OAuth zamiast podstawowego uwierzytelniania SMTP. Przed uruchomieniem produkcyjnym warto sprawdzić zasady swojej dzierżawy (tenant).

Transakcyjne usługi pocztowe

Gdy SMTP hostingu przestaje wystarczać, usługi transakcyjne dają dedykowaną infrastrukturę o wysokiej reputacji, podpisywanie DKIM realizowane za użytkownika, obsługę odbić oraz panel pokazujący, co naprawdę stało się z każdą wiadomością.

Kiedy warto przejść na taką usługę

  • Osiąga się limity wysyłki narzucone przez hosting.
  • Poczta ląduje w spamie, mimo że SPF, DKIM i DMARC świecą na zielono.
  • Potrzebne jest śledzenie dostarczalności oraz obsługa odbić.
  • Reputacja współdzielonego adresu IP ciągnie w dół, a nie da się z tym nic zrobić.

Z czego warto korzystać

Mailgun: od 15 USD/mies. za 10 tys. e-maili. Ceny i limity bezpłatnych planów mogą się zmieniać; przed wyborem należy sprawdzić aktualne warunki każdego dostawcy. Mocne API, użyteczna analityka. SMTP pod adresem smtp.mailgun.org:587.

Postmark: od 15 USD/mies. za 10 tys. e-maili. Najlepszy wskaźnik trafiania do skrzynki, jaki zmierzyliśmy. Twardy rozdział między strumieniem transakcyjnym a marketingowym, co jest dokładnie właściwą architekturą. SMTP pod adresem smtp.postmarkapp.com:587, Server API Token zarówno jako nazwa użytkownika, jak i hasło.

Amazon SES: 0,10 USD za 1000 e-maili. Najtańsza usługa przy dużej skali, o cały rząd wielkości. Dane logowania SMTP generuje się w konsoli SES (a nie klucze AWS IAM). Nowe konta startują w trybie sandbox, dopóki nie wystąpi się o dostęp produkcyjny. Punkt końcowy zależy od regionu, np. email-smtp.eu-west-1.amazonaws.com:587.

SendGrid: darmowy poziom 100/dzień, płatny od 19,95 USD/mies. Nazwą użytkownika jest dosłownie ciąg apikey, a hasłem klucz API. SMTP pod adresem smtp.sendgrid.net:587. Darmowy poziom dzieli adresy IP ze wszystkimi innymi użytkownikami darmowego poziomu, więc dostarczalność jest tam słaba. Warto przewidzieć budżet na wariant płatny.

Brevo: darmowy poziom 300/dzień, płatny od 9 USD/mies. Wbudowany newsletter i CRM, z siedzibą w UE (przydatne pod kątem RODO). SMTP pod adresem smtp-relay.brevo.com:587. Ma własną wtyczkę do PrestaShop, gdyby ktoś jej potrzebował.

Nasze domyślne wybory: Brevo, gdy newslettery mają być w tym samym miejscu. Postmark, gdy liczy się wskaźnik trafiania poczty transakcyjnej do skrzynki. Amazon SES przy dużym wolumenie i ograniczonym budżecie. Mailgun jako bezpieczny uniwersalny wybór.

Jak nawiązać połączenie

Wszystkie mówią zwykłym SMTP, bez potrzeby instalowania modułu. Należy zweryfikować domenę, opublikować ich rekordy SPF i DKIM, wygenerować dane logowania SMTP, wkleić je do PrestaShop i przetestować.

Poczta hostowana samodzielnie

Można prowadzić własny serwer pocztowy. My to robimy, część naszej infrastruktury opiera się na Mailcow. Daje pełną kontrolę, brak opłat za pojedyncze wiadomości i żadnej osoby trzeciej czytającej dane klientów. Ceną jest realna, ciągła praca administracyjna, a wyjście z zerową reputacją zajmuje tygodnie.

Kiedy się to opłaca

  • Prywatność. Dane pocztowe klientów nigdy nie opuszczają własnych serwerów. Naprawdę przydatne przy rygorystycznej interpretacji RODO.
  • Wolumen. Powyżej 100 000 wiadomości miesięcznie VPS za 40 USD nie jest automatycznie tańszy: Amazon SES pobiera 10 USD za 100 000 e-maili, przed doliczeniem dodatkowych opłat.
  • Kontrola. Własne zasady, własne limity, żadnych zawieszeń konta za „naruszenie zasad", o którym zdecydował robot.

Kiedy się nie opłaca

  • Brak doświadczenia administracyjnego. Źle skonfigurowany serwer pocztowy jest gorszy niż hosting współdzielony. Tam przynajmniej adres IP hostingu ma jakąś reputację.
  • Świeży adres IP. Zupełnie nowy wysyłający adres IP jest niewidoczny dla odbiorców. Reputacja buduje się tygodniami. Usługi transakcyjne dają ugruntowaną reputację już pierwszego dnia.
  • Brak rekordu PTR. Bez odwrotnego DNS większość odbiorców odrzuca pocztę od razu.
  • Utrzymanie. Łatki, certyfikaty, monitorowanie list blokujących, przegląd dzienników, to praca ciągła, a nie opcjonalna.

Co byśmy wybrali

Mailcow: Oparty na Dockerze, z webmailem, ochroną antyspamową, antywirusem i autodiscover w komplecie. Wymaga 4 GB+ RAM. To właśnie z tego korzystamy.

Mail-in-a-Box: Rozwiązanie kompleksowe na dedykowanym hoście z Ubuntu. Prostsze, lecz przejmuje całą maszynę.

iRedMail: Klasyczne Postfix + Dovecot. Najbardziej elastyczne, najlżejsze, najbardziej ręczne.

Przez trzy miesiące warto wysyłać przez nowy, samodzielnie hostowany serwer własną firmową pocztę, zanim skieruje się przez niego choć jedno zamówienie klienta. Reputację trzeba budować powoli. Przez cały ten czas warto utrzymywać podłączoną usługę transakcyjną jako rozwiązanie awaryjne.

Rodzaje e-maili wysyłanych przez PrestaShop

Muszą natychmiast trafić do skrzynki odbiorczej

  • Potwierdzenie zamówienia (order_conf). To ten e-mail, który napędza reklamacje obciążeniowe i złe opinie, gdy nie dociera. Należy chronić go ponad wszystkie inne.
  • Potwierdzenie płatności (payment). Klienci są zdenerwowani, dopóki go nie zobaczą.
  • Reset hasła (password_query). Wrażliwy na czas. Dziesięć minut spóźnienia i klient już dawno zrezygnował.
  • Utworzenie konta (account). Pierwsze wrażenie, jakie sklep robi w skrzynce klienta.

Powinny dotrzeć bez zwłoki

  • Powiadomienie o wysyłce (shipping). Numer śledzenia przesyłki znajduje się właśnie tutaj.
  • Aktualizacje statusu zamówienia (order_changed). Przetwarzanie, wysłano, dostarczono.
  • Faktura i zwrot. Kluczowe dla B2B, uspokajające dla każdego.
Pocztę transakcyjną i newslettery należy trzymać na różnych domenach. E-maile o zamówieniach wychodzą z głównej domeny; newslettery z subdomeny w rodzaju news@mail.yourstore.com. W dniu, w którym newsletter wywoła skargi na spam, nie pociągnie za sobą potwierdzeń zamówień.

Szablony znajdują się w mails/{iso_code}/. Każdy ma wersję HTML oraz tekstową. Należy zachować obie. Brakujący plik .txt sam w sobie jest sygnałem spamu, a widzieliśmy moduły tłumaczeń po cichu usuwające je podczas synchronizacji.

Hosting a poczta

Czego hosting współdzielony nie naprawi

  • Reputacja współdzielonego adresu IP. Adres IP dzieli się z setkami innych witryn i nie ma się wpływu na to, co one wysyłają.
  • Limity wysyłki. Zwykle 100–500/godz., 500–5000/dzień. Wyprzedaż błyskawiczna pochłania to w kilka minut.
  • Brak dedykowanego adresu IP. Niedostępny w tym przedziale cenowym.
  • Ograniczona kontrola nad DNS. Tanie hostingi czasem nie pozwalają opublikować własnego rekordu DKIM, TXT czy PTR.
  • Zablokowany port wychodzący 587. Tak, to wciąż się zdarza, i uniemożliwia połączenie z jakąkolwiek usługą transakcyjną.

Co daje VPS

  • Dedykowany adres IP z reputacją należącą wyłącznie do danej instalacji
  • Brak sztucznych limitów wysyłki
  • PTR (odwrotny DNS): nie do pominięcia przy poważnej dostarczalności
  • Pełna kontrola nad DNS, dowolny serwer pocztowy

Hostingowe sygnały ostrzegawcze

  • „Nieograniczona poczta". Nie istnieje na hostingu współdzielonym. Hasło marketingowe, nic więcej.
  • Brak obsługi DKIM. Lepiej odejść.
  • Zablokowany port 587. Nie da się skorzystać z żadnej usługi transakcyjnej.
  • Adresy IP na listach blokujących. Należy sprawdzić w MXToolbox przed rejestracją, a nie po.
Najlepszym posunięciem na hostingu współdzielonym jest całkowite zignorowanie poczty hostingu. Należy podłączyć usługę transakcyjną do PrestaShop przez SMTP. Sklep wysyła wtedy przez jej ugruntowaną reputację, a problem współdzielonego adresu IP przestaje istnieć.

Co zmieniło się w PrestaShop 8 i 9

PS 8: ostatni Swift Mailer

Ostatni stabilny Swift Mailer 6.x, z lepszą negocjacją TLS, użyteczniejszymi dziennikami błędów w var/logs/ oraz metadanymi wychodzących wiadomości zapisywanymi w ps_mail. Test z poziomu konsoli CLI: php bin/console prestashop:mail:test recipient@example.com.

PS 9: Symfony Mailer

Pełna wymiana transportu. Najważniejsze rzeczy, które trzeba wiedzieć:

  • Rozróżnia smtp:// (STARTTLS, port 587) od smtps:// (niejawny TLS, port 465). Te dwa nie są już wymienne.
  • Bardziej rygorystyczny co do zgodności nadawcy koperty z nagłówkiem From, niektóre przekaźniki SMTP, które działały na PS 8, przestają przyjmować pocztę.
  • Surowsza walidacja certyfikatów TLS. Certyfikaty samopodpisane, które ledwo działały na PS 8, zawiodą.
  • Moduły importujące Swift_Message lub Swift_SmtpTransport psują się na PS 9, dopóki ich autor nie wprowadzi aktualizacji.
# Poczta w PS 9 przez zmienne środowiskowe (zaawansowane)
# .env.local: nadpisuje ustawienia panelu administracyjnego
MAILER_DSN=smtp://user:password@smtp.example.com:587
MAILER_DSN=smtp://user%40gmail.com:app-pass@smtp.gmail.com:587
# Znaki specjalne muszą być zakodowane w URL: @ = %40, : = %3A

Wyłącznie do lokalnego programowania, z certyfikatem samopodpisanym:

# Wyłączenie weryfikacji TLS (NIGDY na produkcji)
MAILER_DSN=smtp://user:pass@host:587?verify_peer=0

Testowanie i monitorowanie

Przed uruchomieniem

mail-tester.com: wystarczy wysłać jeden testowy e-mail na adres, który podają, aby otrzymać ocenę w skali do 10 wraz z listą problemów punkt po punkcie. Należy dążyć do 9+. Darmowe 3 testy dziennie. Sprawdza SPF, DKIM, DMARC, listy blokujące, jakość HTML, nagłówki oraz osiągalność odnośników.

MXToolbox: diagnostyka DNS. Rekordy MX, poprawność SPF i liczba zapytań, rozwiązywanie DKIM, polityka DMARC, status na listach blokujących. Warto dodać do zakładek.

MailSenpai DNS check: wpisz swoją domenę, a otrzymasz e-mailem bezpłatny raport (po angielsku) o rekordach SPF, DKIM, DMARC i MX, z dokładnymi wartościami do wklejenia w panelu DNS.

Gdy sklep już działa

Google Postmaster Tools: wskaźnik spamu, reputacja adresu IP, reputacja domeny, skuteczność uwierzytelniania: wszystko z perspektywy samego Gmaila. Darmowe, wymaga zweryfikowania domeny.

Należy czytać nagłówki. W Gmailu: otworzyć wiadomość → trzy kropki → „Pokaż oryginał". Powinno być widoczne:

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

Rytm, którego się trzymamy: cotygodniowy przegląd ps_mail pod kątem niepowodzeń oraz rzut oka na raporty DMARC. Comiesięczne sprawdzenie w mail-tester i przegląd list blokujących. Ponowna weryfikacja DNS po każdej zmianie. Test poczty po każdej aktualizacji rdzenia PrestaShop, skrypty aktualizacyjne nieraz przepisały nam app/config/parameters.php.

Typowe problemy i od czego zacząć analizę

„E-mail testowy działa, ale klienci nie dostają wiadomości o zamówieniach"

  • Błąd Smarty w szablonie. Uszkodzona zmienna w szablonie zamówienia po cichu blokuje wysyłkę. Należy sprawdzić var/logs/.
  • Brak szablonu językowego. Brak pliku mails/{lang_iso}/order_conf.html dla języka klienta i PrestaShop nie wysyła nic.
  • Przekroczenie limitu czasu SMTP. Zamówienie z 30 pozycjami i obrazami może renderować się na tyle długo, że wolne serwery SMTP zrywają połączenie.
  • Odrzucenie adresu nadawcy. Niektóre przekaźniki odmawiają wysyłki, dopóki From nie pokrywa się z uwierzytelnionym użytkownikiem.

Ograniczanie przepustowości

Import 200 zamówień albo wysyłka newslettera do tysiąca klientów? Serwer SMTP przyjmuje pierwszą partię i odrzuca resztę. Należy rozłożyć wysyłki w czasie, sprawdzić limity dostawcy lub przejść na usługę transakcyjną, która kolejkuje pocztę za użytkownika.

Problemy z kodowaniem (polskie, czeskie, niemieckie, francuskie znaki diakrytyczne)

  • Zniekształcony temat wiadomości. Cała instalacja musi być w UTF-8 od początku do końca. Tematy są kodowane jako RFC 2047.
  • Zniekształcona treść. Pliki szablonów e-mail muszą być w UTF-8 bez BOM. Notepad w Windowsie lubi zapisywać w ANSI. Warto używać VS Code.
  • Niezgodność bazy danych. Tabele powinny być w utf8mb4. Należy to potwierdzić poleceniem SHOW CREATE TABLE ps_product_lang;

Poczta zablokowana po migracji serwera

  • SPF wciąż wskazuje na stary adres IP
  • Niezgodność klucza DKIM, ponieważ nowy hosting wygenerował nową parę kluczy
  • Nowy adres IP ma zerową reputację: należy go rozgrzewać stopniowo przez dwa tygodnie
  • Zablokowany port 587 na nowym hostingu
  • Propagacja DNS: po zmianie rekordów należy dać jej 24–48 godzin

Wiadomości z formularza kontaktowego nie docierają

Niektóre moduły ustawiają adres e-mail klienta jako adres From w formularzu kontaktowym. To natychmiast nie przechodzi SPF. Serwer nie ma prawa wysyłać w imieniu customer@gmail.com. Adres From powinien zawsze należeć do domeny sklepu, z klientem umieszczonym w Reply-To. Naprawialiśmy to na większej liczbie modułów formularza kontaktowego, niż chcielibyśmy zliczać.

Lista kontrolna dostarczalności

Krok 1: fundament

  • ☐ Wyłączyć PHP mail() i przejść na prawdziwy SMTP
  • ☐ Utworzyć dedykowaną skrzynkę nadawczą (np. orders@yourstore.com)
  • ☐ Wysłać test na Gmail i Outlook: oba muszą trafić do skrzynki odbiorczej

Krok 2: uwierzytelnianie DNS

  • ☐ Opublikować rekord SPF: zweryfikować go w MXToolbox, poniżej 10 zapytań
  • ☐ Włączyć DKIM i opublikować klucz publiczny
  • ☐ Dodać rekord DMARC w trybie p=none z raportowaniem rua
  • ☐ Otworzyć dostarczoną wiadomość i potwierdzić, że SPF, DKIM oraz DMARC pokazują PASS

Krok 3: jakość

  • ☐ Uzyskać 9+ w mail-tester.com
  • ☐ Wysyłający adres IP nie znajduje się na żadnej liście blokującej
  • ☐ Szablony istnieją dla każdego języka, zarówno w HTML, jak i w postaci tekstowej

Krok 4: test w realnych warunkach

  • ☐ Złożyć zamówienie testowe: potwierdzenie trafia do skrzynki w kilka sekund
  • ☐ Przeprowadzić je przez każdy status zamówienia, każdy e-mail o statusie dociera
  • ☐ Przetestować reset hasła, utworzenie konta, formularz kontaktowy

Krok 5: monitorowanie

  • ☐ Zarejestrować się w Google Postmaster Tools
  • ☐ Skonfigurować przetwarzanie raportów DMARC
  • ☐ Przejść z DMARC na p=quarantine po 2–4 tygodniach, a następnie na p=reject
  • ☐ Comiesięczne sprawdzenie dostarczalności w kalendarzu

Krok 6: zaawansowane

  • ☐ Przejść na usługę transakcyjną po osiągnięciu limitów hostingu
  • ☐ Rozdzielić pocztę transakcyjną i marketingową na osobne domeny
  • ☐ Ustawić rekord PTR, jeśli działa się na VPS/serwerze dedykowanym
  • ☐ Podłączyć obsługę odbić

Każda warstwa (SMTP, SPF, DKIM, DMARC, czyste szablony, renomowany wysyłający adres IP) opiera się na poprzednich. Wystarczy pominąć jedną, a cała konstrukcja słabnie. Należy przejść przez listę kontrolną po kolei, po każdej zmianie wykonać ponowny test, a potwierdzenia zamówień będą docierać do skrzynki odbiorczej, gdzie ich miejsce. Po szerszą diagnostykę warto sięgnąć do naszego przewodnika rozwiązywania problemów.

Powiązane lektury

Powiązane moduły

Powiązane pytania

Do góry