SPF flatten: jak naprawić limit 10 DNS lookupów

Twoje e-maile lądują w spamie albo w ogóle nie docierają do odbiorcy, a w nagłówkach wiadomości widzisz tajemniczy komunikat permerror? Bardzo prawdopodobne, że Twój rekord SPF przekroczył limit 10 DNS lookupów — jeden z najczęstszych i najbardziej niedocenianych problemów w konfiguracji poczty firmowej. W tym artykule wyjaśnię, dlaczego ten limit istnieje, jak go zdiagnozować i jak zastosować technikę SPF flatten, żeby raz na zawsze rozwiązać problem.

Czym jest limit 10 DNS lookupów w SPF?

Rekord SPF (Sender Policy Framework) informuje serwery pocztowe, które hosty są uprawnione do wysyłania maili w imieniu Twojej domeny. Definiujesz go jako rekord TXT w DNS, np. v=spf1 include:_spf.google.com include:sendgrid.net ~all. Problem w tym, że każde odwołanie wymagające kolejnego zapytania DNS — takie jak include, a, mx, ptr czy exists — kosztuje jeden lookup.

Specyfikacja RFC 7208 (rozdział 4.6.4) narzuca twardy limit: podczas weryfikacji rekordu SPF serwer odbiorcy może wykonać maksymalnie 10 zapytań DNS. Jeśli limit zostanie przekroczony, wynik weryfikacji to permerror — trwały błąd, który wiele serwerów traktuje jak niepowodzenie uwierzytelnienia. Oznacza to wyższy wskaźnik odrzuceń lub trafienie do folderu spam.

Które mechanizmy „kosztują" lookup?

• include: — każde zagnieżdżenie to minimum 1 lookup (plus kolejne, jeśli zagnieżdżony rekord sam zawiera include)
• a: i mx: — odpytują DNS o adresy A/AAAA lub rekordy MX
• ptr: — szczególnie kosztowny, odradzany przez RFC
• exists: — jedno zapytanie na wywołanie
• redirect= — liczy się jako 1 lookup i zastępuje cały rekord

Mechanizmy ip4: i ip6: nie wykonują żadnych zapytań DNS — to czyste listy adresów IP, które są przetwarzane lokalnie.

Dlaczego firmy tak łatwo przekraczają ten limit?

Jeszcze kilka lat temu rekord SPF z 3–4 wpisami include był rzadkością. Dziś typowa firma korzysta jednocześnie z kilku usług: Google Workspace lub Microsoft 365 do poczty, Sendgrid lub Mailgun do mailingu transakcyjnego, HubSpot lub Salesforce do CRM, Zendesk do supportu, a do tego może dochodzić system ERP wysyłający faktury. Każdy z tych dostawców wymaga wpisu include w rekordzie SPF.

Co gorsza, dostawcy tacy jak Salesforce czy Google sami używają zagnieżdżonych include w swoich rekordach SPF — rekord Google'a odpytuje kolejne subdomeny, które odpytują jeszcze inne. W efekcie jeden wpis include:_spf.google.com może pochłonąć nawet 4–5 lookupów. Przy czterech usługach zewnętrznych limit 10 jest niemal pewny do przekroczenia.

Jak zdiagnozować problem SPF permerror?

Zanim przystąpisz do naprawy, musisz dokładnie wiedzieć, ile lookupów wykonuje Twój obecny rekord. Oto sprawdzony proces diagnostyczny:

Krok 1 — sprawdź aktualny rekord SPF

W terminalu wpisz:

dig TXT twojadomena.pl +short

Lub użyj narzędzi online, takich jak MXToolbox SPF Record Checker czy dmarcanalyzer.com. Skopiuj pełną treść rekordu.

Krok 2 — policz lookups rekurencyjnie

Narzędzia do analizy SPF (np. kitterman.com/spf/validate.html) pokażą Ci drzewo zapytań DNS i ich łączną liczbę. Zwróć uwagę na kolumnę „DNS Lookups" — każda wartość powyżej 10 to problem.

Krok 3 — zidentyfikuj „pożeraczy lookupów"

Najczęstsi winowajcy to:

• include:_spf.salesforce.com — potrafi kosztować 3–4 lookups
• include:servers.mcsv.net (Mailchimp) — 2–3 lookups
• include:_spf.google.com — 3–4 lookups
• include:sendgrid.net — 2–3 lookups

SPF flatten — na czym polega spłaszczanie rekordu?

SPF flatten (spłaszczanie SPF) to technika polegająca na zastąpieniu wszystkich mechanizmów include bezpośrednimi adresami IP, które te mechanizmy ostatecznie rozwiązują. Zamiast kazać serwerowi odbiorcy wykonywać łańcuch zapytań DNS, podajesz mu gotową listę adresów ip4: i ip6:. Wynik weryfikacji jest identyczny, ale liczba lookupów spada do minimum — często do zera lub jednego.

Przykład przed i po spłaszczeniu

W wersji „po" wszystkie adresy IP są wpisane bezpośrednio — serwer odbiorcy nie musi wykonywać żadnego dodatkowego zapytania DNS.

Jak wykonać SPF flatten krok po kroku?

Krok 1 — zbierz wszystkie adresy IP

Dla każdego mechanizmu include w swoim rekordzie SPF musisz rekurencyjnie rozwinąć wszystkie zagnieżdżone rekordy aż do uzyskania czystych adresów IP. Możesz to zrobić ręcznie poleceniem dig TXT _spf.google.com +short i powtarzać dla każdego kolejnego include, lub użyć automatycznych narzędzi:

• dmarcanalyzer.com — sekcja „SPF Flattening Tool"
• easydmarc.com — automatyczne spłaszczanie z eksportem
• mxtoolbox.com — zakładka „SPF Survey"

Krok 2 — utwórz nowy rekord SPF

Zbuduj rekord zaczynając od v=spf1, następnie wstaw wszystkie zebrane adresy jako ip4: lub ip6:, a na końcu dodaj politykę ~all (softfail) lub -all (hardfail). Przykład:

v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:149.72.0.0/16 ip6:2a00:1450::/32 ip4:185.73.44.0/24 ~all

Pamiętaj, że rekord TXT w DNS ma limit długości 255 znaków na jeden ciąg — przy dużej liczbie adresów IP może być konieczne rozbicie rekordu na kilka ciągów (w cudzysłowach, jeden po drugim w tej samej wartości TXT).

Krok 3 — zaktualizuj rekord DNS

Wejdź do panelu DNS swojej domeny (Cloudflare, OVH, home.pl, nazwa.pl itp.) i zastąp stary rekord TXT dla @ lub twojadomena.pl nową wartością. Ustaw TTL na 300–600 sekund, żeby móc szybko reagować w razie problemów. Po propagacji (zwykle 5–30 minut) zweryfikuj wynik narzędziem online.

Krok 4 — zaplanuj utrzymanie

Tu kryje się największa pułapka SPF flatten: adresy IP dostawców usług zmieniają się. Salesforce, Google czy Sendgrid od czasu do czasu dodają nowe zakresy IP. Jeśli nie zaktualizujesz swojego spłaszczonego rekordu, nowe serwery tych dostawców nie będą autoryzowane — maile zaczną trafiać do spamu lub być odrzucane.

Dlatego musisz:

1. Subskrybować powiadomienia o zmianach infrastruktury u swoich dostawców (większość publikuje changelogi).
2. Ustawić cykliczny monitoring rekordu SPF (np. co 2–4 tygodnie) — narzędzia jak EasyDMARC potrafią wysyłać alerty o zmianach.
3. Rozważyć usługę dynamicznego SPF flatten (np. AutoSPF, dmarcian), która automatycznie aktualizuje rekord przy zmianach IP dostawców.

Alternatywy i dobre praktyki

Czy zawsze warto spłaszczać?

SPF flatten to skuteczne rozwiązanie, ale nie jedyne. Przed wdrożeniem rozważ prostsze opcje:

• Usunięcie zbędnych wpisów — czy naprawdę wszystkie usługi na liście nadal wysyłają maile z Twojej domeny? Stare systemy CRM, nieużywane platformy marketingowe — warto zrobić audyt.
• Subdomeny dla różnych strumieni poczty — wysyłaj mailing transakcyjny z send.twojadomena.pl, a CRM z crm.twojadomena.pl. Każda subdomena ma własny rekord SPF z własnym limitem 10 lookupów.
• Zastąpienie include przez redirect — jeśli cały Twój mailing idzie przez jednego dostawcę, mechanizm redirect= zastępuje cały rekord SPF i kosztuje tylko 1 lookup.

SPF to nie wszystko — DKIM i DMARC

Samo naprawienie rekordu SPF to ważny krok, ale kompletna ochrona domeny wymaga też poprawnie skonfigurowanego DKIM (podpis kryptograficzny wiadomości) i DMARC (polityka raportowania i reakcji na błędy uwierzytelnienia). Od lutego 2024 roku Google i Yahoo wymagają SPF lub DKIM oraz DMARC od nadawców wysyłających powyżej 5000 wiadomości dziennie — bez tego maile są odrzucane na wejściu. Jeśli zarządzasz wysyłką przez własne skrzynki SMTP, narzędzie takie jak MailerPRO pozwala monitorować konfigurację uwierzytelnienia bezpośrednio z poziomu panelu, bez konieczności ręcznego analizowania nagłówków każdej wiadomości.

Najczęstsze błędy przy SPF flatten

• Pominięcie zakresów IPv6 — wiele dostawców używa IPv6 do wysyłki; jeśli pominiesz ip6:, część maili nie przejdzie weryfikacji.
• Zbyt restrykcyjna polityka -all przed testami — najpierw przetestuj z ~all (softfail), a dopiero po potwierdzeniu poprawności przejdź na -all (hardfail).
• Brak monitoringu po wdrożeniu — spłaszczony rekord staje się „statyczny" i szybko może się zdezaktualizować.
• Przekroczenie limitu 512 bajtów odpowiedzi UDP — bardzo długie rekordy SPF mogą powodować problemy z transportem DNS; używaj notacji CIDR zamiast pojedynczych adresów IP tam, gdzie to możliwe.
• Dwa rekordy SPF dla jednej domeny — dozwolony jest tylko jeden rekord TXT zaczynający się od v=spf1; dwa rekordy SPF skutkują błędem permerror niezależnie od liczby lookupów.

Przekroczenie limitu 10 DNS lookupów to problem, który można rozwiązać w ciągu jednego popołudnia — pod warunkiem że podejdziesz do niego metodycznie. Zbierz wszystkie adresy IP, zbuduj spłaszczony rekord, wdróż go z TTL 300 i ustaw monitoring na zmiany. Jeśli Twoja infrastruktura mailingowa jest rozbudowana, rozważ automatyczne narzędzie do dynamicznego SPF flatten — oszczędzi Ci regularnych interwencji ręcznych. Zdrowy rekord SPF to fundament dostarczalności: bez niego nawet najlepiej napisany newsletter trafi do folderu spam lub nie dotrze wcale.