skuteczność dostarczania wg domeny

Jak czytać różnice między dostawcami poczty

Różnica wyników między domenami często wynika z odmiennych mechanizmów filtrowania. Gmail, Outlook.com, Yahoo i dostawcy poczty firmowej mogą inaczej oceniać reputację adresu IP, domeny nadawczej, częstotliwość wysyłki oraz historię interakcji z wiadomościami. Ten sam e-mail może zostać zaakceptowany przez jeden serwer, czasowo odrzucony przez drugi i odrzucony trwale przez trzeci. Przy porównywaniu domen trzeba więc analizować nie tylko procentową skuteczność, ale również liczbę wysłanych wiadomości oraz rodzaje odpowiedzi serwerów.

Odbicie stałe, często oznaczane jako hard bounce, wskazuje zwykle na problem, którego ponawianie wysyłki nie rozwiąże, na przykład nieistniejący adres lub trwałe odrzucenie polityki domeny. Odbicie tymczasowe, czyli soft bounce, może wynikać z pełnej skrzynki, chwilowej niedostępności serwera, limitu połączeń albo ograniczenia tempa wysyłki. W raportach warto zachować pełny kod odpowiedzi SMTP, komunikat serwera i czas zdarzenia. Sam opis „wiadomość niedostarczona” nie wystarcza do rozróżnienia błędu adresu od czasowej blokady.

Do wiarygodnej oceny potrzebna jest odpowiednia próba. Wynik dla domeny, do której wysłano pięć wiadomości, nie ma takiej samej wartości jak wynik dla kilku tysięcy odbiorców. Należy również ustalić, czy obliczenia uwzględniają ponowienia wysyłki. Jeżeli system liczy każdą próbę osobno, jedna niedostarczona wiadomość może sztucznie zwiększyć liczbę błędów. Jeżeli liczy tylko adresata końcowego, wynik może wyglądać lepiej, ale ukrywać liczne problemy z kolejką SMTP.

DNS, uwierzytelnianie i reputacja nadawcy

Jedną z pierwszych kontroli jest konfiguracja DNS domeny nadawczej. Rekord SPF określa, które serwery mogą wysyłać pocztę w imieniu domeny. DKIM dodaje do wiadomości podpis kryptograficzny, który odbiorca weryfikuje na podstawie klucza publicznego opublikowanego w DNS. DMARC definiuje sposób sprawdzania zgodności domeny użytej w adresie From z wynikami SPF lub DKIM oraz wskazuje politykę dla wiadomości, które nie przejdą kontroli. Błąd w którymkolwiek z tych elementów może powodować odrzucenia albo obniżenie zaufania, szczególnie u dostawców stosujących rygorystyczne filtry.

Wynik według domeny może pogorszyć się także wtedy, gdy serwer wysyła wiadomości z adresu IP o słabej reputacji. Znaczenie mają wcześniejsze odbicia, zgłoszenia spamu, nagłe zwiększenie wolumenu oraz wysyłanie na nieaktywne adresy. Dodatkowym sygnałem jest poprawna odwrotna rezolucja DNS, czyli rekord PTR przypisujący nazwę hosta do adresu IP. Nie istnieje jednak jeden uniwersalny test, który samodzielnie potwierdza dostarczalność. Diagnostyka wymaga zestawienia logów SMTP, rekordów DNS, nagłówków odebranych wiadomości i raportów zwrotnych dostawców.

Warto sprawdzać również opóźnienia. Serwer może zwrócić odpowiedź tymczasową z kodem 4xx, a następnie przyjąć wiadomość po kilku minutach lub godzinach. Kod z grupy 5xx oznacza zwykle trwałe odrzucenie, lecz dokładna interpretacja zależy od treści komunikatu. Jeżeli raport grupuje wszystkie kody w jedną kategorię, nie pokazuje, czy problemem jest błędna konfiguracja, limit częstotliwości, blokada reputacyjna czy nieprawidłowy adres odbiorcy.

Diagnostyka wyników na komputerze i w aplikacji pocztowej

Analizę można rozpocząć od eksportu raportu z systemu wysyłkowego i pogrupowania zdarzeń według domeny odbiorcy, kodu SMTP, typu błędu oraz czasu wystąpienia. Następnie należy porównać te dane z logami aplikacji. Jeżeli aplikacja zapisuje status „wysłano” już po przekazaniu wiadomości do lokalnej kolejki, taki status nie oznacza jeszcze zaakceptowania przez zewnętrzny serwer. Prawidłowy model powinien rozróżniać co najmniej utworzenie wiadomości, przekazanie do serwera nadawczego, odpowiedź serwera odbiorcy oraz późniejsze powiadomienie o odbiciu.

Na komputerze użytkownika można zweryfikować, czy panel raportowy pokazuje aktualne dane, czy filtr domeny nie pomija wariantów zapisanych wielkimi literami oraz czy strefa czasowa nie przesuwa zdarzeń do innego dnia. Przydatne jest otwarcie pełnych nagłówków przykładowej wiadomości i sprawdzenie pól Authentication-Results, Received, Return-Path oraz Message-ID. Nie należy usuwać nagłówków ani zmieniać treści przed analizą, ponieważ utrudnia to powiązanie wiadomości z wpisem w logu. Test w przeglądarce może wykazać problem z wyświetlaniem raportu, ale nie zastąpi kontroli odpowiedzi SMTP i konfiguracji DNS.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, dlatego w przypadku problemów z lokalnym programem pocztowym, przeglądarką, siecią lub odczytem raportów można sprawdzić stan systemu, połączenie internetowe oraz konfigurację aplikacji. Sama naprawa komputera nie zmienia reputacji domeny nadawczej ani polityki dostawcy poczty, ale pozwala oddzielić błąd urządzenia użytkownika od rzeczywistego problemu po stronie wysyłki.