Spłaszczanie SPF (SPF flattening) to praktyka polegająca na rozwiązaniu mechanizmów include, a oraz mx w Twoim rekordzie SPF do surowych adresów IP, na które wskazują, a następnie wpisaniu tych wartości ip4 i ip6 bezpośrednio do rekordu. Celem jest zmieszczenie się w limicie 10 zapytań DNS obowiązującym w SPF, aby rekord nie zakończył się błędem PermError. Metoda działa, ale zamienia rekord utrzymujący się samodzielnie na statyczną listę, która teraz należy do Ciebie i którą musisz utrzymywać aktualną. Dlatego rzadko powinno to być Twoje pierwsze posunięcie.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Limit 10 zapytań, który wymusza to pytanie
SPF jest oceniany przez serwer poczty odbiorcy, a RFC 7208 ogranicza tę ocenę do 10 zapytań DNS. Każdy mechanizm include, a, mx, ptr i exists, a także modyfikator redirect, wlicza się do tego budżetu. Zagnieżdżone include też się liczą: jeśli include:_spf.google.com sam w sobie dociąga kolejne include, wszystkie one czerpią z tej samej puli 10. Mechanizmy ip4, ip6 oraz all nie kosztują żadnego zapytania, ponieważ niosą odpowiedź w sobie. RFC 7208 dodaje drugi, mniej znany limit: więcej niż dwa puste zapytania (mechanizmy, które nie rozwiązują się do niczego, takie jak NXDOMAIN lub pusta odpowiedź) również skutkują błędem PermError, nawet gdy łączna liczba pozostaje poniżej 10.
Limit istnieje po to, by chronić odbiorców przed wzmocnieniem ataku typu odmowa usługi, w którym pojedyncza wiadomość mogłaby inaczej wywołać dziesiątki zapytań DNS. Gdy Twój rekord przekroczy 10 zapytań, zgodny ze standardem odbiorca przerywa ocenę i zwraca błąd trwały. Tym wynikiem jest PermError, a większość odbiorców traktuje go jako niepowodzenie SPF. Praktyczny efekt jest taki, że DMARC nie może już uwierzytelnić po stronie SPF, więc opierasz się wyłącznie na dopasowaniu DKIM albo, co gorsza, lądujesz na niepowodzeniu DMARC i możliwym odrzuceniu.
Jeśli właśnie teraz patrzysz na ten błąd, zacznij od towarzyszącego poradnika o tym, jak naprawić zbyt wiele zapytań DNS w SPF, i przeczytaj SPF PermError kontra TempError, aby odróżnić trwały problem strukturalny od przejściowego przekroczenia czasu DNS. TempError nie jest problemem z liczbą zapytań, a spłaszczanie go nie naprawi.
Co spłaszczanie faktycznie robi
Weźmy rekord, który wygląda tak:
v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org a mx ~all
Każdy z tych mechanizmów kosztuje co najmniej jedno zapytanie, a zagnieżdżone include wpychają rzeczywistą sumę znacznie ponad 10. Spłaszczanie rozwiązuje każdy z nich w danym momencie i podstawia wyniki (tutaj w skróconej formie):
v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:167.89.0.0/17 ip4:161.38.192.0/20 -all
Rekord kosztuje teraz zero zapytań DNS podczas oceny, ponieważ każda autoryzowana sieć jest podana wprost. Zamieniłeś zestaw wskaźników w migawkę. Stan bezpieczeństwa w tej chwili się nie zmienił: autoryzowane są te same adresy IP. Zmieniło się to, kto odpowiada za utrzymanie listy w aktualnym stanie.
| Właściwość | Rekord oparty na include | Rekord spłaszczony |
|---|---|---|
| Zapytania DNS przy ocenie | Do 10, łatwo przekroczyć | Zero |
| Utrzymanie adresów IP | Dostawca aktualizuje własny include | Ty aktualizujesz rekord |
| Długość rekordu | Krótki, czytelny | Długi, blisko limitów rozmiaru |
| Tryb awarii | PermError przy przekroczeniu 10 | Ciche niepowodzenia SPF, gdy dostawca doda adres IP |
Zwróć uwagę na ostatni wiersz. To cała istota kompromisu w jednej linii.
Kompromis: spłaszczanie zamraża adresy IP, które nigdy nie były Twoje
Całym sensem mechanizmu include jest delegacja. Gdy publikujesz include:_spf.google.com, mówisz odbiorcom, aby ufali dowolnym adresom IP, które Google aktualnie ogłasza, a Google może rotować, dodawać i wycofywać te adresy bez proszenia Cię o dotknięcie Twojego DNS. Spłaszczanie celowo łamie tę delegację. Kopiujesz dzisiejsze adresy IP i bierzesz na siebie zadanie śledzenia każdej przyszłej zmiany u każdego dostawcy w Twoim rekordzie.
Duzi nadawcy zmieniają publikowane zakresy częściej, niż większość ludzi zakłada. Google rotował swoje zakresy _netblocks więcej niż raz w ciągu jednego roku, a Microsoft 365 oraz główni dostawcy usług pocztowych robią to samo, gdy dodają infrastrukturę wysyłkową. Gdy dostawca uruchamia nowy host wysyłkowy, którego nie ma na Twojej zamrożonej liście, poczta z tego hosta zaczyna nie przechodzić SPF. W zależności od tego, jak duża część Twojego ruchu przechodzi przez nowy host, może ucierpieć znacząca część legalnej poczty. Nic nie zgłasza głośnego błędu. Rekord jest wciąż poprawny, wciąż poniżej limitu, wciąż zwraca czysty wynik. Po prostu po cichu przestaje autoryzować nadawców, którzy naprawdę są Twoi, a dowiadujesz się o tym z nagłego wzrostu liczby wpisów dmarc=fail w raportach zbiorczych albo ze zgłoszenia serwisowego o poczcie lądującej w spamie.
Statyczne spłaszczenie nie jest zatem poprawką, którą stosujesz raz. To zobowiązanie do utrzymania. Jeśli spłaszczasz, potrzebujesz zautomatyzowanego ponownego rozwiązywania, które cyklicznie odpytuje każde źródło i aktualizuje opublikowany rekord za każdym razem, gdy coś się przesunie. To właśnie sprzedają komercyjne usługi hostowanego SPF i automatycznego spłaszczania: nie samo spłaszczanie, które jest trywialne, lecz ciągłe odświeżanie, które nie pozwala migawce się zestarzeć.
Bezpieczniejsze rozwiązania, po które warto sięgnąć najpierw
Zanim spłaszczysz, przejdź przez tańsze poprawki. Większość domen, które przekraczają limit, dźwiga martwy balast, a jego usunięcie sprowadza Cię z powrotem poniżej 10 bez zamrożonych adresów IP i bez nowego utrzymania.
1. Usuń martwe include
Przejrzyj każdy mechanizm i zapytaj, czy nadal wysyła pocztę w Twoim imieniu. Rekordy gromadzą wpisy include dla wersji próbnych usług, byłych ESP i jednorazowych kampanii, których nikt nie usunął. Każdy martwy include może kosztować kilka zapytań przez własne zagnieżdżenie. Całkowicie usuń każdy mechanizm ptr; jest wolny, mocno odradzany przez RFC 7208 i wlicza się do Twojego budżetu. Usuń zbędny a lub mx, jeśli te hosty faktycznie nie generują poczty, i usuń duplikaty nakładających się dostawców. Samo przycięcie często rozwiązuje problem. Twój poradnik konfiguracji SPF omawia znaczenie każdego mechanizmu, abyś mógł ocenić, co bezpiecznie wyciąć.
2. Deleguj strumienie wysyłki do subdomen
Każda domena i subdomena otrzymuje własny niezależny budżet 10 zapytań. Jeśli wysyłasz pocztę marketingową przez jedną platformę, a transakcyjną przez inną, przenieś każdy strumień na własną subdomenę (na przykład mail.example.com i news.example.com), każdą z krótkim rekordem SPF wymieniającym tylko tego dostawcę. Twoja domena zwrotów lub Return-Path decyduje, który rekord sprawdzają odbiorcy, więc dopasowanie nadawcy koperty do subdomeny jest kluczowym krokiem. Przy złagodzonym dopasowaniu DMARC subdomena wciąż dopasowuje się do domeny organizacyjnej, więc DMARC nadal przechodzi. Zobacz rekordy SPF dla subdomen, dopasowanie złagodzone kontra ścisłe oraz szersze pytanie o to, czy powinieneś wysyłać z subdomeny, aby poznać pełny wzorzec.
3. Użyj hostowanego lub zarządzanego SPF
Jeśli naprawdę potrzebujesz wielu dostawców w ramach jednej domeny i nie możesz rozdzielić strumieni, usługa hostowanego SPF daje Ci spłaszczanie plus automatyczne odświeżanie. Publikujesz pojedynczy include lub redirect wskazujący na rekord, który utrzymuje dostawca, a on stale ponownie rozwiązuje źródła bazowe. Utrzymuje Cię to poniżej limitu, zachowując jednocześnie korzyść z delegacji, ponieważ to dostawca śledzi zmiany adresów IP zamiast Ciebie. To spłaszczanie wykonane bezpiecznie, kosztem zależności i zwykle abonamentu.
Kiedy spłaszczanie jest faktycznie właściwym wyborem
Ręczne spłaszczanie zasługuje na swoje miejsce w wąskim zestawie przypadków: dostawca, którego zakresy IP są udokumentowane jako stabilne i rzadko się zmieniają, starszy host lokalny, który kontrolujesz bezpośrednio, albo tymczasowe rozwiązanie zastępcze podczas migracji do delegacji na subdomeny. W takich sytuacjach spłaszczasz coś, co należy do Ciebie, albo coś, co naprawdę się nie przemieszcza, więc ryzyko zamrożonej migawki jest niskie.
Jeszcze jedno ograniczenie: miej oko na rozmiar rekordu. Każdy ciąg wewnątrz rekordu TXT jest ograniczony do 255 znaków, a pełna odpowiedź SPF powinna zmieścić się w odpowiedzi DNS o rozmiarze 512 bajtów, aby uniknąć obcięcia i przejścia na TCP. Mocno spłaszczony rekord może zderzyć się z obydwoma. Podzielenie wartości na wiele ciągów wewnątrz jednego rekordu TXT jest dozwolone i resolwery je łączą, ale publikowanie dwóch osobnych rekordów v=spf1 dla tego samego hosta już nie; to samo w sobie skutkuje błędem PermError.
Przede wszystkim unikaj pokusy zamaskowania problemu przez rozluźnienie polityki. Złagodzenie -all do +all, aby niepowodzenia zniknęły, niczego nie naprawia i autoryzuje cały internet do wysyłania w Twoim imieniu. Powody omawiamy w dlaczego +all jest niebezpieczne.
Najczęściej zadawane pytania
Czy spłaszczanie SPF czyni moją domenę mniej bezpieczną?
Nie w chwili, gdy spłaszczasz, ponieważ autoryzowane są te same adresy IP. Ryzyko dotyczy upływu czasu: zamrożona lista po cichu przestaje autoryzować nowe legalne adresy IP wysyłkowe, gdy dostawca zmienia swoje, co powoduje, że prawdziwa poczta nie przechodzi SPF. Nie autoryzuje to nowych napastników, więc trybem awarii jest utrata dostarczalności, a nie luka umożliwiająca podszywanie się.
Jak często zakresy IP dostawców faktycznie się zmieniają?
Wystarczająco często, by miało to znaczenie. Wielcy nadawcy jak Google i Microsoft rotowali swoje publikowane zakresy więcej niż raz w ciągu jednego roku, a dostawcy usług pocztowych dodają hosty w miarę skalowania. Każdy spłaszczony rekord, który nie jest automatycznie ponownie rozwiązywany, w końcu się zestarzeje i zacznie odrzucać legalną pocztę.
Czy spłaszczanie naprawi błąd SPF TempError?
Nie. TempError to przejściowe niepowodzenie rozwiązywania DNS, takie jak przekroczenie czasu lub SERVFAIL, a nie problem z liczbą zapytań. Spłaszczanie adresuje wyłącznie trwały błąd PermError związany z limitem 10 zapytań. Zobacz poradnik SPF PermError kontra TempError, aby przed działaniem ustalić, który z nich masz.
Czy mogę spłaszczyć tylko niektóre mechanizmy, a inne zostawić jako include?
Tak, i często jest to rozsądna ścieżka pośrednia. Spłaszcz tylko stabilne źródła, które kontrolujesz, pozostawiając szybko zmieniających się dostawców jak Google czy Microsoft jako żywe mechanizmy include, aby ich delegacja dalej działała. Upewnij się tylko, że wynikowa suma pozostaje poniżej 10 zapytań.
Nie masz pewności, czy Twój rekord przekracza limit albo czy już po cichu zawodzi? Uruchom darmowy skan SPFWise, aby zobaczyć swój aktualny rekord SPF, dokładną liczbę zapytań i to, czy spłaszczanie jest w ogóle konieczne, zanim cokolwiek zmienisz.