Klient składa zamówienie, płatność przechodzi prawidłowo, WooCommerce generuje potwierdzenie… a wiadomość ląduje w spamie albo w ogóle nie pojawia się w skrzynce odbiorczej. W sklepie internetowym to nie jest drobny problem techniczny. Brak maila z potwierdzeniem potrafi obniżyć zaufanie klienta i od razu wygenerować pytanie: „czy moje zamówienie na pewno przeszło?”
W takiej sytuacji nie zaczynam od zmiany wyglądu szablonu wiadomości. Najpierw sprawdzam, czy WooCommerce faktycznie wygenerował e-mail, przez jaki serwer został on wysłany oraz czy domena jest prawidłowo uwierzytelniona.
Kluczowe są tutaj trzy mechanizmy: SPF, DKIM i DMARC. Jeżeli do tego dodamy prawidłowo skonfigurowaną wysyłkę SMTP i adres nadawcy we własnej domenie, otrzymujemy znacznie solidniejszą podstawę pod dostarczalność wiadomości z WooCommerce.
Określa, które serwery są uprawnione do wysyłania poczty w imieniu domeny.
Dodaje podpis kryptograficzny pozwalający zweryfikować wiadomość.
Łączy SPF i DKIM z domeną nadawcy i pozwala określić politykę dla wiadomości, które nie przejdą weryfikacji.
Najpierw ustal: mail nie został wysłany czy trafił do spamu?
To dwa zupełnie różne problemy.
Jeżeli WooCommerce w ogóle nie wygenerował wiadomości, poprawianie rekordów DNS może niczego nie zmienić. Jeżeli natomiast wiadomość została wysłana, ale Gmail, Outlook czy inny dostawca umieszcza ją w spamie, wtedy dostarczalność i uwierzytelnienie domeny stają się znacznie ważniejsze.
Czy sklep rzeczywiście utworzył wiadomość dla konkretnego zamówienia?
Czy wiadomość została prawidłowo przyjęta i wysłana przez usługę pocztową?
Czy serwer odbiorczy zaufał wiadomości i dostarczył ją do inboxa?
W nowszych wersjach WooCommerce dostępne są również logi wiadomości transakcyjnych. Przy problemie z konkretnym zamówieniem sprawdzam, czy system odnotował próbę wysłania wiadomości.
Jeżeli masz szerszy problem z WordPressem i poczta nie jest wysyłana również z formularzy, opisałem ten przypadek osobno w poradniku WordPress nie wysyła maili – jak naprawić formularze i SMTP?
Dlaczego e-maile z WooCommerce trafiają do spamu?
Filtr antyspamowy nie ocenia wyłącznie treści wiadomości. Patrzy również na to, kto wysłał e-mail, z jakiego serwera, czy domena potwierdza jego autentyczność i jaka jest reputacja źródła wysyłki.
Dlatego estetyczny szablon potwierdzenia zamówienia może nadal trafiać do spamu, jeżeli technicznie wiadomość wygląda tak, jakby ktoś podszywał się pod Twoją domenę.
Przykład problematycznej konfiguracji
Strona: twojsklep.pl
From:
twojsklep@gmail.com
Wysyłka:
serwer hostingowy twojsklep.pl
Sklep deklaruje wtedy jednego nadawcę, a wiadomość technicznie
wychodzi z zupełnie innej infrastruktury. To zdecydowanie gorszy
punkt wyjścia niż używanie adresu we własnej domenie,
np. zamowienia@twojsklep.pl, wysyłanego przez
poprawnie uwierzytelniony serwer.
SPF, DKIM i DMARC – za co odpowiada każdy z nich?
SPF
Pozwala określić, jakie źródła mają prawo wysyłać wiadomości dla danej domeny.
DKIM
Podpisuje wiadomość. Serwer odbiorcy może sprawdzić podpis względem klucza opublikowanego w DNS.
DMARC
Sprawdza zgodność domeny widocznej dla odbiorcy z SPF lub DKIM i określa sposób obsługi nieprawidłowych wiadomości.
| Mechanizm | Co weryfikuje? | Gdzie konfiguruję? |
|---|---|---|
| SPF | Czy serwer wysyłający jest dozwolony dla domeny. | Rekord TXT w DNS domeny. |
| DKIM | Czy wiadomość posiada prawidłowy podpis powiązany z domeną. | Rekord TXT w DNS + konfiguracja dostawcy poczty. |
| DMARC | Czy SPF lub DKIM są odpowiednio dopasowane do domeny nadawcy i jaka polityka ma zostać zastosowana. | Rekord TXT pod _dmarc. |
SPF – kto może wysyłać e-maile z Twojej domeny?
SPF, czyli Sender Policy Framework, działa jak lista dozwolonych źródeł poczty.
Jeżeli domena twojsklep.pl korzysta przykładowo
z zewnętrznego operatora SMTP, jego infrastruktura powinna być
uwzględniona w rekordzie SPF zgodnie z dokumentacją tego operatora.
Przykładowa składnia może wyglądać tak:
v=spf1 include:_spf.provider.example ~allWartość SPF zależy od tego, kto rzeczywiście wysyła Twoją pocztę: hosting, Google Workspace, Microsoft 365, Brevo, Mailgun, SendGrid, Postmark albo inna usługa.
Uwaga na kilka rekordów SPF
Jeżeli korzystasz z kilku systemów wysyłających pocztę z jednej domeny,
nie tworzę dla każdego z nich osobnego rekordu v=spf1.
Wszystkie prawidłowe źródła trzeba uwzględnić w jednej poprawnej
konfiguracji SPF dla danej domeny.
To szczególnie częsty problem, gdy firma korzysta jednocześnie z poczty firmowej, sklepu WooCommerce oraz platformy newsletterowej.
DKIM – podpis cyfrowy wiadomości
DKIM działa inaczej niż SPF. Dostawca poczty podpisuje wychodzącą wiadomość kluczem prywatnym, a w DNS publikowany jest klucz, dzięki któremu odbiorca może zweryfikować podpis.
Rekord znajduje się zwykle pod adresem w rodzaju:
selector1._domainkey.twojsklep.pl
Sam selector1 jest tylko przykładem.
Dokładną nazwę i wartość DKIM otrzymujesz od dostawcy,
przez którego wysyłasz wiadomości.
Dlaczego DKIM jest tak ważny?
Jeżeli podpis przechodzi prawidłowo, serwer odbiorcy otrzymuje dodatkowy sygnał, że wiadomość została wysłana przez system autoryzowany dla konkretnej domeny i nie została po drodze zmodyfikowana w sposób unieważniający podpis.
DMARC – SPF i DKIM zaczynają pracować razem
Samo posiadanie rekordów SPF i DKIM nie jest jeszcze pełnym obrazem. DMARC patrzy również na alignment, czyli zgodność uwierzytelnionej domeny z domeną widoczną w polu „Od”.
Przykładowy rekord testowy może wyglądać tak:
v=DMARC1; p=none; rua=mailto:dmarc@twojsklep.pl
Polityka p=none służy przede wszystkim do monitorowania.
Nie mówi serwerom odbiorczym, aby od razu odrzucały wszystkie
wiadomości niespełniające warunków.
Po przeanalizowaniu raportów i upewnieniu się, że wszystkie prawidłowe źródła poczty są uwierzytelnione, można świadomie przechodzić do bardziej restrykcyjnych polityk.
Ustawienie restrykcyjnej polityki bez wcześniejszego rozpoznania wszystkich źródeł poczty może sprawić, że również prawidłowe wiadomości firmowe zaczną być odrzucane.
Jak wdrażam SPF, DKIM i DMARC w WooCommerce krok po kroku?
Ustalam, skąd faktycznie wychodzi poczta
Najpierw trzeba wiedzieć, czy WordPress korzysta z serwera hostingowego, firmowej skrzynki SMTP czy zewnętrznej usługi transakcyjnej.
Bez tego nie da się poprawnie przygotować SPF ani DKIM.
Ustawiam adres nadawcy we własnej domenie
W WooCommerce preferuję adres w rodzaju
zamowienia@twojsklep.pl,
sklep@twojsklep.pl albo
kontakt@twojsklep.pl.
Nie ustawiam w polu „Od” przypadkowego adresu Gmail, jeżeli wiadomość technicznie nie jest wysyłana przez infrastrukturę Gmaila.
Konfiguruję uwierzytelnioną wysyłkę
W wielu sklepach wolę skierować wiadomości WordPressa przez prawdziwą usługę SMTP lub API dostawcy poczty zamiast polegać wyłącznie na lokalnym mechanizmie wysyłki PHP hostingu.
Dodaję lub poprawiam SPF
Rekord musi obejmować wszystkie prawidłowe systemy wysyłające pocztę w imieniu domeny.
Jeżeli SPF już istnieje, nie dodaję bezmyślnie drugiego. Najpierw analizuję aktualną wartość.
Aktywuję DKIM u dostawcy
Dostawca podaje selector i rekord DNS. Po publikacji sprawdzam, czy DKIM faktycznie pojawia się w wysyłanych wiadomościach i przechodzi weryfikację.
Wdrażam DMARC i obserwuję wyniki
Zaczynam od konfiguracji pozwalającej obserwować, czy prawidłowe wiadomości przechodzą SPF/DKIM i czy domeny są właściwie dopasowane.
Dopiero później podejmuję decyzję o bardziej restrykcyjnej polityce.
Czy samo SMTP wystarczy, żeby maile WooCommerce nie trafiały do spamu?
Nie traktuję SMTP jako zamiennika SPF, DKIM i DMARC.
SMTP odpowiada przede wszystkim za sposób przekazania wiadomości do serwera pocztowego. Uwierzytelnienie domeny pomaga natomiast odbiorcy ocenić, czy dana wiadomość rzeczywiście ma prawo reprezentować wskazanego nadawcę.
Wiadomość może zostać wysłana, ale domena nadal nie dostarcza wszystkich potrzebnych sygnałów uwierzytelnienia.
Wysyłka i domena tworzą spójny system, który łatwiej zweryfikować serwerowi odbiorcy.
Przy sklepach internetowych WooCommerce konfigurację poczty traktuję jako część procesu sprzedażowego. Potwierdzenie zamówienia, zmiana statusu czy informacja o płatności powinny docierać do klienta niezawodnie.
Gmail, Yahoo i coraz większe wymagania wobec nadawców
Uwierzytelnienie poczty nie jest już dodatkiem, który konfiguruję wyłącznie przy dużych newsletterach.
Gmail wymaga od nadawców wysyłających wiadomości na konta Gmail uwierzytelnienia poczty co najmniej przy pomocy SPF lub DKIM. Przy dużej skali wysyłki wymagania są wyższe i obejmują razem SPF, DKIM oraz DMARC.
Nawet jeśli mały sklep wysyła kilkanaście lub kilkadziesiąt potwierdzeń dziennie, ja i tak konfiguruję wszystkie trzy mechanizmy, jeśli wykorzystywana infrastruktura na to pozwala. To po prostu solidniejsza baza na przyszłość.
Jak sprawdzić, czy SPF, DKIM i DMARC działają?
Po wdrożeniu nie zakładam, że „skoro rekord jest w DNS, to wszystko działa”.
Robię testowe zamówienie i sprawdzam wiadomość wysłaną dokładnie tak, jak otrzyma ją klient.
- Sprawdzam, czy potwierdzenie zamówienia faktycznie zostało wygenerowane.
- Weryfikuję log SMTP lub log wiadomości transakcyjnej.
- Sprawdzam nagłówki otrzymanego e-maila.
- Szukam wyników SPF, DKIM i DMARC.
- Sprawdzam domenę widoczną w polu From.
- Testuję wysyłkę do różnych dostawców – np. Gmail i Outlook.
- Sprawdzam, czy mail trafia do skrzynki głównej, spamu czy zostaje odrzucony.
Jak może wyglądać prawidłowy wynik?
SPF: PASS
DKIM: PASS
DMARC: PASSTaki wynik nie daje matematycznej gwarancji, że każda wiadomość zawsze trafi do folderu głównego, ponieważ filtry antyspamowe biorą pod uwagę również inne czynniki. Jest jednak zdecydowanie lepszym punktem wyjścia niż wysyłka bez uwierzytelnienia.
Najczęstsze błędy przy konfiguracji maili WooCommerce
Dodanie drugiego SPF zamiast poprawienia istniejącego
Jeżeli domena ma już rekord SPF dla poczty firmowej, a sklep zaczyna korzystać z kolejnej usługi, aktualizuję istniejącą politykę zamiast publikować kilka konkurujących rekordów SPF.
Ustawienie From na @gmail.com
Sklep działający pod własną domeną powinien wysyłać wiadomości jako adres należący do tej domeny albo zgodnie z zasadami konkretnego dostawcy pocztowego.
Dodanie DKIM do DNS bez aktywowania podpisywania
Sam rekord DNS niczego nie podpisuje. Dostawca wysyłki musi faktycznie dodawać podpis DKIM do wiadomości.
DMARC p=reject wdrożony pierwszego dnia
Jeżeli firma ma kilka źródeł wysyłki i nie wszystkie zostały jeszcze uwierzytelnione, restrykcyjna polityka może spowodować problemy również z prawidłową pocztą.
Test wyłącznie jednej skrzynki
To, że wiadomość dotarła na jednego Gmaila, nie oznacza jeszcze, że konfiguracja jest idealna. Sprawdzam też wyniki uwierzytelnienia i – jeżeli problem był szerszy – testuję kilku odbiorców.
Moja checklista dostarczalności e-maili WooCommerce
- Adres From znajduje się we własnej domenie sklepu.
- WooCommerce generuje właściwe wiadomości transakcyjne.
- WordPress wysyła pocztę przez prawidłowo skonfigurowany SMTP lub API.
- Domena posiada poprawny rekord SPF.
- Dostawca podpisuje wiadomości DKIM.
- Rekord DMARC został wdrożony świadomie.
- Domeny używane przez SPF/DKIM są prawidłowo dopasowane do From.
- Wiadomość testowa przechodzi SPF, DKIM i DMARC.
- Sprawdzam logi wysyłki, a nie tylko folder „Odebrane”.
- Testuję realne potwierdzenie zamówienia WooCommerce.
Dlaczego warto to poprawić, zanim klient zgłosi problem?
E-mail transakcyjny jest częścią obsługi zamówienia. Klient oczekuje go praktycznie od razu po zakupie.
Jeżeli wiadomość nie przychodzi, może nie wiedzieć, czy płatność została zaksięgowana, czy zamówienie faktycznie istnieje i kiedy zostanie wysłane.
Dobra konfiguracja poczty pozwala ograniczyć takie niepotrzebne wątpliwości. Klient dostaje informację we właściwym momencie, a obsługa sklepu nie musi odpowiadać na kolejne pytania o status prawidłowo złożonych zamówień.
Potwierdzenia zamówień wpadają do spamu albo w ogóle nie dochodzą?
Mogę sprawdzić sposób wysyłki WordPressa, SMTP, rekordy SPF, DKIM i DMARC, adres nadawcy oraz logi WooCommerce. Zamiast zmieniać przypadkowe ustawienia ustalimy, na którym etapie naprawdę pojawia się problem.
E-maile WooCommerce, SPF, DKIM i DMARC – najczęstsze pytania
Dlaczego potwierdzenia zamówień WooCommerce trafiają do spamu?
Przyczyną może być brak prawidłowego uwierzytelnienia domeny, wysyłka z nieodpowiedniego adresu From, reputacja serwera, konfiguracja SMTP albo inne sygnały analizowane przez filtr antyspamowy. Sprawdzam przede wszystkim SPF, DKIM, DMARC oraz sposób faktycznej wysyłki wiadomości.
Czy samo skonfigurowanie SMTP wystarczy?
Nie zawsze. SMTP poprawia sposób wysyłki wiadomości, ale domena powinna być również prawidłowo uwierzytelniona. Dlatego oprócz SMTP sprawdzam SPF, DKIM i DMARC.
Czy WooCommerce potrzebuje SPF?
Jeżeli wiadomości są wysyłane w imieniu Twojej domeny, właściwy system wysyłkowy powinien być uwzględniony w konfiguracji SPF domeny. Konkretna wartość zależy od używanego dostawcy poczty.
Czy DKIM trzeba konfigurować w WordPressie?
DKIM jest zwykle konfigurowany po stronie dostawcy poczty oraz DNS domeny. WordPress lub wtyczka SMTP korzystają później z usługi, która podpisuje wychodzące wiadomości.
Jaką politykę DMARC ustawić na początku?
Nie ustawiam automatycznie restrykcyjnej polityki bez wcześniejszego sprawdzenia źródeł wysyłki. W wielu wdrożeniach zaczynam od monitorowania, analizuję wyniki, a dopiero później zaostrzam politykę.
Czy można używać adresu Gmail jako nadawcy WooCommerce?
Nie ustawiałbym przypadkowo adresu Gmail w polu From, jeśli wiadomość wychodzi przez serwer sklepu lub inną niezależną infrastrukturę. Lepszym rozwiązaniem jest adres we własnej domenie i poprawnie uwierzytelniona wysyłka.
Jak sprawdzić SPF, DKIM i DMARC wiadomości?
Po wysłaniu testowego zamówienia sprawdzam nagłówki otrzymanej wiadomości oraz wyniki uwierzytelnienia. Docelowo chcę zobaczyć prawidłowe przejście SPF, DKIM i DMARC dla wykorzystywanej konfiguracji.
Kamil Sudoł – freelancer WordPress & SEO. Od 2015 roku tworzę i rozwijam strony internetowe oraz sklepy WooCommerce, a także zajmuję się SEO i widocznością firm w Google. Na blogu publikuję praktyczne materiały dotyczące WordPressa, SEO, UX i marketingu internetowego.
