Gmail odrzuca Twoje maile? Trzy błędy konfiguracji domeny

Wyobraź sobie sytuację, w której Twój sklep internetowy lub aplikacja biznesowa nagle przestaje komunikować się z klientami. Wysyłane są potwierdzenia zamówień, powiadomienia o statusie przesyłki czy linki do resetowania haseł, ale żadna z tych wiadomości nie dociera do adresatów korzystających z poczty Gmail. Dla wielu właścicieli małych firm, zwłaszcza działających lokalnie na Śląsku – w Czechowicach-Dziedzicach, Bielsku-Białej czy Katowicach – taki scenariusz oznacza natychmiastowe straty finansowe i wizerunkowe. Klienci, nie otrzymując ważnych wiadomości, rezygnują z zakupów, a Ty tracisz kontrolę nad procesem sprzedaży.

Najgorsze w tym wszystkim jest to, że problem ten często pozostaje niewidoczny na pierwszy rzut oka. Serwer pocztowy może działać bez przerw przez wiele lat, aż do momentu, gdy nagle zacznie generować tysiące odrzuconych wiadomości. Powodem nie jest zmiana w kodzie Twojej strony, ale ewolucja globalnych standardów bezpieczeństwa poczty elektronicznej. Google sukcesywnie zaostrza politykę antyspamową, przez co konfiguracje domeny, które działały poprawnie przez lata, dzisiaj kwalifikują się do natychmiastowego zablokowania.

W tym artykule przeanalizujemy realny przypadek techniczny, w którym trzy niezależne mechanizmy uwierzytelniania domeny uległy awarii w tym samym czasie. Zobaczymy, jak brak prawidłowego rekordu SPF, błędy w konfiguracji PTR oraz cichy błąd w module OpenDKIM doprowadziły do odrzucenia niemal całej korespondencji przez Gmaila. Dowiesz się również, jak skutecznie zdiagnozować te problemy i dlaczego profesjonalne wsparcie od prowebcrafting.com jest kluczowe dla zachowania ciągłości biznesowej Twojej firmy.

Nowe wytyczne Gmaila a blokada wysyłki maili

W lutym 2024 roku Google wprowadziło nowe wytyczne dla nadawców wiadomości (Email sender guidelines), stopniowo zwiększając rygor ich egzekwowania. Zmiany te uderzyły bezpośrednio w serwery, które nie posiadały w pełni poprawnej konfiguracji uwierzytelniania. W analizowanym przypadku serwer, będący przekaźnikiem (outgoing relay) dla poczty transakcyjnej z kilkudziesięciu aplikacji, nagle zaczął odrzucać tysiące wiadomości. Dobowe podsumowanie logów wykazało czterocyfrową liczbę odrzuceń (bounced) przy zaledwie jednocyfrowej liczbie dostarczonych wiadomości. Wśród zablokowanych maili znalazły się kluczowe wiadomości resetujące hasła, co uniemożliwiło użytkownikom dostęp do ich kont.

Serwer pocztowy działał na starszym kontenerze z ponad dwuletnim czasem nieprzerwanej pracy (uptime), korzystając z oprogramowania Postfix oraz OpenDKIM w wersji 2.10.3. Ponieważ przez lata nikt nie modyfikował konfiguracji, administratorzy nie spodziewali się nagłej awarii. Jednak brak zmian w konfiguracji przy jednoczesnej zmianie wymagań po stronie Gmaila okazał się pułapką. Gmail zaczął zwracać jednoznaczny błąd odmowy dostarczenia:

550-5.7.26 Your email has been blocked because the sender is unauthenticated. 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM. 550-5.7.26 Authentication results : 550-5.7.26 DKIM = did not pass 550-5.7.26 SPF [example.org] with ip : [203.0.113.51] = did not pass

Komunikat ten jasno wskazuje, że zawiodły oba kluczowe mechanizmy uwierzytelniania: SPF oraz DKIM. Przyjrzenie się każdemu z nich z osobna pozwala zrozumieć skalę problemu.

Błąd 1: Przestarzały format i brak prawidłowego rekordu SPF

Pierwszym zidentyfikowanym problemem był brak poprawnego rekordu SPF (Sender Policy Framework) dla domeny. SPF to rekord TXT w strefie DNS, który wskazuje, jakie adresy IP są uprawnione do wysyłania wiadomości e-mail w imieniu danej domeny. W badanym przypadku jedynym rekordem przypominającym SPF był przestarzały wpis typu SenderID o strukturze spf2.0/mfrom,pra.

Zgodnie z oficjalnym standardem RFC 7208, serwery pocztowe mają obowiązek odrzucić każdy rekord SPF, który nie zaczyna się dokładnie od frazy v=spf1. Ponieważ domena korzystała z martwego standardu SenderID, systemy Gmaila potraktowały ją tak, jakby w ogóle nie posiadała skonfigurowanego rekordu SPF. To natychmiast przełożyło się na negatywny wynik weryfikacji i przyczyniło do zablokowania dostarczania poczty.

Błąd 2: Niezgodność rekordu PTR i błąd FCrDNS

Kolejną barierą nie do przejścia okazała się konfiguracja odwrotnego DNS (Reverse DNS). Gmail wymaga, aby serwer wysyłający pocztę przeszedł pomyślnie test FCrDNS (Forward-Confirmed Reverse DNS). Oznacza to, że adres IP wysyłający wiadomość musi posiadać rekord PTR wskazujący na konkretną nazwę hosta, a ta nazwa hosta musi z kolei posiadać rekord A wskazujący z powrotem na ten sam adres IP.

W analizowanym przypadku Gmail zwracał następujący błąd:

550-5.7.25 [203.0.113.51] The IP address sending this message does not have a PTR record setup, or the corresponding forward DNS entry does not match the sending IP

Choć wstępne notatki diagnostyczne sugerowały, że rekord PTR jest poprawny, szczegółowa weryfikacja wykazała błąd. Rekord PTR wskazywał na hosta legacy.example.org, jednak jego rekord A prowadził do adresu IP 198.51.100.216 – czyli zupełnie innej maszyny niż serwer wysyłający pocztę (którego rzeczywisty adres IP to 203.0.113.51). Zgodnie z wytycznymi RFC 1912 sekcja 2.1, taka konfiguracja jest błędna i skutkuje natychmiastowym odrzuceniem wiadomości przez rygorystyczne filtry antyspamowe.

Błąd 3: Cichy błąd OpenDKIM i pułapka refile

Trzecim i najbardziej czasochłonnym w diagnozie problemem okazała się konfiguracja podpisywania wiadomości kluczem DKIM (DomainKeys Identified Mail). Moduł OpenDKIM nie podpisywał żadnych wychodzących wiadomości, mimo że usługa działała, a pliki konfiguracyjne ładowały się bez widocznych błędów. Przyczyną była błędna definicja tabel kluczy i podpisów w pliku konfiguracyjnym.

Tabele KeyTable oraz SigningTable zostały podpięte z przedrostkiem refile:, podczas gdy ich zawartość była zapisana w zwykłym formacie dwukolumnowym (np. example.org mail._domainkey.example.org). Użycie parametru refile: instruuje OpenDKIM, że klucze w tabeli są wyrażeniami regularnymi (regex), które należy dopasować do całego adresu nadawcy. W efekcie domena example.org nigdy nie dopasowywała się do adresu takiego jak noreply@example.org. Dopiero zmiana tego parametru na zwykłe file: rozwiązała ten problem.

Diagnozę utrudniał fakt, że OpenDKIM w przypadku braku znalezienia klucza dla danego adresu nie zapisuje absolutnie żadnych informacji w logach systemowych. Daemon uruchamiał się poprawnie, konfiguracja była parsowana bez błędów, klucze były czytelne, a poczta mimo to opuszczała serwer bez podpisu cyfrowego. Dodatkowo, plik InternalHosts zawierał mniej niż dziesięć adresów IP, podczas gdy parametr mynetworks w Postfixie był dwu- lub trzykrotnie dłuższy. Sprawiało to, że poczta z niektórych hostów aplikacyjnych była jedynie weryfikowana przez OpenDKIM zamiast być podpisywana.

Dlaczego standardowe testy diagnostyczne mogą Cię zmylić?

Podczas rozwiązywania problemów z dostarczalnością poczty łatwo wpaść w pułapki diagnostyczne, które wydłużają czas przestoju. W opisywanym przypadku administratorzy popełnili kilka kluczowych błędów w ocenie sytuacji:

• Testowanie lokalne: Ręczne wysyłanie wiadomości testowych za pomocą polecenia sendmail bezpośrednio z serwera pocztowego kończyło się sukcesem. Działo się tak, ponieważ adres pętli zwrotnej 127.0.0.1 znajdował się w pliku InternalHosts. Tymczasem rzeczywisty ruch z innych hostów aplikacyjnych wychodził niepodpisany.
• Brak nagłówków w logach: Próba sprawdzenia podpisów za pomocą komendy grep -c DKIM-Signature /var/log/mail.log zwracała wartość 0 niezależnie od tego, czy podpisywanie działało. Postfix domyślnie nie zapisuje nagłówków wiadomości do logu systemowego.
• Nieaktualna dokumentacja wewnętrzna: Notatki techniczne sporządzone dzień wcześniej zawierały błędne informacje, jakoby DNS był hostowany na Cloudflare, a domena nie posiadała rekordu DMARC. W rzeczywistości zapytanie dig NS wykazało serwery Route 53 (AWS), a rekord DMARC istniał od samego początku z polityką monitorującą (v=DMARC1; p=none).

Co to oznacza dla małej firmy?

Dla właściciela małej firmy, który nie jest specjalistą IT, powyższe szczegóły techniczne mogą brzmieć skomplikowanie, ale ich konsekwencje biznesowe są niezwykle proste i bolesne. Jeśli prowadzisz działalność na Śląsku, np. w Bielsku-Białej, Katowicach czy Czechowicach-Dziedzicach, i opierasz swoją sprzedaż na kontakcie mailowym, każda niedostarczona wiadomość to utracony zysk. Klienci korzystający z Gmaila po prostu nie dowiedzą się o statusie swojego zamówienia, nie otrzymają faktury ani nie będą mogli zalogować się do swojego konta z powodu braku maila z resetem hasła.

Wiele małych firm korzysta z serwerów pocztowych, które zostały skonfigurowane lata temu i od tamtej pory nie były aktualizowane. W świetle nowych zasad wprowadzonych przez Google w 2024 roku, takie systemy stają się tykającą bombą zegarową. Naprawienie tylko jednego elementu (np. dodanie rekordu SPF) nie przyniesie rezultatu, jeśli pozostałe elementy (DKIM lub PTR) nadal będą błędnie skonfigurowane. Dopiero kompleksowy audyt i precyzyjne wdrożenie wszystkich standardów gwarantują, że Twoje maile nie będą odrzucane.

Podsumowanie

Bezpieczeństwo i dostarczalność poczty elektronicznej to fundament nowoczesnego biznesu. Przypadek cichego błędu OpenDKIM oraz problemów z rekordami SPF i PTR pokazuje, jak drobne niedopatrzenia w konfiguracji mogą sparaliżować komunikację z klientami. Aby uniknąć strat wizerunkowych i finansowych, warto powierzyć zarządzanie infrastrukturą sieciową profesjonalistom. Zespół prowebcrafting.com oferuje kompleksowe wsparcie w zakresie optymalizacji, automatyzacji oraz wdrażania bezpiecznych rozwiązań internetowych dla małych i średnich firm, dbając o to, aby Twoje wiadomości zawsze trafiały bezpośrednio do skrzynek odbiorczych Twoich klientów.

Zdjęcie: Brett Sayles / Pexels