Checker Rekordów SPF — Sprawdź SPF Online

Sprawdź rekord SPF dowolnej domeny tak, jak robią to serwery odbierające pocztę: każdy include z własnym kosztem zapytań DNS, bieżąca suma względem limitu 10, puste zapytania i wynik testu SPF dla dowolnego IP nadawcy wraz z członem, który zdecydował.

Aktualizacja: 24 października 2026

Źródła: rekordy TXT domeny i każdy include, przez Google Public DNS (za nim Cloudflare 1.1.1.1) · RFC 7208 check_host, uruchamiany na naszym serwerze · nic nie jest zapisywane

Dokładnie ta nazwa, którą wpiszesz: SPF nie dziedziczy, więc mail.example.com potrzebuje własnego rekordu.

Spróbuj

Czym jest rekord SPF?

Rekord SPF to rekord TXT, który wymienia serwery uprawnione do wysyłania poczty w imieniu domeny. Zaczyna się od v=spf1, potem wskazuje nadawców człon po członie i kończy się tym, co odbiorcy mają zrobić z całą resztą (RFC 7208, kwiecień 2014, wciąż obowiązujący standard).

Odbiorcy sprawdzają go względem adresu serwera, który się łączy, i domeny w nadawcy koperty, czyli MAIL FROM lub Return-Path, a nie względem linii From:, którą widzi czytelnik. Powiązanie SPF z From: to zadanie DMARC.

Rekord obejmuje tylko dokładnie tę nazwę, w której leży: SPF nie dziedziczy, więc mail.example.com potrzebuje własnego rekordu. Domena, która nie wysyła poczty, powinna opublikować v=spf1 -all.

Rekord SPF, człon po członiegoogle.com · TXT · zapisano 24 października 2026 · TTL 5 minut

v=spf1Wersjainclude:_spf.google.comMechanizm · 1 zapytanie~allKwalifikator ~ · mechanizm all

Include wskazuje _spf.google.com · 8 zakresów, bez dalszych zapytań

ip4:74.125.0.0/16ip4:209.85.128.0/17ip6:2001:4860:4864::/56ip6:2404:6800:4864::/56ip6:2607:f8b0:4864::/56ip6:2800:3f0:4864::/56ip6:2a00:1450:4864::/56ip6:2c0f:fb50:4864::/56~all

WersjaDokładnie v=spf1, na początku: rekord, który zaczyna się inaczej, nie jest rekordem SPF.

Mechanizmyinclude, a, mx, ip4, ip6, exists, ptr i all, sprawdzane od lewej do prawej: decyduje pierwsze trafienie.

Kwalifikatory+ pass (domyślny), - fail, ~ softfail, ? neutral, zapisywane przed mechanizmem.

Modyfikatoryredirect= przekazuje sprawdzenie do innego rekordu; exp= wyjaśnia fail.

Cały rekord domeny google.com to trzy człony: odbiorca pobiera include, dopasowuje IP nadawcy do jego zakresów albo dochodzi do ~all. Zapisano przez Google Public DNS dnia 24 października 2026.

Jak sprawdzić rekord SPF

Wpisz domenę powyżej, a checker odczyta jej rekordy TXT, wybierze ten, który zaczyna się od v=spf1, i pójdzie za każdym include i redirect tak, jak zrobiłby to serwer odbierający, licząc po drodze każde zapytanie DNS.

Ręcznie zapytaj o rekordy TXT: dig TXT example.com +short lub nslookup -type=TXT example.com. Odpowiedź zawiera każdy rekord TXT w tej nazwie; rekordem SPF jest ten zaczynający się od v=spf1, a długi przychodzi jako kilka ciągów w cudzysłowach, które SPF łączy bez spacji. Każdy include to kolejne zapytanie, a liczyć trzeba samodzielnie.

Aby sprawdzić, czy konkretny serwer może wysyłać, przełącz się na Test IP: uruchamia to samo sprawdzenie dla tego adresu i pokazuje człon, który pasował.

% dig TXT example.com +short

Każdy rekord TXT w tej nazwie, tak jak ma go twój resolver; rekordem SPF jest ten zaczynający się od v=spf1. Uruchom ponownie dla każdego include.

Co pokazuje dig, a czego niegithub.com · dig TXT · zapisano 24 października 2026

konsola1 z 24 rekordów TXT

$ dig TXT github.com @dns1.p08.nsone.net +norec +noall +answer
github.com.  3300  IN  TXT  1"v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.2"2 "27.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all"

# potem każdy include, po jednym zapytaniu:
$ dig +short TXT _spf.salesforce.com4
"v=spf1 exists:%{i}._spf.mta.salesforce.com -all"

Jeden rekord zaczyna się od v=spf1. 23 inne rekordy TXT obok (tokeny weryfikacyjne i tym podobne) nie mają znaczenia dla SPF, poza rozmiarem odpowiedzi.
Połączone bez spacji: 2 ciągi. Podział co 255 bajtów wypada wewnątrz ip4:62.253.227.114: odbiorcy sklejają ciągi z powrotem, więc to w porządku.
TTL 5 minut. Jak długo resolvery mogą trzymać tę kopię po zmianie. Własny serwer strefy mówi 5 minut; resolver pokazuje to, co zostało z jego kopii.
Każdy include to osobne zapytanie. Przejście rekordu domeny github.com to 10 zapytań, razem z zagnieżdżonymi. dig pokazuje jedną nazwę naraz: liczenie do 10 zostaje po twojej stronie.

Windows

$ nslookup -type=TXT github.com 8.8.8.8

PowerShell

# każdy rekord TXT w tej nazwie, z Google Public DNS
PS> Resolve-DnsName -Name github.com -Type TXT -Server 8.8.8.8

Ta strona

/pl/spf-checker?domain=github.com

Odpowiedź TXT domeny github.com z jej własnego serwera nazw: rekord SPF przychodzi jako dwa ciągi, połączone bez spacji, wśród innych rekordów TXT domeny.

Jak czytać wynik: drzewo include

Werdykt mówi, co dostają odbiorcy dla nadawcy, którego rekord nie wymienia: poprawny z zakończeniem (softfail dla ~all, fail dla -all), albo permerror z przyczyną, albo „nie udało się sprawdzić”, gdy DNS nie odpowiedział.

Granatowa kolumna to budżet zapytań: jedna komórka na zapytanie DNS, w kolorze include, który je wydaje, bieżąca suma względem 10 i puste zapytania jako kółka. Po 10. komórki czerwienieją i zaznaczona jest gałąź, na której odbiorcy przerywają.

Widok Drzewo wylicza odczyty, najpierw błędy, każdy z sekcją RFC i poprawką, a potem każde zapytanie w kolejności, w jakiej pyta odbiorca.

Sprawdź rekord SPF domeny github.com: 10 z 10 zapytań DNS, jedno puste zapytanie i koszt każdego include w budżecie zapytań — Sprawdzenie SPF dla github.com: werdykt, rekord podzielony na człony, odczyty i budżet zapytań z kosztem każdego include. Wybierz numer, aby zobaczyć, co pokazuje każda część.

Limit 10 zapytań i „too many DNS lookups” (permerror)

Odbiorcy liczą każdy człon, który wymaga zapytania DNS, czyli include, a, mx, ptr, exists i redirect, przez każdy zagnieżdżony include, i przerywają na 10. Jedenaste daje permerror (RFC 7208 §4.6.4). ip4, ip6, all i exp nic nie kosztują.

To permerror, a nie fail: co odbiorca z nim zrobi, to jego własna decyzja, ale przy DMARC permerror nigdy nie liczy się jako pass. A ponieważ sprawdzenie kończy się na pierwszym trafieniu, rekord ponad limit wciąż przechodzi dla nadawców wymienionych wcześnie i psuje się tylko dla tych wymienionych późno.

Koszt chowa się w include: include:_netblocks.mimecast.com sam wydaje 9, Yandex 360 wydaje 8, Freshdesk 7, Mailgun 5. Include Google i Microsoft 365 kosztują po 1. Aby zejść poniżej 10, usuń nadawców, z których już nie korzystasz, i przenieś masowego nadawcę na subdomenę z własnym rekordem.

Kto wydaje 10 zapytańKoszty zmierzone 24 października 2026 · wymyślony rekord z prawdziwych include

v=spf1 include:spf.protection.outlook.com include:_netblocks.mimecast.com include:mailgun.org include:sendgrid.net -all

Potrzebnych 17 zapytań

Wymieniony w pierwszych 10 zapytaniach: passMicrosoft 3651Mimecast2–10

Wymieniony po zapytaniu 10: permerrorMailgun11–15Twilio SendGrid16–17

Wszyscy pozostali też dostają permerror, a nie fail z -all z rekordu: odbiorcy przerywają, zanim do niego dojdą.

Ile kosztuje jeden includeWłasny udokumentowany include każdego dostawcy · zmierzono 24 października 2026

_netblocks.mimecast.comMimecast9 zapytań
_spf.yandex.netYandex 3608 zapytań
email.freshdesk.comFreshdesk7 zapytań
mailgun.orgMailgun5 zapytań
icloud.comiCloud+5 zapytań
spf.titan.emailTitan Email4 zapytania
secureserver.netGoDaddy3 zapytania
_spf.google.comGoogle Workspace1 zapytanie
spf.protection.outlook.comMicrosoft 3651 zapytanie

Zapytania liczone tak jak w RFC 7208 §4.6.4: sam include plus wszystko, co jest w środku. Wyniki na żywo na tej stronie zawsze pochodzą z przejścia rekordu, nie z tej tabeli.

Czym są puste zapytania (void lookups)?

Puste zapytanie (void lookup) to zapytanie, które wraca bez żadnych rekordów: nazwa nie istnieje (NXDOMAIN) albo istnieje bez rekordu, o który pytano. Odbiorcy powinni dopuścić dwa; trzecie to permerror (RFC 7208 §4.6.4).

Człon wskazujący na host, którego już nie ma, a:old.example.com, sam w sobie nie jest błędem: po prostu nie pasuje i liczy się jako jedno puste zapytanie. Tak samo exists:%{i}._spf.mta.salesforce.com dla każdego nadawcy, którego Salesforce nie wymienia, dlatego kolejność include ma znaczenie.

Awaria serwera albo przekroczenie czasu nie jest pustym zapytaniem: to temperror, a odbiorcy zwykle próbują ponownie później.

Cztery odpowiedzi, trzy wynikiRFC 7208 §4.6.4

Własny rekord domeny salesforce.com dla 192.0.2.1, zapisano 24 października 2026

v=spf1 include:_spf.google.com include:_spf.salesforce.com exists:%{i}._spf.corp.salesforce.com ~all

Puste zapytania2 / 2trzecie: permerror

exists:%{i}._spf.mta.salesforce.com192.0.2.1._spf.mta.salesforce.com → NXDOMAIN · zapytanie 3 · w _spf.salesforce.com
exists:%{i}._spf.corp.salesforce.com192.0.2.1._spf.corp.salesforce.com → NXDOMAIN · zapytanie 4 · w salesforce.com

Wynik: softfail, z wykorzystanymi obydwoma dozwolonymi pustymi zapytaniami

Nazwa istnieje, rekordu nie maa:mail.example.com dla nazwy, która wciąż jest, ale nie ma już adresu: NOERROR bez odpowiedzi. Brak dopasowania, jedno puste zapytanie, sprawdzenie idzie dalej.NODATApuste

Nazwa nie istniejeexists:%{i}._spf.mta.salesforce.com buduje nazwę z każdego IP nadawcy; dla adresu, którego Salesforce nie wymienia, odpowiedzią jest NXDOMAIN: za każdym razem jedno puste zapytanie.NXDOMAINpuste

Trzecie puste zapytaniemx:shop.example.com, nazwa, której już nie ma, po 2 pustych zapytaniach: odbiorcy przerywają tutaj.NXDOMAINpermerror

Brak jakiejkolwiek odpowiedziSERVFAIL lub przekroczenie czasu dla include:_spf.vendor.example: DNS zawiódł, więc nic nie liczy się jako puste.SERVFAILtemperror, nie puste

Include include:spf.bmv.jp domeny blastmail zaczyna się od dwóch takich członów exists: dla adresu, którego nie wymienia, sam wydaje oba dozwolone puste zapytania.

Tylko pusta odpowiedź liczy się jako puste zapytanie. Awaria to temperror i sprawdzenie jest ponawiane później.

Spłaszczanie SPF: kiedy pomaga, a kiedy psuje

Spłaszczanie zastępuje include adresami, które wymienia, więc rekord kosztuje mniej zapytań. Działa dla zakresów, które rzadko się zmieniają, i obraca się przeciwko tobie, gdy dostawca doda serwer, którego nie skopiowałeś: poczta z niego nie przechodzi wtedy SPF.

Microsoft mówi, żeby nie spłaszczać include:spf.protection.outlook.com, a include Google i Microsoft i tak kosztują po jednym zapytaniu. Przeniesienie masowego nadawcy na subdomenę, taką jak news.example.com, daje mu własny rekord i własne 10 zapytań.

Jeden include, spłaszczonymailgun.org · zapisano 24 października 2026

Przed

include:mailgun.org

Zapytania: 5
Pobrane rekordy: 5
Bajty w twoim rekordzie: 19
Mailgun zmienia zakres: uwzględnione od razu

ip4:159.135.224.0/20 ip4:69.72.32.0/20 ip4:204.220.90.0/23 ip4:204.220.92.0/22 +18 więcej

Zapytania: 0
Bajty w twoim rekordzie: 450
Potrzebne ciągi TXT: 2
Mailgun zmienia zakres: twoja kopia jest nieaktualna

Ryzyko nieaktualnej kopii. Kopiujesz dziś 22 zakresy; gdy Mailgun doda kolejny, poczta z niego nie przechodzi SPF, dopóki ktoś nie zauważy i nie zaktualizuje rekordu.

Spłaszczaj tylko zakresy, które rzadko się zmieniają, takie jak adresy własnych serwerów.

Nie spłaszczaj Microsoft 365: Microsoft mówi, że jego adresy nadawcze często się zmieniają, więc zostaw include.

Wybieraj subdomenę dla każdego masowego nadawcy: każda dostaje własny rekord i własne 10 zapytań.

Spłaszczanie wymienia zapytania na utrzymanie: kopia jest poprawna tylko do czasu, aż dostawca zmieni swoje zakresy.

~all czy -all (i DMARC)

Ostatni człon mówi, co dzieje się z każdym nadawcą spoza listy. -all to fail, najmocniejsze stwierdzenie; ~all to softfail, „raczej nie”; ?all to neutral, który odbiorcy traktują jak brak SPF; +all przepuszcza wszystkich i nigdy nie powinien być publikowany.

Między ~all a -all nie ma złej odpowiedzi. Google dokumentuje ~all dla Google Workspace, a Microsoft -all dla Microsoft 365. Przy DMARC w trybie egzekwowania ~all pozwala DMARC zdecydować na podstawie DKIM: niektórzy odbiorcy odrzucają na -all, zanim DMARC zobaczy poprawny podpis DKIM, więc przekazana poczta może wrócić (RFC 9989 §7.1).

Cztery zakończeniaRFC 7208 §2.6 · RFC 9989 §7.1

~all

softfail„Prawdopodobnie nieautoryzowany”: odbiorcy nie powinni odrzucać wiadomości tylko na tej podstawie.

DokumentujeGoogle WorkspaceMailguniCloud+

-all

failNajmocniejsze stwierdzenie: odbiorca może odrzucić wiadomość w SMTP.

DokumentujeMicrosoft 365ZendeskGoDaddy

?all

neutralŻadnego stwierdzenia: odbiorcy traktują to dokładnie jak brak SPF.

DokumentujeFastmailInclude IONOS i OVHcloud też kończą się na ?all: tam jest to nieszkodliwe, bo pasuje tylko pass wewnątrz include.

+all

pass dla wszystkichKażdy serwer w Internecie przechodzi jako ta domena.

Nigdy go nie publikuj

-all z DMARC na p=reject

SPF: fail
odrzucone w SMTP
DKIM nigdy nie sprawdzony

Niektórzy odbiorcy działają najpierw na podstawie SPF, więc przekazana wiadomość z poprawnym podpisem DKIM może zostać odrzucona, zanim ruszy DMARC, a strata nigdy nie pojawia się w raportach DMARC.

~all z DMARC na p=reject

SPF: softfail
DMARC sprawdza DKIM
zgodny DKIM: pass

Decyduje DMARC. Bez podpisu DKIM Microsoft mówi jednak, że DMARC jest w praktyce ignorowany przy niepowodzeniach ~all, i z tego powodu zaleca -all.

Zarówno ~all, jak i -all to poprawne wybory; ?all nic nie mówi, a +all przepuszcza każdego.

Najczęstsze błędy w rekordzie SPF i jak je naprawić

Większość zepsutych rekordów bierze się z trzech wpadek: drugiego rekordu SPF dodanego obok pierwszego zamiast scalenia, include dla dostawcy, którego już nie ma, i wartości skopiowanej z dokumentacji z literówką.

Dokumentacje dostawców same drukują część z nich: Mimecast pisze –all z półpauzą, Postmark include: spf.mtasv.net ze spacją, a Twilio SendGrid wymienia mechanizm aaaa, który nie istnieje. Każdy błąd składni robi z całego rekordu permerror. Kropka po domenie jest natomiast poprawna.

Osiem rekordów, osiem wynikówWymyślone przykłady prawdziwych błędów

Dwa rekordy SPFpermerror

v=spf1 include:_spf.google.com ~allv=spf1 include:sendgrid.net ~all

Poprawka: scal je w jeden: jedno v=spf1, każdy include raz, jedno zakończenie.

Ponad 10 zapytańpermerror

v=spf1 include:_netblocks.mimecast.com include:mailgun.org -all

14 zapytań

Poprawka: usuń nadawców, z których już nie korzystasz, albo daj masowemu nadawcy własną subdomenę.

Trzecie puste zapytaniepermerror

v=spf1 a:old.example.com mx:gone.example.net exists:%{i}.spf.example.org -all

3 puste

Poprawka: usuń człony z nazwami, których już nie ma, i daj include'y exists na końcu.

Include bez rekordu SPF za sobąpermerror

v=spf1 include:spf.retired-vendor.example -all

Poprawka: popraw nazwę albo usuń dostawcę, którego już nie używasz.

Półpauza w –allpermerror

v=spf1 include:_netblocks.mimecast.com –all

Tak wydrukowane we własnej dokumentacji Mimecast

Poprawka: zwykły łącznik: -all.

Spacja po include:permerror

v=spf1 a mx include: spf.mtasv.net ~all

Tak wydrukowane we własnej dokumentacji Postmark

Poprawka: include:spf.mtasv.net

Mechanizm aaaapermerror

v=spf1 aaaa:example.com ~all

Tak wydrukowane we własnej dokumentacji Twilio SendGrid

Poprawka: a:example.com; a już pasuje do rekordów AAAA nadawców IPv6.

Kropka na końcupoprawny

v=spf1 include:spf.protection.outlook.com. -all

Poprawna: RFC 7208 §7.3 mówi, żeby jej nie publikować, ale odbiorcy muszą ją akceptować.

W pomocy Zendesk czytamy też: „składnia redirect: jest obsługiwana”; modyfikator zapisuje się redirect= (RFC 7208 §6.1).

Każdy rekord to wymyślony przykład; błędy są tymi, które odbiorcy widzą najczęściej.

Czego wymagają Gmail, Yahoo i Microsoft

Od lutego 2024 Gmail i Yahoo wymagają od każdego nadawcy skonfigurowania SPF lub DKIM. Nadawcy masowi potrzebują obu, rekordu DMARC co najmniej p=none i domeny From: zgodnej z jednym z nich. Outlook.com prosi nadawców o dużym wolumenie o SPF i DKIM jednocześnie, a od 5 maja 2025 odrzuca tych, którzy ich nie mają.

Próg Gmaila to ponad 5000 wiadomości dziennie do kont osobistych; Yahoo żadnego nie publikuje. Sam SPF nigdy nie sprawia, że poczta jest „zgodna” (aligned): domena MAIL FROM musi być twoja, a nie domeną zwrotną dostawcy.

Zasady trzech dostawców skrzynekOdczytane na własnych stronach każdego dostawcy, 24 października 2026

	Gmail	Yahoo	Outlook.com
Próg masowy	Gmailponad 5000 wiadomości dziennie do osobistych kont Gmail, liczone na domenę główną	Yahoobrak opublikowanego: „Nie będziemy określać progu wolumenu”	Outlook.componad 5000 dziennie (blog Microsoftu); 5000 lub więcej z jednej domeny From: (jego artykuł pomocy)
Wszyscy nadawcy	GmailSPF lub DKIM, plus DNS w przód i odwrotny, TLS i odsetek spamu poniżej 0,3%	YahooSPF lub DKIM, plus DNS w przód i odwrotny oraz odsetek spamu poniżej 0,3%	Outlook.combrak twardej zasady
Nadawcy masowi	GmailSPF i DKIM, DMARC (wystarczy p=none), From: zgodne z SPF lub DKIM, wypisanie jednym kliknięciem dla poczty marketingowej	YahooSPF i DKIM, DMARC co najmniej p=none i przechodzący, From: zgodne z SPF lub DKIM, wypisanie jednym kliknięciem	Outlook.comSPF musi przejść i DKIM musi przejść, DMARC co najmniej p=none, zgodne z SPF lub DKIM
Obowiązuje od	Gmail1 lutego 2024; odrzucanie nasiliło się od listopad 2025	Yahooluty 2024	Outlook.com5 maja 2025 (odrzucanie)
Niepowodzenie SPF widać jako	Gmail`4.7.275.7.27`	Yahooniedokumentowane dla SPF	Outlook.com`550 5.7.515`

Japonia: najostrzejsze ustawienie NTT docomo, 「全て拒否する」, odrzuca pocztę, której IP nadawcy nie autoryzuje rekord SPF domeny, oraz pocztę z domen, które w ogóle nie publikują rekordu SPF. docomo.ne.jp

Źródłasupport.google.com senders.yahooinc.com techcommunity.microsoft.com

Zasady każdego dostawcy tak, jak podają je jego własne strony dnia 24 października 2026.

Sprawdzanie SPF a dig i nslookup

dig i nslookup pokazują rekordy TXT tak, jak ma je twój resolver: rekord SPF i cokolwiek jeszcze leży w tej nazwie. Nie idą za include, nie liczą zapytań ani pustych zapytań i nie mówią, co zdecydowałby odbiorca.

Test SPF taki jak ten przechodzi cały rekord, więc liczby zgadzają się z tym, co oblicza serwer odbierający. Użyj dig dla jednej nazwy, a tego checkera dla werdyktu.

Trzy sposoby spojrzenia na SPFCo pokazuje każdy z nich

	Ten checker	`dig TXT`	`nslookup -type=TXT`
Pokazuje rekordy TXT	Ten checkerTakpodzielone na człony	dig TXTTak	nslookup -type=TXTTak
Łączy ciągi długiego rekordu	Ten checkerTakjak odbiorcy	dig TXTNiepokazuje każdy ciąg osobno	nslookup -type=TXTNiepokazuje każdy ciąg osobno
Idzie za każdym include	Ten checkerTakcałe drzewo	dig TXTNiejedna nazwa na zapytanie	nslookup -type=TXTNiejedna nazwa na zapytanie
Liczy zapytania do 10	Ten checkerTakbieżąca suma, dla każdego include	dig TXTNieręcznie	nslookup -type=TXTNieręcznie
Liczy puste zapytania	Ten checkerTakz nazwami	dig TXTNie	nslookup -type=TXTNie
Mówi, że dwa rekordy = permerror	Ten checkerTak	dig TXTNiedrukuje oba	nslookup -type=TXTNiedrukuje oba
Testuje IP nadawcy	Ten checkerTakcheck_host i pasujący człon	dig TXTNie	nslookup -type=TXTNie
Pyta twój własny resolver	Ten checkerNieGoogle Public DNS, z naszego serwera	dig TXTTak	nslookup -type=TXTTak

To samo pytanie zadane na trzy sposoby: dig i nslookup pokazują to, co ma twój resolver, checker to, co oblicza odbiorca.

Checker SPF: najczęstsze pytania

Co to jest sprawdzenie rekordu SPF?

Sprawdzenie rekordu SPF odczytuje rekord SPF domeny, czyli rekord TXT zaczynający się od v=spf1, i przechodzi go tak jak serwer pocztowy odbiorcy: idzie za każdym include i redirect, liczy każde zapytanie DNS względem limitu 10, a każdą pustą odpowiedź względem limitu 2. Kończy się tym, co dostają odbiorcy dla nadawcy spoza listy, albo permerror z jego przyczyną.

Jak sprawdzić, czy adres IP może wysyłać pocztę w imieniu mojej domeny?

Wybierz Test IP, wpisz domenę i adres serwera wysyłającego, IPv4 lub IPv6, a opcjonalnie adres MAIL FROM i nazwę HELO. Checker uruchamia check_host dla tego adresu i pokazuje pass, fail, softfail, neutral lub permerror, dokładny człon, który pasował, jego kwalifikator i łańcuch include, który do niego doprowadził.

Co znaczy „SPF too many DNS lookups”?

Znaczy, że sprawdzenie rekordu wymaga więcej niż 10 zapytań DNS, czyli limitu z RFC 7208. Każdy include, a, mx, ptr, exists i redirect kosztuje jedno, także te zagnieżdżone w include. Odbiorcy przerywają na 11. z permerror, więc nadawcy wymienieni po tym miejscu przestają przechodzić SPF. Usuń nieużywane include albo przenieś nadawcę na subdomenę z własnym rekordem.

Co to jest permerror w SPF?

Permerror to wynik SPF oznaczający „tego rekordu nie da się ocenić”. Pochodzi z ponad 10 zapytań DNS, ponad 2 pustych zapytań, dwóch rekordów SPF w jednej nazwie, include nazwy bez rekordu SPF albo błędu składni. To nie jest fail: odbiorcy sami decydują, co z nim zrobić, ale przy DMARC nigdy nie liczy się jako pass.

Co to jest puste zapytanie (void lookup) w SPF?

Puste zapytanie to zapytanie DNS zadane dla członu SPF, które wraca puste: nazwa nie istnieje (NXDOMAIN) albo nie ma rekordu zapytanego typu. RFC 7208 mówi, że odbiorcy powinni dopuścić dwa; trzecie to permerror. Awaria serwera lub przekroczenie czasu nie jest pustym zapytaniem, tylko temperror, który odbiorcy zwykle ponawiają później.

Czy mój rekord SPF powinien kończyć się na ~all czy -all?

Oba są poprawne. -all (fail) to najmocniejsze stwierdzenie i Microsoft dokumentuje je dla Microsoft 365; ~all (softfail) dokumentuje Google dla Google Workspace. Przy podpisywaniu DKIM i DMARC na quarantine lub reject bezpieczniejsze bywa ~all, bo niektórzy odbiorcy odrzucają na -all, zanim DMARC zdąży przyjąć poprawny podpis DKIM.

Czy domena może mieć dwa rekordy SPF?

Nie. Jeśli nazwa ma dwa rekordy TXT zaczynające się od v=spf1, odbiorcy nie mogą wybrać jednego i sprawdzenie kończy się permerror przed jakimkolwiek zapytaniem, dla każdego nadawcy (RFC 7208 §4.5). Zwykle dzieje się tak, gdy rekord nowego dostawcy jest dodany obok starego. Scal je w jeden rekord z jednym v=spf1, każdym include raz i jednym zakończeniem.

Czym jest spłaszczanie SPF i czy warto z niego korzystać?

Spłaszczanie zastępuje include zakresami IP, które wymieniają, więc rekord potrzebuje mniej zapytań DNS. Pomaga dla zakresów, które rzadko się zmieniają, ale spłaszczona kopia robi się nieaktualna, gdy tylko dostawca doda serwery, a poczta z nich przestaje przechodzić SPF. Lepiej usuwać nieużywane include albo dać masowemu nadawcy własną subdomenę; nigdy nie spłaszczaj include Microsoft 365.

Czy subdomena potrzebuje własnego rekordu SPF?

Tak. SPF nie dziedziczy: rekord obejmuje tylko dokładnie tę nazwę, w której jest opublikowany, więc mail.example.com lub news.example.com potrzebuje własnego rekordu, jeśli pojawia się w MAIL FROM lub HELO. Różni się to od DMARC, który wraca do domeny organizacyjnej. Subdomena, która nie wysyła poczty, może opublikować v=spf1 -all.

Dlaczego SPF przechodzi tutaj, a w Gmailu nie?

Zwykle dlatego, że Gmail sprawdził inną domenę lub adres. SPF jest oceniany dla domeny MAIL FROM (Return-Path) i IP łączącego się serwera, którą może być domena zwrotna twojego dostawcy, a nie twoja. Przekazywanie też psuje SPF, bo IP przekazującego nie ma w twoim rekordzie. Sprawdź nagłówek Authentication-Results prawdziwej wiadomości i przetestuj tutaj to IP i tę domenę.

Jaka jest różnica między SPF, DKIM i DMARC?

SPF wymienia serwery uprawnione do wysyłania w imieniu domeny i jest sprawdzany względem nadawcy koperty. DKIM podpisuje każdą wiadomość kluczem opublikowanym w DNS, więc podpis przetrwa przekazanie. DMARC wiąże je z adresem From:, który widzi czytelnik: wiadomość przechodzi DMARC, gdy SPF lub DKIM przechodzi dla domeny zgodnej z From:, a polityka mówi, co zrobić w przeciwnym razie.

Jak długo zmiana rekordu SPF zaczyna działać?

Tak długo, jak resolvery trzymają stary rekord: do jego TTL, który ustawia domena (300 sekund dla google.com i github.com, godzina dla microsoft.com, gdy sprawdzaliśmy). Odbiorcy pytają swój resolver, więc zmiana jest widoczna, gdy wygaśnie każda zapamiętana kopia. Ten checker pokazuje TTL tak, jak podaje go własny serwer nazw domeny; sprawdź ponownie po tym czasie.

Checker Rekordów SPF — Sprawdź SPF Online

Czym jest rekord SPF?

Jak sprawdzić rekord SPF

Jak czytać wynik: drzewo include

Limit 10 zapytań i „too many DNS lookups” (permerror)

Czym są puste zapytania (void lookups)?

Spłaszczanie SPF: kiedy pomaga, a kiedy psuje

~all czy -all (i DMARC)

Najczęstsze błędy w rekordzie SPF i jak je naprawić

Czego wymagają Gmail, Yahoo i Microsoft

Sprawdzanie SPF a dig i nslookup

Checker SPF: najczęstsze pytania

Co to jest sprawdzenie rekordu SPF?

Jak sprawdzić, czy adres IP może wysyłać pocztę w imieniu mojej domeny?

Co znaczy „SPF too many DNS lookups”?

Co to jest permerror w SPF?

Co to jest puste zapytanie (void lookup) w SPF?

Czy mój rekord SPF powinien kończyć się na ~all czy -all?

Czy domena może mieć dwa rekordy SPF?

Czym jest spłaszczanie SPF i czy warto z niego korzystać?

Czy subdomena potrzebuje własnego rekordu SPF?

Dlaczego SPF przechodzi tutaj, a w Gmailu nie?

Jaka jest różnica między SPF, DKIM i DMARC?

Jak długo zmiana rekordu SPF zaczyna działać?

Wyszukiwanie MX

Sprawdzanie DMARC

Sprawdzanie DKIM

Analiza Nagłówków E-mail

Sprawdzanie Czarnej Listy IP

Odwrotne DNS

Wyszukiwanie DNS

Generator rekordu SPF

Czym jest rekord SPF?

Jak sprawdzić rekord SPF

Jak czytać wynik: drzewo include

Limit 10 zapytań i „too many DNS lookups” (permerror)

Czym są puste zapytania (void lookups)?

Spłaszczanie SPF: kiedy pomaga, a kiedy psuje

~all czy -all (i DMARC)

Najczęstsze błędy w rekordzie SPF i jak je naprawić

Czego wymagają Gmail, Yahoo i Microsoft

Sprawdzanie SPF a dig i nslookup

Checker SPF: najczęstsze pytania

Co to jest sprawdzenie rekordu SPF?

Jak sprawdzić, czy adres IP może wysyłać pocztę w imieniu mojej domeny?

Co znaczy „SPF too many DNS lookups”?

Co to jest permerror w SPF?

Co to jest puste zapytanie (void lookup) w SPF?

Czy mój rekord SPF powinien kończyć się na ~all czy -all?

Czy domena może mieć dwa rekordy SPF?

Czym jest spłaszczanie SPF i czy warto z niego korzystać?

Czy subdomena potrzebuje własnego rekordu SPF?

Dlaczego SPF przechodzi tutaj, a w Gmailu nie?

Jaka jest różnica między SPF, DKIM i DMARC?

Jak długo zmiana rekordu SPF zaczyna działać?

Powiązane narzędzia do poczty i DNS

Wyszukiwanie MX

Sprawdzanie DMARC

Sprawdzanie DKIM

Analiza Nagłówków E-mail

Sprawdzanie Czarnej Listy IP

Odwrotne DNS

Wyszukiwanie DNS

Generator rekordu SPF