Jak spłaszczyć rekord SPF

Spłaszczanie rekordu SPF oznacza zastąpienie mechanizmów wywołujących odpytania DNS — include:, a, mx, exists, ptr oraz redirect — jawnymi zakresami ip4: i ip6:, do których się rozwiązują. Rezultatem jest rekord, który autoryzuje dokładnie tych samych nadawców, ale zmusza serwery odbierające do przejścia znacznie mniejszej (najlepiej zerowej) liczby zapytań DNS, utrzymując Pana/Panią bezpiecznie poniżej limitu 10 odpytań z RFC 7208. Ten przewodnik przeprowadza przez proces krok po kroku, pokazuje, jak wygląda spłaszczony rekord, i wyjaśnia, jak utrzymać go w aktualności, gdy już będzie działać.

Ta strona jest częścią naszego szerszego przewodnika po spłaszczaniu SPF. Jeśli chce Pan/Pani całkowicie pominąć pracę ręczną, SPF Checker rozwija każdy include i zlicza Pana/Pani odpytania w kilka sekund.

Dlaczego w ogóle miałby(-łaby) Pan/Pani spłaszczać rekord SPF

Uwierzytelnianie SPF jest ograniczone do 10 odpytań DNS na ewaluację zgodnie z RFC 7208. Każdy człon include:, a, mx, exists oraz redirect liczy się względem tego budżetu, a każdy z nich może wywołać dalsze rekurencyjne odpytania wewnątrz domeny, na którą wskazuje. Dodając platformę marketingową, CRM, helpdesk i usługę fakturowania, pojedynczy rekord v=spf1 może po cichu rozrosnąć się do 15–40 odpytań.

Gdy przekracza Pan/Pani limit, odbiorcy zwracają PermError. PermError nie powoduje niepowodzenia tylko jednej wiadomości — unieważnia cały rekord, więc prawidłowa poczta ze wszystkich autoryzowanych źródeł może zacząć zawodzić w SPF. Ponieważ nic nie odbija się głośno, zespoły często tego nie zauważają, dopóki klient nie zgłosi brakującej faktury lub wiadomości z resetem hasła.

Spłaszczanie rozwiązuje to, rozwiązując te pośrednie mechanizmy z wyprzedzeniem i publikując surowe adresy IP. Odbiorca ewaluujący w pełni spłaszczony rekord wykonuje proste dopasowanie IP bez rekurencyjnego przechodzenia DNS, co oznacza również szybszą walidację i brak narażenia na chwilową awarię DNS strony trzeciej.

Jak wygląda spłaszczony rekord SPF

Oto typowy niespłaszczony rekord, który opiera się na trzech wpisach include:

v=spf1 include:_spf.google.com include:vendor.com include:vendor2.net -all

Każdy include to co najmniej jedno odpytanie, a sam include Google zagnieżdża ich kilka więcej. Po spłaszczeniu ta sama autoryzacja staje się bezpośrednią listą adresów IP:

v=spf1 ip4:203.0.113.5 ip4:192.168.1.1 ip4:185.23.45.67 -all

W chwili ewaluacji nie zachodzą żadne odpytania, ponieważ każdy autoryzowany adres jest już rozpisany. Kwalifikator -all jest zachowany, aby polityka pozostała restrykcyjna.

Jak spłaszczyć rekord SPF, krok po kroku

Krok 1: Znajdź i przeprowadź audyt bieżącego rekordu

Pobierz istniejący rekord SPF za pomocą zapytania dig TXT yourdomain.com (lub panelu Pana/Pani dostawcy DNS) i potwierdź, że ma Pan/Pani dokładnie jeden rekord TXT v=spf1. Wiele rekordów SPF pod tą samą nazwą samo w sobie stanowi PermError. Zwróć uwagę, które mechanizmy powodują odpytania (include, a, mx, exists, redirect, ptr) w odróżnieniu od bezkosztowych wpisów ip4/ip6, które można zachować bez zmian.

Krok 2: Zlicz swoje odpytania

Zanim cokolwiek Pan/Pani zmieni, zmierz, jak bardzo przekracza budżet. Przepuść domenę przez SPF Checker, który rekurencyjnie rozwija każdy include i podaje dokładną liczbę odpytań. Jeśli jest Pan/Pani na poziomie 8 lub więcej albo już widzi PermError, spłaszczanie (lub delegowanie) jest uzasadnione. Jeśli ma Pan/Pani 3 lub mniej stabilnych wpisów include, spłaszczanie może w ogóle nie być potrzebne.

Krok 3: Rekurencyjnie rozwiąż każdy mechanizm do adresów IP

To sedno spłaszczania. Dla każdego członu wywołującego odpytanie rozwiąż go do jawnych adresów:

Mechanizm	Jak go rozwiązać	Rezultat
include:	Pobierz rekord SPF celu i rozwiń jego mechanizmy rekurencyjnie	ip4:/ip6: dla każdego autoryzowanego przez niego IP
a	Rozwiąż rekordy A/AAAA domeny	Jeden ip4:/ip6: na adres
mx	Rozwiąż rekordy MX, a następnie A/AAAA każdego hosta pocztowego	ip4:/ip6: dla IP każdego hosta MX
ptr	Nie spłaszczaj — jest przestarzały, wolny i niepewny	Usuń go
exists:	Zwykle nie da się spłaszczyć (zależy od makr działających w czasie rzeczywistym)	Zachowaj bez zmian lub odizoluj do subdomeny
ip4/ip6	Już statyczne	Zachowaj bez zmian

Przechodź graf w głąb (depth-first) i śledź, które domeny już odwiedziłeś, aby móc wykryć cykliczne wpisy include — jeśli include wskazuje z powrotem na domenę już znajdującą się na Pana/Pani stosie rozwiązywania, zatrzymaj się i zachowaj go jako include, zamiast zapętlać się w nieskończoność.

Krok 4: Usuń duplikaty i zagreguj bloki CIDR

Rozwijanie rekurencyjne powoduje nakładanie się. Dwaj dostawcy mogą współdzielić adres IP, albo może Pan/Pani zebrać kilka sąsiadujących bloków /25, które czysto łączą się w /24. Usuń duplikaty każdego adresu, a następnie zagreguj sąsiadujące zakresy w supernetce tylko wtedy, gdy suma pozostaje w całości wewnątrz autoryzowanej przestrzeni jednego dostawcy. Nadmierne agregowanie w poprzek niepowiązanych dostawców autoryzuje adresy IP, których Pan/Pani nie kontroluje — to regres bezpieczeństwa, a nie optymalizacja.

Krok 5: Pilnuj rozmiaru rekordu

Ciągi DNS TXT są ograniczone do 255 znaków na cudzysłowowy segment; dłuższe rekordy muszą zostać podzielone na kilka połączonych ciągów w obrębie tego samego rekordu. Jako praktyczną zasadę należy utrzymywać całkowitą odpowiedź poniżej mniej więcej 450–900 bajtów, aby uniknąć fragmentacji UDP i problemów z urządzeniami pośredniczącymi (middlebox). Jeśli spłaszczona lista jest zbyt duża, podziel adresy IP na etykiety pomocnicze (np. spf-a.example.com, spf-b.example.com), z których każda zawiera wyłącznie wpisy ip4/ip6, i dołącz je z głównego rekordu — każda etykieta pomocnicza kosztuje jedno odpytanie, więc utrzymaj sumę ≤ 10.

Krok 6: Ponownie dołącz kwalifikator all i zweryfikuj

Dopisz swój oryginalny mechanizm końcowy — dla nadawców produkcyjnych zalecane jest -all dla ścisłego egzekwowania. Następnie ponownie przepuść rekord przez walidator SPF, aby potwierdzić, że składnia jest czysta, że wciąż jest tylko jeden rekord, a liczba odpytań jest tam, gdzie Pan/Pani oczekuje. Jeśli migruje Pan/Pani ostrożnie, można na krótko opublikować z ~all, a następnie przełączyć na -all, gdy monitorowanie wykaże stabilne wskaźniki przechodzenia.

Krok 7: Opublikuj z niskim TTL, a potem go podnieś

Przed publikacją obniż TTL rekordu do 60–300 sekund, aby dowolny błąd można było szybko naprawić. Opublikuj nowy spłaszczony rekord, zweryfikuj, że rozwiązuje się poprawnie z wielu publicznych resolverów (Google, Cloudflare, Quad9), i obserwuj swoje zbiorcze raporty DMARC pod kątem spadku wskaźników przechodzenia SPF. Gdy wszystko będzie stabilne, podnieś TTL z powrotem do 1–4 godzin.

Haczyk: spłaszczone rekordy się dezaktualizują

Oto problem, który podkłada nogę większości osób spłaszczających ręcznie. W chwili spłaszczenia Pana/Pani rekord staje się migawką. Gdy Google, Mailchimp, Amazon SES lub dowolny inny dostawca zrotuje swoje adresy IP nadawcze — a duzi dostawcy ESP robią to nieustannie — Pana/Pani zakodowana na stałe lista przestaje odpowiadać rzeczywistości. Poczta z nowych adresów IP po cichu zawodzi w SPF, i wraca Pan/Pani do utraconych faktur i nieudanych resetów haseł, tyle że teraz przyczyna jest niewidoczna, bo rekord wygląda dobrze.

Nadawcy oparci na CDN i marketingowi są najgorszymi winowajcami: wewnętrzne dane AutoSPF z ponad 1200 domen pokazują, że nadawcy oparci na CDN zmieniają 8–15% swojego zestawu IP miesięcznie, w porównaniu z poniżej 0,5% w przypadku wewnętrznych serwerów pocztowych. Spłaszczanie dostawcy o dużej zmienności na ślepo to proszenie się o kłopoty.

Praktyczne wnioski:

• Spłaszczaj stabilne źródła (przekaźniki on-prem, statyczne adresy IP w chmurze) agresywnie.
• Pozostaw zmiennych dostawców ESP jako wpisy include lub odizoluj je za delegowaną subdomeną, taką jak mail-out.example.com, którą korzeń dołącza jednym odpytaniem.
• Nigdy nie traktuj spłaszczania jako czynności jednorazowej — wymaga ono ciągłego ponownego rozwiązywania.

Zautomatyzuj ponowne spłaszczanie za pomocą AutoSPF

Wykonywanie kroków 1–7 ręcznie za każdym razem, gdy dostawca zmieni adresy IP, jest nierealne. Właśnie do tego stworzono zautomatyzowaną usługę spłaszczania SPF od AutoSPF. Uruchamia ona nieustannie powyższy deterministyczny algorytm spłaszczania: skanuje Pana/Pani wpisy include co 15 minut, a gdy adresy IP dostawcy wyższego poziomu się zmienią, automatycznie aktualizuje opublikowany rekord poprzez API Pana/Pani dostawcy DNS — z atomowymi zamianami, stopniowanymi TTL i wycofywaniem jednym kliknięciem, jeśli sprawdzenie kanarkowe zawiedzie.

Co kluczowe, AutoSPF rozwiązuje do dokładnie tych samych adresów IP, do których rozwiązują się Pana/Pani wpisy include — nigdy nie poszerza autoryzacji zbyt szerokimi scaleniami CIDR, więc nie autoryzuje Pan/Pani przypadkowo nadawców, których nie zamierzał(-a). Utrzymuje Pan/Pani mały, stabilny rekord w korzeniu; AutoSPF utrzymuje go poprawnym w tle.

Aby zdecydować, które ze źródeł spłaszczyć, a które delegować, zobacz nasz przewodnik po najlepszych narzędziach do spłaszczania SPF. Jeśli woli Pan/Pani całkowicie uniknąć zakodowywania adresów IP na stałe, porównaj podejścia w spłaszczanie SPF a makra. A zanim Pan/Pani spłaszczy, warto potwierdzić, że zmiana nie zaburzy innych rekordów uwierzytelniania — zobacz czy spłaszczanie SPF wpływa na DKIM i DMARC.

Często zadawane pytania

Czy spłaszczenie rekordu SPF psuje DKIM lub DMARC?

Nie, gdy zostanie wykonane poprawnie. Spłaszczanie zmienia jedynie, które adresy IP autoryzuje SPF — nie dotyka podpisów DKIM ani wyrównania DMARC. Ryzyko jest pośrednie: jeśli zdezaktualizowany spłaszczony rekord zacznie zawodzić w SPF dla prawidłowej poczty, może to obniżyć wskaźniki przechodzenia DMARC. Utrzymuj rekord ponownie rozwiązywany, a oba pozostaną zdrowe.

Ile odpytań DNS zużywa spłaszczony rekord SPF?

W pełni spłaszczony rekord zużywa zero odpytań DNS w chwili ewaluacji, ponieważ każdy autoryzowany adres IP jest wymieniony jawnie jako ip4:/ip6:. Jeśli zachowa Pan/Pani kilka zmiennych wpisów include lub podzieli adresy IP na etykiety pomocnicze, każdy z nich dodaje jedno odpytanie — po prostu utrzymaj sumę na poziomie lub poniżej limitu 10 z RFC 7208.

Czy mogę spłaszczyć mechanizmy ptr i exists?

Zasadniczo nie. ptr jest przestarzały, wolny i powinien być po prostu usunięty. exists: zwykle opiera się na makrach działających w czasie rzeczywistym (ewaluujących MAIL FROM lub HELO w chwili sprawdzenia), więc nie da się go zredukować do statycznej listy adresów IP. Zachowaj exists bez zmian lub odizoluj go do delegowanej subdomeny, aby ograniczyć jego wpływ na liczbę odpytań.

Jak często spłaszczony rekord SPF wymaga aktualizacji?

Tak często, jak Pana/Pani nadawcy zmieniają swoje adresy IP. Wewnętrzne serwery pocztowe mogą być stabilne przez tygodnie, ale główni dostawcy ESP i CDN mogą zmieniać adresy codziennie. Właśnie dlatego ręczne spłaszczanie jest kruche, a AutoSPF skanuje ponownie co 15 minut, automatycznie publikując zaktualizowany rekord za każdym razem, gdy zmieni się zestaw IP wyższego poziomu.

Co się stanie, jeśli mój spłaszczony rekord zrobi się zbyt duży?

Rekordy DNS TXT są ograniczone do 255 znaków na ciąg, a nadmiernie duże rekordy grożą fragmentacją UDP. Jeśli spłaszczona lista adresów IP jest zbyt duża, podziel ją na etykiety pomocnicze (każda zawierająca wyłącznie wpisy ip4/ip6) i dołącz je z głównego rekordu albo deleguj zmiennych dostawców do subdomeny. Dąż do utrzymania całkowitej odpowiedzi poniżej ~900 bajtów, a liczby odpytań ≤ 10.

Czy spłaszczać rekord SPF ręcznie, czy używać narzędzia?

Ręczne spłaszczanie sprawdza się jako jednorazowa poprawka, ale nie nadąża za dostawcami rotującymi adresy IP — ręcznie spłaszczony rekord po cichu odbiera autoryzację nadawcom, gdy tylko zmieni się zakres wyższego poziomu. Zarządzane narzędzie takie jak AutoSPF wykonuje za Pana/Panią rekurencyjne rozwiązywanie, usuwanie duplikatów, zarządzanie rozmiarem oraz ciągłe ponowne spłaszczanie, dlatego jest to zalecane podejście dla wszystkiego poza pojedynczym statycznym nadawcą.