4.7.26Poczta nadawcy tymczasowo objęta ograniczeniem tempa z powodu braku uwierzytelnienia SPF/DKIM (Gmail)

Gmail stosuje wzorzec rejestru X.7.26 („Multiple authentication checks failed”, niepowodzenie więcej niż jednej kontroli uwierzytelniania) konkretnie do poczty bez pozytywnego wyniku SPF lub DKIM; kod 4.7.26 nakłada na ten wzorzec klasę tymczasową, gdy system odbiorczy odrzucił wiadomość albo ograniczył jej tempo z powodu więcej niż jednej nieudanej kontroli. Mechaniczne potwierdzenie IANA dla X.7.26 w tym katalogu obejmuje wyłącznie wariant klasy 5 (5.7.26, Associated Basic Status Code 550); konkretna forma klasy 4 takiego potwierdzenia z rejestru tu nie ma. Istnienie i znaczenie opierają się więc wyłącznie na dokładnym dowodzie produkcyjnym zebranym w korpusie (odpowiedź Gmaila 421 4.7.26 poniżej). Status zgłasza przejściowy brak uwierzytelnienia w tej próbie, a nie trwale nieprawidłowy adres ani stan skrzynki.

RFC 7372 rejestruje X.7.26 właśnie dla stanu niepowodzenia wielu kontroli uwierzytelniania: wiadomość nie przeszła więcej niż jednej kontroli uwierzytelniania, wbrew lokalnej polityce, bez wskazania, które mechanizmy zawiodły. RFC 3463 (sekcja 3.8) definiuje ogólną klasę przedmiotową X.7 („Security or Policy Status”), ale sam nie wymienia kodu szczegółowego 26; późniejsza rejestracja niesie Associated Basic Status Code 550, potwierdzony w tym katalogu wyłącznie dla klasy 5 (5.7.26). Konkretny kod 4.7.26 (klasa 4) stosuje ten sam wzorzec jako niepowodzenie przejściowe: w akceptowanym przykładzie Gmail zgłasza, że wiadomość jest nieuwierzytelniona, ponieważ ani SPF, ani DKIM nie przeszły, i ogranicza jej tempo zamiast odrzucić ją od razu. Publikujemy go tu na podstawie dokładnego dowodu korpusowego, a nie potwierdzenia z rejestru IANA dla tej klasy.

Pierwsza cyfra 4 oznacza uporczywe niepowodzenie przejściowe: w chwili tej próby Gmail ogranicza tempo wiadomości, ponieważ brakuje jej pozytywnego wyniku SPF lub DKIM, ale stan ustępuje, gdy domena nadawcy zacznie się poprawnie uwierzytelniać. Nie myl tego z 5.7.26, gdzie ten sam wzorzec „niepowodzenie wielu kontroli uwierzytelniania” występuje jako niepowodzenie trwałe.

Klasa

Niepowodzenie tymczasowe

Ponowienie

Kontrolowane ponowienie

Supresja

Sprawdź pełny kontekst

Ponawianie bez żadnej zmiany nic nie da: najpierw napraw SPF i/lub DKIM dla domeny nadawcy, potwierdź, że rekordy się propagują i że wychodząca poczta rzeczywiście niesie przechodzący podpis lub wynik SPF, a dopiero potem ponawiaj z backoffem i limitem prób. Zakończ ponawianie, gdy wiadomości zaczną przechodzić uwierzytelnianie i docierać do odbiorców, albo po wyczerpaniu limitu; nie wysyłaj dalej tego samego nieuwierzytelnionego strumienia, oczekując innego wyniku.

Nie wykluczaj ani nie usuwaj adresu odbiorcy wyłącznie na podstawie kodu 4.7.26: warunek dotyczy uwierzytelniania po stronie nadawcy, a nie skrzynki odbiorcy ani ważności jego adresu. Decyzje o wykluczeniu powinny opierać się na niezależnych sygnałach dotyczących konkretnego odbiorcy (twarde odbicia, kody trwałe), a nie na tej luce uwierzytelniania po stronie nadawcy.

• Domena nadawcy nie ma rekordu SPF albo rekord SPF nie obejmuje adresu IP infrastruktury wysyłkowej, więc SPF zawodzi albo zwraca none/softfail zamiast pass.
• DKIM nie jest skonfigurowany, klucz podpisujący nie zgadza się z rekordem selektora opublikowanym w DNS, albo wiadomość została zmodyfikowana po drodze (np. przez przekazywanie lub przekaźnik), przez co podpis DKIM przestaje się weryfikować.
• W zaakceptowanym przykładzie Gmaila odpowiedź wprost wymaga sprawdzenia zarówno SPF, jak i DKIM, i zgłasza, że żadne z nich nie przeszło — to udokumentowane zachowanie zgodne z wymaganiami Google dotyczącymi uwierzytelniania nadawców masowych z lutego 2024 roku, nie ogólna definicja kodu 4.7.26 u wszystkich dostawców.

1. Sprawdź surową odpowiedź SMTP i potwierdź, że kod rozszerzony to dokładnie 4.7.26, a podstawowa odpowiedź należy do klasy 4xx (w akceptowanym przykładzie: 421).
2. Pobierz nagłówek Authentication-Results wiadomości (albo równoważny raport DMARC/DKIM/SPF) dla konkretnej wysyłki i potwierdź, który mechanizm zawiódł — SPF, DKIM czy oba, jak w akceptowanym przykładzie.
3. Sprawdź opublikowany rekord SPF domeny nadawcy oraz selektor DKIM względem infrastruktury, która faktycznie wysłała wiadomość, w tym ewentualnego zewnętrznego ESP lub przekaźnika na trasie.
4. Po poprawieniu rekordów DNS wyślij nową wiadomość testową i potwierdź, że nagłówek Authentication-Results pokazuje wynik pozytywny, zanim wznowisz wysyłkę pełnym wolumenem.