SPF PermError „too many DNS lookups”: jak obejść limit 10 zapytań

Błąd „SPF PermError: too many DNS lookups” (za dużo zapytań DNS) oznacza, że sprawdzenie rekordu SPF Twojej domeny wymaga więcej niż 10 zapytań DNS, a tyle wynosi twardy limit z RFC 7208. Serwer odbiorcy przerywa wtedy ocenę i zamiast wyniku „pass” zwraca błąd trwały, więc każda wiadomość, której Return-Path używa tej domeny, traci SPF. Naprawa polega na policzeniu zapytań, także tych ukrytych głębiej w każdym include:, usunięciu martwych wpisów, zastąpieniu własnych serwerów wpisami ip4:/ip6: i przeniesieniu zewnętrznych nadawców na osobne subdomeny.

Co wlicza się do limitu 10 zapytań DNS w SPF?

Liczy się sześć elementów: mechanizmy include, a, mx, ptr i exists oraz modyfikator redirect. Gdy ocena rekordu wymaga więcej niż 10 z nich, wynik musi brzmieć permerror. Mechanizmy ip4, ip6 i all nic nie kosztują (RFC 7208, sekcja 4.6.4).

Limit dotyczy całej oceny, a nie jednej linijki widocznej w panelu DNS. Microsoft pisze to wprost: include wskazujący rekord z trzema kolejnymi include’ami kosztuje cztery zapytania, więc mniej niż 10 wpisów include: nie gwarantuje mniej niż 10 zapytań DNS (Microsoft Learn: konfiguracja SPF). Strona pomocy Google upraszcza to do „maksymalnie 10 tagów include”, co jest prawdą tylko wtedy, gdy żaden z nich nie zagnieżdża następnych (Google Workspace: konfiguracja SPF).

Stan na listopad 2026, według RFC 7208.

Drugi limit: dwa puste zapytania

RFC 7208 zaleca też ograniczenie tzw. void lookups, czyli zapytań, które nie zwracają rekordu albo trafiają w nieistniejącą nazwę, do dwóch. Przekroczenie tego limitu również daje permerror. W praktyce dotyka to domen, które trzymają include’y usług dawno wypowiedzianych: dostawca usuwa nazwę z DNS, a Twój rekord wskazuje w próżnię. Include, którego cel nie ma rekordu SPF, sam w sobie jest już permerror (to samo podaje Microsoft).

Jeden rekord na nazwę

Jedna nazwa może mieć tylko jeden rekord TXT zaczynający się od v=spf1. Dwa rekordy, zwykle efekt dodania nowego dostawcy jako drugiego wpisu zamiast scalenia, też kończą się permerror. Długi rekord możesz podzielić na kilka ciągów w cudzysłowach w jednym rekordzie TXT; odbiorcy sklejają je bez dodawania spacji (RFC 7208, 3.3). W panelach home.pl, nazwa.pl czy OVHcloud wygląda to różnie, ale zasada jest ta sama.

Jak policzyć zapytania DNS w rekordzie SPF?

Pobierz swój rekord TXT poleceniem dig, policz w nim sześć „kosztownych” elementów, potem odpytaj każdy cel include: i redirect= i powtarzaj, aż dojdziesz do rekordów zawierających wyłącznie ip4/ip6. Suma ze wszystkich poziomów to liczba, którą widzi odbiorca.

# 1. Your own record (exactly one line must start with v=spf1)
dig +short TXT example.com

# 2. Every include: in it, then every include: inside those
dig +short TXT mailgun.org
dig +short TXT _spf.mailgun.org

Ręcznie robi się to męczące już na drugim poziomie, dlatego poniżej krótki skrypt w Bashu, który przechodzi całe drzewo i je wypisuje. Korzysta tylko z dig, sed i tr, działa na Linuksie i macOS:

#!/usr/bin/env bash
# spf-count.sh: count the SPF terms that cost a DNS lookup, following include: and redirect=
# Usage: ./spf-count.sh example.com
spf() { dig +short TXT "$1" | sed 's/" "//g; s/"//g' | grep -i '^v=spf1'; }

count() {
  local domain=$1 depth=$2 n=0 term lterm rec
  rec=$(spf "$domain")
  printf '%*s%s: %s\n' $((depth * 2)) '' "$domain" "${rec:-NO SPF RECORD}" >&2
  for term in $rec; do
    term=${term#[+~?-]}
    lterm=$(printf '%s' "$term" | tr 'A-Z' 'a-z')
    case $lterm in
      include:*)  n=$((n + 1 + $(count "${term#*:}" $((depth + 1))))) ;;
      redirect=*) n=$((n + 1 + $(count "${term#*=}" $((depth + 1))))) ;;
      a|a:*|a/*|mx|mx:*|mx/*|ptr|ptr:*|exists:*) n=$((n + 1)) ;;
    esac
  done
  echo "$n"
}

total=$(count "$1" 0)
echo "Lookups: $total of 10"

chmod +x spf-count.sh
./spf-count.sh mailgun.org

Wynik (skrócony):

mailgun.org: v=spf1 include:_spf.mailgun.org include:_spf.eu.mailgun.org -all
  _spf.mailgun.org: v=spf1 include:_spf1.mailgun.org include:_spf2.mailgun.org ~all
    _spf1.mailgun.org: v=spf1 ip4:159.135.224.0/20 ip4:69.72.32.0/20 ...
    _spf2.mailgun.org: v=spf1 ip4:161.38.192.0/20 ip4:143.55.224.0/21 ...
  _spf.eu.mailgun.org: v=spf1 ip4:141.193.32.0/23 ip4:159.135.140.80/29 ...
Lookups: 4 of 10

Suma to koszt poniżej danej nazwy; sam include dokłada jeszcze jedno zapytanie. Zatem include:mailgun.org kosztuje w Twoim rekordzie 5 zapytań. Skrypt jest celowo prosty: nie rozwija makr (exists:%{i}… liczy jako jedno, i słusznie) i nie liczy zapytań o adresy A poszczególnych hostów za mx.

Ile kosztuje include poszczególnych dostawców?

Uruchomiliśmy skrypt dla include’ów, które dostawcy podają swoim klientom. Różnice są duże, a jeden helpdesk potrafi zająć ponad połowę limitu.

Stan na listopad 2026: zmierzone powyższym skryptem 14 listopada 2026. Dostawcy zmieniają rekordy bez zapowiedzi, więc zanim oprzesz się na liczbie, uruchom skrypt ponownie.

Jak naprawić błąd „too many DNS lookups”?

Zacznij od najtańszych zmian i idź w stronę najbardziej inwazyjnych: usuń to, co zbędne, zastąp zapytania o własną infrastrukturę adresami, a nadawców masowych przenieś na subdomeny. Większość domen schodzi poniżej 10, zanim spłaszczanie w ogóle jest potrzebne.

Weźmy rekord bardzo podobny do tych, z którymi kończy wiele małych firm po kilku latach dokładania narzędzi:

; Before: 17 lookups, every message gets spf=permerror
example.com.  3600  IN  TXT  "v=spf1 a mx include:_spf.google.com include:mailgun.org include:email.freshdesk.com include:_spf.salesforce.com ~all"

To 1 (a) + 1 (mx) + 1 (Google) + 5 (Mailgun) + 7 (Freshdesk) + 2 (Salesforce) = 17 zapytań. Odbiorcy, którzy oceniają cały rekord, zwracają permerror dla każdej wiadomości z example.com, także dla zwykłej poczty pracowników.

1. Sprawdź, którzy nadawcy naprawdę używają Twojej domeny w Return-Path

   SPF sprawdza domenę z koperty (MAIL FROM, widoczną w doręczonej wiadomości jako Return-Path), a nie adres From. Wyślij z każdego narzędzia test na konto Gmail i otwórz „Pokaż oryginał”. Jeśli Return-Path to bounces+123@vendor-mail.com, Twój rekord nigdy nie jest sprawdzany dla tego narzędzia i jego include to balast. Wiele helpdesków, CRM-ów i narzędzi newsletterowych działa właśnie tak i przechodzi DMARC dzięki DKIM podpisanemu Twoją domeną.

2. Usuń include’y narzędzi, z których już nie korzystasz

   Wypowiedziane usługi to najczęstsza przyczyna zarówno przekroczenia limitu, jak i pustych zapytań. Jeśli nikt nie wie, po co jest dany include, sprawdź go przez dig; jeśli należy do usługi, z której zrezygnowałeś, usuń go.

3. Wyrzuć ptr, przemyśl a i mx

   ptr jest wolny, a RFC 7208 każe go nie publikować. a ma sens tylko wtedy, gdy serwer WWW sam wysyła pocztę; mx tylko wtedy, gdy serwery poczty przychodzącej wysyłają też wychodzącą. Przy Google Workspace czy Microsoft 365 hosty MX są już objęte include’em dostawcy, więc mx to zmarnowane zapytanie.

4. Własne serwery zapisz jako ip4:/ip6:

   Dla serwera, który kontrolujesz, na przykład serwera aplikacji, NetSendo MTA czy relaya w biurze, wpisz adres wprost: ip4:203.0.113.10. Nie kosztuje to nic i zmienia się tylko wtedy, gdy zmieniasz serwer.

5. Przenieś nadawców masowych i marketingowych na subdomeny

   Skonfiguruj Mailgun na mg.example.com, Amazon SES z własną domeną MAIL FROM, np. bounce.example.com, i tak dalej. Każda subdomena ma własny rekord SPF i własny limit 10. W kolejnej sekcji wyjaśniamy, dlaczego DMARC nadal przechodzi.

6. Resztę spłaszcz, tylko jeśli musisz

   Jeśli jeden dostawca, który musi zostać na domenie głównej, nadal przepycha Cię ponad limit, zastąp jego include opublikowanymi zakresami adresów i wpisz sobie do kalendarza termin przeglądu.

Po krokach 1–5 ta sama domena wygląda tak:

; After: each name has its own budget of 10
example.com.     3600  IN  TXT  "v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all"
mg.example.com.  3600  IN  TXT  "v=spf1 include:mailgun.org ~all"
bounce.example.com.  3600  IN  TXT  "v=spf1 include:amazonses.com ~all"
bounce.example.com.  3600  IN  MX   10 feedback-smtp.eu-west-1.amazonses.com.

Rekord domeny głównej kosztuje teraz 3 zapytania, mg.example.com 5, a bounce.example.com 1, każdy z dużym zapasem we własnym limicie. Freshdesk zniknął z domeny głównej, bo w tym przykładzie jego Return-Path wskazywał domenę dostawcy. Rekord MX na subdomenie SES jest wymagany przez Amazon SES dla własnej domeny MAIL FROM, a tamtejszy rekord SPF to dokładnie ten, który podaje SES (Amazon SES: własna domena MAIL FROM). W hoście MX użyj regionu swojego konta SES, np. eu-central-1.

⚠️ Uwaga: Nie usuwaj include’a, dopóki na prawdziwej wiadomości nie potwierdzisz, dokąd wskazuje Return-Path danego narzędzia. Usunięcie nadawcy, którego koperta używa Twojej domeny głównej, zamienia jego wynik SPF w fail; DMARC przejdzie wtedy tylko, jeśli narzędzie podpisuje też DKIM zgodnym z Twoją domeną.

Czy spłaszczanie SPF to dobry pomysł?

Spłaszczanie (SPF flattening) zastępuje include zakresami IP, na które w tej chwili się rozwija, więc dany nadawca nie kosztuje żadnego zapytania. To działa, ale przejmujesz zadanie, które wykonywał za Ciebie dostawca: zauważenie, że jego adresy się zmieniły.

; Flattened by hand: 0 lookups for this sender, but the list goes stale when the vendor adds a range
example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ip4:198.51.100.0/24 ip4:203.0.113.0/25 ~all"

Wytyczne Microsoftu to dobra reguła: spłaszczaj tylko dostawców ze stabilnymi, opisanymi zakresami, nigdy samego Microsoft 365, którego adresy wysyłkowe często się zmieniają. Jeśli spłaszczasz, zapisz, co zastąpiłeś, śledź dokumentację dostawcy, przeglądaj wpisy co najmniej raz na kwartał i testuj po każdej zmianie (Microsoft Learn).

Spłaszczanie ręczne a automatyczne

Ręczne spłaszczanie to przykład powyżej: kopiujesz adresy raz. Jest darmowe i przejrzyste, ale psuje się po cichu w dniu, w którym dostawca doda nowy zakres, bo poczta z nowego zakresu nie przechodzi SPF, a w panelu DNS wszystko wygląda dobrze. Usługi automatycznego spłaszczania co jakiś czas ponownie rozwijają include’y i publikują wynik, zwykle przez include lub CNAME do własnej strefy. Lista jest aktualna, ale w ścieżce uwierzytelniania poczty pojawia się płatna zależność; gdy usługa padnie, pada też Twój SPF.

Dlaczego subdomena do wysyłki rozwiązuje problem?

Ponieważ SPF jest oceniany dla dokładnie tej domeny, która stoi w kopercie, a każda nazwa ma własny rekord i własny limit 10 zapytań. Microsoft pisze wprost, że każda subdomena ma własny budżet 10 zapytań, i zaleca subdomeny dla usług pocztowych, których nie kontrolujesz (Microsoft Learn).

To DMARC sprawia, że działa to także dla widocznego adresu From. DMARC korzysta wyłącznie z wyniku SPF dla tożsamości MAIL FROM i wymaga, by była ona zgodna (aligned) z domeną From (RFC 9989, 4.4.2). Domyślnie zgodność jest luźna (aspf=r), więc bounce.example.com i news@example.com mają wspólną domenę organizacyjną example.com i są uznawane za zgodne. Możesz dalej wysyłać z news@example.com, a SPF będzie sprawdzany na subdomenie.

Zgadza się to też z tym, czego Gmail wymaga od każdego nadawcy: SPF i DKIM skonfigurowanych dla Twojej domeny, zgodnych na poziomie domeny organizacyjnej (Google: wytyczne dla nadawców). Osobna subdomena dla marketingu ma jeszcze jedną zaletę: odbicia i skargi z kampanii trafiają na nazwę, którą możesz obserwować oddzielnie. Pełne omówienie SPF, DKIM, DMARC i rozgrzewania własnych serwerów znajdziesz w naszym poradniku o dostarczalności dla wysyłki z własnego serwera.

💡 Wskazówka: Jeśli Twój rekord DMARC ustawia aspf=s (tryb ścisły), koperta na subdomenie nie jest zgodna i SPF przestaje się liczyć dla DMARC. Zanim przeniesiesz nadawców, sprawdź rekord poleceniem dig +short TXT _dmarc.example.com.

~all czy -all na końcu rekordu?

Gdy masz już DMARC, działa jedno i drugie, bo DMARC traktuje zarówno ~all (softfail), jak i -all (fail) jako porażkę SPF. Google zaleca ~all (Google Workspace); Microsoft zaleca -all dla domen Microsoft 365, które używają też DKIM i DMARC (Microsoft Learn).

Różnica dotyczy tego, co dzieje się, zanim DMARC w ogóle ruszy. RFC 9989 ostrzega, że niektórzy odbiorcy sprawdzają SPF wcześnie w sesji SMTP, więc -all może doprowadzić do odrzucenia wiadomości, która przeszłaby DMARC dzięki zgodnemu podpisowi DKIM, a takie odrzucenia nigdy nie trafią do Twoich raportów zbiorczych DMARC (RFC 9989, 7.1). Ma to znaczenie przy przekierowaniach i listach dyskusyjnych. Praktyczna reguła:

• Dopóki porządkujesz include’y i przenosisz nadawców, używaj ~all.
• Dla subdomeny używanej przez jednego nadawcę, np. mg.example.com, -all jest mało ryzykowne: nic innego nie powinno z niej wysyłać.
• Dla domeny głównej z pocztą pracowników ~all plus DMARC z p=quarantine lub p=reject daje egzekwowanie bez wczesnych odrzuceń na SPF.

Żaden wybór nie naprawi permerror: przy zbyt wielu zapytaniach all na końcu nigdy nie zostaje osiągnięte.

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

Sprawdź opublikowany rekord spoza własnej sieci, policz zapytania jeszcze raz, a potem wyślij prawdziwą wiadomość i przeczytaj nagłówek Authentication-Results. Po upływie TTL starego rekordu oczekuj spf=pass dla domeny z koperty.

# The record the world sees (ask a public resolver, not your cache)
dig +short TXT example.com @1.1.1.1

# Exactly one SPF record per name
dig +short TXT example.com @1.1.1.1 | grep -c 'v=spf1'

# The count after the change
./spf-count.sh example.com 2>/dev/null

Następnie wyślij wiadomość z każdego narzędzia na skrzynkę w Gmailu albo Outlook.com i obejrzyj nagłówki. Zepsuty rekord wygląda tak, a wynik DMARC ratuje tu jeszcze DKIM:

Authentication-Results: mx.receiver.example;
       spf=permerror smtp.mailfrom=news@example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

Po naprawie chcesz zobaczyć spf=pass i smtp.mailfrom w zaplanowanej domenie. Jeśli dostajesz dmarc=fail przy porażce i SPF, i DKIM, zajrzyj do naszego poradnika o błędzie Gmaila 550-5.7.26 (unauthenticated).

Przez dwa tygodnie po zmianie obserwuj raporty zbiorcze DMARC (rua): źródło, które nagle pokazuje SPF fail, to zwykle nadawca, o którym nie wiedziałeś, a który wysyła z domeny głównej.

Zapytania SPF przy wysyłce z NetSendo

NetSendo nie publikuje własnego include’a SPF, więc nigdy nie dokłada do Twojego rekordu zagnieżdżonego łańcucha. To, czego potrzebuje Twój SPF, zależy od sposobu wysyłki skrzynki:

• NetSendo MTA (wbudowany w każdą instalację od wersji 2.11.0): rekord domeny nadawcy musi zawierać publiczny adres serwera albo dedykowany adres IP skrzynki jako ip4:/ip6:. Nie kosztuje to żadnego zapytania. Panel pokazuje dokładny wpis do dodania.
• Relaye SMTP: NetSendo rozpoznaje Amazon SES, SendGrid, Google Workspace, Microsoft 365 i Mailgun po hoście SMTP. Dla Amazon SES i SendGrid nie dodaje include’a, bo te relaye wysyłają z własną domeną koperty (albo z własną domeną MAIL FROM, którą u nich skonfigurujesz).
• Return-Path: gdy skrzynka ma włączoną obsługę odbić, NetSendo ustawia Return-Path na jej adres do odbić, więc adres odbić na subdomenie przenosi tam sprawdzanie SPF. Konfigurację opisuje dokumentacja konfiguracji.

W planie GOLD moduł Deliverability sprawdza SPF, DKIM i DMARC każdej domeny, a jego generator SPF zachowuje istniejący rekord i dodaje tylko include’y potrzebne Twoim skrzynkom NetSendo. Pokazuje liczbę zapytań i oznacza rekordy powyżej 8. Ta liczba obejmuje elementy samego rekordu i nie rozwija zagnieżdżonych include’ów, więc przy rekordzie pełnym zewnętrznych include’ów uruchom też skrypt z tego artykułu. Na start skorzystaj z szybkiego startu.

Najczęściej zadawane pytania

Źródła

• RFC 7208: Sender Policy Framework (SPF)
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• Microsoft Learn: Set up SPF to identify valid email sources for your Microsoft 365 domain
• Google Workspace Admin Help: Set up SPF
• Google: Email sender guidelines
• Amazon SES: Using a custom MAIL FROM domain