Własny transport Amazon SES i wyjście z trybu Sandbox krok po kroku

Dlaczego własny transport Amazon SES w regionie eu-central-1 zmienia ekonomię mailingu

Tradycyjne platformy do e-mail marketingu narzucają wielokrotną marżę na samą infrastrukturę wysyłkową, podnosząc drastycznie abonament wraz ze wzrostem bazy kontaktów i liczby wysyłanych newsletterów. Podłączenie własnego lub dedykowanego transportu Amazon Simple Email Service w Mailfly oddziela warstwę zaawansowanego oprogramowania marketingowego od hurtowego kosztu przesyłania pakietów SMTP i HTTP. W rezultacie koszt wysłania dziesięciu tysięcy wiadomości spada do poziomu jednego dolara według oficjalnego cennika chmury AWS.

Dla firm działających w Polsce i Unii Europejskiej kluczowe znaczenie ma wybór regionu przetwarzania danych eu-central-1 zlokalizowanego w centrach danych we Frankfurcie nad Menem. Korzystanie z europejskiego regionu AWS gwarantuje, że treść wiadomości, adresy e-mail odbiorców oraz logi zdarzeń dostarczalności nie opuszczają Europejskiego Obszaru Gospodarczego. Zapewnia to pełną zgodność z wymogami RODO oraz wytycznymi dotyczącymi lokalizacji przetwarzania danych osobowych.

Oprócz korzyści finansowych i prawnych bezpośrednia integracja z Amazon SES w regionie eu-central-1 zapewnia najniższe opóźnienia sieciowe do europejskich serwerów pocztowych, w tym do polskich operatorów takich jak Onet, WP, Interia czy o2, a także europejskich węzłów Gmaila i Microsoft 365. Po połączeniu konta w panelu Ustawienia Mailfly od razu pobiera aktualne parametry techniczne, takie jak limit dobowy na poziomie 61 700 maili na 24 godziny oraz maksymalne tempo wysyłki wynoszące 14 wiadomości na sekundę.

• Rozdzielenie warstwy kreacji i segmentacji od hurtowego transportu AWS SES obniża koszty wysyłki przy dużych bazach nawet o 80 procent.
• Lokalizacja infrastruktury w regionie eu-central-1 we Frankfurcie zapewnia pełną rezydencję danych na terenie Unii Europejskiej.
• Niskie czasy odpowiedzi sieciowej do polskich i europejskich serwerów MX przyspieszają dostarczanie wiadomości transakcyjnych i koszykowych.
• Panel Mailfly w czasie rzeczywistym odczytuje z API AWS aktualną kwotę dobową Max24HourSend oraz przepustowość MaxSendRate.

Weryfikacja tożsamości domeny i konfiguracja kluczy Easy DKIM 2048-bit

Pierwszym krokiem konfiguracji w konsoli Amazon SES po wybraniu regionu Frankfurt jest utworzenie nowej tożsamości typu Domain w sekcji Verified identities. Zamiast weryfikować pojedyncze adresy e-mail, należy uwierzytelnić całą domenę lub dedykowaną subdomenę wysyłkową, co pozwoli na używanie dowolnych adresów nadawcy w jej obrębie. Podczas tworzenia tożsamości należy wybrać metodę Easy DKIM i ustawić długość klucza kryptograficznego na poziomie RSA 2048 bitów.

Po zatwierdzeniu formularza Amazon SES wygeneruje trzy unikalne rekordy typu CNAME zawierające tokeny identyfikujące w nazwie hosta oraz docelowe adresy w domenie dkim.amazonses.com. Rekordy te należy przekopiować do panelu zarządzania strefą DNS swojej domeny, pamiętając o wyłączeniu proxy HTTP (pomarańczowej chmurki w Cloudflare) dla wszystkich trzech wpisów. Tylko czysty rekord CNAME pozwala serwerom AWS zweryfikować obecność kluczy publicznych i automatycznie zarządzać ich okresową rotacją.

W momencie gdy serwery DNS rozpropagują nowe wpisy, status DKIM configuration w konsoli AWS oraz w panelu Mailfly zmieni się na Verified, a każda wychodząca wiadomość otrzyma cyfrowy podpis kryptograficzny w nagłówku DKIM-Signature. Podpis ten stanowi dla filtrów antyspamowych Gmaila, Yahoo oraz polskich portali niepodważalny dowód, że wiadomość pochodzi od właściciela domeny i jej treść nie została zmodyfikowana w trakcie transportu przez internet.

• Weryfikacja całej domeny zamiast pojedynczych skrzynek pozwala dowolnie tworzyć adresy nadawców dla newsletterów i automatyzacji.
• Standard Easy DKIM z kluczem RSA 2048-bit zapewnia najwyższy poziom bezpieczeństwa kryptograficznego wymagany przez dostawców poczty.
• W strefie DNS Cloudflare rekordy CNAME dla DKIM muszą działać w trybie DNS Only bez pośrednictwa proxy HTTP.
• Amazon SES automatycznie przeprowadza rotację kluczy kryptograficznych bez konieczności ręcznej podmiany rekordów w przyszłości.

Konfiguracja Custom MAIL FROM, rekordu SPF oraz polityki DMARC Alignment

Domyślnie wiadomości wysyłane przez Amazon SES posiadają w kopertowym adresie zwrotnym Return-Path domenę techniczną amazonses.com. Choć przechodzi ona podstawową weryfikację SPF, to domena z koperty SMTP różni się od domeny widocznej dla odbiorcy w nagłówku From. Aby osiągnąć pełną zgodność identyfikatorów DMARC SPF Alignment i wzmocnić reputację własnej marki, należy skonfigurować w ustawieniach tożsamości SES dedykowaną subdomenę Custom MAIL FROM, na przykład bounce.twojadomena.pl lub mail.twojadomena.pl.

Aktywacja własnej domeny kopertowej wymaga dodania dwóch rekordów w strefie DNS dla wybranej subdomeny. Pierwszy to rekord MX o priorytecie 10 wskazujący na serwer feedback-smtp.eu-central-1.amazonses.com, który przejmuje obsługę asynchronicznych powiadomień o odbiciach zwrotnych. Drugi to rekord TXT z definicją SPF o wartości v=spf1 include:amazonses.com ~all przypisany bezpośrednio do tej subdomeny kopertowej.

Ostatnim elementem trójkąta uwierzytelniania jest publikacja rekordu DMARC pod nazwą _dmarc w głównej domenie nadawczej. Na początku wdrożenia warto ustawić politykę monitorującą p=none z adresem do odbioru raportów zagregowanych rua, a po potwierdzeniu stuprocentowej zgodności podpisów DKIM i SPF przejść na docelową politykę kwarantanny p=quarantine lub odrzucania p=reject. Tak skonfigurowana domena spełnia wszystkie rygorystyczne wymogi nadawców masowych wprowadzone przez Google i Yahoo.

• Subdomena Custom MAIL FROM ujednolica domenę z koperty SMTP z domeną widoczną w polu nadawcy From.
• Rekord MX dla subdomeny kopertowej musi wskazywać bezpośrednio na punkt odbioru odbić w regionie eu-central-1.
• Wyrównanie identyfikatorów jednocześnie po DKIM oraz SPF gwarantuje bezbłędne przejście weryfikacji DMARC na każdym serwerze.
• Stopniowe zaostrzanie polityki DMARC od p=none do p=reject chroni markę przed podszywaniem się przez oszustów phishingowych.

Czym jest tryb Sandbox w Amazon SES i jakie nakłada ograniczenia

Każde nowo utworzone konto w usłudze Amazon Simple Email Service w danym regionie geograficznym domyślnie startuje w izolowanym trybie testowym nazywanym SES Sandbox. Amazon stosuje to zabezpieczenie, aby uniemożliwić spamerom automatyczne zakładanie tysięcy kont chmurowych i natychmiastowe rozsyłanie niechcianej poczty. Dopóki konto znajduje się w piaskownicy, podlega trzem sztywnym ograniczeniom technicznym, które uniemożliwiają prowadzenie normalnych kampanii do klientów.

Po pierwsze, w trybie Sandbox wiadomości można wysyłać wyłącznie na adresy e-mail oraz domeny, które zostały wcześniej ręcznie dodane i zweryfikowane w sekcji Verified identities tego samego konta AWS. Próba wysłania maila do zewnętrznego subskrybenta z bazy sklepu zakończy się natychmiastowym błędem API MessageRejected z komunikatem informującym, że adres docelowy nie jest zweryfikowany. Po drugie, całkowity limit wysyłki wynosi zaledwie dwieście wiadomości w ciągu dwudziestu czterech godzin, a maksymalne tempo to jeden mail na sekundę.

Tryb Sandbox jest jednak doskonałym środowiskiem do przeprowadzenia wstępnej integracji z Mailfly przed startem produkcyjnym. Właściciel sklepu lub agencja może w tym czasie podłączyć klucze dostępowe, skonfigurować powiadomienia o odbiciach, zweryfikować rekordy DNS oraz wysłać testowe wiadomości na własną skrzynkę firmową, aby sprawdzić poprawność podpisów DKIM i renderowanie szablonów.

• W trybie Sandbox wysyłka działa wyłącznie do adresów e-mail uprzednio zweryfikowanych w konsoli AWS SES.
• Maksymalna dzienna kwota wysyłkowa w piaskownicy to 200 wiadomości na dobę przy przepustowości 1 wiadomości na sekundę.
• Ograniczenia trybu Sandbox są przypisane do konkretnego regionu AWS, dlatego wniosek produkcyjny składa się dla eu-central-1.
• Piaskownica pozwala bezpiecznie przetestować komunikację API z Mailfly oraz podpisy kryptograficzne przed otwarciem ruchu.

Procedura wyjścia z trybu Sandbox i wzór wniosku o dostęp produkcyjny

Aby odblokować wysyłkę do dowolnych odbiorców i uzyskać produkcyjne limity rzędu kilkudziesięciu tysięcy wiadomości na dobę, należy złożyć w konsoli AWS wniosek Request production access. Zespół bezpieczeństwa Amazon Web Services bardzo dokładnie weryfikuje każde zgłoszenie, odrzucając lakoniczne, jednozdaniowe prośby. Kluczem do otrzymania pozytywnej decyzji w ciągu kilkunastu godzin jest wcześniejsze ukończenie konfiguracji technicznej oraz szczegółowe opisanie legalnego procesu zbierania bazy.

Przed kliknięciem przycisku wysyłki wniosku należy bezwzględnie upewnić się, że domena nadawcza ma już status Verified dla kluczy DKIM, strona internetowa podana w formularzu działa pod protokołem HTTPS i posiada widoczną politykę prywatności, a w SES skonfigurowano obsługę odbić i skarg. W formularzu należy wybrać typ komunikacji Marketing lub Transactional, wskazać adres URL witryny firmowej oraz potwierdzić zgodność z warunkami usługi AWS.

W polu opisu Use case description należy po angielsku, konkretnie wyjaśnić, skąd pochodzą adresy odbiorców i jak działa higiena bazy w Mailfly. Należy wskazać, że subskrybenci zapisują się samodzielnie przez formularze z potwierdzeniem Double Opt-In lub podczas zakupów w sklepie internetowym, każda wiadomość zawiera nagłówek List-Unsubscribe-Post oraz widoczny link wypisu w stopce, a twarde odbicia i zgłoszenia spamu przekazywane przez Amazon SNS są automatycznie i natychmiastowo blokowane na liście supresji w bazie danych.

Po wyjściu z trybu testowego Sandbox produkcyjne masowe wysyłanie maili przez region eu-central-1 we Frankfurcie zapewnia przepustowość ponad sześćdziesięciu tysięcy wiadomości na dobę.

• Złożenie wniosku o wyjście z Sandboxa powinno nastąpić dopiero po pełnym zweryfikowaniu domeny, rekordów DKIM oraz DMARC.
• Opis przypadku użycia musi jasno wskazywać na metodę pozyskiwania zgód Double Opt-In oraz brak kupowanych list adresowych.
• W treści zgłoszenia należy wymienić automatyczną obsługę powiadomień Bounce i Complaint przez integrację Amazon SNS z Mailfly.
• Po akceptacji wniosku konto w regionie Frankfurt otrzymuje standardowy limit rzędu 50 000 do 61 700 maili na dobę oraz 14 maili na sekundę.

Zestawy konfiguracyjne Configuration Sets i routing zdarzeń przez Amazon SNS

Aby aplikacja Mailfly mogła w czasie rzeczywistym blokować nieistniejące adresy e-mail oraz rejestrować statusy doręczeń, konieczne jest skonfigurowanie zwrotnego kanału komunikacji z Amazon SES za pomocą usługi Amazon Simple Notification Service (SNS). W tym celu w konsoli SES tworzy się obiekt Configuration Set przypisany do domeny lub przestrzeni roboczej. Zestaw konfiguracyjny określa zestaw reguł postępowania ze zdarzeniami generowanymi podczas cyklu życia każdej wysłanej wiadomości.

W ustawieniach Event destinations danego zestawu konfiguracyjnego należy wybrać jako cel usługę Amazon SNS i zaznaczyć kluczowe typy zdarzeń: Hard Bounces (twarde odbicia), Soft Bounces (miękkie odbicia), Complaints (zgłoszenia spamu w pętlach zwrotnych Feedback Loop), Deliveries (potwierdzenia przyjęcia wiadomości przez serwer docelowy) oraz Rejects. Wszystkie te zdarzenia kieruje się do utworzonego w tym samym regionie eu-central-1 tematu SNS.

Następnie w konsoli Amazon SNS dodaje się subskrypcję protokołu HTTPS wskazującą na dedykowany punkt końcowy odbioru powiadomień w instalacji Mailfly. Podczas tworzenia subskrypcji AWS wysyła specjalny pakiet SubscriptionConfirmation zawierający adres URL potwierdzający. Punkt końcowy Mailfly automatycznie weryfikuje podpis kryptograficzny certyfikatu AWS, odczytuje token i potwierdza subskrypcję. Od tej chwili każde odbicie lub skarga spamowa w ułamku sekundy trafia do bazy danych i aktualizuje status subskrybenta.

• Configuration Set w Amazon SES grupuje reguły śledzenia dostarczalności i kieruje je do wybranego strumienia powiadomień.
• Subskrypcja HTTPS w Amazon SNS przesyła w czasie rzeczywistym obiekty JSON ze szczegółami zdarzeń Bounce, Complaint oraz Delivery.
• Endpoint odbiorczy w Mailfly automatycznie obsługuje pakiet SubscriptionConfirmation oraz weryfikuje autentyczność podpisu wiadomości SNS.
• Przypisanie osobnych Configuration Sets pozwala niezależnie monitorować reputację różnych domen i klientów w panelu.

Automatyczna obsługa twardych odbić i skarg spamowych chroniąca konto AWS

Amazon Web Services bardzo rygorystycznie pilnuje reputacji swoich adresów IP i nakłada na wszystkie konta SES twarde progi bezpieczeństwa. Wskaźnik odbić Bounce Rate na koncie nigdy nie powinien przekroczyć pięciu procent (poziom ostrzegawczy zaczyna się już przy dwóch procentach), natomiast wskaźnik skarg spamowych Complaint Rate musi pozostawać poniżej jednej dziesiątej procenta (0,1%), a ostrzeżenie pojawia się już przy poziomie 0,05%. Przekroczenie tych wartości skutkuje umieszczeniem konta na cenzurowanym lub całkowitym wstrzymaniem możliwości wysyłki.

Integracja Mailfly z powiadomieniami Amazon SNS stanowi automatyczną tarczę chroniącą konto przed przekroczeniem tych limitów. Gdy tylko serwer docelowy odrzuci wiadomość jako twarde odbicie typu Permanent Bounce (na przykład z podtypem General lub NoEmail), aplikacja natychmiast zmienia status kontaktu na odbijający i dopisuje go do twardej listy supresji przestrzeni roboczej. Żadna kolejna kampania ani reguła automatyzacji nie podejmie już próby wysyłki na ten adres.

Identyczny mechanizm bezpieczeństwa działa w przypadku odebrania zdarzenia Complaint, które powstaje, gdy odbiorca kliknie przycisk Zgłoś spam w swoim programie pocztowym. Mailfly w ułamku sekundy wycofuje zgodę marketingową dla takiego rekordu, zatrzymuje wszystkie aktywne ścieżki automatyczne i oznacza źródło wypisu jako skargę antyspamową. Dodatkowo na poziomie samego konta SES warto włączyć natywną listę Account-level suppression list dla zdarzeń Bounce i Complaint jako drugą warstwę zabezpieczenia.

• Utrzymanie wskaźnika odbić poniżej 2% oraz skarg spamowych poniżej 0,05% gwarantuje bezproblemowe działanie konta AWS SES.
• Odebranie zdarzenia Permanent Bounce z tematu SNS powoduje natychmiastowe i trwałe wykluczenie adresu z przyszłych wysyłek.
• Zgłoszenie wiadomości jako spam automatycznie wypisuje subskrybenta i zapisuje zdarzenie w raporcie kondycji bazy.
• Włączenie natywnej listy supresji na poziomie konta SES stanowi dodatkowe zabezpieczenie na wypadek błędów zewnętrznych.

Bezpieczna autoryzacja IAM: polityki najmniejszych uprawnień i sts:AssumeRole

Podłączanie infrastruktury Amazon SES do aplikacji zewnętrznej nigdy nie powinno odbywać się przy użyciu kluczy głównych właściciela konta Root ani konta IAM z pełnymi uprawnieniami administratora AdministratorAccess. Zgodnie z zasadą najmniejszych uprawnień Least Privilege dostęp dla silnika wysyłkowego należy ograniczyć wyłącznie do operacji niezbędnych do nadawania poczty oraz odczytu parametrów kwotowych i statystyk dostarczalności w API wersji drugiej SES v2.

W środowiskach wielopodmiotowych oraz przy podłączaniu kont AWS należących do klientów agencji najbezpieczniejszym wzorcem architektonicznym jest delegacja uprawnień między kontami za pomocą roli IAM oraz mechanizmu AWS Security Token Service sts:AssumeRole. Zamiast generować długoterminowe klucze Access Key ID oraz Secret Access Key, które mogłyby ulec zagubieniu, na koncie docelowym tworzy się rolę IAM z polityką zaufania Trust Policy wskazującą konto wykonawcze platformy.

Polityka zaufania wymaga podania unikalnego, kryptograficznie losowego parametru ExternalId przypisanego do konkretnej przestrzeni roboczej workspace_id w Mailfly. Kiedy serwer przygotowuje wysyłkę kampanii, wywołuje operację AssumeRole z odpowiednim identyfikatorem zewnętrznym i otrzymuje krótkotrwałe poświadczenia sesyjne ważne tylko przez kilkadziesiąt minut. Rozwiązanie to eliminuje przechowywanie stałych sekretów w bazie i pozwala klientowi w dowolnej sekundzie odwołać dostęp jednym kliknięciem w swojej konsoli AWS.

• Polityka IAM dla transportu powinna zezwalać wyłącznie na akcje ses:SendEmail, ses:SendRawEmail oraz odczyt limitów konta.
• Model autoryzacji sts:AssumeRole zastępuje statyczne klucze dostępowe tymczasowymi tokenami sesyjnymi o krótkim czasie życia.
• Wymagany warunek sts:ExternalId w polityce zaufania zapobiega problemowi Confused Deputy w architekturze wielopodmiotowej.
• Pełny dziennik wywołań API jest rejestrowany w usłudze AWS CloudTrail po stronie właściciela konta chmurowego.

Kontrola przepustowości wysyłki, kolejkowanie i obsługa limitu 14 maili na sekundę

Każde produkcyjne konto Amazon SES posiada ściśle określony parametr maksymalnego tempa wysyłki MaxSendRate, który dla świeżo odblokowanych kont wynosi zazwyczaj 14 wiadomości na sekundę, a wraz z budowaniem pozytywnej historii wzrasta do 50, 100 lub więcej maili na sekundę. Jeżeli aplikacja wysyłkowa spróbuje wypchnąć do API AWS sto żądań jednocześnie na koncie z limitem czternastu, serwer SES odrzuci nadmiarowe pakiety z błędem ThrottlingException (Maximum sending rate exceeded).

Silnik kolejkowania w Mailfly odpytuje punkt końcowy GetAccount w API Amazon SES przed startem kampanii i automatycznie kalibruje lokalny algorytm Token Bucket do aktualnej przepustowości konta z zachowaniem bezpiecznego marginesu na pilne wiadomości transakcyjne i koszykowe. Dzięki temu podczas wysyłki newslettera do bazy pięćdziesięciu tysięcy odbiorców aplikacja równomiernie podaje wiadomości z prędkością na przykład dwunastu sztuk na sekundę, zostawiając dwie jednostki przepustowości dla bieżących potwierdzeń z formularzy.

W przypadku przejściowego ograniczenia przepustowości lub chwilowego błędu sieciowego po stronie dostawcy chmury proces roboczy stosuje strategię wykładniczego wycofywania Exponential Backoff z losowym odchyleniem Jitter. Wiadomość nie przepada ani nie jest oznaczana jako odbicie, lecz wraca do kolejki z opóźnieniem kilku sekund i zostaje ponowiona bez tworzenia zatorów. Pozwala to bezbłędnie realizować bardzo duże wysyłki przy zachowaniu stuprocentowej stabilności połączenia.

Aby utrzymać niskie wskaźniki odbić i pełną kontrolę nad reputacją nadawcy, połącz chmurę AWS z aplikacją działającą jako narzędzie do wysyłania maili z automatyczną obsługą powiadomień SNS.

• Automatyczna synchronizacja z parametrem MaxSendRate dopasowuje prędkość pracy kolejki do aktualnych limitów konta SES.
• Rezerwacja pasma dla ruchu transakcyjnego gwarantuje, że duża kampania newsletterowa nie opóźni wysyłki maili z koszyka.
• Mechanizm Exponential Backoff z losowym Jitterem bezpiecznie obsługuje przejściowe błędy ThrottlingException bez utraty wiadomości.
• Wraz ze wzrostem limitów przyznawanych przez AWS prędkość wysyłek w Mailfly rośnie automatycznie bez zmian w kodzie.

Virtual Deliverability Manager oraz diagnostyka na poziomie pojedynczej wiadomości

Dla zespołów wymagających najgłębszej analityki dostarczalności Amazon SES udostępnia zaawansowany moduł Virtual Deliverability Manager (VDM). Narzędzie to rozbudowuje standardowe statystyki konta o szczegółowe wykresy skuteczności doręczeń w podziale na poszczególnych dostawców skrzynek pocztowych ISP, takich jak Gmail, Yahoo, Outlook.com czy polskie portale horyzontalne. Administrator od razu widzi, czy spadek otwarć wynika z ogólnego problemu z kreacją, czy dotyczy wyłącznie filtrów jednego konkretnego operatora.

Drugim filarem modułu VDM jest funkcja Message Insights, która pozwala prześledzić losy każdej pojedynczej wiadomości wysłanej w ciągu ostatnich dni. Wpisując adres e-mail odbiorcy lub identyfikator Message-ID, specjalista widzi dokładną oś czasu: moment przyjęcia pakietu przez API SES, czas dostarczenia do serwera docelowego wraz z odpowiedzią SMTP, informację o otwarciu wiadomości oraz ewentualne kliknięcia lub zgłoszenia w pętli zwrotnej.

Ponadto wbudowany doradca Guardian analizuje konfigurację wszystkich tożsamości na koncie i wykrywa subtelne anomalie infrastrukturalne, takie jak wygasające rekordy DNS, brakujące wyrównanie DMARC na jednej z subdomen czy nagły wzrost miękkich odbić wynikający z przepełnienia skrzynek w danej domenie. Połączenie tych danych z panelem Reputacji i ochrony w Mailfly daje pełny obraz kondycji wysyłkowej bez konieczności zgadywania przyczyn problemów.

• Virtual Deliverability Manager prezentuje twarde metryki dostarczalności w rozbiciu na konkretnych operatorów pocztowych ISP.
• Narzędzie Message Insights umożliwia inspekcję pełnej ścieżki doręczenia pojedynczego maila po jego identyfikatorze Message-ID.
• Moduł doradczy wykrywa luki w konfiguracji SPF, DKIM i DMARC oraz ostrzega o nietypowych skokach współczynnika odrzuceń.
• Analiza odpowiedzi serwerów docelowych pozwala szybko odróżnić problem z reputacją domeny od blokady konkretnego linku w treści.

Współdzielona pula adresów IP kontra dedykowane adresy IP w Amazon SES

Jednym z najczęstszych pytań podczas wdrażania Amazon SES jest wybór między domyślną pulą współdzielonych adresów IP (Shared IPs) a dzierżawą dedykowanych adresów IP (Dedicated IPs). Dla zdecydowanej większości sklepów internetowych, marek B2B oraz agencji wysyłających poniżej kilkuset tysięcy wiadomości miesięcznie z jednej domeny najlepszym i najbezpieczniejszym wyborem jest pozostanie na zarządzanej puli współdzielonej Amazonu.

Adresy IP z głównej puli Amazon SES charakteryzują się stałym, wysokim i przewidywalnym ruchem, który jest nieustannie monitorowany przez inżynierów AWS. Nowa domena podłączona do tej puli nie musi przechodzić wielotygodniowego procesu rozgrzewania samego adresu IP od zera, ponieważ serwery docelowe doskonale znają te klasy adresowe, a o umieszczeniu wiadomości w skrzynce odbiorczej decyduje przede wszystkim reputacja samej domeny nadawczej podpisanej kluczem DKIM.

Dedykowane adresy IP (zarówno w wariancie Standard, jak i Managed Dedicated IPs) mają uzasadnienie wyłącznie wtedy, gdy dany podmiot wysyła regularnie bardzo duże wolumeny przekraczające kilkaset tysięcy wiadomości tygodniowo i chce mieć stuprocentową izolację reputacji sieciowej. Przy niższych lub nieregularnych wysyłkach własny adres IP szybko traci historię u operatorów pocztowych i paradoksalnie może pogorszyć dostarczalność w porównaniu ze sprawdzoną pulą współdzieloną.

• Współdzielona pula adresów IP w Amazon SES jest optymalnym rozwiązaniem dla większości sklepów i firm wysyłających do kilkuset tysięcy maili.
• Współczesne filtry Gmaila i Microsoftu oceniają przede wszystkim reputację domeny nadawczej zweryfikowanej przez DKIM oraz DMARC.
• Dedykowany adres IP wymaga stałego, wysokiego i regularnego wolumenu wysyłek, aby utrzymać pozytywną ocenę u operatorów.
• Opcja Managed Dedicated IPs w AWS automatycznie steruje rozgrzewaniem adresów przy bardzo dużym ruchu korporacyjnym.

Plan rozgrzewania nowej domeny nadawczej (Domain Warm-up) po starcie

Nawet przy korzystaniu z doskonale ocenianej puli adresów IP w Amazon SES zupełnie nowa domena lub świeżo utworzona subdomena wysyłkowa nie posiada żadnej historii w systemach reputacyjnych Google Postmaster Tools oraz Microsoft SNDS. Nagłe wysłanie pięćdziesięciu tysięcy wiadomości pierwszego dnia z domeny, która nigdy wcześniej nie nadawała poczty, zostanie potraktowane przez algorytmy antyspamowe jako anomalia i spowoduje skierowanie większości kampanii do folderu Spam lub tymczasowe odrzucenia typu 421 Too many connections.

Rozgrzewanie domeny polega na stopniowym zwiększaniu dziennego wolumenu wysyłki przez pierwsze dwa do czterech tygodni, zaczynając od najbardziej zaangażowanych subskrybentów. W pierwszym tygodniu warto uruchomić wyłącznie automatyzacje e-commerce i formularze zapisu (gdzie wskaźnik otwarć przekracza pięćdziesiąt procent) oraz wysłać pierwszą kampanię do wąskiego segmentu osób, które dokonały zakupu lub kliknęły link w ciągu ostatnich trzydziestu dni.

W kolejnych dniach porcje wysyłkowe zwiększa się stopniowo z pięciuset do tysiąca, następnie dwóch i pół tysiąca, pięciu tysięcy, dziesięciu tysięcy aż do pełnej wielkości aktywnej bazy. Wysoki odsetek otwarć i kliknięć przy zerowym poziomie twardych odbić w pierwszych dniach buduje silny kredyt zaufania dla domeny. Po zakończeniu tego procesu filtry pocztowe uznają nowego nadawcę za wiarygodnego i bez przeszkód przyjmują pełne wolumeny kampanii promocyjnych.

• Rozgrzewanie nowej domeny należy zawsze zaczynać od uruchomienia wiadomości transakcyjnych, koszykowych i powitalnych o najwyższym zaangażowaniu.
• Pierwsze wysyłki newsletterowe kieruje się wyłącznie do segmentu najaktywniejszych odbiorców z ostatnich 30 dni.
• Dzienny wolumen wysyłek zwiększa się stopniowo co 2 lub 3 dni, obserwując na bieżąco wskaźnik odbić i otwarć w panelu.
• Rejestracja domeny w bezpłatnym narzędziu Google Postmaster Tools pozwala śledzić ocenę reputacji domeny u najważniejszego operatora.

Weryfikacja końcowa połączenia SES w panelu Ustawienia Mailfly

Po zakończeniu konfiguracji w konsoli AWS i wpisaniu parametrów dostępowych w panelu Mailfly należy przeprowadzić kompleksowy test weryfikacyjny w zakładce Ustawienia. Prawidłowo połączony system powinien wyświetlać zielony status komunikacji z regionem eu-central-1, wykrywać wyjście z trybu Sandbox oraz prezentować dokładne wartości limitów pobranych z konta, na przykład limit dobowy 61 700 wiadomości oraz maksymalne tempo 14 maili na sekundę.

Następnie należy sprawdzić tabelę zweryfikowanych tożsamości w dolnej części ekranu. Domena nadawcza musi posiadać status aktywnego podpisu DKIM oraz skonfigurowany rekord DMARC. Korzystając z funkcji wysyłki wiadomości testowej, warto nadać pojedynczy e-mail na zewnętrzne konto w usłudze Gmail, otworzyć widok Pokaż oryginał i osobiście potwierdzić obecność trzech wpisów PASS dla mechanizmów SPF, DKIM oraz DMARC.

Ostatnim krokiem testu technicznego jest weryfikacja pętli zwrotnej Amazon SNS za pomocą oficjalnych adresów symulacyjnych udostępnianych przez AWS, takich jak bounce@simulator.amazonses.com oraz complaint@simulator.amazonses.com. Wysłanie wiadomości na te adresy nie psuje prawdziwej reputacji konta, a pozwala w kilka sekund sprawdzić, czy wygenerowane przez symulator zdarzenie dotarło przez temat SNS do bazy danych Mailfly i poprawnie zablokowało testowy rekord.

• Sprawdzenie w panelu Ustawienia, czy aplikacja poprawnie odczytuje status produkcyjny konta oraz limity Max24HourSend i MaxSendRate.
• Wysłanie wiadomości kontrolnej na konto Gmail i weryfikacja nagłówków Authentication-Results pod kątem statusów SPF, DKIM i DMARC PASS.
• Przetestowanie odbioru powiadomień SNS przy użyciu bezpiecznych adresów symulatora pocztowego simulator.amazonses.com.
• Potwierdzenie obecności nagłówków List-Unsubscribe oraz List-Unsubscribe-Post w kodzie źródłowym odebranej wiadomości.