Defaults.Exposed › Naprawy › Guides

SPF nie przechodzi dla narzędzi SaaS? Dlaczego tak się dzieje i jak to naprawić — edycja europejska (2026)

Opublikowano 2026-07-08

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

Gdy narzędzie SaaS „nie zalicza SPF”, Twój rekord zazwyczaj nie jest problemem: poczta nie przechodzi wyrównania DMARC albo łańcuch includes przekroczył limit 10 wyszukiwań DNS. 2 119 539 z 138 927 207 domen publikujących SPF ma 9–10 wyszukiwań — jeden include SaaS od przepaści — zgodnie ze spisem Defaults.Exposed obejmującym 261 086 232 domen.

Poniżej znajdziesz: jak stwierdzić, który z dwóch problemów masz, oraz kolejność naprawy — najpierw skanowanie, potem ustal domenę, z której naprawdę wysyła narzędzie, przełącz dostawcę na DKIM z własną domeną i dodawaj include SPF tylko tam, gdzie naprawdę pomaga — plus szczegóły dla HubSpot, Salesforce, Mailchimp i SendGrid.

Dlaczego poczta z narzędzia SaaS nie przechodzi SPF?

Trzy wzorce obejmują niemal każdy przypadek:

Dane z 2026-06-29.

Wyróżniony pogrubioną czcionką wiersz to miejsce, gdzie stoi większość ludzi. Dodawanie linii include: dla każdego narzędzia tego nie naprawia — i każda linia przybliża do drugiego wiersza: co najmniej 797 263 domen już przekroczyło limit 10 wyszukiwań i ich SPF zwraca PermError, który nic nie chroni. Pełne liczby w raporcie SPF PermError.

Którą domenę SPF faktycznie sprawdza?

Nie tę w nagłówku From. Odbiorcy oceniają SPF względem domeny Return-Path (RFC5321.MailFrom, zwanej też adresem bounce lub envelope-from) — nagłówek From widoczny dla odbiorcy nie bierze żadnego udziału w samym sprawdzaniu SPF.

Ten jeden fakt wyjaśnia większość „niepowodzeń SPF SaaS”. Twoja platforma marketingowa wysyła z Return-Path takim jak [email protected]; SPF jest sprawdzany względem vendor.com i przechodzi bez problemu. Następnie DMARC pyta, czy ta domena sprawdzona przez SPF zgadza się z domeną From. Nie zgadza się, więc noga SPF w DMARC nie przechodzi i Twój panel mówi „SPF failing”. Edytowanie własnego rekordu SPF tego nie naprawi — Twój rekord nigdy nie był konsultowany.

Jaka jest kolejność naprawy?

1. Najpierw uruchom bezpłatne skanowanie. Mówi Ci w jednym przebiegu, czy Twój SPF brakuje, jest zduplikowany, przekracza limit wyszukiwań czy jest w porządku, oraz gdzie stoi DMARC — zanim dotkniesz DNS.
2. Znajdź Return-Path, którego narzędzie faktycznie używa. Wyślij do siebie test z narzędzia i odczytaj nagłówek Return-Path (i Authentication-Results) w surowej wiadomości. To mówi Ci, w którym wierszu powyższej tabeli jesteś.
3. Włącz DKIM z własną domeną u dostawcy. Każde poważne narzędzie SaaS oferuje „uwierzytelnianie domeny”: kilka rekordów CNAME, które pozwalają mu podpisywać DKIM jako Twoja domena. Ten podpis wyrównuje z domeną From, więc DMARC przechodzi przez DKIM — trwale i nawet gdy poczta jest przekazywana. To jest naprawa, która przetrwa próbę czasu.
4. Dodaj include SPF dostawcy tylko wtedy, gdy używa Twojego return-path — włączyłeś jego niestandardową domenę bounce lub naprawdę wysyła z Twoją domeną w kopercie. Include dla dostawcy, który bounceuje przez własną domenę, nic nie kupuje i spala Twój budżet wyszukiwań.
5. Policz wyszukiwania DNS przed zapisaniem. Limit to 10 rozwiązanych wyszukiwań, includes liczą się rekurencyjnie, a 2 119 539 domen już ma 9–10 — 99. percentyl spisu to 9. Blisko granicy? Najpierw usuń includes dla narzędzi, których już nie używasz. Właśnie zmieniłeś dostawcę poczty? Sprawdź, czy nie ma drugiego zduplikowanego rekordu — dwa rekordy SPF to PermError.
6. Ponów skanowanie i potwierdź. SPF przechodzi dla właściwej domeny, DKIM wyrównany, DMARC przechodzi. Pełny opis jest na stronie jak naprawić SPF; przewodniki dla dostawców jak SPF w GoDaddy i DMARC w IONOS opisują kliknięcia w panelu DNS.

Co zrobić dla HubSpot, Salesforce, Mailchimp i SendGrid?

HubSpot. Połącz domenę wysyłkową w ustawieniach HubSpot i opublikuj dwa CNAME DKIM, które wydaje (hs1-… / hs2-…). To wyrównuje DKIM z domeną From. Nie potrzebujesz include SPF dla HubSpot, chyba że skonfigurowałeś go do używania własnej domeny bounce.

Salesforce. Utwórz klucz DKIM w konfiguracji Salesforce i opublikuj parę CNAME, którą generuje. Jeśli Salesforce wysyła z return-path Twojej organizacji, dodaj include:_spf.salesforce.com i skonfiguruj domenę bounce — to jedyne duże CRM, gdzie include SPF jest często naprawdę potrzebny.

Mailchimp. Uwierzytelnij domenę i opublikuj CNAME DKIM k2 / k3. Wyrównanie Mailchimp jest oparte tylko na DKIM — nie ma już include SPF do dodania, a dodawanie go ze starego poradnika po prostu marnuje wyszukiwania.

SendGrid. Zakończ uwierzytelnianie domeny („automatyczne zabezpieczenia”): trzy CNAME obsługujące zarówno DKIM, jak i return-path w Twojej własnej subdomenie. Nie potrzeba include SPF. Z 740 321 domen, których SPF autoryzuje sendgrid.net, tylko 18,0% ma wymuszający DMARC (dane z 2026-06-29) — większość nadawców SendGrid zatrzymuje się krok za wcześnie.

Zendesk i wszystko inne: ten sam wzorzec. Znajdź stronę „uwierzytelniania domeny” narzędzia, opublikuj jego CNAME DKIM i dotykaj SPF tylko wtedy, gdy narzędzie dokumentuje, że używa Twojego return-path.

Czy SPF różni się dla europejskich firm?

Nie — SPF, DKIM i DMARC działają identycznie wszędzie. To, co różni się w Europie, to kontekst: kto pyta i co zrobili już Twoi sąsiedzi.

Twoje ccTLD wyznacza lokalną poprzeczkę. Europejskie ccTLD publikują SPF znacznie powyżej stawek .com, ale domeny, które kończą zadanie — wymuszająca polityka DMARC na wierzchu — stanowią mniejszość wszędzie:

Dane z 2026-06-29. Francja: 13,65% wymuszający DMARC; Włochy: 5,24%.

Domyślne ustawienia Twojego europejskiego hosta mają znaczenie. 4 346 526 domen autoryzuje serwery pocztowe IONOS z UE (_spf-eu.ionos.com) w swoim SPF — i tylko 0,3% kończy się ścisłym -all, a 1,0% ma wymuszony DMARC. OVH z jego 2 132 049 wypada lepiej pod względem ścisłości (43,7%), ale tylko 2,2% wymusza DMARC (dane z 2026-06-29). Jeśli nigdy nie dotykałeś swojego rekordu, stoisz na tych domyślnych ustawieniach.

Regulatorzy już to nazywają po imieniu. Artykuł 21 ust. 2 lit. j NIS2 wymaga od podmiotów objętych zakresem zabezpieczenia komunikacji, a Rozporządzenie Wykonawcze Komisji (UE) 2024/2690 szczegółowo określa środki bezpieczeństwa poczty i DNS. Uwierzytelnianie poczty to konkretny, sprawdzalny element — i, wyjątkowo jak na zgodność z przepisami, bezpłatny do naprawy.

W kwestii rezydencji danych: skaner i spis Defaults.Exposed działają w AWS eu-west-1, publikujemy tylko dane zagregowane, a skanowanie sprawdza tylko domenę, o którą pytasz.

Często zadawane pytania

Mój checker SPF mówi „pass”, ale panel narzędzia mówi, że SPF nie przechodzi — dlaczego? Checker przetestował Twój rekord; odbiorca przetestował domenę Return-Path, której narzędzie faktycznie użyło, a następnie DMARC porównał ją z domeną From. To jest błąd wyrównania, a nie błąd rekordu — naprawiony przez DKIM z własną domeną u dostawcy, a nie edytowaniem SPF.

Czy powinienem po prostu dodać include SPF dla każdego narzędzia, którego używamy? Nie. Każdy include wydaje część budżetu 10 wyszukiwań SPF, rekurencyjnie: 2 119 539 z 138 927 207 domen publikujących SPF ma 9–10 wyszukiwań, a co najmniej 797 263 przekroczyło limit — ich SPF zwraca PermError i niczego nie chroni (dane z 2026-06-29).

Czy include naprawia też DMARC? Tylko jeśli narzędzie wysyła z Twoim return-path, więc SPF przechodzi i wyrównuje. Dla większości narzędzi SaaS tak nie jest — dlatego wyrównany DKIM, a nie SPF, jest nogą, która sprawia, że DMARC przechodzi dla poczty SaaS.

Czy to jest wymóg prawny w UE? Dla podmiotów objętych zakresem NIS2 art. 21 ust. 2 lit. j i Rozporządzenie Wykonawcze (UE) 2024/2690 czynią bezpieczeństwo poczty obowiązkiem. Nawet poza zakresem, ubezpieczyciele i kwestionariusze klientów coraz częściej pytają — a według stanu na 2026-06-29, żadne europejskie ccTLD nie doprowadza nawet jednej trzeciej swoich domen do wymuszającej polityki DMARC (29,43% w .nl to najlepszy wynik; 5,24% w .it).

Wyślij właścicielowi raport

Gdy CNAME są aktywne, ponów skanowanie i prześlij oceniony raport właścicielowi firmy lub klientowi. Pokazuje on w prostym języku, co nie działało, co naprawiłeś i gdzie teraz stoi domena — dokładnie takie dowody, jakich potrzebują do przedłużenia ubezpieczenia lub kwestionariusza bezpieczeństwa klienta, na piśmie, a nie na Twoje słowo.

Sprawdź swoją domenę bezpłatnie

Zobacz dokładnie, która noga SPF, DKIM i DMARC nie przechodzi — prywatnie i tylko dla właściciela.

Sprawdź swoją domenę → · Napraw SPF → · SPF PermError: „too many DNS lookups” → · Jak oceniamy → · Tylko dane zagregowane. Dane przechowywane i przetwarzane w UE.