PoradnikiUwierzytelnianie

DMARC nie przechodzi, chociaż SPF i DKIM przechodzą

Obie kontrole pokazują pass, a DMARC nadal pokazuje fail. Przyczyną jest domena, która nie zgadza się z twoim adresem From. Jeden testowy email pokazuje, która to domena, a rozwiązaniem jest ustawienie u tego, kto wysyła pocztę.

Zaktualizowano 5 października 20269 min czytania

W skrócie

DMARC przechodzi tylko wtedy, gdy SPF albo DKIM przechodzi dla domeny z twojego adresu From. Wynik pass dla domeny twojego dostawcy się nie liczy.
Otwórz wysłaną wiadomość w Gmailu przez Show original (Pokaż oryginał) i porównaj smtp.mailfrom, header.i i header.from w nagłówku Authentication-Results.
Najpierw napraw DKIM: włącz podpisywanie własną domeną w każdej usłudze, która wysyła w twoim imieniu. Podpis DKIM przetrwa przekazanie dalej, SPF nie.
Subdomena domyślnie jest wystarczająco blisko. Jeśli twój rekord DMARC zawiera adkim=s albo aspf=s, już nie.
Rozgrzewanie nie naprawia zgodności domen. Wiadomości rozgrzewające są wysyłane przez twoją skrzynkę i nie przechodzą razem z nią.

DMARC nie pyta, czy SPF i DKIM przeszły. Pyta, czy któryś z nich przeszedł dla domeny z twojego adresu From. Jeśli SPF przeszedł dla domeny zwrotów twojego dostawcy, a DKIM dla domeny podpisującej twojego dostawcy, oba wiersze pokazują „pass”, a DMARC mimo to pokazuje „fail”. Naprawia się to u nadawcy: niech podpisuje twoją domeną albo używa adresu zwrotnego w twojej domenie. Wystarczy jedno z dwojga.

To dopasowanie nazywa się zgodnością domen (alignment). To ta część DMARC, której narzędzie sprawdzające DNS nie widzi. To, czy domeny w twojej poczcie są zgodne, widać tylko w wiadomości, która naprawdę została wysłana. Ta strona pokazuje, jak taką wiadomość odczytać.

Z każdym emailem podróżują trzy domeny

Email zawiera twoją domenę nawet w trzech miejscach. Każda kontrola patrzy na inne.

Granatowy proporzec z emblematem koperty, worek pocztowy z mosiężną zawieszką i list z pieczęcią lakową, obok siebie na nabrzeżu; pieczęć powtarza emblemat proporca, zawieszka nie — Proporzec to pole From, zawieszka na worku pocztowym to Return-Path, a pieczęć lakowa to podpis DKIM. DMARC chce, żeby zawieszka albo pieczęć zgadzała się z proporcem.

Gdzie	Inne nazwy	Kto na to patrzy
Pole From, które widzi twój czytelnik	Header From, `header.from`	DMARC. To miara dla dwóch pozostałych.
Return-Path	Envelope sender (nadawca kopertowy), MAIL FROM, adres zwrotny (bounce address), `smtp.mailfrom`	SPF. Sprawdza, czy serwer wysyłający może używać tej domeny.
Wartość `d=` w nagłówku DKIM-Signature	Domena podpisująca, `header.d` albo `header.i`	DKIM. Sprawdza, czy podpis tej domeny jest prawidłowy.

SPF (RFC 7208) i DKIM (RFC 6376) odpowiadają każdy na wąskie pytanie i żadne z tych pytań nie dotyczy twojego pola From. Usługa newsletterowa może przejść SPF dla własnej domeny zwrotów i podpisać wiadomość własnym kluczem, a wiadomość nadal może podawać się za wysłaną przez ciebie. DMARC zamyka tę lukę. RFC 9989, standard DMARC od maja 2026 r., uznaje wynik tylko wtedy, gdy stojąca za nim domena zgadza się z domeną From, i w jednym zdaniu podaje powód dla DKIM:

DMARC wymaga, aby zgodność identyfikatorów (Identifier Alignment) była stosowana do identyfikatora uwierzytelnionego przez DKIM, ponieważ wiadomość może nosić prawidłowy podpis dowolnej domeny, nawet takiej, której używa nieuczciwy podmiot.

To samo dotyczy SPF, bo każdy może opublikować rekord SPF dla domeny, którą posiada. Reguła brzmi więc: DMARC przechodzi, jeśli SPF przechodzi i jego domena jest zgodna, albo jeśli DKIM przechodzi i jego domena jest zgodna.

Znajdź niezgodność w jednej prawdziwej wiadomości

Potrzebujesz jednego emaila wysłanego tak, jak wysyłana jest twoja prawdziwa poczta, i adresu Gmail, który go odbierze.

Wyślij wiadomość ze skrzynki albo narzędzia, o które chodzi, na adres Gmail, który możesz otworzyć.
Otwórz ją w Gmailu na komputerze. Obok przycisku odpowiedzi kliknij More (Więcej), a potem Show original (Pokaż oryginał). Google opisuje te same kroki na stronie Trace an email with its full header (śledzenie emaila na podstawie pełnego nagłówka).
Znajdź nagłówek Authentication-Results, w którym serwer odbierający zapisuje wynik swoich kontroli (RFC 8601). Porównaj trzy wartości: domenę po smtp.mailfrom=, domenę po header.i=@ (niektórzy odbiorcy piszą header.d=) i domenę po header.from=. Poradnik Jak czytać nagłówki wiadomości omawia ten wiersz krok po kroku.

Tak wygląda wzorzec wiadomości, która przechodzi SPF i DKIM, a nie przechodzi DMARC. Nagłówek jest skrócony i używa przykładowych domen:

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

Czytaj od dołu. Domena From to example.com. SPF przeszedł, ale dla send.vendor-mail.example. DKIM przeszedł, ale podpis należy do vendor-mail.example. Żadna z nich nie jest example.com, więc nic nie potwierdza nazwy z pola From.

Gdy usługa zostanie skonfigurowana tak, żeby podpisywała twoją domeną, ta sama wiadomość wygląda tak:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

SPF nadal wskazuje na dostawcę usługi. To w porządku. DKIM teraz się zgadza, a DMARC potrzebuje tylko jednego wyniku pass ze zgodną domeną.

Jak blisko to wystarczająco blisko: zgodność łagodna i ścisła

Obie domeny nie muszą być identyczne. Domyślnie zgodność jest łagodna (relaxed): wystarczy, że obie należą do tej samej zarejestrowanej domeny, którą standard nazywa domeną organizacyjną. Zgodność ścisła (strict) wymaga dokładnego dopasowania. Wybierasz za pomocą znaczników adkim dla DKIM i aspf dla SPF w swoim rekordzie DMARC.

SPF albo DKIM przeszedł dla	Domena From	Łagodna (domyślna)	Ścisła
`example.com`	`example.com`	Zgodna	Zgodna
`mail.example.com`	`example.com`	Zgodna	Niezgodna
`example.com`	`news.example.com`	Zgodna	Niezgodna
`vendor-mail.example`	`example.com`	Niezgodna	Niezgodna

Standard zauważa, że „niemal wszyscy właściciele domen uznali zgodność łagodną za wystarczającą dla swoich potrzeb”. Mimo to sprawdź własny rekord. Przykładowy rekord na górze strony Google Set up DMARC kończy się na adkim=s; aspf=s, więc rekord skopiowany stamtąd jest ścisły. Jeśli twój ma te dwa znaczniki, a jakieś narzędzie wysyła z subdomeny, usuń je. Sam Google ostrzega na tej stronie, że zgodność ścisła „może powodować, że wiadomości z powiązanych subdomen będą odrzucane lub wysyłane do spamu”.

Skąd zwykle bierze się niezgodność

Usługa, która wysyła z własnych serwerów

Platformy newsletterowe, systemy CRM, narzędzia do fakturowania i systemy obsługi zgłoszeń wysyłają twoją pocztę ze swojej infrastruktury. Dopóki nie podłączysz swojej domeny, zwykle używają adresu zwrotnego w swojej domenie i podpisują własnym kluczem. Dokumentacja Amazona mówi wprost, dlaczego zgodność SPF jest tu rzadka: Return-Path „służy do obsługi zwrotów i skarg, które dostawca (SES) śledzi za pomocą adresu należącego do niego” (Amazon SES). Ustawienie, które to naprawia, w każdej usłudze nazywa się inaczej, a kończy się na kilku rekordach DNS po twojej stronie.

Usługa	Zanim podłączysz swoją domenę	Ustawienie, którego szukasz
Twilio SendGrid	Poczta jest pokazywana jako wysłana „via sendgrid.net”.	Domain authentication: rekordy CNAME dla subdomeny zwrotów i dwa klucze DKIM.
Amazon SES	Return-Path to subdomena `amazonses.com`.	Easy DKIM dla podpisu i custom MAIL FROM domain (własna domena MAIL FROM) dla SPF.
Mailchimp	Domena jest zweryfikowana, ale nie uwierzytelniona.	Email domain authentication: dwa rekordy CNAME dla DKIM.

To opisy samych dostawców według stanu na październik 2026 r. Inne usługi działają podobnie. Szukaj w ich pomocy haseł „authenticate domain”, „custom DKIM” albo „branded sending domain”.

Twój dostawca poczty podpisuje własną domeną albo wcale

Przy skrzynce we własnej domenie Return-Path to zwykle twój własny adres, więc SPF jest zgodny, gdy tylko twój rekord SPF wymienia dostawcę. Pokazuje to wartość po smtp.mailfrom=. DKIM to ta część, którą trzeba włączyć.

Google Workspace. Dopóki DKIM dla twojej domeny nie jest włączony, Google dotychczas podpisywał jedną z własnych domen. Wcześniejsza wersja strony pomocy Google podawała, że Gmail podpisuje wtedy „tym domyślnym kluczem domeny DKIM: d=*.gappssmtp.com”. Obecna strona nie wymienia już tej domeny, więc sprawdź własny nagłówek: header.i kończące się na gappssmtp.com oznacza, że twój klucz nie jest aktywny. Wygeneruj go w konsoli administracyjnej Google w sekcji Apps, Google Workspace, Gmail, Authenticate email (uwierzytelnianie poczty), dodaj rekord TXT, który tam zobaczysz, a potem kliknij Start authentication, czyli „rozpocznij uwierzytelnianie” (Set up DKIM).
Microsoft 365. Dokumentacja Microsoftu, zaktualizowana w sierpniu 2026 r., podaje: „Obecnie poczta wychodząca z domen niestandardowych nie jest podpisywana DKIM”. Publikujesz dwa rekordy CNAME i włączasz podpisywanie w portalu Defender (How to use DKIM for email in your custom domain).

Rekord, który dodajesz dla klucza DKIM, zawsze leży poniżej _domainkey, pod nazwą wybraną przez dostawcę. Dla Google Workspace wygląda tak, ze skróconym kluczem:

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Narzędzie, które łączy się z twoją skrzynką i wysyła przez nią, nie dodaje własnego podpisu. Poczta z takiego narzędzia wygląda dokładnie tak jak poczta pisana ręcznie, więc naprawia się to u dostawcy poczty, a nie w narzędziu.

Wiadomość została przekazana dalej

Gdy odbiorca automatycznie przekazuje twoją pocztę dalej, dociera ona z serwera, którego twój rekord SPF nie wymienia. SPF nie przechodzi albo przechodzi dla domeny przekazującego. Podpis DKIM przetrwa tę drogę, o ile nikt nie zmieni wiadomości. Listy mailingowe, które dodają stopkę albo znacznik w temacie, również łamią podpis. Z twojej strony nie da się tego naprawić. FAQ Google dla nadawców mówi, że w Gmailu „zgodność DMARC nie jest wymagana dla wiadomości przekazanych dalej ani wiadomości z list mailingowych”. To powód, żeby mieć zgodny DKIM i nie polegać na samym SPF.

Zapieczętowany list przechodzi z jednej łodzi pocztowej na drugą; każda łódź ma własny worek pocztowy i zawieszkę, a pieczęć lakowa na liście jest nienaruszona — Przekazanie dalej zmienia worek pocztowy i jego zawieszkę. Pieczęć na liście pozostaje nienaruszona.

To nie jest twoja poczta

Jeśli twoje raporty DMARC pokazują niepowodzenia z serwerów, które nigdy nie były przez ciebie używane, ktoś może wysyłać z twoim adresem. Te wiadomości mają nie przechodzić. Nie trzeba niczego naprawiać, a są one argumentem za surowszą polityką w przyszłości.

Najpierw napraw DKIM, potem SPF

Każdy z nich daje ci wynik pass. Lepiej mieć DKIM, bo podróżuje razem z wiadomością. Dobre praktyki M3AAWG ujmują to jako regułę: „Podpisuj całą pocztę wychodzącą kluczem DKIM, który jest zgodny z domeną nagłówka RFC5322.From”. RFC 9989 zaleca stosowanie obu.

Spisz wszystko, co wysyła jako twoja domena. Skrzynki, narzędzie do newsletterów, CRM, faktury, formularz kontaktowy na twojej stronie. Twoje raporty DMARC wskażą te źródła, o których nie pamiętasz.
Przetestuj każde z nich opisaną wyżej kontrolą nagłówka i zanotuj, która z dwóch domen nie jest twoja.
Włącz podpisywanie własną domeną wszędzie tam, gdzie header.i pokazuje inną nazwę, i opublikuj rekordy, które poda ci usługa. Wybierz klucz 2048-bitowy, jeśli twój dostawca DNS go przyjmuje. Gmail wymaga co najmniej 1024 bitów i zaleca 2048.
Ustaw własną domenę zwrotów tam, gdzie usługa ją oferuje, w subdomenie takiej jak bounce.example.com. To zapewnia zgodność także dla SPF.
Wyślij test ponownie i szukaj dmarc=pass. Zmiany w DNS mogą chwilę potrwać. Google daje nowemu kluczowi DKIM do 48 godzin na rozpoczęcie działania.

Nie działa natomiast dopisanie dostawcy usługi do własnych rekordów. include: dla dostawcy w twoim rekordzie SPF niczego nie zmienia, jeśli Return-Path jest w domenie dostawcy, bo SPF sprawdza rekord tamtej domeny, a nie twojej. Rekord DMARC też nie może wymieniać zaufanych stron trzecich. Standard mówi, że nie ma na to „żadnego ogólnie przyjętego mechanizmu”.

Jeśli nagłówek pokazuje dmarc=pass, a wiadomość nadal trafia do spamu, przyczyną nie jest już uwierzytelnianie. Od tego miejsca prowadzi poradnik SPF, DKIM i DMARC przechodzą, a email i tak trafia do spamu.

Co kosztuje DMARC, który nie przechodzi, gdy twoja polityka to p=none

Przy p=none prosisz odbiorców, żeby po niepowodzeniu nic nie robili, więc z powodu twojej polityki nic nie jest odrzucane. Mimo to działa to na twoją niekorzyść na dwa sposoby.

Zasady dla nadawców masowych. Gmail, Yahoo i Outlook.com wymagają od nadawców masowych poczty ze zgodnymi domenami, co w Gmailu i Outlook.com oznacza próg 5000 wiadomości dziennie. FAQ Google dla nadawców wymienia błąd tymczasowy 4.7.32 dla poczty, której nagłówek From „nie jest zgodny z uwierzytelnioną domeną organizacyjną SPF ani DKIM”, i jako konsekwencję podaje „kody błędów tymczasowych lub trwałych albo umieszczanie w folderze spamu”.
Blokuje następny krok. Gdy tylko przejdziesz na p=quarantine albo p=reject, każda twoja własna wiadomość bez zgodnej domeny ma być traktowana jako spam albo odrzucana. W Gmailu zwrot brzmi „Unauthenticated email from domain-name is not accepted due to domain's DMARC policy”, błąd 5.7.26 (Troubleshoot DMARC issues).

Jeśli w ogóle nie masz rekordu DMARC, zacznij od rekordu, który trzeba dodać. Włącza on też raporty, które pokazują zgodność domen dla wszystkich twoich nadawców naraz.

Co rozgrzewanie może tu zrobić, a czego nie

Rozgrzewanie nie naprawia zgodności domen. WarmupBay łączy się z twoją skrzynką i wysyła z niej, więc jego wiadomości rozgrzewające są wysyłane i podpisywane przez twojego dostawcę dokładnie tak jak poczta, którą piszesz samodzielnie. Jeśli twoja skrzynka nie przechodzi DMARC, one też nie przechodzą. Najpierw napraw rekordy.

WarmupBay pomaga w tym, co przedtem, i w tym, co potem. Gdy łączysz skrzynkę, sprawdza SPF, DKIM i DMARC domeny i zatrzymuje rozgrzewanie, jeśli po 72 godzinach nadal ich brakuje. Gdy rekordy są na miejscu, twoja skrzynka wymienia kilka emaili dziennie z innymi skrzynkami we wspólnej sieci, a panel pokazuje, gdzie trafiły: do skrzynki odbiorczej, na kartę Gmaila czy do spamu, osobno dla Google i dla innych dostawców. Nie testuje poczty z twojego narzędzia do newsletterów ani z CRM, bo ta nigdy nie przechodzi przez twoją skrzynkę, i nie potrafi jeszcze łączyć skrzynek Microsoft 365 ani Outlook.com. 10 wiadomości rozgrzewających dziennie jest za darmo. Połącz swoją skrzynkę, gdy nagłówek pokazuje dmarc=pass.

Częste pytania

SPF przechodzi i ma zgodną domenę, DKIM nie ma zgodnej domeny. Czy to wystarczy?

Dla DMARC tak. Wystarczy jeden wynik pass ze zgodną domeną. Przestaje wystarczać, gdy odbiorca przekazuje twoją pocztę dalej, bo SPF wtedy już się nie zgadza. Google pisze też w swoim FAQ dla nadawców, że zgodność zarówno z SPF, jak i z DKIM prawdopodobnie stanie się wymogiem, więc i tak skonfiguruj DKIM dla swojej domeny.

Dlaczego DMARC u jednych odbiorców nie przechodzi, a u innych przechodzi?

Bo poczta dociera do nich różnymi drogami albo od różnych nadawców. Odbiorca, który przekazuje pocztę do innej skrzynki, albo lista mailingowa zmienia to, co widzi SPF, a czasem także DKIM. Może to być też jedna z kilku usług wysyłających, która nie jest jeszcze skonfigurowana. Raporty zbiorcze podają wyniki według serwera wysyłającego i pokazują, który to przypadek.

Czy adres Reply-To ma znaczenie dla DMARC?

Nie. DMARC używa wyłącznie domeny z nagłówka From. Adres Reply-To, nazwa nadawcy i nagłówek Sender nie są częścią kontroli.

Jak zobaczyć problemy ze zgodnością domen bez otwierania nagłówków?

W raportach zbiorczych DMARC. Każdy rekord ma blok policy_evaluated z wynikiem dkim i spf, czyli z wynikami po teście zgodności. Blok auth_results poniżej pokazuje surowe wyniki i domeny, których dotyczyły. Surowy pass obok ocenionego fail to dokładnie przypadek z tej strony. Raporty dostaniesz, gdy dodasz adres rua do swojego rekordu DMARC.

Nagłówek pokazuje dkim=fail albo dkim=neutral. Czy to ten sam problem?

Nie. Wtedy nie zweryfikował się sam podpis, a to inna usterka. Jeśli w tekście jest body hash did not verify, strona rozwiązywania problemów Google podaje przyczynę: wiadomość została zmieniona po podpisaniu, na przykład przez bramę, która dodaje stopkę. Zgodność domen dotyczy podpisu, który jest prawidłowy, ale należy do innej domeny.

Czy potrzebuję osobnego klucza DKIM dla każdej usługi, która wysyła w moim imieniu?

W praktyce tak. Każda usługa podpisuje własnym kluczem i publikuje go pod własną nazwą selektora poniżej _domainkey w twojej domenie, więc kilka kluczy istnieje obok siebie bez konfliktu. Inaczej jest z SPF, gdzie domena może mieć tylko jeden rekord.