Wróć do bloga

Dlaczego Twoje maile nie docierają do klientów

Marek KoncewiczMarek Koncewicz
5 stycznia 20265 min czytania
Dlaczego Twoje maile nie docierają do klientów

W pierwszej kolejności rekomenduję zapoznać się z naszą realizacją aplikacji SaaS, z której wywodzi się ten temat.

Wstęp

Stojąc przed wyzwaniem dostarczenia newslettera bądź kampanii marketingowej do sporego grona odbiorców, mamy kilka opcji:

  • W całości oddelegować proces realizacji newslettera do zewnętrznej platformy e-mail marketingowej
  • Skorzystać z usług dostawcy infrastruktury wysyłkowej (tzw. bramki SMTP), a resztę procesów – planowanie kampanii, przechowywanie kontaktów, analitykę – zaimplementować po swojej stronie
  • Zbudować własny ekosystem, zaczynając od bramki SMTP, aż po panel umożliwiający zarządzanie kampanią marketingową

W tym artykule, na podstawie naszego doświadczenia, podejmuję się wyjaśnienia, na co należy zwrócić uwagę przy zarządzaniu własną bramką SMTP i co może być przyczyną lądowania wysłanych wiadomości e-mail w spamie bądź nadmiernej liczby odbić (tzw. bounce).

W tabeli porównawczej zestawiłem każde z tych podejść, aby można było uzmysłowić sobie, jak dużym wyzwaniem jest utrzymanie własnej infrastruktury.

Może się wydawać, że skorzystanie z gotowej bramki SMTP jest najrozsądniejszym wyborem. Owszem, często tak jest. Są jednak przypadki, w których pozostaje tylko trzecia opcja – utrzymanie własnej infrastruktury. Jak do tego mądrze podejść i na co zwrócić uwagę – o tym jest ten artykuł.

Kryterium Model 01Platforma email marketingowa Model 02Bramka SMTP Model 03Własna infrastruktura
Kreator treści i szablony W pakiecieedytor wizualny Po twojej stronie Po twojej stronie
Baza kontaktów W pakiecie Twoja aplikacja Twoja aplikacja
Planowanie kampanii W pakiecie Do zbudowania Do zbudowania
Analityka kampanii Pełnaotwarcia, kliknięcia, konwersje !Podstawowastatystyki dostarczeń w panelu Do zbudowania
Serwery i adresy IP Po stronie dostawcy Po stronie dostawcy Po twojej stronie
Reputacja adresu IP !Pula współdzielonazależysz od innych nadawców Zarządzanapula dedykowana lub współdzielona Budujesz od zera
Rozgrzewanie nowego IP Nie dotyczy Prowadzone przez dostawcę Tygodnie ręcznej pracy
Rekord PTR (rDNS) Po stronie dostawcy Po stronie dostawcy !Zależny od operatora IPnie ustawisz go we własnym DNS
Podpis DKIM Dostawca podpisujety publikujesz klucz Dostawca podpisujety publikujesz klucz Twoja konfiguracjaklucze, selektory, rotacja
Rekordy SPF i DMARC !Po twojej stronie !Po twojej stronie !Po twojej stronie
Zgodność domen !Po twojej stroniewłasny Return-Path do skonfigurowania !Po twojej stronie !Po twojej stronie
Obsługa odbić Automatycznaadresy same znikają z listy !Dostawca zwraca danereagujesz sam Własny mechanizm
Wypisy i List-Unsubscribe W pakiecie !Nagłówek dodajesz sam Do zbudowania
Monitoring czarnych list Po stronie dostawcy Po stronie dostawcy Twoje zadanieplus procedura delistingu
Analiza raportów DMARC !Po twojej stronie !Po twojej stronie !Po twojej stronie
Kontrola nad nagłówkami Ograniczona Pełna Pełna
Czas uruchomienia Godziny !Dniintegracja po stronie aplikacji Tygodnie
Koszt początkowy Zerowy Niski Wysokiczas zespołu, nie sprzęt
Koszt przy dużej skali Rośnie z baząrozliczenie za kontakt Niskirozliczenie za wiadomość !Niski jednostkowostały koszt utrzymania
Wymagane kompetencje Niskiemarketing bez działu IT !Średnieintegracja i DNS Bardzo wysokie
Odpowiedzialność Głównie dostawca !Dzielona W całości twoja
Ryzyko vendor lock-in Wysokiedane, szablony, automatyzacje !Niskiezmiana to podmiana hosta SMTP Brak

Cała uwaga na PTR

Zanim omówimy SPF, DKIM czy DMARC, należy zacząć od czegoś innego – od PTR.

Jest to rekord DNS działający odwrotnie niż wszystkie pozostałe. Zwykle wykonywane są zapytania typu: „jaki adres IP ma domena koncewicz.pl?”. PTR służy do odwrotnego procesu – pozwala pobrać nazwę (np. określoną domenę), która kryje się pod konkretnym adresem IP.

Do przechowywania tych danych służy osobna przestrzeń nazw, potocznie nazywana rDNS, czyli reverse DNS.

Ten mechanizm serwery pocztowe wykorzystują do upewnienia się, czy nadawca faktycznie jest właścicielem konkretnego adresu IP. Bierze w tym udział również nazwa hosta, którą posługuje się bramka SMTP podczas nawiązywania połączenia z serwerem odbiorczym.

Oto krok po kroku, jak przebiega to sprawdzenie:

  • Bramka SMTP nawiązuje połączenie z serwerem odbiorcy, posługując się w komunikacji konkretną nazwą hosta – załóżmy, że będzie to mail.koncewicz.pl
  • Serwer odbiorczy odpytuje rDNS o adres IP, z którego przyszło połączenie, i porównuje zwróconą wartość z hostem bramki
  • Serwer odbiorczy odpytuje DNS o host zwrócony przez rDNS, żeby upewnić się, że wskazuje on z powrotem na ten sam adres IP

Jeśli wszystkie trzy wartości ze sobą współgrają – host podany przez bramkę, wpis rDNS dla jej adresu IP oraz adres IP tego hosta – pętla jest domknięta i można wykluczyć jedną z najczęstszych przyczyn odrzucenia wiadomości.

Żaden standard nie nakazuje odrzucania wiadomości e-mail przy niezgodności rDNS z hostem bramki – każdy odbiorca egzekwuje to po swojemu. Część z nich poprzestaje na sprawdzeniu, czy rDNS w ogóle istnieje, a rozjazd z nazwą podaną przez bramkę traktuje jako punkty karne, a nie powód do odrzucenia.

Wiedza na temat PTR jest pomocna przy wyborze infrastruktury wysyłkowej. Zanim zdecydujemy się na konkretnego dostawcę sprzętu, należy sprawdzić, czy serwerownia toleruje wychodzący ruch SMTP oraz czy jest możliwość ustawienia własnego rDNS.

Zgodność domen

Każda wiadomość e-mail ma pewne ukryte parametry, o których wiedzą głównie specjaliści techniczni, a niepoprawna konfiguracja jednej z nich może skutkować problemami z docieralnością. Łączy je wspólna cecha: w swojej składni zawierają domenę internetową.

Oto parametry, o których mowa:

  • dkim – wskazuje na klucz publiczny, którym serwer odbiorcy zweryfikuje podpis wiadomości
  • from – adres e-mail podany jako nadawca wiadomości
  • return_path – adres e-mail do obsługi odbić

Istnieje kilka podejść do konfiguracji domen występujących w tych parametrach, a właściwy wybór zależy od kontekstu biznesowego.

Załóżmy, że celem jest dostarczenie newslettera do trzech grup docelowych i dla każdej z nich chcielibyśmy użyć odrębnego adresu nadawcy: news@domena-1.pl, news@domena-2.pl oraz news@domena-3.pl.

Oznacza to, że będziemy mieli do skonfigurowania trzy osobne domeny i zostaną one użyte w parametrze from z powyższej listy.

Takie zdefiniowanie wymagań biznesowych otwiera drogę do konfiguracji dkim. Oto, jaką rolę on odgrywa:

  • Bramka SMTP dokleja do każdej wysłanej wiadomości podpis cyfrowy – używa do tego celu klucza prywatnego, którego nikt inny nie posiada
  • Serwer odbiorczy pobiera z DNS klucz publiczny i sprawdza, czy podpis się zgadza

Parametr dkim wskazuje właśnie domenę, spod której w DNS można pobrać klucz publiczny. Domena ta nie musi się zgadzać ani z domeną wysyłkową (from), ani z domeną obsługującą odbicia (return_path). Oznacza to, że możemy mieć odrębną domenę, która będzie służyć wyłącznie do przechowywania klucza publicznego biorącego udział w podpisie cyfrowym dkim.

Osobna domena dla podpisu ma jednak swoją cenę: skoro nie zgadza się z domeną nadawcy, DKIM nie bierze udziału w ocenie DMARC i cała weryfikacja opiera się wtedy na SPF, który przestaje działać przy automatycznym przekierowaniu wiadomości – nadaje wówczas serwer pośredniczący, którego nie ma w naszym rekordzie.

W przypadku newslettera bywa to akceptowalny kompromis. W zamian można mieć nieograniczoną liczbę domen wysyłkowych – widocznych w adresie nadawcy – i posługiwać się tylko jedną domeną do składania podpisu.

Domena adresu e-mail obsługującego odbicia (parametr return_path) powinna się zgadzać z domeną wysyłkową.

SPF i DMARC

Kolejnym etapem jest informowanie serwera odbiorczego o adresach IP uprawnionych do wysyłania poczty w imieniu konkretnego nadawcy.

Deklaracja ta nosi nazwę SPF i jest wpisem DNS. Rekord ten powinien się znajdować na domenie obsługującej odbicia – return_path.

DMARC również jest wpisem DNS, tyle że wyłącznie na domenie nadawcy – from. Polityka ta opiera się na wynikach SPF i DKIM oraz określa, co zrobić z wiadomością, która nie przeszła uwierzytelnienia.

Co jeszcze

Wspomniane polityki i mechanizmy są elementami stałymi – konfiguruje się je jeden raz i nie ma potrzeby wracać do tematu ponownie.

Problemy z docieralnością mogą również wynikać ze słabo przemyślanej strategii prowadzenia newslettera, przekroczenia limitów po stronie serwera odbiorczego czy trafienia adresu IP na czarne listy.

Marek Koncewicz
Marek KoncewiczFullstack Engineer

Ewangelista Laravela. Zwolennik produktowego podejścia do rozwoju aplikacji webowych.