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ścifrom– adres e-mail podany jako nadawca wiadomościreturn_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.
