Przejdź do treści
Poradniki · Bezpieczeństwo IT

Maile ze sklepu nie dochodzą: SPF, DKIM i DMARC w praktyce

Maile ze sklepu nie dochodzą do klientów? Sprawdź SPF, DKIM i DMARC, routing poczty po Office 365 i czarne listy. Dowiedz się, jak to zdiagnozować.

Spis treści
  1. SPF, DKIM i DMARC prostym językiem
  2. Dlaczego maile ze sklepu nie dochodzą, a poczta biurowa działa
  3. Jak sprawdzić to samodzielnie
  4. DMARC: zacznij od obserwacji, nie od blokady
  5. Kiedy wysyłka maili potrzebuje osobnej usługi
  6. Lista kontrolna dla właściciela sklepu
  7. FAQ

Gdy maile ze sklepu nie dochodzą, przyczyna prawie zawsze leży w tym, że serwer pocztowy klienta nie ufa nadawcy: domena nie ma poprawnych rekordów SPF, DKIM i DMARC, wiadomości wychodzą z innego serwera niż reszta poczty albo adres trafił na czarną listę. Klient nie dostaje potwierdzenia zamówienia, dzwoni albo pisze z pytaniem, czy zapłata przeszła, a obsługa traci czas. Poniżej tłumaczę te trzy rekordy prostym językiem, pokazuję typowe przyczyny w małych firmach i to, jak sprawdzić problem samodzielnie.

SPF, DKIM i DMARC prostym językiem

To trzy wpisy w DNS domeny, dzięki którym serwer odbiorcy może sprawdzić, czy mail naprawdę pochodzi od Ciebie. Bez nich wiadomość wygląda jak podszywanie się pod Twoją firmę i ląduje w spamie albo nie dociera wcale.

  • SPF to lista serwerów, które mają prawo wysyłać pocztę z Twojej domeny. Opisuje go specyfikacja SPF w RFC 7208.
  • DKIM to cyfrowy podpis dodawany do każdej wiadomości. Odbiorca sprawdza go kluczem publicznym opublikowanym w DNS i wie, że treść nie została zmieniona po drodze.
  • DMARC mówi serwerom odbiorców, co zrobić z mailem, który nie przeszedł kontroli SPF i DKIM: przepuścić, wrzucić do spamu albo odrzucić. Pozwala też dostawać raporty o tym, kto wysyła pocztę w Twoim imieniu.

Najczęstszy błąd to nie brak rekordów, tylko rekordy niepełne. SPF obejmuje serwer poczty biurowej, ale nie serwer sklepu, który wysyła potwierdzenia zamówień. Dla serwera odbiorcy taki mail pochodzi od obcego nadawcy.

Dlaczego maile ze sklepu nie dochodzą, a poczta biurowa działa

Sklep i biuro zwykle wysyłają pocztę z dwóch różnych miejsc, choć z tej samej domeny. Pracownicy piszą z Office 365 albo ze skrzynek u hostingodawcy, a WooCommerce czy PrestaShop wysyła maile z serwera, na którym działa sklep. Jeśli rekordy DNS opisują tylko jedno z tych miejsc, drugie wypada z kontroli.

Typowe sytuacje, które widuję u mikrofirm:

  • Połączenie domen z Office 365: firma przenosi pocztę do Microsoftu, rekordy MX i SPF zostają przestawione pod nową usługę, a serwer sklepu znika z listy dozwolonych nadawców.
  • Routing poczty wewnątrz domeny: sklep wysyła powiadomienie o zamówieniu na adres w tej samej domenie, ale serwer sklepu nadal uważa się za odbiorcę i dostarcza maila lokalnie, zamiast do Office 365. Zamówienia giną, zanim ktokolwiek je zobaczy.
  • Wysyłka funkcją PHP bez uwierzytelnienia: sklep wysyła maile bezpośrednio z serwera, bez podpisu DKIM, więc trafiają do spamu.
  • Czarna lista: adres serwera dzieli się z innymi stronami na hostingu współdzielonym i ktoś z sąsiadów rozsyłał spam.

O tym, co jeszcze sprawdzić przy zmianie dostawcy usług, pisałem w tekście o hostingu dla małej firmy. Poczta to tam osobna pozycja na liście.

Jak sprawdzić to samodzielnie

Pierwszą diagnozę zrobisz bez programisty w kilkanaście minut. Potrzebujesz zamówienia testowego i skrzynki w popularnej darmowej usłudze pocztowej.

  1. Złóż zamówienie testowe na swój prywatny adres i sprawdź, czy mail doszedł i w którym folderze.
  2. Otwórz oryginał wiadomości (opcja w rodzaju „pokaż oryginał” albo „pokaż źródło”). W nagłówku Authentication-Results zobaczysz wynik kontroli SPF, DKIM i DMARC. Szukasz trzech wyników pass.
  3. Sprawdź w nagłówkach, z jakiego serwera wyszedł mail. Jeśli to serwer sklepu, a nie Office 365, ten serwer musi być w rekordzie SPF i podpisywać wiadomości DKIM.
  4. Wyślij testowego maila do publicznego testera dostarczalności. Takie narzędzia pokazują brakujące rekordy i obecność na czarnych listach.
  5. Sprawdź adres serwera sklepu w wyszukiwarkach czarnych list. Jeśli tam jest, ustal przyczynę, zanim poprosisz o usunięcie.

Jeśli wynik SPF to fail albo softfail, a DKIM w ogóle nie występuje, masz odpowiedź. Poprawka to zwykle kilka wpisów w DNS i zmiana sposobu wysyłki w sklepie.

DMARC: zacznij od obserwacji, nie od blokady

Polityka DMARC ma trzy poziomy: tylko raportuj, wrzucaj do spamu, odrzucaj. Zawsze zaczynam od samego raportowania, bo raporty pokazują wszystkie miejsca, z których wychodzi poczta w domenie, także te, o których firma zapomniała: system fakturowy, formularz na stronie, newsletter. Mechanizm raportów opisuje specyfikacja DMARC w RFC 7489.

Dopiero gdy każde źródło ma poprawny SPF i podpis DKIM, zaostrzam politykę. Ustawienie blokady od razu potrafi odciąć faktury albo przypomnienia o płatności, które wysyła zewnętrzny system.

Kiedy wysyłka maili potrzebuje osobnej usługi

Osobna usługa do wysyłki ma sens, gdy sklep wysyła dużo powiadomień, a serwer stoi na hostingu współdzielonym albo nikt nie pilnuje jego reputacji. Wtedy sklep przekazuje maile przez uwierzytelnione połączenie do dostawcy, który dba o podpisy, reputację adresów i statystyki doręczeń.

W praktyce wygląda to tak: sklep wysyła przez SMTP z loginem albo przez API, domena ma rekordy SPF i DKIM wskazujące na tę usługę, a Ty widzisz, które maile doszły, a które odbiły się od skrzynki odbiorcy. Przykładem takiego narzędzia jest nasz Mailcraft do wysyłki transakcyjnej, ale zasada jest ta sama przy każdym dostawcy: wysyłka transakcyjna ma być oddzielona od biurowej i opisana w DNS.

Przy okazji przejrzyj, kto ma dostęp do ustawień poczty w sklepie i panelu DNS. Zmiana rekordów przez osobę spoza firmy to też problem bezpieczeństwa, który opisałem w tekście o bezpieczeństwie sklepu internetowego.

Lista kontrolna dla właściciela sklepu

Zanim uznasz, że maile ze sklepu nie dochodzą przez winę klienta, przejdź po kolei te punkty:

  • Rekord SPF obejmuje wszystkie serwery i usługi, które wysyłają pocztę z domeny.
  • Każde źródło wysyłki podpisuje maile DKIM.
  • DMARC jest ustawiony, a ktoś czyta raporty.
  • Sklep wysyła przez uwierzytelnione SMTP albo API, nie przez lokalną funkcję serwera.
  • Adresy w domenie firmy nie są dostarczane lokalnie na serwerze sklepu.
  • Po każdej zmianie poczty robisz zamówienie testowe i sprawdzasz nagłówki.

Jeśli maile ze sklepu nie dochodzą, zacznij od zamówienia testowego i nagłówka Authentication-Results, bo w nim zwykle jest gotowa diagnoza. Gdy wynik pokazuje błędy, których nie umiesz poprawić w DNS, napisz do mnie z nagłówkiem wiadomości, a powiem, od czego zacząć.

FAQ

Czy wystarczy, że klient sprawdzi folder spam?

To obejście, a nie rozwiązanie. Część serwerów odrzuca podejrzane wiadomości bez umieszczania ich w spamie, więc klient nie ma czego szukać. Trzeba poprawić rekordy i sposób wysyłki po stronie sklepu.

Ile trwa naprawa SPF i DKIM?

Same wpisy w DNS to krótka praca, a zmiany rozchodzą się zwykle w ciągu godzin. Dłużej trwa ustalenie wszystkich miejsc, które wysyłają pocztę z domeny, dlatego pomagają raporty DMARC zbierane przez kilka dni.

Czy newsletter może psuć dostarczalność maili z zamówień?

Może, jeśli idzie z tego samego serwera i tej samej domeny, a odbiorcy oznaczają go jako spam. Dlatego wysyłkę marketingową i transakcyjną dobrze rozdzielić, najlepiej także na osobne subdomeny.

Krzysztof Balicki
CEO & CTO Web Systems

Buduję oprogramowanie od 1999 r. Z zespołem Web Systems projektuję i wdrażam systemy dla firm – coraz częściej z agentami AI.

Klienci piszą, że nie dostali potwierdzenia zamówienia, a Ty nie wiesz, gdzie giną maile? Umów rozmowę

Powiązane wpisy