Jeśli Gmail odrzucił Twoją wiadomość z kodem 550-5.7.26, oznacza to, że wiadomość została odrzucona, ponieważ system nie mógł potwierdzić, że masz uprawnienia do wysyłania z Twojej domeny. Pełna treść komunikatu brzmi "This message does not have authentication information or fails to pass authentication checks." Mówiąc prosto, wiadomość nie przeszła zarówno SPF, jak i DKIM w sposób zgodny z Twoim adresem w polu From, więc Gmail potraktował ją jako niezweryfikowanego nadawcę i zablokował przed dostarczeniem.
To twarde odrzucenie, a nie umieszczenie w folderze spamu. Wiadomość nigdy nie dociera do odbiorcy, a nadawca otrzymuje zwrot. Dobra wiadomość jest taka, że kod 5.7.26 niemal zawsze da się przypisać do jednej z trzech możliwych do naprawienia przyczyn, a którą z nich, ustalisz w ciągu kilku minut.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Co naprawdę oznacza 550-5.7.26
Gmail zwraca kod 5.7.26, gdy wiadomość dociera bez żadnego pozytywnego, zgodnego uwierzytelnienia. Od lutego 2024 roku Gmail egzekwuje wymagania wobec nadawców, które wcześniej były jedynie zaleceniami. Każdy nadawca musi mieć pozytywny wynik SPF lub DKIM, a nadawcy masowi (mniej więcej 5000 lub więcej wiadomości dziennie do Gmaila) potrzebują zarówno SPF, jak i DKIM oraz prawidłowego rekordu DMARC.
Kluczowe jest słowo "zgodny". Gmailowi nie wystarczy, że SPF lub DKIM przejdzie pomyślnie na dowolnej domenie. Chce, aby przynajmniej jeden z nich przeszedł na domenie odpowiadającej widocznemu adresowi w polu From. Wiadomość może pokazywać spf=pass w nagłówkach, a mimo to zostać odrzucona z kodem 5.7.26, jeśli ten pozytywny wynik dotyczy domeny zwrotnej Twojego dostawcy poczty, a nie Twojej własnej domeny z pola From. To najczęstszy powód, dla którego ludzie są zdezorientowani tym zwrotem: ich dostawca "przechodzi SPF", a Gmail i tak odmawia przyjęcia poczty.
Oto logika, którą stosuje Gmail:
- Czy SPF przechodzi pomyślnie ORAZ czy domena SPF jest zgodna z domeną z pola From? Jeśli tak, wiadomość jest uwierzytelniona.
- Czy DKIM przechodzi pomyślnie ORAZ czy domena
d=jest zgodna z domeną z pola From? Jeśli tak, wiadomość jest uwierzytelniona. - Jeśli żadne ze sprawdzeń zgodności nie przejdzie, zwracany jest kod
550-5.7.26.
Przyczyna 1: ani SPF, ani DKIM nie przechodzi pomyślnie
Pierwsze, co należy wykluczyć, to zwykła awaria uwierzytelniania. Jeśli SPF jest zepsuty, a DKIM nie podpisuje wiadomości, Gmail nie ma czego zaakceptować.
SPF najczęściej zawodzi, ponieważ wysyłający adres IP nie jest wymieniony w Twoim rekordzie lub ponieważ rekord ma zbyt wiele odwołań DNS i zwraca PermError. Prawidłowy rekord SPF dla domeny wysyłającej przez Google Workspace wygląda tak:
v=spf1 include:_spf.google.com ~all
Jeśli wysyłasz przez wiele usług, każda z nich potrzebuje swojego include, a cały rekord musi się rozwiązać w limicie dziesięciu odwołań. Gdy go przekroczysz, SPF zwraca PermError, a Gmail traktuje to jako niepowodzenie. Zobacz naprawa SPF zbyt wiele odwołań DNS, jeśli Twój rekord przekroczył limit.
DKIM zawodzi, gdy selektor nie jest opublikowany, klucz został zmieniony bez aktualizacji DNS lub podpis nigdy nie zostaje dodany, ponieważ DKIM nigdy nie został włączony na platformie wysyłającej. Rekord DKIM to rekord TXT (lub CNAME) na hoście selektora, takim jak google._domainkey.yourdomain.com. Jeśli Twój dostawca twierdzi, że DKIM jest włączony, a Gmail pokazuje dkim=none, podpis nie jest nakładany na pocztę wychodzącą.
Potwierdź obie rzeczy, czytając nagłówki wiadomości. Otwórz zwróconą lub testową wiadomość, wyświetl oryginał i sprawdź wiersz Authentication-Results. Nasz przewodnik jak czytać nagłówek Authentication-Results dokładnie wyjaśnia, co oznaczają spf=, dkim= i dmarc= w tym bloku.
Przyczyna 2: uwierzytelnianie przechodzi, ale nie jest zgodne
To przypadek, który zaskakuje nadawców, którzy "już mają SPF". Zgodność oznacza, że domena, która przeszła uwierzytelnianie, musi odpowiadać domenie z Twojego adresu w polu From.
SPF uwierzytelnia adres Return-Path (nadawcę koperty), który u wielu dostawców jest poddomeną zwrotną należącą do dostawcy, taką jak bounces.provider.net. Jeśli Twój adres w polu From to you@yourdomain.com, ale SPF przeszedł dla provider.net, SPF nie jest zgodny. Zarówno DMARC, jak i wymaganie Gmaila potrzebują zgodności, więc niezgodny pozytywny wynik SPF liczy się jako niepowodzenie na potrzeby kodu 5.7.26.
Zgodność DKIM działa tak samo. Domena podpisująca w nagłówku DKIM (d=) musi odpowiadać Twojej domenie z pola From. Jeśli Twoja platforma podpisuje wiadomości z d=provider.net zamiast d=yourdomain.com, DKIM przechodzi, ale nie jest zgodny.
Rozwiązaniem jest uwierzytelnianie na własnej domenie. W przypadku SPF użyj niestandardowego adresu Return-Path lub domeny zwrotnej we własnej domenie, tam gdzie dostawca to obsługuje. W przypadku DKIM opublikuj klucz podpisujący dostawcy na selektorze w swojej domenie i włącz podpisywanie na poziomie domeny, tak aby wartość d= była Twoją domeną. Większość platform nazywa to "uwierzytelnianiem domeny" lub "zweryfikowaną domeną wysyłania". Nasz opis jak naprawić zgodność DKIM obejmuje dokładne rekordy, a zgodność luźna a ścisła wyjaśnia, dlaczego poddomena może nadal być zgodna w domyślnym trybie luźnym.
Przyczyna 3: brak rekordu DMARC
Jeśli wysyłasz do Gmaila w dużych ilościach, sam brak rekordu DMARC może wywołać odrzucenie, nawet gdy SPF i DKIM wyglądają poprawnie. Zasady Gmaila dla nadawców masowych wymagają, aby rekord DMARC istniał, przynajmniej z polityką none.
Rekord początkowy jest prosty i bezpieczny:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Opublikuj go jako rekord TXT na _dmarc.yourdomain.com. Polityka none spełnia wymóg posiadania DMARC bez zmiany sposobu obsługi jakiejkolwiek poczty, więc jest to właściwy pierwszy krok. Później możesz zaostrzyć do quarantine, a następnie reject, gdy raporty potwierdzą, że cała legalna poczta jest zgodna. Jeśli w ogóle nie masz rekordu, postępuj według naprawa braku rekordu DMARC, aby dodać go poprawnie.
Nie myl kodu 5.7.26 z 550-5.7.1. Kod 5.7.1 oznacza, że Twoja wiadomość została odrzucona, ponieważ nie przeszła Twojej własnej opublikowanej polityki DMARC quarantine lub reject. Jeśli widzisz ten kod, przeczytaj 550-5.7.1 wiadomość odrzucona zgodnie z polityką DMARC.
Gotowa do skopiowania lista diagnostyczna
Wykonaj te sprawdzenia w kolejności. Pierwsze "nie" to Twoja główna przyczyna.
- Czy w Twojej domenie głównej istnieje rekord SPF i czy zawiera każdą usługę, która wysyła w Twoim imieniu?
- Czy SPF rozwiązuje się w limicie dziesięciu odwołań DNS (bez PermError)?
- Czy DKIM jest włączony na Twojej platformie wysyłającej, z selektorem opublikowanym w DNS?
- Czy w testowej wiadomości na konto Gmail nagłówek Authentication-Results pokazuje
spf=passLUBdkim=pass? - Czy pozytywny mechanizm jest zgodny z Twoją domeną z pola From? Domena SPF Return-Path lub DKIM
d=musi odpowiadaćyourdomain.com. - Czy rekord DMARC istnieje na
_dmarc.yourdomain.com?
Jeśli wolisz nie czytać surowych nagłówków, sprawdź swoją domenę za pomocą darmowego narzędzia powyżej. Pokazuje ono SPF, DKIM, DMARC i zgodność obok siebie, więc od razu zobaczysz, która z trzech przyczyn zawodzi. Pełną listę tego, czego teraz wymagają Gmail i Yahoo, znajdziesz w wymagania Google i Yahoo dla nadawców.
Najczęściej zadawane pytania
Czy 5.7.26 oznacza, że moja domena jest na czarnej liście?
Nie. 5.7.26 to niepowodzenie uwierzytelniania, a nie blokada z powodu reputacji. Gmail nie mógł potwierdzić, że masz uprawnienia do wysyłania z Twojej domeny w polu From. Napraw SPF, DKIM i zgodność, a odrzucenie ustanie, niezależnie od statusu na listach blokujących.
Dlaczego dostaję 5.7.26, skoro mój dostawca mówi, że SPF przechodzi?
Ponieważ SPF przechodzi dla domeny zwrotnej Twojego dostawcy, a nie dla Twojej domeny z pola From. To niepowodzenie zgodności. Skonfiguruj niestandardowy Return-Path we własnej domenie lub polegaj na DKIM podpisanym z d=yourdomain.com, tak aby pozytywne sprawdzenie było zgodne z adresem, który widzą odbiorcy.
Jak długo po naprawie DNS ustaną zwroty?
Nowe rekordy zaczynają obowiązywać po wygaśnięciu pamięci podręcznej DNS, zwykle w ramach ustawionego TTL, często od 1 do 24 godzin. Po propagacji rekordów wyślij nową wiadomość testową na konto Gmail i potwierdź, że nagłówek Authentication-Results pokazuje zgodny pozytywny wynik, zanim wznowisz kampanię.
Czy potrzebuję DMARC, jeśli SPF i DKIM już przechodzą?
Dla nadawców o małym wolumenie zgodny pozytywny wynik SPF lub DKIM często wystarcza, aby uniknąć 5.7.26. Jeśli wysyłasz 5000 lub więcej wiadomości dziennie do Gmaila, rekord DMARC jest obowiązkowy. Opublikowanie p=none spełnia wymóg bez zmiany obsługi poczty, więc dodaj go tak czy inaczej.