Ich e-maile wciąż znikały. Przenieśliśmy pocztę sklepu do Google Workspace, a o sukcesie zdecydowały szczegóły

Zgłoszenie przyszło w typowy dla takich problemów sposób: bez konkretów. Niektórzy klienci nie dostawali naszych odpowiedzi. Użytkownicy Gmaila nie mieli problemów. Co jakiś czas wiadomość wracała z adnotacją niedostarczona. A jeden dostawca, hurtownia, w której sklep robi zakupy, mógł bez problemu pisać do sklepu, ale sklep nie mógł mu odpowiedzieć.

Chodzi o niewielki sklep specjalistyczny, którym się opiekujemy. Jedna wspólna skrzynka firmowa z wieloletnią historią, kilka osób czytających pocztę na komputerach i telefonach oraz sklep internetowy wysyłający potwierdzenia zamówień z tego samego adresu. Nikt nie chce tam zaprzątać sobie głowy pocztą. Ma po prostu docierać.

Opisujemy, jak rozwiązaliśmy ten problem: bez danych pozwalających rozpoznać firmę, za to z kolejnymi krokami, pułapkami, które ominęliśmy, i kontrolami, które zalecamy po każdej takiej przeprowadzce. W skrócie: przenieśliśmy skrzynkę do Google Workspace, a stronę zostawiliśmy na dotychczasowym hostingu, zmieniając tylko jej ustawienia poczty. Warto jednak poznać całą historię, bo większość pracy pochłonęły szczegóły wymagające dodatkowego dopracowania: przełączenie DNS, dziesiątki tysięcy starych wiadomości, folder Wysłane i powiadomienia z samego sklepu.

Wszystkie testy wypadały dobrze, a poczta wciąż znikała

Pierwsze, co zwykle się sprawdza, to uwierzytelnianie, więc od tego też zaczęliśmy. SPF przechodził poprawnie. DKIM też. DMARC również, z polityką p=none, która prosi odbiorców, by w ogóle nie podejmowali działań w razie niepowodzenia kontroli DMARC. Na papierze domena była skonfigurowana prawidłowo, a problemy trwały od miesięcy mimo pozytywnych wyników tych kontroli.

Przyczyna tkwiła o poziom dalej. Wszystko, z czego korzystał sklep (DNS domeny, strona i skrzynka), znajdowało się u jednego dostawcy hostingu współdzielonego. Poczta wychodząca nie była wysyłana z własnego serwera sklepu. Przechodziła przez współdzielony serwer pośredniczący dostawcy, jeden z tej samej niewielkiej grupy serwerów, przez które wysyła pocztę wielu innych klientów. A adres serwera przekazującego wiadomości sklepu znalazł się na publicznej liście blokad antyspamowych.

Sposób dostarczania wiadomości pasował do tego wpisu: odbiorcy korzystający z takich list odrzucają pocztę z umieszczonego na nich adresu lub kierują ją do spamu, niezależnie od poprawności podpisu, podczas gdy Gmail opiera się głównie na własnych danych o reputacji. Nie widzieliśmy samego komunikatu odrzucenia z hurtowni, ale po jej stronie wszystko zachowywało się dokładnie tak, jak przy filtrze korzystającym z tej listy.

Problemem nigdy nie było uwierzytelnianie. Była nim reputacja współdzielonego serwera pośredniczącego.

Jeśli chcesz przeprowadzić taką samą diagnostykę swojej domeny, te polecenia pozwolą ci sprawdzić większość rzeczy. Adres IP odczytasz z wiersza Received:, który serwer odbierający dodał do wiadomości wysłanej przez ciebie na twój własny adres Gmail (otwórz ją, a następnie wybierz Pokaż oryginał (Show original)).

# Kto odbiera twoją pocztę i co mówią SPF oraz DMARC?
dig +short MX example-shop.com
dig +short TXT example-shop.com | grep -i spf
dig +short TXT _dmarc.example-shop.com

# Czy serwer, który wysłał twoją wiadomość, jest na liście blokad?
# To tylko przykład: odwróć rzeczywisty adres IP nadawcy, 203.0.113.25 staje się 25.113.0.203
dig 25.113.0.203.bl.spamcop.net A +noall +comments +answer
# status NOERROR z 127.0.0.2 = na liście; status NXDOMAIN = w tej chwili poza listą;
# SERVFAIL, REFUSED lub przekroczenie czasu oczekiwania = brak odpowiedzi, użyj wyszukiwarki na stronie samej listy

Jedna praktyczna uwaga: niektóre listy blokad, w tym Spamhaus, odmawiają odpowiedzi na zapytania przechodzące przez duże publiczne resolwery DNS i zamiast tego zwracają kod błędu. Poza tym takie zapytanie sprawdza jedną listę w danym momencie, a nie całą dostarczalność twojej poczty.

Dlaczego przenieśliśmy pocztę i tylko pocztę

Poczta i hosting strony to osobne usługi, które po prostu często sprzedaje się razem. Przenoszenie strony to projekt z ryzykiem przestoju, rozgrzewaniem pamięci podręcznej i wieloma zależnymi elementami. Przenoszenie poczty to zmiana DNS i import. Strona sklepu działała, więc zostawiliśmy ją na dotychczasowym hostingu i rozwiązaliśmy problem, który faktycznie doskwierał.

Rozważyliśmy cztery możliwości:

Polecilibyśmy obie te duże usługi. Wybraliśmy Workspace z prostego powodu: osoby korzystające ze skrzynki znały już Gmaila, a im mniej mały zespół musi się uczyć, tym szybciej przyzwyczai się do zmiany.

Zostawiliśmy też skrzynkę firmową jako osobnego użytkownika Workspace, zamiast łączyć ją z czyimkolwiek kontem prywatnym. Adres firmowy działający w czyimś prywatnym Gmailu trudno przekazać, skontrolować i odzyskać, gdy ta osoba odchodzi. Jeśli kilka osób potrzebuje własnego logowania zamiast jednego wspólnego, delegowanie dostępu w Gmailu pozwala im pracować we wspólnej skrzynce z własnych kont. O dostępie pisaliśmy w artykule o tym, co się dzieje, gdy pracownik odchodzi, a jego dostęp zostaje.

Zanim ruszysz DNS: przygotowanie

Samo przełączenie zajmuje kilka minut. Od przygotowania zależy, czy te minuty będą nudne, czy nerwowe.

• Zapisz stan całej strefy DNS. Wyeksportuj ją lub zapisz każdy rekord, żeby móc dokładnie odtworzyć poprzednie wpisy. Pamiętaj, że cofnięcie zmian wpływa tylko na miejsce dostarczania nowych wiadomości: wszystko, co w międzyczasie dotarło do Google, tam zostanie.
• Spisz wszystkie adresy, na które przychodzi poczta. Skrzynki, aliasy, przekierowania, grupy, reguły catch-all. Gdy rekord MX wskaże Google, każdy z tych adresów musi istnieć również tam, inaczej poczta będzie wracać do nadawców. W tym sklepie była tylko jedna skrzynka i nic więcej, więc lista była krótka.
• Spisz wszystko, co wysyła pocztę w imieniu twojej domeny. Programy pocztowe na komputerach i telefonach, sklep internetowy (potwierdzenia zamówień, formularz kontaktowy, resetowanie haseł), narzędzia do fakturowania, konta na platformach marketplace. Każdy z tych elementów musi działać po przełączeniu.
• Dzień wcześniej obniż TTL rekordu MX do 300 sekund. MX sklepu miał TTL wynoszący cztery godziny, co oznaczało, że inne serwery pocztowe mogły pamiętać stary adres docelowy jeszcze przez cztery godziny po zmianie.
• Dodaj rekord TXT weryfikacji Google i dokończ aktywację Gmaila w konsoli administracyjnej (Admin console). Rekord weryfikacyjny znajduje się obok rekordu SPF. Domena może mieć wiele rekordów TXT, ale tylko jeden z nich może być rekordem SPF.
• Włącz weryfikację dwuetapową dla administratora Workspace i użytkownika skrzynki oraz schowaj kody zapasowe w bezpiecznym miejscu, zanim poczta zacznie napływać.

Przełączenie, rekord po rekordzie

Oto wprowadzone zmiany. Nazwy używane w sklepie zastąpiliśmy przykładowymi.

W rekordzie SPF zachowaj wszystkie mechanizmy, których nadal potrzebują aktywni nadawcy, i dopisz obok nich include Google. Obowiązuje jeden rekord SPF dla danej nazwy i nie więcej niż dziesięć zapytań DNS łącznie po uwzględnieniu wszystkich include.

Dwa szczegóły zasługują na osobny akapit. Po pierwsze, klucz DKIM jest dłuższy niż 255 znaków, które może pomieścić pojedynczy ciąg tekstowy DNS. Nadal musi to być jeden rekord TXT: niektóre panele DNS automatycznie dzielą go na kilka ciągów w cudzysłowach w obrębie tego rekordu, w innych musisz zrobić to samodzielnie. Porównaj opublikowaną wartość z konsolą administracyjną znak po znaku, a następnie kliknij Rozpocznij uwierzytelnianie (Start authentication) w sekcji Aplikacje, Google Workspace, Gmail, Uwierzytelniaj pocztę e-mail (Apps > Google Workspace > Gmail > Authenticate email). Na zupełnie nowym koncie Workspace Google może potrzebować co najmniej doby, zanim pozwoli wygenerować klucz.

Po drugie, nie polegaj na własnym resolwerze przy sprawdzaniu, czy przełączenie się udało. Zapytaj bezpośrednio każdy autorytatywny serwer nazw:

# Zapytaj każdy serwer nazw domeny, jaki rekord MX obecnie zwraca
for ns in $(dig +short NS example-shop.com.); do
  printf '%s\n' "$ns"
  dig @"$ns" example-shop.com. MX +norecurse +noall +comments +answer
done
# W każdym bloku szukaj flagi "aa" (odpowiedź autorytatywna) i nowego rekordu MX

Gdy to sprawdziliśmy, jeden serwer nazw zaczął zwracać Google w ciągu kilku sekund. Pozostałe trzy jeszcze przez około dwadzieścia minut podawały stary MX, z tym samym numerem seryjnym strefy. Nigdy nie ustaliliśmy dlaczego. Gdybyśmy sprawdzili tylko własny resolwer, uznalibyśmy sprawę za zamkniętą i przeoczylibyśmy dwadzieścia minut, podczas których poczta wciąż szła starą drogą.

Jeden serwer nazw odpowiadał adresem Google po kilku sekundach. Pozostałe trzy potrzebowały około dwudziestu minut.

Licz się też z opóźnionymi dostarczeniami. Serwery pocztowe, które sprawdziły stary MX przed zmianą lub miały wiadomości w kolejce do ponownej próby, mogą jeszcze przez pewien czas dostarczać je do starej skrzynki. Dlatego w okresie przejściowym utrzymuj obie skrzynki, obserwuj starą i ponawiaj import, aż przestaną trafiać do niej nowe wiadomości. W panelach hostingowych takich jak cPanel sprawdź też ustawienie routingu poczty dla domeny: jeśli konto hostingowe nadal uważa, że obsługuje pocztę domeny, wiadomości wysyłane ze strony na twój własny adres mogą trafić lokalnie do starej skrzynki.

Jak przenieść 40 000 wiadomości i nie zgubić ani jednej

Stara skrzynka zawierała 39 840 wiadomości w 27 folderach, łącznie około 13 GB, z wielu lat: faktury od dostawców, zamówienia z platform marketplace, powiadomienia od kurierów, rozmowy z klientami. Utrata czegokolwiek nie wchodziła w grę, podobnie jak tydzień z folderami zaimportowanymi do połowy.

Import to łatwa część. Dopiero weryfikacja pozwala powiedzieć, że nic nie zginęło.

Zaczęliśmy od wbudowanego narzędzia migracji danych Google, które łączy się ze starym serwerem przez IMAP i kopiuje wszystko do nowej skrzynki. Działa, ale przy tej skrzynce miało trzy problemy:

• Szybkość. Około 2 400 wiadomości na godzinę, co dla tej skrzynki oznaczało ponad szesnaście godzin. Z tego, co mogliśmy zaobserwować, narzędzie pobierało jedną wiadomość na sesję IMAP i nie udostępniało ustawienia szybkości.
• Braki. Przy kilku folderach pojawił się komunikat „crawl failure” z wewnętrznym błędem synchronizacji, a zalecenie sprowadzało się do ponownego uruchomienia migracji później.
• Błędne daty. 925 wiadomości pochodziło od jednego nadawcy, którego system pocztowy zapisuje nieprawidłowy nagłówek Date (sekundy bez zera na początku i brak strefy czasowej, na przykład 2 Apr 2024 18:36:4), a dwie kolejne w ogóle nie miały nagłówka Date. Migracja przypisała im czas importu, więc wiadomości sprzed lat pojawiły się na górze skrzynki odbiorczej, jakby przyszły tego ranka.

Dokończyliśmy więc pracę własnym importerem, opartym na API importu Gmaila, nad którym mieliśmy pełną kontrolę:

• Źródło tylko do odczytu. Starą skrzynkę otwieraliśmy w trybie tylko do odczytu, a każdą wiadomość pobieraliśmy bez ustawiania flagi „seen”. Na starym serwerze nic się nie zmieniło, więc nadal stanowił sprawny wariant awaryjny.
• Pomijanie tego, co już dotarło. Każdą wiadomość sprawdzaliśmy po Message-ID wśród wiadomości obecnych w Gmailu, dzięki czemu importer nie kopiował tego, co przeniosła już migracja Google.
• Foldery stają się etykietami. Stary folder taki jak INBOX.Invoices stawał się etykietą Gmaila Invoices, więc zespół znajdował wszystko tam, gdzie się spodziewał.
• Możliwość wznowienia. Plik stanu zapisywał postęp, więc po przerwaniu można było wznowić pracę bez zaczynania od nowa.
• Własna data wiadomości. Wiadomości z prawidłowym nagłówkiem Date zajmowały miejsce w chronologii zgodnie z nim, a nie z dniem importu.

Jeszcze jeden szczegół, który widać już pierwszego dnia: flagi. Oznaczenia gwiazdką nie przeniosły się podczas importu, a zespół, który od lat używa gwiazdek jako listy zadań, od razu zauważa ich brak. Dopasowaliśmy 530 oznaczonych wiadomości ze starej skrzynki do ich kopii w Gmailu i ponownie dodaliśmy im gwiazdki.

Folder Wysłane wymagał osobnego planu

Po samej dostarczalności to na tej części najbardziej zależało właścicielowi sklepu. Po przejściu do Gmaila z folderem Wysłane pojawiły się trzy osobne problemy.

1. Gmail sam zdecydował, co uznać za wysłane

W tej skrzynce każda zaimportowana wiadomość z jej własnego adresu pojawiała się w folderze Wysłane. Później zaobserwowaliśmy to samo przy kopiach dostarczanych przez serwer pośredniczący. Po imporcie dotyczyło to także wieloletniej historii automatycznych powiadomień sklepu, bo potwierdzenia zamówień zawsze wychodziły z adresu firmowego. W folderze Wysłane nagle znalazło się około 1 950 wiadomości, których nikt nie napisał, wymieszanych z prawdziwymi odpowiedziami zespołu.

Rozpoznaliśmy wiadomości generowane przez sklep po nagłówkach programu wysyłającego i wszystkie 1 959 przenieśliśmy z Wysłanych do właściwych etykiet poleceniem przenoszenia IMAP. W tej skrzynce przeniesienie wiadomości z folderu Wysłane usuwało jej etykietę Wysłane, czyli dokładnie to, czego potrzebowaliśmy. Najpierw sprawdziliśmy to na małej partii. W folderze Wysłane znów została wyłącznie poczta napisana przez ludzi.

Gmail umieścił powiadomienia sklepu w Wysłanych. Ich przeniesienie sprawiło, że zespół znów mógł wygodnie korzystać z tego folderu.

2. Nowa poczta sklepu znów by go zapełniła

Najbardziej oczywisty sposób wysyłania poczty sklepu przez Google to użycie danych logowania do samej skrzynki na smtp.gmail.com. To działa, ale od tego dnia każde potwierdzenie zamówienia znów trafia do Wysłanych. Zamiast tego sklep wysyła przez usługę przekaźnika SMTP (SMTP relay service) Google (smtp-relay.gmail.com), którą administrator konfiguruje w konsoli administracyjnej w sekcji Aplikacje, Google Workspace, Gmail, Routing:

• Dozwoleni nadawcy (Allowed senders): Tylko adresy z moich domen (Only addresses in my domains)
• Wymagaj uwierzytelniania SMTP (Require SMTP authentication)
• Wymagaj szyfrowania TLS (Require TLS encryption)

Kompleksowe przechowywanie poczty (Comprehensive mail storage), ustawienie administratora w sekcji Gmail, Zgodność (Compliance), było na tym koncie wyłączone, a przekazywane wiadomości nie pojawiały się w folderze Wysłane nadawcy. Włączenie tego ustawienia zapisuje kopie przekazywanej poczty w skrzynkach użytkowników. Jeśli masz obowiązek przechowywania korespondencji, przyjrzyj się temu ustawieniu i Google Vault.

3. Zespół nadal chce widzieć, co wysłał sklep

Porządek w folderze Wysłane cieszy do chwili, gdy klient zadzwoni i zapyta, co było w jego potwierdzeniu. Dlatego dzięki niewielkiemu fragmentowi kodu dodanemu w sklepie każda pomyślnie wysłana wiadomość uruchamia teraz wysyłkę jednej kopii na adres głównej skrzynki z dopiskiem po plusie (office+shop@). Kopia przychodzi z osobnego adresu w domenie (shop@), który w ogóle nie jest skrzynką. Jego nazwa wyświetlana zawiera pierwotnych odbiorców („Do: customer@...”), a Reply-To wskazuje klienta, więc odpowiedź trafia tam, gdzie powinna.

Filtr Gmaila z warunkiem deliveredto:office+shop@example-shop.com pomija folder Odebrane, oznacza kopię jako przeczytaną i nadaje jej etykietę Wysłane - sklep. Po co inny adres nadawcy? Z powodu opisanego w punkcie 1: w tej skrzynce kopie z jej własnego adresu trafiały do Wysłanych nawet wtedy, gdy przychodziły przez serwer pośredniczący. Powiadomienia, które sklep wysyła własnym pracownikom, również wychodzą z shop@, więc trafiają do Odebranych, gdzie ktoś faktycznie je przeczyta.

Warto znać jedno ograniczenie: Gmail nie pozwala umieścić etykiety wewnątrz Wysłanych. Wysłane - sklep znajduje się obok na liście etykiet. Właściciel sklepu zaakceptował to, gdy poznał przyczynę.

Programy pocztowe na komputerach

Kilka ustawień zdecydowało o tym, czy usłyszymy „Thunderbird działa wolno od czasu przeprowadzki”, czy program będzie działał sprawnie:

• Synchronizuj mniej. Gmail pokazuje każdą etykietę jako folder IMAP, więc jedna wiadomość może być pobierana kilka razy. W ustawieniach Gmaila, w sekcji Etykiety (Labels), odznacz „Pokaż w IMAP” (Show in IMAP) przy folderach, których zespół nie używa na komputerach, takich jak Ważne. Uważaj na folder Wszystkie: zarchiwizowane wiadomości są tylko tam, więc jeśli zespół archiwizuje pocztę w Gmailu, pozostaw folder Wszystkie widoczny, a zamiast tego ogranicz pobieranie wiadomości do pracy offline w programie pocztowym.
• Nie pozwalaj programowi zapisywać drugiej kopii wysłanej poczty. Przy kontach wysyłających przez Gmaila to Gmail zachowuje już każdą wysłaną wiadomość. Sprawdź, czy wiadomość testowa pojawia się w folderze Wysłane, a następnie wyłącz zapisywanie kopii przez program, który w przeciwnym razie przesyła każdą wiadomość drugi raz.
• Wycofaj stare konto z programu. Usuń je po ostatnim imporcie albo przynajmniej zmień jego nazwę, żeby nikt z przyzwyczajenia nie odpowiadał ze starego serwera.

Poczta sklepu w ustawieniach PrestaShop

Niezależnie od tego, na czym działa twój sklep, ustawienia serwera pośredniczącego mają to samo znaczenie. W PrestaShop 1.7 i 8 znajdziesz je w „Advanced Parameters”, „E-mail” (nazwy mogą się nieco różnić między wersjami):

Adres e-mail samego sklepu, ustawiony w „Shop Parameters”, musi należeć do twojej domeny, inaczej serwer pośredniczący go odrzuci. Wyślij wiadomość testową z tej samej strony ustawień, otwórz ją w Gmailu, wybierz Pokaż oryginał i sprawdź trzy pozytywne wyniki: SPF, DKIM z podpisem twojej własnej domeny oraz DMARC. Opisana wyżej kopia archiwalna nie jest częścią tych ustawień: w tym sklepie wymagała dodatkowego kodu, a PrestaShop nie tworzy jej standardowo. Więcej o ustawieniach poczty PrestaShop znajdziesz w naszym poradniku konfiguracja poczty w PrestaShop: SMTP, Gmail i e-maile transakcyjne.

Po przełączeniu: zamknięcie starych dróg dostępu

Migracja kończy się wtedy, gdy nic już nie zależy od starego systemu i nikt nie może użyć go przez pomyłkę. Oto lista, według której pracujemy po takiej przeprowadzce:

• Zaostrz SPF, gdy kilka spokojnych dni pokaże, że nic już nie wysyła przez stary serwer: usuń include poprzedniego dostawcy.
• Zachowaj niezależny eksport starej skrzynki, zanim stara usługa zostanie wyłączona, i ustaw dla starej skrzynki długie, losowe hasło, żeby nikt nie korzystał z niej z przyzwyczajenia.
• Unieważnij wszystkie tymczasowe dane dostępu użyte podczas przeprowadzki: hasła do aplikacji służące do importu, klientów API, tokeny hostingu.
• Upewnij się, że raporty DMARC rzeczywiście docierają (rekord musi zawierać adres do raportów), czytaj je przez kilka tygodni, a potem zmień politykę z p=none na quarantine.
• Rozważ Google Postmaster Tools, aby obserwować odsetek zgłoszeń spamu i reputację w Gmailu. Przy niewielkiej liczbie wysyłek danych może być tam mało, dlatego nadal śledź zwrotki i informacje od odbiorców.
• Zapisz, gdzie co się znajduje: DNS, administrator Workspace, ustawienia serwera pośredniczącego, filtry. Następna osoba, która się tym zajmie, będzie ci wdzięczna, nawet jeśli będziesz nią ty za dwa lata.

Efekt

Poczta sklepu wychodzi teraz przez infrastrukturę Google, podpisana własną domeną sklepu. SPF, DKIM i DMARC przechodzą poprawnie, hurtownia znów dostaje odpowiedzi, a zgłoszenia o niedostarczonych wiadomościach ustały. Jedyna zwrotka w pierwszych dniach po przełączeniu dotyczyła potwierdzenia konta wysłanego na fałszywy adres, który bot wpisał w formularzu rejestracyjnym. Taką zwrotkę akurat chcesz dostać.

Skrzynka odbiorcza zespołu wygląda jak dawniej, a każda stara wiadomość jest tam, gdzie powinna. Folder Wysłane zawiera to, co napisali ludzie. Powiadomienia sklepu mają własną etykietę, dostępną jednym kliknięciem, gdy zadzwoni klient.

I jeszcze jeden szczegół, o którym uczciwie wspominamy: pierwszego dnia nasze własne wiadomości testowe do nowej skrzynki trafiły do Spamu. Pochodziły z naszego niewielkiego serwera z bezbłędnym uwierzytelnianiem i bardzo krótką historią wysyłek. Nie znamy powodów decyzji Gmaila, ale ta krótka historia jest najbardziej prawdopodobnym wyjaśnieniem. To ta sama lekcja, która płynie z całej historii: poprawne uwierzytelnianie nie oznacza jeszcze zaufania.

Najczęściej zadawane pytania

Źródła

• Google: konfiguracja rekordów MX dla Google Workspace
• Google: poczta wychodząca przez serwer pośredniczący SMTP Google
• Google: limity wysyłania Gmaila w Google Workspace
• Google: ustaw DKIM
• Google: kompleksowe przechowywanie poczty
• API Gmaila: importowanie wiadomości