Odbicia, odrzucenia i limitowanie: jak sklasyfikować błąd SMTP

Pierwsze 15 minut

1. Zachowaj pełny raport NDR i oddziel odbiorców konsumenckich z Outlook.com od odbiorców Exchange Online lub Microsoft 365.
2. Pogrupuj niepowodzenia według usługi odbiorcy, rozszerzonego kodu statusu, pełnej diagnostyki, adresu IP nadawcy, domeny i okna czasowego.

Teraz

• Wstrzymaj ponowienia bez zmian dla trwałych niepowodzeń i wybierz działania naprawcze na podstawie pełnej diagnostyki.

Najbliższe 24 godziny

• Jeśli Exchange Online zgłasza Delivery not authorized, popraw ograniczenie odbiorcy lub regułę transportu wskazaną w NDR.
• Jeśli RESOLVER.RST.AuthRequired dotyczy folderu publicznego z obsługą poczty, popraw dla tego odbiorcy konfigurację nadawców zewnętrznych.

Najbliższe 7 dni

• Dla niepowodzeń z konsumenckich kont Outlook.com napraw konkretną zwróconą diagnostykę, korzystając z aktualnych dowodów: adresu IP, domeny, uwierzytelniania, listy, zgłoszeń spamu i treści.

Kontrole techniczne

Kryteria weryfikacji

• Po zmianie zdiagnozowanego stanu kontrolowana wiadomość do tej samej kohorty usługi odbiorcy nie zwraca już tego samego trwałego NDR. Nie traktuj ponownej wysyłki bez zmian jako weryfikacji.

Kryteria eskalacji

• Eskaluj RESOLVER.RST.AuthRequired do administratora Exchange odpowiedzialnego za folder publiczny, którego dotyczy problem, albo eskaluj sprawę Outlook.com z pełną diagnostyką i aktualnymi dowodami po stronie nadawcy.

Zapobieganie

• Zachowaj pełną diagnostykę Microsoftu i monitoruj niepowodzenia osobno dla usługi konsumenckiej Outlook.com oraz zasad dzierżawy Exchange Online.

Wpływ na biznes

• Wiadomości, których dotyczy problem, kończą się trwałym niepowodzeniem, chyba że zmieni się sama wiadomość albo warunki po stronie miejsca docelowego. Ponowne wysłanie ich bez zmian prawdopodobnie nie zadziała.

Uwagi dostawcy

• Exchange Online 5.7.1 Delivery not authorized może wskazywać na ograniczenia odbiorcy albo odrzucenie przez regułę transportu, podczas gdy RESOLVER.RST.AuthRequired może wskazywać folder publiczny odrzucający nadawców zewnętrznych.

Otwarte pytania

• Nie podano pełnego tekstu NDR, rozszerzonego podkodu, nazwy odrzucającego hosta, usługi odbiorcy, której dotyczy problem, adresu IP i domeny nadawcy ani rozkładu w czasie.
• Filtrowanie po stronie konsumenckiej Outlook.com i zasady dzierżawy Exchange Online to różne obszary Microsoftu; nie można ich diagnozować jako jednego zachowania dostawcy.

Pierwsze 15 minut

1. Zachowaj pełne odpowiedzi SMTP z Gmaila i pogrupuj je według diagnostyki: limitów żądań, uwierzytelniania, DNS, zasad i formatu wiadomości.
2. Na podstawie dokładnej diagnostyki ustal, czy 421 4.7.28 dotyczy adresu IP, domeny SPF czy domeny DKIM.
3. Porównaj surowe logi z ESP z opóźnionym panelem Delivery Errors w Postmaster Tools, ale nie traktuj brakujących danych o niskim wolumenie jako aktualnego dowodu.

Teraz

• Ogranicz objęty problemem wolumen do Gmaila, dopóki błędy SMTP są podwyższone, i przerwij ponawianie bez zmian trwałych błędów 5xx.

Najbliższe 24 godziny

• Napraw konfigurację SPF, DKIM lub DMARC wskazaną przez diagnostykę 550 5.7.26 albo konfigurację PTR i forward DNS wskazaną przez 550 5.7.25.

Najbliższe 7 dni

• Wolumen do Gmaila zwiększaj powoli i dopiero po spadku wskaźnika błędów SMTP, a jeśli błędy utrzymują się przy niskim wolumenie, sprawdzaj pojedyncze wiadomości.

Kontrole techniczne

Kryteria weryfikacji

• Surowe wskaźniki błędów SMTP z Gmaila spadają, zanim zwiększysz wolumen, a każdy utrzymujący się błąd przy niskim wolumenie sprawdzasz wiadomość po wiadomości.
• Opóźniony widok Delivery Errors w Postmaster Tools z czasem potwierdza odrzucony i tymczasowo nieprzyjęty ruch uwierzytelniony, gdy wolumen jest wystarczający, by pojawiły się dane.

Kryteria eskalacji

• Eskaluj sprawę do ESP lub właściciela dostarczalności, gdy pełna diagnostyka z Gmaila pozostaje niesklasyfikowana albo jest sprzeczna z danymi o błędach dostarczania ruchu uwierzytelnionego.

Zapobieganie

• Utrzymuj prawidłowy rekord PTR i zgodny forward DNS dla każdego adresu IP wysyłającego do Gmaila.
• Wprowadzaj zmiany wolumenu w sposób kontrolowany i natychmiast ograniczaj ruch, gdy rosną odbicia lub odroczenia z Gmaila.

Wpływ na biznes

• Ruch do Gmaila, którego dotyczy incydent, może zostać tymczasowo zlimitowany z powodu nietypowego wolumenu niezamówionych wiadomości albo trwale odrzucony ze względu na uwierzytelnianie, DMARC, zasady, reputację lub format wiadomości.

Otwarte pytania

• Nie podano surowych odpowiedzi SMTP, rozkładu kodów, podziału na adresy IP lub domeny, zmiany wolumenu wysyłki, wyniku uwierzytelniania ani kohorty odbiorców.
• Postmaster Tools może działać z opóźnieniem lub pomijać dane o niskim wolumenie, więc sam jego panel nie ustali aktualnej przyczyny odbić.
• Obecne zarchiwizowane źródło FAQ Gmaila (snapshot) dokumentuje tymczasowy kod 4.7.32, a nie rzekomy trwały kod 5.7.32 dotyczący zgodności domen, więc łączone twierdzenie nie jest w pełni potwierdzone w źródle.

Pierwsze 15 minut

1. Zachowaj nazwę odrzucającego hosta, pełną rozszerzoną odpowiedź, odbiorców objętych incydentem, wysyłające IP i domenę, identyfikatory wiadomości oraz znacznik czasu.
2. Potwierdź, że rozszerzony kod to 5.7.1, i skorzystaj z pełnej diagnostyki dostawcy, aby zawęzić przyczynę do zasad albo autoryzacji.

Teraz

• Wstrzymaj ponowienia bez zmian, ponieważ trwały błąd klasy 5 wymaga zmiany stanu wiadomości albo miejsca docelowego.

Najbliższe 24 godziny

• Dla Gmaila usuń konkretną przyczynę wskazaną w pełnej diagnostyce — zasady odbiorcy, niezamówioną pocztę, reputację lub zniekształcony nagłówek; dla Exchange Online popraw autoryzację odbiorcy albo regułę transportu wskazaną w NDR.

Najbliższe 7 dni

• Prowadź osobne ścieżki naprawcze dla Gmaila i Exchange Online, ponieważ ten sam kod 5.7.1 oznacza różne warunki u różnych dostawców.

Kontrole techniczne

Kryteria weryfikacji

• Po usunięciu konkretnej przyczyny nieagresywna, kontrolowana wiadomość daje nowy wynik SMTP, zanim wznowisz normalny wolumen, a niezmieniony odrzucany ruch nie jest wielokrotnie ponawiany.

Kryteria eskalacji

• Eskaluj sprawę Exchange Online do administratora dzierżawy odbiorcy, gdy NDR wskazuje autoryzację albo regułę transportu; wsparciu innego dostawcy prześlij zachowaną nazwę hosta, pełną odpowiedź, odbiorców, tożsamość nadawcy, identyfikatory wiadomości i znacznik czasu.

Zapobieganie

• Zachowuj pełną diagnostykę dostawcy, blokuj automatyczne ponowienia bez zmian dla trwałych błędów i wymagaj kontrolowanego, pomyślnego wyniku SMTP, zanim przywrócisz normalny wolumen.

Wpływ na biznes

• Wiadomości, których dotyczy problem, pozostaną niedostarczone, dopóki nie zmieni się stan samej wiadomości albo miejsca docelowego; ponowna wysyłka bez zmian prawdopodobnie się nie powiedzie.

Uwagi dostawcy

• Zarówno Gmail, jak i Exchange Online używają 5.7.1 dla wielu różnych warunków, więc o działaniach naprawczych decydują pełny tekst diagnostyczny i kontekst NDR.

Otwarte pytania

• Niedostępne są: odrzucający dostawca, pełna diagnostyka SMTP, odbiorcy objęci incydentem, wysyłające IP i domena, próbka wiadomości oraz okno czasowe.
• Ten sam kod 550 5.7.1 odpowiada różnym warunkom zasad u dostawcy i w dzierżawie; naprawa nie może być uniwersalna.

Pierwsze 15 minut

1. Zachowaj pełny NDR, rozszerzony kod stanu, odpowiedź zdalnego serwera, typ odbiorcy oraz serwer, który wygenerował raport.
2. Przestań powtarzać to samo odrzucone żądanie SMTP w niezmienionej postaci.
3. Jeśli adresowanie i uwierzytelnianie po stronie nadawcy nie tłumaczą NDR, przekaż niezbędne minimum dowodów administratorowi Exchange po stronie odbiorcy — zatwierdzonym kanałem.

Teraz

• Po sprawdzeniu adresowania i uwierzytelniania po stronie nadawcy eskaluj niewyjaśnione przypadki do administratora Exchange po stronie odbiorcy, dołączając pełny NDR.

Najbliższe 24 godziny

• Jeśli potwierdzisz regułę przepływu poczty po stronie odbiorcy, poproś tę organizację o przejrzenie lub zmianę reguły, o ile nadawca powinien być dopuszczony.

Najbliższe 7 dni

• Przy potwierdzonym przypadku AuthRequired dla folderu publicznego poproś organizację odbiorcy o poprawienie ustawienia zarządzania dostarczaniem, jeśli poczta zewnętrzna ma być przyjmowana.

Kontrole techniczne

Kryteria weryfikacji

• Po usunięciu udokumentowanej przyczyny sprawdź, czy nowa sekwencja poleceń jest przyjmowana i nie zwraca już tego samego pełnego NDR 5.7.1.
• Jeśli przyczyną jest reguła lub folder publiczny, potwierdź, że konfiguracja po stronie odbiorcy dopuszcza już zamierzonego nadawcę i dany typ odbiorcy.

Kryteria eskalacji

• Eskaluj niewyjaśnione przypadki do administratora Exchange po stronie odbiorcy, dołączając pełny NDR, ponieważ nadawcy zewnętrzni nie mają wglądu w reguły, uprawnienia, łączniki i ograniczenia odbiorców w dzierżawie.

Zapobieganie

• Zachowuj pełne pola NDR, aby późniejsze incydenty 5.7.1 można było kierować według ich dokładnej przyczyny, a nie na podstawie samego kodu.
• Przeglądaj reguły przepływu poczty, które odrzucają zamierzonych nadawców, i utrzymuj aktualne warunki dla dozwolonych nadawców.

Wpływ na biznes

• Wiadomości, których dotyczy problem, nie zostały przyjęte, co może zatrzymać proces biznesowy zależny od dostarczenia poczty do tych odbiorców.

Uwagi dostawcy

• Microsoft dokumentuje kilka przyczyn w rodzinie kodów 5.7.x w Exchange Online; lokalny Exchange i bramy innych producentów mogą dla tego samego kodu liczbowego używać innego tekstu.
• Folder publiczny z włączoną obsługą poczty może zwrócić 550 5.7.1 AuthRequired, gdy skonfigurowano go tak, by wymagał uwierzytelnionych nadawców.

Otwarte pytania

• Nie mamy pełnego NDR, rozszerzonego kodu stanu, odpowiedzi zdalnego serwera, serwera, który wygenerował raport, typu odbiorcy ani topologii Exchange, więc dokładna przyczyna 5.7.1 pozostaje nieznana.
• Exchange Online, lokalny Exchange, łączniki hybrydowe i bramy innych producentów mogą przypisywać samej odpowiedzi 550 5.7.1 różne znaczenia i różne poprawki.

Pierwsze 15 minut

1. Zapisz przyczynę zdarzenia Deferred, w tym kod odpowiedzi SMTP serwera odbierającego oraz jego opis.
2. Policz czas dostarczania end-to-end na podstawie znaczników czasu przetworzenia i dostarczenia dla ukończonych wiadomości. Opóźnienie wiadomości niedostarczonych pozostaw otwarte.
3. Przy limitach tempa lub połączeń 421 lub 450 tymczasowo zmniejsz wolumen wysyłany do domeny odbiorcy, której dotyczy problem.

Teraz

• Pozwól, aby standardowa kolejka odroczeń SendGrid ponowiła tymczasowy błąd po stronie operatora pocztowego, zachowując przy tym historię zdarzeń.

Najbliższe 24 godziny

• Jeśli dokładną przyczyną jest limit tempa lub połączeń 421 lub 450, tymczasowo zmniejsz wolumen wysyłany do tej domeny odbiorcy.

Najbliższe 7 dni

• Utrzymuj tempo wysyłki na poziomie domeny dopasowane do obserwowanej przepustowości operatora odbierającego, zanim wrócisz do normalnego wolumenu.

Kontrole techniczne

Kryteria weryfikacji

• Sprawdź, czy zdarzenia odroczone przechodzą w dostarczone i czy czas dostarczania end-to-end wraca do poziomu bazowego nadawcy.
• Potwierdź, że wiadomości nie pozostają odroczone przez pełny 72-godzinny okres ponawiania i nie zmieniają statusu na zablokowany.

Kryteria eskalacji

• Eskaluj sprawę do SendGrid, gdy wiadomości zbliżają się do końca 72-godzinnego cyklu ponawiania albo gdy dokładna odpowiedź zachowuje się niezgodnie z udokumentowaną dla niej klasą tymczasową lub trwałą.

Zapobieganie

• Zachowuj przyczyny zdarzeń Deferred oraz znaczniki czasu przetworzenia i dostarczenia, aby każdy incydent dało się zawęzić według odpowiedzi i opóźnienia end-to-end.
• Dla domen, które zwracają limity tempa lub połączeń, ogranicz strumień objęty problemem, zamiast wysyłać dalej z tym samym tempem.

Wpływ na biznes

• Utrzymujące się odroczenia opóźniają pocztę o krótkim oknie ważności, a wiadomość wciąż odroczona przez cały 72-godzinny okres ponawiania w SendGrid zmienia status na zablokowany.

Uwagi dostawcy

• SendGrid ponawia odroczenia od operatorów pocztowych z wykładniczym backoffem przez maksymalnie 72 godziny.
• Wiadomość, która pozostaje odroczona przez cały ten okres, zmienia status na zablokowany.

Otwarte pytania

• Nie podano dokładnej odpowiedzi SMTP, domeny odbiorcy, liczby wiadomości objętych incydentem, znaczników czasu przetworzenia i dostarczenia, adresu IP SendGrid ani obecnego wieku ponowienia.
• Przyczyny throttlingu po stronie operatora odbierającego oraz oczekiwania co do ponawiania bywają różne; 72-godzinnego cyklu życia SendGrid nie wolno uogólniać na innego ESP.

Pierwsze 15 minut

1. Zanotuj trzycyfrowy kod odpowiedzi, rozszerzony kod statusu, treść odpowiedzi, etap SMTP, odbiorcę i historię prób.
2. Tymczasowe odpowiedzi 421 i 451 kieruj do kolejki ponowień. Udokumentowane odpowiedzi 550 klasyfikuj jako odrzucone.

Teraz

• Odpowiedzi Gmaila 4xx kolejkuj do ponowienia w ramach budżetu. Identyczne ponowienia 5xx wstrzymaj do czasu usunięcia udokumentowanej przyczyny.

Najbliższe 24 godziny

• Przejrzyj reguły kierowania ponowieniami, tak aby to wiodąca klasa odpowiedzi decydowała, czy wiadomość zostaje ponowiona, czy wstrzymana do naprawy.

Najbliższe 7 dni

• Zapisuj w kolejkach operacyjnych pełną treść odpowiedzi dostawcy i rozszerzony kod statusu, aby działanie naprawcze i moment ponowienia pozostały dopasowane do konkretnej przyczyny.

Kontrole techniczne

Kryteria weryfikacji

• Reprezentatywne odpowiedzi 421 i 451 są zapisywane jako błędy tymczasowe i kierowane do ponowienia.
• Reprezentatywne udokumentowane odpowiedzi 550 są rejestrowane jako odrzucone, a nie odroczone.

Kryteria eskalacji

• Eskaluj sprawę do ESP lub właściciela dostarczalności, gdy udokumentowane tymczasowe odpowiedzi Gmaila utrzymują się mimo wykorzystania budżetu ponowień albo gdy z pełnej odpowiedzi nie da się ustalić przyczyny 550.

Zapobieganie

• Zachowuj pełną odpowiedź SMTP i przy każdej próbie dostarczenia do Gmaila wymuszaj kierowanie ponowieniami według klasy odpowiedzi.

Wpływ na biznes

• Tymczasowe odpowiedzi 421 lub 451 opóźniają dostarczenie, natomiast udokumentowane odpowiedzi 550 związane z odbiorcą lub zasadami odrzucają wiadomość i mogą uniemożliwić jej dotarcie do odbiorcy.

Uwagi dostawcy

• Gmail w swojej dokumentacji opisuje 421 4.3.0 i 451 4.3.0 jako tymczasowe, natomiast 550 5.1.1 i wymienione przypadki 550 5.7.1 to odrzucenia.

Otwarte pytania

• Nie podano dokładnego trzycyfrowego kodu odpowiedzi, rozszerzonego kodu statusu, treści odpowiedzi, etapu SMTP, liczby odbiorców ani historii prób.
• Moment ponowienia po odpowiedzi 4xx zależy od konkretnej treści odpowiedzi Gmaila, zasad Retry-After lub kolejki oraz historii kolejnych prób; nie ma tu jednego, uniwersalnego opóźnienia.
• Po wprowadzeniu poprawki wiadomość, która otrzymała 5xx, może dać się dostarczyć, ale powtarzanie identycznego żądania bez usunięcia jego przyczyny jest niezgodne ze standardem SMTP.

Pierwsze 15 minut

1. Zbierz znormalizowane klasy odbić sprzed i po migracji, surowe odpowiedzi SMTP, domeny skrzynek, wysyłające adresy IP, wyniki uwierzytelniania i wolumen ruchu.
2. Uzgodnij nową platformę z poprzednim stanem wykluczeń u dostawcy, uwzględniając zachowanie zależne od dostawcy i regionu.

Teraz

• Zmniejsz objęty problemem wolumen kierowany do Gmaila, a jeśli problem utrzymuje się przy niskim wolumenie, przyjrzyj się pojedynczym błędom.

Najbliższe 24 godziny

• Popraw brakującą autoryzację SPF i zaimportuj do wdrożonego dostawcy wymagany stan wykluczeń z tytułu odbić, zgłoszeń spamu i nieprawidłowych adresów.

Najbliższe 7 dni

• Zwiększaj wolumen zmodyfikowanego segmentu osobno, zamiast po zmianie infrastruktury od razu przenosić pełny wolumen.

Kontrole techniczne

Kryteria weryfikacji

• Wskaźnik błędów SMTP dla Gmaila spada przy zmniejszonym wolumenie, zanim zaczniesz powoli zwiększać ruch.
• Nowe wiadomości przechodzą poprawioną autoryzację nadawcy, a wykluczenia nieprawidłowych odbiorców pozostają aktywne u wdrożonego dostawcy.

Kryteria eskalacji

• Eskaluj sprawę do ESP lub do kanału dostarczalności operatora pocztowego, gdy błędy utrzymują się przy niskim wolumenie mimo uzgodnienia surowych kodów, uwierzytelniania, reputacji IP i stanu wykluczeń.

Zapobieganie

• Wprowadzaj przyszłe zmiany infrastruktury etapami, jako osobne segmenty ruchu, zamiast migrować od razu pełnym wolumenem.
• Uwzględnij migrację uwierzytelniania i stanu wykluczeń na liście kontrolnej przełączenia platformy.

Wpływ na biznes

• Filtrowanie ruchu z nierozgrzanych adresów IP, masowe odroczenia lub ruch kierowany do nieprawidłowych odbiorców mogą po migracji uniemożliwić prawidłowej poczcie dotarcie do odbiorców.

Uwagi dostawcy

• Stan wykluczeń na poziomie konta Amazon SES jest ograniczony do jednego konta AWS w bieżącym regionie.
• SendGrid utrzymuje włączone wykluczenia z tytułu odbić i nieprawidłowych adresów, aby chronić reputację nadawcy.

Otwarte pytania

• Nie dostarczono taksonomii odbić sprzed i po migracji, surowych odpowiedzi SMTP, wysyłających adresów IP, wyników uwierzytelniania, tempa narastania ruchu, kohorty odbiorców ani rekordu importu wykluczeń.
• Zmiana platformy może ujawnić naraz kilka niezależnych przyczyn — nierozgrzane adresy IP, zmiany uwierzytelniania, zmiany wolumenu lub stan wykluczeń w zakresie dostawcy — więc bez posegmentowanych dowodów nie należy wskazywać jednej przyczyny.
• Nazwy odbić i zachowanie wykluczeń różnią się w zależności od ESP; porównuj znormalizowaną klasę, surowy kod dostawcy i domenę skrzynki, a nie sam ogólny wskaźnik.

Pierwsze 15 minut

1. Wyeksportuj na poziomie odbiorcy typ odbicia, podtyp, rozszerzony status, tekst diagnostyczny, raportujące MTA oraz adres IP zdalnego MTA.
2. Pogrupuj te zdarzenia według kampanii, domeny odbierającej, dostawcy i czasu, aby zlokalizować zmianę.
3. Natychmiast zmniejsz wolumen do Gmaila, jeśli poczta do tej kohorty odbija się lub jest odraczana.

Teraz

• Wyklucz odbiorcę natychmiast dopiero wtedy, gdy zdarzenie zostanie wiarygodnie sklasyfikowane jako trwałe twarde odbicie.
• Ogranicz tempo objętego problemem ruchu do Gmaila, dopóki jego błędy SMTP nie spadną.

Najbliższe 24 godziny

• Wyklucz wiarygodnie sklasyfikowane trwałe twarde odbicia i utrzymuj zmniejszony wolumen do Gmaila, dopóki błędy SMTP nie spadną.

Najbliższe 7 dni

• Zwiększaj wolumen do Gmaila powoli, dopiero po spadku jego wskaźnika błędów SMTP.

Kontrole techniczne

Kryteria weryfikacji

• Dowody na poziomie odbiorcy wskazują klasę odbicia i kohortę, których dotyczy problem, zamiast pozostawiać jedynie zbiorczy procent.
• Wskaźnik błędów SMTP dla Gmaila spada przy zmniejszonym wolumenie i pozostaje pod kontrolą, gdy powoli zwiększasz wolumen.

Kryteria eskalacji

• Eskaluj sprawę do ESP lub osoby odpowiedzialnej za dostarczalność, gdy nie da się wiarygodnie zebrać ani pogrupować pól diagnostycznych na poziomie odbiorcy.
• Eskaluj utrzymujące się błędy Gmaila do przeglądu na poziomie pojedynczych wiadomości, gdy nie ustępują nawet przy niskim wolumenie.

Zapobieganie

• Automatycznie wykluczaj odbiorców po wiarygodnie sklasyfikowanym trwałym twardym odbiciu.
• Stosuj wyraźny opt-in, potwierdzaj adresy, sprawdzaj, czy odbiorcy są nadal zainteresowani, i rozważ usunięcie niezaangażowanych subskrybentów Gmaila.

Wpływ na biznes

• Odbiorcy, których dotyczy problem, mogą nie otrzymać wiadomości transakcyjnych, operacyjnych lub marketingowych; wpływ mierz liczbą nieudanych prób dostarczenia i celem wiadomości, a nie założoną kwotą przychodu.

Uwagi dostawcy

• Gmail zaleca zmniejszenie wolumenu, dopóki błędy SMTP nie spadną, a potem powolne zwiększanie; inni operatorzy mogą wymagać innych mechanizmów kontroli.

Otwarte pytania

• Nie podano mianownika wskaźnika, definicji zdarzenia, strumieni wiadomości, domen odbierających ani punktu odniesienia do porównania; bez nich nie da się wiarygodnie zinterpretować prawie 25%.
• Przyczyna źródłowa pozostaje nieustalona do czasu zbadania typów odbić na poziomie odbiorcy, rozszerzonych kodów statusu, tekstu diagnostycznego i kohort dostawców.
• Etykiety odbić, sposób ponawiania i sposób liczenia wskaźników różnią się w zależności od ESP i operatora pocztowego.

Pierwsze 15 minut

1. Zarejestruj pełną transkrypcję SMTP z Gmaila, rozszerzony kod statusu, treść, znacznik czasu oraz odpowiedź po terminatorze DATA.
2. Na podstawie pełnej odpowiedzi Gmail 550 sklasyfikuj trwałą odmowę. Odróżnij przy tym zdalną akceptację 2yz po DATA od lokalnego statusu w kolejce.

Teraz

• Wiadomości z odpowiedzią dokładnie 4yz utrzymuj w kontrolowanym ponawianiu, a wiadomości z odpowiedzią dokładnie 5yz poddaj kwarantannie, by nie ponowić ich bez zmian.

Najbliższe 24 godziny

• Zanim ponownie prześlesz wiadomość, usuń wskazany w pełnej odpowiedzi Gmail 550 5.7.1 problem z zasadami, reputacją lub nagłówkiem.

Najbliższe 7 dni

• Zapisuj na stałe w rekordach zdarzeń dostarczania klasyfikację SMTP na przejściową i trwałą oraz pełną treść odpowiedzi.

Kontrole techniczne

Kryteria weryfikacji

• Kontrolowana, poprawiona wiadomość otrzymuje po DATA zdalne zakończenie 2yz zamiast odmowy Gmail 550 5.7.1 z incydentu.
• Kontrolowane próbki nie zwracają już pełnej odpowiedzi Gmail 550 5.7.1 z incydentu.

Kryteria eskalacji

• Eskaluj sprawę do ESP lub specjalisty ds. dostarczalności, jeśli pełna odpowiedź Gmail 550 5.7.1 utrzymuje się po usunięciu wskazanego w niej stanu albo jej przyczyna pozostaje niejasna.

Zapobieganie

• Utrwalaj zdalną odpowiedź zwróconą po DATA i kieruj wyniki 4yz do kontrolowanego ponowienia, a wyniki 5yz — do interwencji.

Wpływ na biznes

• Trwała odmowa z Gmaila oznacza, że próba dostarczenia, której dotyczy problem, nie doszła do skutku, przez co wiadomości o krótkim oknie ważności mogą nie dotrzeć do odbiorców, dopóki nie naprawisz przyczyny.

Uwagi dostawcy

• Udokumentowana odpowiedź Gmaila 450 4.2.1 to tymczasowy stan związany z limitem tempa po stronie odbiorcy — właściwą reakcją jest późniejsze ponowne wysłanie.
• Gmail 550 5.7.1 to nie jedna diagnoza — do odróżnienia udokumentowanych przyczyn odmowy potrzebujesz pełnej treści odpowiedzi.

Otwarte pytania

• Nie dostarczono rzeczywistej transkrypcji SMTP, rozszerzonego kodu statusu, DSN ani znacznika czasu dla dostarczenia, którego dotyczy problem.
• Nie wiadomo, czy wiadomość wciąż czeka w lokalnej kolejce, czy już dostała trwałe odrzucenie z Gmaila.
• Nie znamy liczby ani znaczenia wiadomości i odbiorców objętych incydentem.

Pierwsze 15 minut

1. Zapisz pełną treść komunikatu 550 lub 553, serwer, który ją odrzuca, i etap SMTP — nie opieraj się na samym kodzie.
2. Sprawdź, czy skonfigurowany serwer SMTP poczty wychodzącej rozpoznaje połączenie i uwierzytelnianie nadawcy.
3. Porównaj skonfigurowany serwer przesyłania i uwierzytelnianie z wartościami, które autoryzował dostawca.

Teraz

• Użyj serwera SMTP autoryzowanego dla bieżącego połączenia albo skonfiguruj obsługiwane przez niego uwierzytelnianie SMTP.

Najbliższe 24 godziny

• Jeśli pełna odpowiedź potwierdza ograniczenie adresu zwrotnego, zmień adres zwrotny na domenę dozwoloną przez tego dostawcę.

Najbliższe 7 dni

• Udokumentuj zatwierdzoną konfigurację serwera przesyłania (submission) i adresu zwrotnego, aby kolejni nadawcy nie wywołali ponownie błędu przekazywania (relay).

Kontrole techniczne

Kryteria weryfikacji

• Nowe żądanie testowe zostaje przyjęte po poprawieniu konfiguracji autoryzowanego serwera SMTP lub uwierzytelniania.
• Postęp w dostarczaniu potwierdzają dowody z warstwy transportu, a nie sama obecność wiadomości w Elementach wysłanych.

Kryteria eskalacji

• Skontaktuj się z dostawcą internetu (ISP) lub administratorem poczty, jeśli z dostępnych opcji konta nie da się skonfigurować autoryzowanego serwera SMTP ani obsługiwanego uwierzytelniania.

Zapobieganie

• Skonfiguruj klientów pocztowych z autoryzowanym przez dostawcę serwerem przesyłania (submission) i obsługiwanym uwierzytelnianiem SMTP.
• Egzekwuj dozwoloną przez dostawcę domenę adresu zwrotnego wszędzie tam, gdzie to ograniczenie jest skonfigurowane.

Wpływ na biznes

• Wiadomość może trafić do Elementów wysłanych w Outlooku, mimo że dostawca ją odrzucił, a odbiorca nigdy jej nie dostał.
• Niezmienione żądanie nie dojdzie do skutku, dopóki trwały stan 5yz pozostaje nienaprawiony.

Uwagi dostawcy

• Opisany przez Microsoft scenariusz przekazywania (relay) dotyczy serwera wychodzącego, który nie uznaje nadawcy za autoryzowanego; same kody 550 lub 553 mogą oznaczać inne zasady.

Otwarte pytania

• Nie podano pełnej treści błędu, rozszerzonego kodu statusu, serwera odrzucającego, etapu, na którym wystąpił błąd, bieżącej konfiguracji SMTP, wyniku uwierzytelniania, kontekstu połączenia ani topologii poczty, więc dokładna przyczyna pozostaje nieznana.
• Same kody 550 lub 553 mogą oznaczać różne zasady w konsumenckim Outlooku, Microsoft 365, lokalnym Exchange, u ISP i w bramach innych firm; o diagnozie decyduje pełna odpowiedź.

Pierwsze 15 minut

1. Zachowaj pełną odpowiedź SMTP wraz z rozszerzonym podkodem i tekstem diagnostycznym dla reprezentatywnych odrzuconych wiadomości.
2. Sprawdź, czy tekst diagnostyczny kończy się na gsmtp oraz czy gcdp wskazuje zasadę ustawioną przez administratora domeny odbiorcy.
3. Przypisz dany rozszerzony kod do właściwego mechanizmu kontroli — PTR, uwierzytelniania, SPF, wolumenu, TLS, DKIM lub DMARC.

Teraz

• Popraw wyłącznie ten mechanizm kontroli, który wskazuje pełny rozszerzony kod i diagnostyka Gmaila.

Najbliższe 24 godziny

• Zweryfikuj obowiązującą linię bazową SPF, DKIM, DMARC oraz zgodności dla poczty wysyłanej bezpośrednio, właściwą dla klasy wolumenu tego nadawcy w Gmailu.

Najbliższe 7 dni

• Przeprowadź audyt uwierzytelniania i zgodności bieżących tożsamości nadawczych, aby linia bazowa Gmaila była nieprzerwanie spełniona.

Kontrole techniczne

Kryteria weryfikacji

• Właściwe testy SPF, DKIM, DMARC i zgodności dla poczty bezpośredniej przechodzą pomyślnie dla tożsamości nadawczej, której dotyczy problem.
• Wyniki testów po zmianie są skorelowane z sygnałami uwierzytelniania, spamu, reputacji domeny i reputacji IP z Postmaster Tools, o ile są dostępne.

Kryteria eskalacji

• Odrzucenie z markerem gcdp eskaluj do administratora Google Workspace w domenie odbiorcy — wskazuje ono niestandardową zasadę tej domeny.
• Jeśli pełnej diagnostyki Gmaila nadal nie da się przypisać do żadnego mechanizmu, eskaluj sprawę z pełną odpowiedzią i reprezentatywnymi tożsamościami objętymi incydentem, a nie z samym kodem 550 5.7.1.

Zapobieganie

• Utrzymuj wymaganą przez Gmaila linię bazową uwierzytelniania i zgodności domeny From dla każdej tożsamości nadawczej.
• Monitoruj w Postmaster Tools sygnały uwierzytelniania, spamu i reputacji, a obok nich dokładną diagnostykę SMTP.

Wpływ na biznes

• Odrzucone polecenie SMTP nie zostało przyjęte, więc żądane dostarczenie nie doszło do skutku.
• Ten sam widoczny kod 5.7.1 może oznaczać zasadniczo różne warunki — związane z zasadami, uwierzytelnianiem, reputacją, nagłówkiem, przekazywaniem (relay) lub bezpośrednim IP.

Uwagi dostawcy

• Marker gcdp wskazuje niestandardową regułę administratora Google Workspace, a marker gsmtp pojawia się przy błędach SMTP Gmaila w ogóle.
• Gmail publikuje osobne rozszerzone kody dla warunków związanych z PTR, uwierzytelnianiem, SPF, nietypowym wolumenem, TLS, DKIM i DMARC.

Otwarte pytania

• Bez pełnej odpowiedzi SMTP — z rozszerzonym podkodem statusu, tekstem diagnostycznym oraz identyfikatorem gsmtp lub gcdp — nie ustalisz dokładnego warunku zasad Gmaila.