Błąd 550 5.7.26 w Gmailu: przyczyny i naprawa

Gmail odpowiada błędem 550-5.7.26, gdy wiadomość nie ma uwierzytelnienia powiązanego z domeną z pola Od (From): albo ani SPF, ani DKIM nie przeszły, albo przeszły dla cudzej domeny, a Twoja polityka DMARC kazała Gmailowi taką pocztę odrzucić. Naprawa prawie nigdy nie polega na dopisaniu kolejnego include do SPF. Chodzi o to, żeby DKIM podpisywał Twoją domeną, a nadawca kopertowy (Return-Path) też był w Twojej domenie, tak by przynajmniej jedno z nich było zgodne (wyrównane) z From.

Co oznacza błąd 550-5.7.26 w Gmailu?

To trwałe odrzucenie (pierwsza cyfra 5) poczty, którą Gmail uznał za nieuwierzytelnioną. Lista kodów błędów SMTP Google podaje pod 5.7.26 trzy różne komunikaty, a dokładne zdanie w Twoim zwrocie mówi, który test się nie powiódł.

Myślnik w 550- nie oznacza innego kodu. Serwer SMTP wysyła odpowiedzi wielowierszowe jako 550- w każdym wierszu poza ostatnim, który ma 550 ze spacją. Dlatego ten sam błąd widzisz raz jako „550-5.7.26”, a raz jako „550 5.7.26”.

Stan na listopad 2026, brzmienie komunikatów z listy kodów SMTP Google.

Dlaczego widzisz go coraz częściej: wytyczne Gmaila dla nadawców od 1 lutego 2024 wymagają od każdego nadawcy SPF lub DKIM, a od nadawców masowych (ponad 5000 wiadomości dziennie do Gmaila) SPF, DKIM i DMARC z wyrównaną domeną From. FAQ do wytycznych mówi, że od listopada 2025 Gmail zaostrza egzekwowanie wobec niezgodnego ruchu, z tymczasowymi i trwałymi odrzuceniami. Poczta, która kiedyś lądowała w spamie, teraz się odbija.

Podstawy działania każdego rekordu opisuje nasz artykuł czym są SPF, DKIM i DMARC. Tutaj zajmujemy się konkretnym zwrotem i tym, jak się go pozbyć.

Jak czytać Authentication-Results w „Pokaż oryginał”?

Wyślij wiadomość na swój adres w Gmailu, otwórz ją, wybierz Więcej → Pokaż oryginał i znajdź nagłówek Authentication-Results: mx.google.com. Zapisuje trzy werdykty i, co ważniejsze, trzy domeny, których dotyczył każdy z nich.

Jeśli wiadomość się odbiła i nie dotarła, sam zwrot często cytuje te wyniki. W przeciwnym razie tymczasowo ustaw swój DMARC na p=none, żeby wiadomość doszła i dało się ją obejrzeć.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@relay.example.net header.s=s1 header.b=Ab12Cd34;
       spf=pass (google.com: domain of bounces+8812@mail.relay.example.net designates 203.0.113.25 as permitted sender) smtp.mailfrom="bounces+8812@mail.relay.example.net";
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=example.com

To klasyczny przypadek 550-5.7.26: SPF i DKIM mówią pass, a DMARC i tak nie przechodzi. Czytaj domeny, nie werdykty:

DMARC przechodzi, gdy co najmniej jeden z testów SPF i DKIM przechodzi i jego domena jest wyrównana z header.from. Tu żaden nie jest, więc dmarc=fail, a ponieważ example.com publikuje p=reject, wynikiem jest dis=REJECT, czyli zwrot.

💡 Wskazówka: Wiadomość może mieć kilka podpisów DKIM. Wystarczy jeden wyrównany, więc zanim cokolwiek zmienisz, poszukaj dkim=pass, którego header.i kończy się Twoją domeną.

Dlaczego poczta wysyłana przez relay nie przechodzi DMARC?

Bo większość przekaźników SMTP domyślnie podpisuje własną domeną i używa własnej domeny zwrotów, więc oba testy przechodzą dla przekaźnika, a nie dla Ciebie. Wyrównanie pojawia się dopiero wtedy, gdy przekażesz mu swoją domenę przynajmniej dla jednego z nich.

Aktualna specyfikacja DMARC, RFC 9989 (maj 2026, zastępuje RFC 7489), zna dwa tryby. Wyrównanie swobodne (relaxed, domyślne) akceptuje każdą domenę z tą samą domeną organizacyjną, więc bounce.example.com pasuje do example.com. Wyrównanie ścisłe (aspf=s lub adkim=s) wymaga identycznej domeny. RFC 9989 ustala domenę organizacyjną przechodząc po drzewie DNS zamiast korzystać z Public Suffix List; dla zwykłych domen wynik jest ten sam.

Stan na listopad 2026, zasady wyrównania według RFC 9989.

Celuj w przedostatni wiersz. Wyrównanie DKIM lepiej przeżywa przekierowania niż SPF (wyjaśniamy to niżej), a wyrównany SPF daje drugą ścieżkę, gdy podpis DKIM zepsuje bramka przepisująca treść.

Inne typowe przyczyny tego samego błędu:

• Nowa usługa, której nikt nie skonfigurował. CRM, helpdesk albo program do faktur wysyła jako @twojadomena.pl na swoich domyślnych ustawieniach. Każda usługa używająca Twojej domeny w From wymaga tej samej konfiguracji, także skrzynki w home.pl, nazwa.pl czy OVH, jeśli wysyłasz z nich pocztę firmową.
• Domena From, której nadawca nie posiada. Wysyłka jako @gmail.com czy @wp.pl przez własny serwer nigdy nie będzie wyrównana.
• Niepotrzebnie ścisłe wyrównanie. adkim=s; aspf=s nie przechodzi, gdy przekaźnik podpisuje domeną mail.example.com, a From to example.com.
• Zepsuty klucz DKIM. Rekord TXT źle podzielony na ciągi, klucz ucięty przez panel DNS albo selektor, który przekaźnik zrotował: dkim=fail lub dkim=neutral (body hash did not verify).

Jak naprawić błąd 550-5.7.26 krok po kroku?

Niech DKIM podpisuje Twoją domeną, nadawca kopertowy dostanie Twoją domenę tam, gdzie przekaźnik na to pozwala, SPF będzie poprawny dla domeny kopertowej, a DMARC opublikowany. Idź w tej kolejności; każdy krok da się sprawdzić osobno.

1. Spisz wszystko, co wysyła jako Twoja domena

   Przekaźnik platformy mailingowej, dostawca poczty firmowej (Google Workspace, Microsoft 365, home.pl, OVH), maile transakcyjne z aplikacji, CRM, helpdesk, faktury. Raporty zbiorcze DMARC (krok 5) pokażą to, o czym zapomnisz.

2. Włącz DKIM z własną domeną w każdym przekaźniku

   Każdy przekaźnik poda albo rekordy CNAME wskazujące na rotowane przez niego klucze, albo rekord TXT z kluczem publicznym. Opublikuj dokładnie to, co pokazuje, i potwierdź w jego panelu. Google zaleca klucze 2048-bitowe, jeśli dostawca je obsługuje (wytyczne dla nadawców).

3. Ustaw własną domenę MAIL FROM (Return-Path)

   Większość przekaźników pozwala użyć subdomeny, np. bounce.example.com, jako nadawcy kopertowego. Wymagają rekordu MX (żeby zwroty nadal do nich trafiały) i rekordu SPF na tej subdomenie.

4. Popraw SPF dla domeny kopertowej

   Jeden rekord SPF na nazwę, zakończony ~all lub -all, z maksymalnie 10 mechanizmami wymagającymi zapytań DNS (include, a, mx, ptr, exists, redirect) według RFC 7208, sekcja 4.6.4. Dwa rekordy SPF na jednej nazwie to permerror, który liczy się jak niepowodzenie.

5. Opublikuj DMARC, zaczynając od p=none

   Rekord TXT na _dmarc.example.com z adresem do raportów. Na quarantine i reject przechodź dopiero wtedy, gdy raporty pokażą wszystkie prawdziwe źródła jako wyrównane.

6. Przetestuj ponownie

   Wyślij wiadomość do testowej skrzynki w Gmailu i potwierdź dmarc=pass, zanim wyślesz cokolwiek prawdziwym subskrybentom.

Przykładowe rekordy dla domeny, która wysyła pocztę pracowników przez Google Workspace, a newslettery przez Amazon SES (podmień tokeny, region i adres raportów na swoje):

; SPF dla domeny From (poczta pracowników przez Google Workspace)
example.com.                      TXT   "v=spf1 include:_spf.google.com ~all"

; Własna subdomena MAIL FROM dla Amazon SES
bounce.example.com.               MX    10 feedback-smtp.eu-west-1.amazonses.com.
bounce.example.com.               TXT   "v=spf1 include:amazonses.com ~all"

; Easy DKIM: trzy rekordy CNAME z konsoli SES (pokazany jeden)
abc123token._domainkey.example.com. CNAME abc123token.dkim.amazonses.com.

; DMARC, najpierw monitorowanie
_dmarc.example.com.               TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Szczegóły SES (sandbox, regiony, dane logowania SMTP) opisuje nasz poradnik konfiguracji Amazon SES jako SMTP. Inne przekaźniki nazywają te same funkcje inaczej: „custom return path”, „bounce domain”, „branded sending domain” albo „domain authentication”.

⚠️ Uwaga: Nie przeskakuj od razu na p=reject, żeby „spełnić wymagania”. Reguła Gmaila dla masowych nadawców akceptuje p=none; ścisła polityka opublikowana, zanim wszystkie źródła są wyrównane, to dokładnie przepis na 550-5.7.26 dla Twojej własnej, prawdziwej poczty.

Cały proces zaostrzania DMARC, rozgrzewania i monitorowania znajdziesz w poradniku o dostarczalności maili przy własnym serwerze.

Dlaczego odbijają się przekierowania i listy dyskusyjne?

Przekierowanie wysyła Twoją wiadomość z nowego adresu IP, którego nie ma w Twoim SPF, więc SPF nie przechodzi; listy dyskusyjne często zmieniają temat lub dodają stopkę, co psuje podpis DKIM. Gdy znikną oba, ścisła polityka DMARC odrzuca przekierowaną kopię.

Zalecenia Google dotyczące przekierowywania poczty do Gmaila mówią, że przekierowane wiadomości często nie przechodzą SPF i że Gmail sam ponownie sprawdza uwierzytelnienie. Dlatego wyrównany DKIM jest ważniejszy niż SPF: niezmieniona wiadomość zachowuje ważny podpis po przekierowaniu.

ARC (Authenticated Received Chain, RFC 8617, dokument o statusie eksperymentalnym) pozwala każdemu pośrednikowi zapisać wyniki uwierzytelnienia, które zobaczył, i opieczętować je własnym podpisem. Odbiorca, który ufa temu pośrednikowi, może skorzystać z tych wyników, gdy oryginalne testy już nie przechodzą. ARC dodają serwery przekierowujące i listy dyskusyjne, a nie Ty jako pierwotny nadawca, i to odbiorca decyduje, czy danej pieczęci ufa.

• Jeśli Twoja poczta odbija się po przekierowaniu: upewnij się, że DKIM jest wyrównany i że nic nie modyfikuje wiadomości po podpisaniu (robią to niektóre bramki śledzące linki lub dopisujące stopki).
• Jeśli to Ty prowadzisz przekierowanie lub listę: zgodnie z radami Google przepisuj nadawcę kopertowego na swoją domenę przekierowań, utrzymuj dla niej SPF i DKIM i unikaj zmian psujących DKIM. Oprogramowanie list często podmienia From na adres listy dla nadawców ze ścisłym DMARC.
• Jeśli to prywatne przekierowanie subskrybenta: nie naprawisz jego konfiguracji; pojedynczy zwrot z takiego adresu nie oznacza, że Twoje uwierzytelnienie jest zepsute.

Jak sprawdzić, że naprawa zadziałała?

Sprawdź DNS z zewnątrz, wyślij jedną wiadomość do testowej skrzynki w Gmailu, przeczytaj Authentication-Results, a potem przez co najmniej tydzień obserwuj Postmaster Tools.

# 1. Rekordy tak, jak widzi je świat (tylko jeden rekord SPF)
dig +short TXT example.com | grep spf1
dig +short TXT bounce.example.com
dig +short TXT _dmarc.example.com
dig +short CNAME abc123token._domainkey.example.com

# 2. Test przez ten sam przekaźnik i port, którego używa Twoja platforma (swaks)
swaks --to ty@gmail.com --from newsletter@example.com \
      --server email-smtp.eu-west-1.amazonaws.com --port 587 --tls \
      --auth LOGIN --auth-user "$SMTP_USER" --auth-password "$SMTP_PASS" \
      --header "Subject: Test wyrownania DMARC"

Poprawny wynik wygląda tak, z Twoją domeną we wszystkich trzech miejscach:

dkim=pass header.i=@example.com header.s=abc123token
spf=pass (google.com: domain of 0102018f-test@bounce.example.com designates 203.0.113.40 as permitted sender) smtp.mailfrom=bounce.example.com
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Panel stanu zgodności w Google Postmaster Tools pokazuje, czy Twoja domena spełnia wytyczne (SPF, DKIM, a dla masowych nadawców także DMARC i rezygnację jednym kliknięciem). Google zaznacza, że dane to średnia krocząca z kilku dni, i radzi sprawdzić ponownie po 7 dniach, więc nie oczekuj zielonego statusu godzinę po poprawce DNS. Rezygnacja jednym kliknięciem to osobny wymóg; opisuje go nasz poradnik o RFC 8058.

Co, jeśli nie wysyłałeś odbitej wiadomości?

Wtedy ktoś inny wpisał Twoją domenę w pole Od, a Gmail zrobił dokładnie to, o co prosi Twoja polityka DMARC. Zwrot wiadomości, której nie wysyłałeś, to tzw. backscatter: serwer fałszerza dostarczył odrzucenie na sfałszowany Return-Path, który może być Twoim adresem.

Sprawdź nagłówki zacytowane w zwrocie. Adres IP, który nie należy do żadnego z Twoich dostawców, format Message-ID, jakiego Twoje systemy nie używają, albo temat, którego nie napisałeś, wskazują na podszywanie się. Raporty zbiorcze DMARC pokazują to samo hurtowo: źródła z Twoim header.from, które nie przechodzą ani SPF, ani DKIM.

• Nie luzuj DMARC, żeby zwroty ustały; to p=reject chroni odbiorców przed sfałszowaną pocztą.
• Filtruj lub usuwaj zwroty na adresy, których nigdy nie używasz jako Return-Path.
• Jeśli zwroty wskazują na Twojego prawdziwego, zapomnianego nadawcę, to krok 1 naprawy powyżej, a nie podszywanie.

Uporczywe zwroty prawdziwej poczty to osobny temat: podział na twarde i miękkie odbicia oraz blokowanie adresów opisuje nasz poradnik o obsłudze zwrotów.

Błąd 550-5.7.26 przy wysyłce z NetSendo

NetSendo wysyła przez skrzynkę, którą podłączysz (przekaźnik SMTP, np. Amazon SES lub Mailgun, Gmail API, SendGrid albo NMI, czyli NetSendo Mail Infrastructure), więc uwierzytelnienie konfigurujesz u tego dostawcy i w swoim DNS. NetSendo nie publikuje własnego include do SPF.

• Kto podpisuje DKIM: dla skrzynek SMTP, SendGrid i Gmail podpisuje dostawca, nie NetSendo; włącz u niego DKIM z Twoją domeną. NMI generuje 2048-bitowe klucze DKIM i pokazuje rekordy DNS do skopiowania.
• Return-Path: od NetSendo 2.2.0 adres zwrotów skrzynki wysyłającej jest ustawiany jako nadawca kopertowy przy każdej wysyłce przez skrzynki SMTP i Gmail, nie tylko w automatyzacjach. Gdy skrzynka zwrotów jest w Twojej domenie, SPF jest sprawdzany dla tej domeny, więc jej rekord SPF musi dopuszczać przekaźnik. API SendGrid ustawia własnego nadawcę kopertowego, więc tam użyj uwierzytelnienia domeny w SendGrid. Niektóre przekaźniki podmieniają nadawcę kopertowego na swoją domenę zwrotów; sprawdź ich ustawienie własnego MAIL FROM.
• Kontrola w NetSendo: Deliverability Shield, część licencji GOLD, regularnie sprawdza SPF, DKIM i DMARC zweryfikowanych domen. Od 2.8.0 możesz wpisać selektor DKIM przekaźników takich jak Amazon SES, które używają tokenów per domena, a generator DMARC zaczyna od p=none ze swobodnym wyrównaniem. Same rekordy DNS działają przy każdej licencji, także darmowej SILVER.

Skrzynki, opcje wysyłki i NMI opisuje dokumentacja konfiguracji, a instalacja NetSendo to kilka poleceń z szybkiego startu.

Najczęściej zadawane pytania

Źródła

• Google Workspace: Gmail SMTP errors and codes
• Google: Email sender guidelines
• Google: Email sender guidelines FAQ
• Google: Postmaster Tools dashboards
• Gmail Help: Best practices for forwarding email to Gmail
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 7208: Sender Policy Framework (SPF)
• RFC 8617: Authenticated Received Chain (ARC)