Defaults.Exposed › Naprawy › Guides

Przekazywana poczta nie przechodzi SPF — dlaczego tego nie da się naprawić i co naprawdę działa (2026)

Opublikowano 2026-07-08

Dane z 2026-06-29 · metodologia v7. Zagregowane dane ze spisu 261 milionów ocenionych domen. Zobacz jak oceniamy.

Nie możesz sprawić, żeby SPF przechodziło dla przekazywanej poczty — przekazywanie z założenia niszczy SPF, a jedyną uczciwą naprawą jest wyrównany DKIM, który przeżywa przekazywanie. Skala jest ogólnospisu: 7 355 985 z 138 927 207 domen publikujących SPF autoryzuje wyłącznie include przekazywania Namecheap, a ścisłość SPF wynosi <0.1%, zgodnie ze spisem Defaults.Exposed obejmującym 261 milionów domen.

Poniżej znajdziesz: dlaczego żaden rekord SPF, który możesz napisać, nie przeżyje przekazywania, dlaczego SRS i ARC nie są narzędziami, które kontrolujesz, i naprawę, która się utrzyma — podpisywanie DKIM z własną domeną jako zaliczenie DMARC — plus jeden przypadek, który niszczy też DKIM (listy mailingowe przepisujące wiadomości) i co zrobić z tą resztką.

Dlaczego przekazywanie niszczy SPF?

Odbiorcy oceniają SPF względem domeny Return-Path (RFC5321.MailFrom), a nie nagłówka From. Gdy wysyłasz bezpośrednio, IP Twojego serwera jest w Twoim rekordzie SPF i sprawdzenie przechodzi. Gdy odbiorca automatycznie przekazuje wiadomość dalej — na prywatne konto Gmail, przez alias uczelniani, za pośrednictwem produktu do przekazywania rejestratora — serwer przekazującego ją retransmituje, zazwyczaj zachowując Twoją domenę w Return-Path. Końcowy odbiorca teraz pyta: czy ten serwer przekazujący jest autoryzowany w Twoim rekordzie SPF?

Nie jest i nigdy nie będzie: nie wybrałeś przekazującego, nie wiesz, że istnieje, a ta sama wiadomość przekazana przez inną usługę jutro nie przejdzie z innego IP. SPF odpowiada na jedno pytanie — „czy to IP pochodzi z serwera autoryzowanego przez domenę Return-Path?” — a dla przekazywanej poczty prawdziwa odpowiedź brzmi nie. Niepowodzenie to SPF działający zgodnie ze specyfikacją, a nie błędny rekord.

Spis pokazuje, jak powszechna jest ta ścieżka: 7 355 985 domen autoryzuje include przekazywania e-mail Namecheap (spf.efwd.registrar-servers.com) — produkt do przekazywania jednego dostawcy, wyciągnięty z 139 milionów wydawców SPF — z udziałem ścisłego SPF wynoszącym <0.1% i tylko 0,2% wymuszającym DMARC. Ten miękki szablon to nie niedbałość: przekazywanie to dokładnie miejsce, gdzie ścisłe -all chybia, a dostawca, którego produktem jest przekazywanie, wysyła odpowiednio. Pełna historia kwalifikatorów jest w naszym raporcie ~all vs -all, a obraz dostawcy po dostawcy w który dostawca poczty daje najsilniejszy SPF.

Czy nie mogę po prostu dodać serwera przekazującego do rekordu SPF?

Nie — i to właśnie jest sedno tego artykułu:

1. Nie możesz wyliczyć przekazujących. Każdy odbiorca gdziekolwiek może przekazać Twoją pocztę przez dowolną usługę. Twój rekord SPF musiałby wymieniać serwery, których nie możesz z góry znać.
2. Wylistowanie ich by unicestwiło cel. Duże usługi przekazywania retransmitują pocztę dla milionów klientów. Wstaw ich zakresy do swojego rekordu a każda wiadomość, którą retransmituje jakikolwiek ich użytkownik — w tym spoofer — przejdzie SPF jako Ty.

Ta sama logika wyklucza luzowanie kwalifikatora, żeby „przekazywanie działało”: kwalifikator nie jest powodem, dla którego przekazywana poczta nie przechodzi, a gdy DMARC jest w grze, zmienia mniej niż twierdzą większość poradników — patrz dane dotyczące kwalifikatorów. Rekord nie jest tutaj dźwignią. Przestań go ciągnąć.

A co z SRS i ARC — czy one nie naprawiają przekazywania?

Adresują problem — ale żaden nie jest narzędziem, które możesz wdrożyć:

Dane i status mechanizmów z 2026-06-29.

SRS sprawia, że problem SPF przekazującego znika, nie Twój: przepisanie Return-Path zmienia, czyje SPF jest sprawdzane, podczas gdy Twój nagłówek From — domena, którą DMARC broni — pozostaje niezmieniony. ARC to decyzja o zaufaniu między operatorami infrastruktury. Jeśli poradnik mówi Ci, żebyś „wdrożył SRS” jako właściciel domeny, to pomylił Cię z dostawcą przekazywania.

Jak sprawić, żeby poczta przeżyła przekazywanie?

Sprawdź, żeby DKIM, wyrównany z Twoją domeną, był Twoim zaliczeniem DMARC. Podpis DKIM to kryptografia noszona w nagłówkach wiadomości: weryfikuje wszędzie tam, gdzie wiadomość trafia, bez względu na to, ile serwerów ją retransmitowało, o ile podpisana treść nie została zmodyfikowana. DMARC potrzebuje tylko jednego wyrównanego zaliczenia — SPF lub DKIM — więc gdy przekazywanie niszczy nogę SPF, wyrównany DKIM utrzymuje wiadomość uwierzytelnioną.

1. Uruchom bezpłatne skanowanie na defaults.exposed przed dotykaniem DNS. Pokazuje, czy masz w ogóle DKIM, czy podpisuje Twoją domeną i gdzie stoi DMARC — abyś naprawił rzeczywistą lukę, a nie walczył z rekordem SPF.
2. Potwierdź, że przekazywanie jest faktycznie Twoim problemem. W nagłówku Authentication-Results wiadomości, której dotyczy problem, bezpośrednia poczta przechodzi SPF, podczas gdy przekazana kopia nie przechodzi z IP usługi przekazywania. Jeśli SPF i DKIM przechodzą, a DMARC nadal nie, masz problem z wyrównaniem — patrz DMARC nie przechodzi, ale SPF i DKIM tak.
3. Włącz podpisywanie DKIM z własną domeną w każdej usłudze wysyłkowej — najpierw dostawca skrzynki, potem ESP i nadawcy transakcyjni. Domyślne ustawienia dostawców często podpisują domeną dostawcy, która się nie wyrównuje; chcesz d=yourdomain. Zacznij od jak naprawić DKIM, ze ścieżkami kliknięć dla Google Workspace i Microsoft 365.
4. Sprawdź wyrównanie, a nie tylko zaliczenie. Domena d= w podpisie musi pasować do domeny From; dkim=pass na cudzej domenie nic nie robi dla Twojego DMARC.
5. Zostaw rekord SPF w spokoju. Trzymaj go dokładnym dla poczty bezpośredniej — nadal uwierzytelnia większość Twojego ruchu i pozostaje Twoją drugą nogą DMARC. Po prostu przestań próbować sprawić, żeby obejmował przekazujących.
6. Ponów skanowanie, a następnie etapowo wdrożyj wymuszanie DMARC — następna sekcja i przewodnik przejścia od p=none do p=reject.

Ta kombinacja — SPF plus wymuszający DMARC oparty na wyrównanym DKIM — to wzorzec odporny na przekazywanie, i jest rzadki: z 77,5 milionów domen publikujących ~all, tylko 9,2% (7 116 774) popiera to wymuszającą polityką DMARC, a tylko 3,87% z 261 milionów ocenionych domen (10 092 481) wypełnia pełną triadę SPF + DKIM + wymuszony DMARC, zgodnie ze spisem (2026-06-29).

A co z listami mailingowymi, które przepisują wiadomości?

Jedyna ścieżka przekazywania, której wyrównany DKIM nie przeżywa: listy mailingowe, które modyfikują wiadomość — tag tematu [nazwa-listy], stopka z linkiem wypisania, usunięty załącznik. Zmień podpisaną treść a hash ciała już nie pasuje, więc DKIM też nie przechodzi (dkim=fail: body hash did not verify to własny przewodnik dla tej awarii). Teraz obie nogi DMARC są martwe i tylko lista może to złagodzić (przepisanie From, pieczętowanie ARC).

Ta resztka jest dokładnie tym, do czego służy etapowe wymuszanie DMARC. Przechodzenie przez p=quarantine z rampą pct podczas obserwowania raportów zbiorczych pokazuje, ile Twojej prawdziwej poczty przepływa przez przepisujące listy zanim polityka p=reject zacznie je odbijać. Nie skacz od razu do reject na domenie, której użytkownicy żyją na listach mailingowych; nie tkwij też wiecznie w p=none. Przewodnik etapowego wdrożenia opisuje rampę.

Często zadawane pytania

Czy przekazywanie niszczy też DKIM? Zwykłe przekazywanie, nie: podpis podróżuje z wiadomością i weryfikuje u końcowego odbiorcy. DKIM psuje się tylko gdy podpisana treść jest modyfikowana w drodze — tagi tematu listy mailingowej i stopki to klasyczny przypadek — dlatego resztka listy jest obsługiwana przez etapowanie polityki DMARC, a nie przez cokolwiek w DNS.

Czy powinienem przejść z -all na ~all, żeby przekazywanie przestało nie przechodzić? Zmiana kwalifikatora nie sprawi, że przekazujący przejdą — to nie jest powód, dla którego nie przechodzą. Znamienne jest, że include przekazywania Namecheap, 7 355 985 domen i największa w spisie populacja dedykowanego przekazywania (2026-06-29), ma ścisły SPF na poziomie <0.1%: miękkie SPF to prawdopodobnie właściwy szablon dla produktu do przekazywania. Patrz raport ~all vs -all, żeby zobaczyć, co kwalifikator faktycznie zmienia.

Dlaczego poczta przechodzi SPF wysłana bezpośrednio, ale nie przechodzi gdy ktoś ją przekazuje? Odbiorca sprawdza, czy IP ostatniego serwera transmitującego jest autoryzowane przez rekord SPF domeny Return-Path. Bezpośrednie: Twój serwer, w Twoim rekordzie, przechodzi. Przekazane: serwer przekazującego, nie w Twoim rekordzie, nie przechodzi. Twój rekord się nie zmienił — zmienił się transmitujący IP.

Czy mogę skonfigurować SRS, żeby to naprawić? Tylko jeśli jesteś przekazującym. SRS działa na serwerze wykonującym przekazywanie, a nawet tam, gdzie działa, wynikające zaliczenie SPF należy do domeny przekazującego i nie wyrównuje się z Twoim From — Twój DMARC nadal potrzebuje nogi DKIM.

Czy SPF jest bezużyteczny, skoro i tak jest niszczony przez przekazywanie? Nie. Większość poczty jest dostarczana bezpośrednio, gdzie SPF działa dokładnie zgodnie z przeznaczeniem, i pozostaje jedną z Twoich dwóch nóg DMARC. Z 261 086 232 domen w spisie (2026-06-29), 138 927 207 publikuje SPF — trzymaj swój dokładnym poprzez stronę naprawy SPF i pozwól DKIM nieść przekazaną resztę.

Wyślij właścicielowi raport

Jeśli naprawiasz to dla klienta lub pracodawcy, zamknij pętlę z dowodem. Gdy DKIM z własną domeną jest aktywny i DMARC jest etapowany, ponów bezpłatne skanowanie i prześlij oceniony raport właścicielowi firmy: z datą, w prostym języku, pokazujący, że domena pozostaje uwierzytelniona nawet gdy jej poczta jest przekazywana. To artefakt do przedłużenia ubezpieczenia cybernetycznego i kolejnego kwestionariusza dostawcy — udokumentowane porównanie przed i po, a nie „włączyłem coś”.

Sprawdź swoją domenę → · DMARC nie przechodzi, ale SPF i DKIM tak → · Napraw DKIM → · Jak oceniamy → · Tylko dane zagregowane. Dane przechowywane i przetwarzane w UE.