Dostarczalność email PrestaShop: SMTP, SPF i DKIM

Dlaczego e-maile z PrestaShop trafiają do spamu

Twój klient składa zamówienie. E-mail z potwierdzeniem nigdy nie dociera — albo ląduje w spamie. Klient kontaktuje się z Tobą, zdezorientowany. Sprawdzasz PrestaShop: e-mail został „wysłany”. Doreczalność e-maili nie polega na tym, czy PrestaShop wysyła wiadomość — chodzi o to, czy serwer pocztowy odbiorcy ją akceptuje i umieszcza w skrzynce odbiorczej.

PHP mail() — domyślna opcja, której nikt nie powinien używać

Świeża instalacja PrestaShop używa wbudowanej funkcji PHP mail(). To najgorsza opcja dla sklepu produkcyjnego:

Brak uwierzytelnienia: E-mail jest wysyłany bez żadnego dowodu, że go autoryzowałeś. Gmail, Outlook i Yahoo traktują nieuwierzytelnione wiadomości jako podejrzane.
Współdzielona reputacja IP: Na hostingu współdzielonym Twoje e-maile wychodzą z tego samego IP co każda inna strona. Jeśli którakolwiek wysyła spam, Twoje e-maile są karane.
Brak podpisywania DKIM: PHP mail() nie podpisuje wiadomości kryptograficznie.
Brakujące nagłówki: Minimalne nagłówki powodują, że filtry antyspamowe natychmiast oznaczają wiadomość.

Jeśli Twój sklep używa teraz PHP mail(), przełącz się na SMTP zanim zrobisz cokolwiek innego. Ta jedna zmiana naprawia więcej problemów z doręczalnością niż wszystkie inne kroki razem wzięte.

Typowe wyzwalacze spamu

Niezgodność adresu nadawcy: Wysyłasz z noreply@yourstore.com, ale Twój serwer nie ma rekordu SPF, który to umożliwia.
Szablony ciężkie od HTML: Szablony PrestaShop są bogate w obrazy. Wysoki stosunek obrazów do tekstu wyzwala filtry.
Brakująca alternatywa tekstowa: PS wysyła obie wersje, ale niestandardowe szablony lub moduły czasem psują część tekstową.
Uszkodzone linki: Filtry antyspamowe podążają za linkami. Jeśli URL Twojego sklepu jest nieosiągalny (błąd SSL, tryb konserwacji), e-mail zostaje oznaczony.
Problemy z kodowaniem: Sklepy używające polskich, czeskich lub innych znaków diakrytycznych generują zniekształcone znaki, gdy kodowanie jest nieprawidłowe.

Konfiguracja e-maili w PrestaShop

Ustawienia e-mail zostały przeniesione, a podstawowa biblioteka zmieniła się znacząco w wersji 9.

PrestaShop 1.6 i 1.7

Przejdź do Zaawansowane → E-mail. Wybierz „Ustaw własne parametry SMTP” i wypełnij serwer, port, szyfrowanie, nazwę użytkownika i hasło. PS 1.6 używa wbudowanej obsługi SMTP w PHP; PS 1.7 wprowadził Swift Mailer dla bardziej niezawodnych połączeń. Opcje szyfrowania:

TLS (port 587): Współczesny standard używający STARTTLS. To jest to, czego potrzebujesz.
SSL (port 465): Starsze niejawne TLS. Niektórzy starsi dostawcy tego wymagają.
Brak (port 25): Nieszyfrowane. Nigdy tego nie używaj.

PrestaShop 8.x

Ta sama lokalizacja, ten sam interfejs. PS 8 używa ostatecznej wersji Swift Mailer z ulepszonym raportowaniem błędów. Błędy SMTP są logowane z większą ilością kontekstu w var/logs/.

PrestaShop 9.x — Symfony Mailer

PS 9 zastępuje przestarzały Swift Mailer bibliotekami Symfony Mailer. Interfejs administracyjny wygląda podobnie, ale warstwa transportowa jest zupełnie inna:

Format DSN: Wewnętrznie używa smtp://user:password@server:port.
Obsługa TLS: Automatycznie wykrywa STARTTLS na porcie 587. Lista rozwijana „szyfrowanie” może zachowywać się inaczej po aktualizacji z PS 8.
Bardziej rygorystyczna walidacja: Symfony Mailer jest bardziej rygorystyczny w kwestii zgodności nadawcy koperty z nagłówkiem From oraz certyfikatów TLS.
Kompatybilność modułów: Moduły odwołujące się do Swift_Message lub Swift_SmtpTransport przestaną działać na PS 9.

# PS 9 internal DSN examples (configured via admin UI)
smtp://user:password@mail.example.com:587      # STARTTLS
smtps://user:password@mail.example.com:465     # Implicit TLS
smtp://your%40gmail.com:app-pass@smtp.gmail.com:587  # Gmail
native://default                                # PHP mail() (not recommended)

Po aktualizacji do PS 9 zawsze ponownie przetestuj e-mail. Migracja z Swift Mailer na Symfony Mailer może ujawnić przypadki brzegowe z certyfikatami samopodpisanymi, niestandardowymi portami lub luźno zaimplementowanymi serwerami SMTP.

Przycisk testowania e-maila

Każda wersja PS ma opcję „Wyślij testowy e-mail”. Używaj jej, ale pamiętaj, że potwierdza ona jedynie działanie połączenia SMTP — nie to, że e-mail dotrze do skrzynki odbiorczej. Wysyła prosty tekst, nie bogaty HTML potwierdzeń zamówień. Testuj na Gmail, Outlook i własnej domenie.

Uwierzytelnianie domeny — Święta Trójca

SPF, DKIM i DMARC to uwierzytelnianie oparte na DNS, które dowodzi, że Twoje e-maile są autentyczne. Gmail i Yahoo uczyniły SPF i DKIM obowiązkowymi dla masowych nadawców w lutym 2024.

SPF (Sender Policy Framework)

SPF mówi serwerom odbiorczym, które adresy IP mogą wysyłać e-maile w imieniu Twojej domeny — to pojedynczy rekord TXT w DNS.

# Basic — allows 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

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

Częste błędy:

Wiele rekordów SPF: Tylko JEDEN rekord SPF TXT na domenę. Dwa rekordy = oba nieważne. Łącz usługi za pomocą wielu dyrektyw include:.
Zbyt wiele zapytań DNS: SPF pozwala na maksymalnie 10 zapytań (każde include: się liczy, zagnieżdżone też). Użyj walidatorów SPF, aby to sprawdzić.
+all zamiast ~all: +all pozwala każdemu wysyłać jako Twoja domena. Użyj ~all (softfail) podczas konfiguracji, następnie -all (hardfail) w produkcji.
Zapominanie o subdomenach: SPF dla shop.example.com potrzebuje własnego rekordu — nie dziedziczy z example.com.

DKIM (DomainKeys Identified Mail)

DKIM dodaje podpis kryptograficzny do każdego wychodzącego e-maila. PrestaShop nie obsługuje DKIM — podpisywanie realizuje Twój dostawca hostingu, przekierowanie SMTP lub usługa transakcyjna. Klucz publiczny publikujesz w DNS.

Hosting współdzielony (cPanel/Plesk): Zwykle włączane automatycznie. Sprawdź cPanel → Email Deliverability.
Gmail/Google Workspace: Konsola administracyjna → Gmail → Uwierzytelnianie poczty. Google udostępnia rekord TXT.
Usługi transakcyjne: Każda dostarcza rekordy DNS podczas procesu weryfikacji domeny.

# DKIM TXT record example
# Name: default._domainkey.yourstore.com (selector varies by provider)
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC łączy SPF i DKIM razem i mówi serwerom, co robić, gdy uwierzytelnianie się nie powiedzie.

# Stage 1: Monitor only
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourstore.com;

# Stage 2: Quarantine failures
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourstore.com;

# Stage 3: Reject failures (maximum protection)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourstore.com;

Tag rua wysyła raporty zbiorcze — pliki XML pokazujące, kto wysyła e-maile jako Twoja domena. Użyj Postmark DMARC monitoring, aby przeanalizować je w czytelne panele.

Zalecany plan wdrożenia: p=none przez 2-4 tygodnie podczas czytania raportów. Napraw legalnych nadawców, którzy nie przechodzą weryfikacji. Przejdź na p=quarantine na 2-4 tygodnie. Następnie p=reject. Pospieszne włączenie reject pierwszego dnia blokuje e-maile, o których nie wiedziałeś.

Konfiguracja SMTP na hostingu współdzielonym

Większość sklepów PrestaShop działa na hostingu współdzielonym. Utwórz dedykowane konto e-mail (np. orders@yourstore.com) i użyj tych danych uwierzytelniających.

Ustawienia zależne od dostawcy

# Generic cPanel
Server: mail.yourstore.com | Port: 587 | Encryption: TLS

# OVH
Server: ssl0.ovh.net | Port: 587 | Encryption: TLS

# Hostinger
Server: smtp.hostinger.com | Port: 587 | Encryption: TLS

# SiteGround
Server: yourstore.com | Port: 465 | Encryption: SSL

# Bluehost
Server: mail.yourstore.com | Port: 465 | Encryption: SSL

Gmail SMTP

Wymaga hasła aplikacji (Konto Google → Bezpieczeństwo → Weryfikacja dwuetapowa → Hasła aplikacji).

Server: smtp.gmail.com | Port: 587 | Encryption: TLS
Username: your@gmail.com | Password: (16-char App Password)

Limity: Darmowy Gmail: 500/dzień. Google Workspace: 2000/dzień. Zbyt szybkie wysyłanie wyzwala tymczasowe blokady.

Gmail SMTP sprawdza się w sklepach z mniej niż 30 zamówieniami dziennie. Powyżej tego, osiągnięcie limitów oznacza, że klienci czekają do 24 godzin na potwierdzenie zamówienia.

Microsoft 365 SMTP

Server: smtp.office365.com | Port: 587 | Encryption: TLS
Username: your@yourstore.com | Password: account or App Password

Limit: 10 000 odbiorców/dzień, 30 wiadomości/minutę. Microsoft coraz częściej wymaga OAuth zamiast podstawowego uwierzytelniania SMTP — sprawdź ustawienia swojego tenanta.

Transakcyjne usługi e-mail

Gdy Twój sklep przerasta możliwości SMTP hostingu, te usługi zapewniają dedykowaną infrastrukturę o wysokiej reputacji, podpisywanie DKIM, obsługę odrzuceń i analitykę dostarczania.

Kiedy się przełączyć

Osiągasz limity wysyłania hostingu
E-maile trafiają do spamu pomimo poprawnych rekordów DNS
Potrzebujesz śledzenia dostarczania i zarządzania odrzuceniami
Współdzielona reputacja IP hostingu ciągnie Cię w dół

Porównanie usług

Mailgun — od 15$/mies. za 10 tys. e-maili. Doskonałe API, szczegółowa analityka. SMTP: smtp.mailgun.org:587.

Postmark — od 15$/mies. za 10 tys. e-maili. Najwyższy wskaźnik doręczalności w branży. Oddziela wiadomości transakcyjne od marketingowych. SMTP: smtp.postmarkapp.com:587. Użyj Server API Token jako nazwy użytkownika i hasła.

Amazon SES — 0,10$ za 1000 e-maili. Najtaniej przy dużej skali. Utwórz dane SMTP w konsoli SES (nie klucze dostępu AWS). Nowe konta zaczynają w trybie sandbox. Serwer zależny od regionu: email-smtp.eu-west-1.amazonaws.com:587.

SendGrid — darmowy plan: 100/dzień. Płatne od 19,95$/mies. Nazwa użytkownika to dosłownie apikey, hasłem jest Twój klucz API. SMTP: smtp.sendgrid.net:587. Współdzielone IP darmowego planu mają słabą reputację — zaplanuj budżet na płatny plan.

Brevo — darmowy plan: 300/dzień. Płatne od 9$/mies. Wbudowany newsletter/CRM, siedziba w UE (RODO). SMTP: smtp-relay.brevo.com:587. Posiada dedykowaną wtyczkę dla PrestaShop.

Rekomendacja: Brevo, jeśli chcesz również e-mail marketingowy. Postmark, jeśli priorytetem jest doręczalność wiadomości transakcyjnych. Amazon SES przy dużym wolumenie i ograniczonym budżecie. Mailgun jako rozwiązanie uniwersalne.

Integracja

Wszystkie działają przez standardowy SMTP — nie są potrzebne żadne moduły: (1) zweryfikuj swoją domenę, (2) dodaj ich rekordy DNS (SPF, DKIM), (3) wygeneruj dane SMTP, (4) wpisz je w ustawieniach e-mail PrestaShop, (5) przetestuj.

Własny serwer pocztowy (zaawansowane)

Prowadzenie własnego serwera pocztowego daje pełną kontrolę — brak limitów zewnętrznych, brak opłat za wiadomość, pełna prywatność. Sami używamy Mailcow. Ale koszt czasu i wiedzy jest realny.

Kiedy to ma sens

Prywatność: Wszystkie dane e-mail pozostają na Twoim serwerze. Ważne przy rygorystycznym RODO.
Wolumen: Przy 100 tys.+ e-maili/miesiąc, VPS za 40$/mies. jest tańszy niż jakakolwiek usługa transakcyjna.
Kontrola: Własne reguły, brak arbitralnych limitów, brak zawieszania konta.

Kiedy nie ma sensu

Brak doświadczenia administracyjnego: Źle skonfigurowany serwer pocztowy jest gorszy niż hosting współdzielony.
Nowe IP: Budowanie reputacji od zera trwa tygodniami. Usługi transakcyjne dają Ci ustaloną reputację natychmiast.
Brak rekordu PTR: Bez odwrotnego DNS większość serwerów odrzuca Twoje e-maile od razu.
Obciążenie utrzymaniem: Aktualizacje, certyfikaty, monitorowanie czarnych list, logi — ciągła praca.

Opcje

Mailcow: Oparty na Docker, zawiera webmail, antyspam, antywirus, autodiscover. Wymaga 4GB+ RAM. Nasz wybór.

Mail-in-a-Box: Wszystko w jednym na dedykowanym serwerze Ubuntu. Prostszy, ale przejmuje całą maszynę.

iRedMail: Tradycyjny Postfix+Dovecot. Najbardziej elastyczny, najlżejszy, najbardziej ręczny.

Zacznij od prowadzenia własnego serwera pocztowego dla swojej firmy przez 3 miesiące, zanim skierujesz przez niego e-maile sklepów klientów. Buduj reputację stopniowo. Zachowaj usługę transakcyjną jako zapas.

Rodzaje e-maili w PrestaShop

Krytyczne — muszą dotrzeć natychmiast

Potwierdzenie zamówienia (order_conf): Najważniejszy e-mail. Jeśli trafi do spamu, spodziewaj się obciążeń zwrotnych i utraty zaufania.
Potwierdzenie płatności (payment): Klienci są niespokojni, dopóki tego nie zobaczą.
Resetowanie hasła (password_query): Wrażliwe czasowo. Jeśli dostarczenie trwa 10 minut, klient odchodzi.
Utworzenie konta (account): Pierwsze wrażenie o Twoim sklepie.

Ważne — powinny dotrzeć sprawnie

Powiadomienie o wysyłce (shipping): Zawiera informacje o śledzeniu.
Aktualizacje statusu zamówienia (order_changed): W trakcie realizacji, wysłane, dostarczone.
Faktura i zwrot: Potrzebne dla B2B i budowania pewności.

Oddziel e-maile transakcyjne od marketingowych. Używaj głównej domeny dla wiadomości o zamówieniach i subdomeny (news@mail.yourstore.com) dla newsletterów. Zapobiega to sytuacji, w której skargi na spam z newslettera niszczą reputację potwierdzeń zamówień.

Szablony znajdują się w mails/{iso_code}/. Każdy ma wersję HTML (.html) i tekstową (.txt). Zawsze utrzymuj obie — brak alternatywy tekstowej jest sygnałem spamu.

Wybór hostingu pod kątem e-maili

Ograniczenia hostingu współdzielonego

Współdzielona reputacja IP: Dzielisz IP z ponad 200 stronami. Jeśli którakolwiek wysyła spam, Twoje e-maile są karane. Nie masz na to wpływu.
Limity wysyłania: Zwykle 100-500/godzinę i 500-5000/dzień. Wyprzedaże i newslettery szybko to wyczerpują.
Brak dedykowanego IP: Niedostępne na hostingu współdzielonym. Kropka.
Ograniczona kontrola DNS: Niektórzy tani dostawcy ograniczają niestandardowe rekordy DKIM, TXT lub PTR.
Zablokowane porty: Niektórzy dostawcy blokują wychodzący port 587, uniemożliwiając połączenie z usługami transakcyjnymi.

Zalety VPS

Dedykowane IP z własną reputacją
Brak sztucznych limitów wysyłania
Rekord PTR (odwrotny DNS) — niezbędny dla doręczalności
Pełna kontrola DNS, dowolny serwer pocztowy

Sygnały ostrzegawcze

„Nieograniczone e-maile”: Coś takiego nie istnieje na hostingu współdzielonym.
Brak obsługi DKIM: Uciekaj.
Port 587 zablokowany: Nie możesz korzystać z usług transakcyjnych.
IP na czarnej liście: Sprawdź na MXToolbox przed podpisaniem umowy.

Najlepsza strategia dla hostingu współdzielonego: całkowicie pomiń e-mail dostawcy. Użyj usługi transakcyjnej przez SMTP. Twój sklep wysyła przez ich infrastrukturę o wysokiej reputacji, całkowicie omijając problem współdzielonego IP.

Nowości w PrestaShop 8 i 9

PS 8: Ostateczna wersja Swift Mailer

PS 8 używa ostatniej stabilnej wersji Swift Mailer 6.x. Ulepszona negocjacja TLS, lepsze logi błędów w var/logs/ i metadane e-maili w ps_mail. Testowanie z CLI: php bin/console prestashop:mail:test recipient@example.com.

PS 9: Symfony Mailer

Całkowita wymiana warstwy transportowej. Kluczowe zmiany:

Rozróżnia smtp:// (STARTTLS, port 587) od smtps:// (niejawne TLS, port 465)
Bardziej rygorystyczne podejście do zgodności nadawcy koperty z nagłówkiem From
Bardziej rygorystyczna walidacja certyfikatów TLS — samopodpisane certyfikaty, które działały w PS 8, mogą nie przejść
Moduły używające klas Swift Mailer (Swift_Message itp.) przestają działać i wymagają aktualizacji

# PS 9 email via environment variables (advanced)
# .env.local — overrides admin panel settings
MAILER_DSN=smtp://user:password@smtp.example.com:587
MAILER_DSN=smtp://user%40gmail.com:app-pass@smtp.gmail.com:587
# Special chars must be URL-encoded: @ = %40, : = %3A

Dla samopodpisanych certyfikatów w środowisku deweloperskim:

# Disable TLS verification (NEVER in production)
MAILER_DSN=smtp://user:pass@host:587?verify_peer=0

Testowanie i monitoring

Przed uruchomieniem

mail-tester.com: Wyślij testowy e-mail na ich adres i otrzymaj ocenę z 10 z konkretnymi problemami. Celuj w 9+. Darmowe 3 testy/dzień. Sprawdza SPF, DKIM, DMARC, czarne listy, jakość HTML, nagłówki i linki.

MXToolbox: Diagnostyka DNS — rekordy MX, ważność SPF i liczba zapytań, rozpoznawanie DKIM, polityka DMARC, status czarnych list.

Bieżący monitoring

Google Postmaster Tools: Pokazuje wskaźnik spamu, reputację IP, reputację domeny, powodzenie uwierzytelniania z perspektywy Gmail. Darmowe, wymaga weryfikacji domeny.

Nagłówki e-maila: W Gmail otwórz e-mail → trzy kropki → „Pokaż oryginał”. Szukaj:

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

Harmonogram: cotygodniowe sprawdzanie ps_mail pod kątem błędów i raportów DMARC. Miesięczne testy mail-tester.com i sprawdzanie czarnych list. Ponowna weryfikacja DNS po każdej zmianie. Test e-maili po każdej aktualizacji PrestaShop.

Typowe problemy i rozwiązania

„Testowy e-mail działa, ale klienci nie otrzymują potwierdzeń zamówień”

Błąd renderowania szablonu: Błąd Smarty w szablonie zamówienia po cichu zapobiega wysyłaniu. Sprawdź var/logs/.
Brakujący szablon: Szablon dla języka klienta nie istnieje w mails/{lang_iso}/.
Timeout SMTP: Duże potwierdzenia zamówień (wiele produktów) przekraczają limit czasu na wolnych połączeniach SMTP.
Odrzucony adres nadawcy: Serwery SMTP, które wymagają zgodności adresu From z uwierzytelnionym użytkownikiem.

Ograniczenie częstotliwości

Importujesz 200 zamówień lub wysyłasz newsletter do 1000 subskrybentów? Twój serwer SMTP przyjmuje pierwszą partię i odrzuca resztę. Rozłóż wysyłki w czasie, sprawdź limity dostawcy lub użyj usługi transakcyjnej, która automatycznie obsługuje kolejkowanie.

Problemy z kodowaniem (polskie/czeskie/specjalne znaki)

Zniekształcony temat: Upewnij się, że Twoja instalacja używa UTF-8 wszędzie. Tematy kodują się w formacie RFC 2047.
Uszkodzona treść szablonu: Pliki szablonów e-mail muszą być w UTF-8 bez BOM. Windows Notepad może zapisać jako ANSI — używaj VS Code.
Niezgodność bazy danych: Tabele powinny używać utf8mb4. Sprawdź: SHOW CREATE TABLE ps_product_lang;

E-maile zablokowane po migracji

SPF nie zaktualizowany o nowy adres IP serwera
Niezgodność klucza DKIM — nowy hosting wygenerował nowe klucze
Nowe IP nie ma reputacji — rozgrzewaj je stopniowo przez 2 tygodnie
Port 587 zablokowany na nowym hostingu
Propagacja DNS — poczekaj 24-48 godzin po zmianach

Formularz kontaktowy nie dociera

Niektóre moduły ustawiają adres e-mail klienta jako adres nadawcy (From). To nie przechodzi SPF, ponieważ Twój serwer nie może wysyłać z customer@gmail.com. Nadawca powinien zawsze pochodzić z domeny Twojego sklepu, a adres klienta powinien być w Reply-To.

Lista kontrolna doręczalności e-maili

Krok 1: Podstawy

☐ Przełącz z PHP mail() na SMTP
☐ Utwórz dedykowany adres wysyłkowy (np. orders@yourstore.com)
☐ Wyślij testowy e-mail na Gmail i Outlook — oba muszą dotrzeć do skrzynki odbiorczej

Krok 2: Uwierzytelnianie DNS

☐ Dodaj rekord SPF — zweryfikuj na MXToolbox, poniżej 10 zapytań
☐ Włącz DKIM i opublikuj klucz w DNS
☐ Dodaj rekord DMARC z p=none i raportowaniem rua
☐ Sprawdź nagłówki e-maila — wszystkie trzy muszą pokazywać PASS

Krok 3: Kontrola jakości

☐ Ocena 9+ na mail-tester.com
☐ IP nie znajduje się na czarnych listach
☐ Szablony istnieją dla wszystkich języków, zarówno HTML, jak i tekst

Krok 4: Testowanie w warunkach rzeczywistych

☐ Złóż testowe zamówienie — e-mail z potwierdzeniem dociera do skrzynki w ciągu sekund
☐ Przeprowadź zamówienie przez każdy status — każdy e-mail dociera
☐ Przetestuj reset hasła, utworzenie konta, formularz kontaktowy

Krok 5: Monitoring

☐ Zarejestruj się w Google Postmaster Tools
☐ Skonfiguruj przetwarzanie raportów DMARC
☐ Zaktualizuj DMARC do p=quarantine po 2-4 tygodniach, następnie p=reject
☐ Zaplanuj miesięczne kontrole doręczalności

Krok 6: Zaawansowane

☐ Przejdź na usługę transakcyjną, jeśli osiągasz limity hostingu
☐ Oddziel e-maile transakcyjne i marketingowe na różne domeny
☐ Ustaw rekord PTR, jeśli korzystasz z VPS/serwera dedykowanego
☐ Wdroż obsługę odrzuceń

Każda warstwa (SMTP, SPF, DKIM, DMARC, czyste szablony, renomowane IP) buduje Twoją wiarygodność. Pomiń jedną, a cały system się osłabia. Przejdź przez tę listę kontrolną metodycznie, testuj po każdej zmianie, a Twoje e-maile z PrestaShop będą docierać do skrzynki odbiorczej. Aby zapoznać się z ogólnymi krokami diagnostycznymi, zobacz nasz poradnik rozwiązywania problemów.