Krótka odpowiedź: tak, każda subdomena wysyłająca pocztę potrzebuje własnego rekordu SPF, a każdą subdomenę, która nigdy nie wysyła poczty, również należy zabezpieczyć takim rekordem. SPF nie dziedziczy z domeny organizacyjnej w taki sposób jak DMARC. Jeśli mail.example.com nie ma własnego rekordu SPF, sprawdzenie tej nazwy zwróci none, a nie politykę ustawioną dla example.com. To właśnie tej luki szukają osoby podszywające się pod domeny.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
SPF sprawdza jedną dokładną nazwę i nigdy nie wędruje w górę
Ocena SPF, zdefiniowana w RFC 7208, analizuje domenę w kopercie SMTP (pole MAIL FROM, nazywane też return-path lub envelope-from) oraz, osobno, nazwę HELO/EHLO przedstawianą przez serwer wysyłający. Odbiorca bierze tę domenę, wykonuje pojedyncze zapytanie TXT dla tej dokładnej nazwy i ocenia rekord, który tam znajdzie.
Nie ma żadnego przechodzenia po drzewie. Jeśli domeną koperty jest news.example.com, odbiorca odpytuje news.example.com o rekord TXT v=spf1 i nic więcej. Nie sięga w rezerwie do example.com. Nie łączy tych dwóch rekordów. To najczęściej źle rozumiany fakt na temat SPF, który dezorientuje zespoły zakładające, że rekord domeny głównej chroni wszystko, co znajduje się poniżej.
Dla kontrastu DMARC zbudowano tak, aby wędrował w górę. DMARC ocenia domenę widoczną w nagłówku From:, a jeśli dana subdomena nie ma rekordu DMARC, odbiorca wspina się do domeny organizacyjnej i stosuje politykę nadrzędną. SPF nie ma odpowiednika tego mechanizmu. Ta jedna różnica projektowa sprawia, że osoby, które "ustawiają SPF tylko raz, na samej górze", pozostawiają dziurę pod każdą subdomeną.
Co tak naprawdę oznacza wynik "none"
Gdy odbiorca sprawdza SPF dla subdomeny i nie znajduje rekordu, wynikiem jest none, co dosłownie znaczy "domena nie opublikowała żadnej polityki SPF, więc nie możemy nic stwierdzić". To nie jest miękka porażka ani twarda porażka, to po prostu brak. Wynik none nie daje odbiorcy żadnej podstawy do odrzucenia wiadomości. W połączeniu z nagłówkiem From: na tej samej subdomenie atakujący może wysłać pocztę, która przejdzie podstawowe kontrole i - w zależności od konfiguracji DMARC - trafi do skrzynek odbiorczych. Jeśli chcesz zrozumieć pełny obraz ochrony przed podszywaniem się, nasz przewodnik jak powstrzymać podszywanie się pod domenę pocztą e-mail osadza SPF, DKIM i DMARC we właściwym kontekście.
Każda wysyłająca subdomena potrzebuje własnego rekordu
Jeśli wysyłasz pocztę transakcyjną z mail.example.com, marketingową z news.example.com, a odpowiedzi działu pomocy z support.example.com, każda z nich jest odrębną nazwą DNS i każda potrzebuje własnego rekordu v=spf1 wymieniającego serwery uprawnione do wysyłania w jej imieniu.
Typowa subdomena transakcyjna korzystająca z dostawcy takiego jak Amazon SES może wyglądać tak:
mail.example.com. IN TXT "v=spf1 include:amazonses.com -all"
Subdomena marketingowa korzystająca z osobnej platformy jest niezależna:
news.example.com. IN TXT "v=spf1 include:sendgrid.net -all"
Zwróć uwagę, że rekordy nie muszą być identyczne i nie powinny być kopiami rekordu domeny głównej. Każda subdomena autoryzuje wyłącznie infrastrukturę, która faktycznie w jej imieniu wysyła pocztę. Dzięki temu liczba zapytań pozostaje niska, a polityka precyzyjna. Mechanikę budowania czystego rekordu opisujemy w przewodniku jak skonfigurować SPF, a jeśli jesteś już blisko limitu, tekst naprawa błędu zbyt wielu zapytań DNS w SPF omawia limit dziesięciu zapytań obowiązujący dla każdego rekordu i każdej nazwy.
Rekord domeny głównej nie obejmuje subdomen
Warto powiedzieć to wprost, bo bardzo wiele osób rozumie to na odwrót. Ten rekord:
example.com. IN TXT "v=spf1 include:_spf.google.com -all"
chroni pocztę wysyłaną z example.com. Nie robi nic dla mail.example.com, news.example.com ani żadnej innej subdomeny. Każda z nich jest oceniana według własnej nazwy i bez własnego rekordu zwraca none.
Zabezpiecz subdomeny, które nigdy nie wysyłają poczty
Większość organizacji ma znacznie więcej subdomen, niż sobie zdaje sprawę: www, app, vpn, dev, staging, cdn, stare marketingowe mikrostrony i dziesiątki nazw DNS istniejących z powodów webowych lub infrastrukturalnych, które nigdy zgodnie z prawem nie będą źródłem poczty. Każda z nich jest podatną na podszycie domeną koperty, dopóki nie powiesz inaczej.
Rozwiązaniem jest rekord SPF z twardą porażką, który nie autoryzuje niczego:
dev.example.com. IN TXT "v=spf1 -all"
Ten rekord mówi "żaden serwer na świecie nie ma prawa wysyłać poczty jako ta nazwa". Odbiorca, który zobaczy pocztę rzekomo pochodzącą z dev.example.com, otrzymuje teraz jednoznaczny wynik fail zamiast pobłażliwego none i może ją od razu odrzucić. Publikowanie v=spf1 -all na subdomenach, które nie wysyłają poczty, to jeden z najtańszych i najbardziej wartościowych kroków wzmacniających bezpieczeństwo, jakie możesz podjąć.
Symbole wieloznaczne pomagają, ale tylko częściowo
Możesz opublikować rekord TXT z symbolem wieloznacznym, aby przechwycić subdomeny, których nie nazwałeś jawnie:
*.example.com. IN TXT "v=spf1 -all"
To przydatne, ale trzeba rozumieć ograniczenia tego rozwiązania. Symbol wieloznaczny DNS syntezuje rekord tylko dla nazwy, która w ogóle nie istnieje w strefie. W momencie, gdy subdomena ma jakikolwiek własny rekord dowolnego typu, ta nazwa istnieje, więc zapytanie o jej SPF zwraca pustą odpowiedź, a nie wartość z symbolu wieloznacznego. Właśnie dlatego twoje subdomeny webowe i infrastrukturalne zazwyczaj nie są objęte ochroną: mają już rekordy A lub CNAME, więc symbol wieloznaczny nigdy się do nich nie odnosi. Każda subdomena, która się rozwiązuje, a już z pewnością każda, która wysyła pocztę, musi mieć własny jawny rekord SPF. Symbole wieloznaczne nie pomagają też przy tożsamości HELO serwerów przedstawiających konkretną nazwę hosta. Traktuj symbol wieloznaczny jako siatkę bezpieczeństwa dla długiego ogona nazw, a nie jako zastępstwo dla nazwanych rekordów na subdomenach, które mają znaczenie.
Jak tag sp= w DMARC wypełnia lukę SPF
Ponieważ SPF nie potrafi wędrować w górę, to właśnie DMARC daje ci ochronę subdomen w skali całej organizacji. W rekordzie DMARC tag sp= ustawia politykę dla subdomen, które nie publikują własnego rekordu DMARC.
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"
Tutaj p=reject rządzi domeną organizacyjną, a sp=reject rządzi każdą subdomeną, która tej polityki nie nadpisała. Jeśli pominiesz sp=, subdomeny domyślnie dziedziczą wartość p=. To warstwa bezpieczeństwa, która wyłapuje podszyte subdomeny, których zapomniałeś zabezpieczyć na poziomie SPF, ponieważ DMARC odrzuci wiadomość, której From: wskazuje nieuwierzytelnioną subdomenę, nawet wtedy, gdy SPF tej subdomeny zwrócił none.
Oba systemy współpracują ze sobą. Rekordy SPF -all czynią poszczególne subdomeny jednoznacznie nieautoryzowanymi na poziomie koperty. DMARC sp=reject zapewnia zbiorczą politykę na poziomie nagłówka dla wszystkiego, co przeoczyłeś. Podwójne zabezpieczenie. Nasz przewodnik jak skonfigurować DMARC wyjaśnia cały rekord, a tekst polityka DMARC none, quarantine czy reject omawia wybór właściwego poziomu egzekwowania, zanim podkręcisz sp= do reject.
Ostrożnie z sp= i wyrównaniem
Jeśli ustawisz sp=reject, gdy legalna subdomena wciąż wysyła bez prawidłowego wyrównania SPF lub DKIM, zaczniesz odrzucać własną pocztę. Wprowadzaj egzekwowanie w przemyślany sposób: najpierw opublikuj rekordy dla każdej wysyłającej subdomeny, potwierdź, że przechodzą kontrole i są wyrównane, a dopiero potem zaostrzaj sp=. Unikaj pokusy stosowania gdziekolwiek pobłażliwego +all, aby pozbyć się porażek. To rana zadana samemu sobie, którą wyjaśnia tekst dlaczego +all w SPF jest niebezpieczne.
Weryfikuj całe drzewo, a nie tylko domenę główną
Praktyczny wniosek jest taki, że "mamy SPF" nie jest stwierdzeniem na poziomie domeny, lecz stwierdzeniem na poziomie pojedynczej nazwy. Musisz sprawdzić każdą wysyłającą subdomenę osobno i potwierdzić trzy rzeczy: rekord istnieje, wymienia właściwą infrastrukturę wysyłkową i kończy się na -all. Następnie potwierdź, że twoje niewysyłające subdomeny zwracają jednoznaczny fail, a tag sp= w DMARC zabezpiecza całość. Sprawdź swoją domenę i każdą subdomenę w powyższym narzędziu, aby zobaczyć rzeczywisty wynik, jaki wyliczyłby odbiorca, zamiast zakładać dziedziczenie, które nie istnieje.
Najczęściej zadawane pytania
Czy SPF dziedziczy z domeny nadrzędnej tak jak DMARC?
Nie. SPF nie ma dziedziczenia ani przechodzenia po drzewie. Wykonuje pojedyncze zapytanie TXT dla dokładnej sprawdzanej domeny koperty. Subdomena bez własnego rekordu zwraca none, niezależnie od tego, co publikuje domena nadrzędna. Tylko DMARC wspina się do domeny organizacyjnej, używając dla subdomen tagu sp=.
Jaki rekord SPF ustawić na subdomenie, która nigdy nie wysyła poczty?
Opublikuj na niej v=spf1 -all. To autoryzuje zero nadawców i zamienia każdą podszytą pocztę z tej nazwy w jednoznaczny fail, który odbiorca może odrzucić, zamiast pobłażliwego none. Zrób to dla każdej nazwy DNS istniejącej z powodów webowych lub infrastrukturalnych, która nigdy nie będzie źródłem poczty.
Jeśli ustawię sp=reject w DMARC, czy nadal potrzebuję SPF na każdej subdomenie?
Tak, dla każdej subdomeny, która faktycznie wysyła pocztę. DMARC potrzebuje wyrównanego wyniku pozytywnego SPF lub DKIM, aby przepuścić legalną pocztę, więc wysyłająca subdomena wciąż potrzebuje prawidłowego rekordu SPF. sp=reject obsługuje tylko subdomeny, które nic nie wysyłają i w przeciwnym razie zostałyby podszyte; nie zastępuje SPF na poziomie subdomeny dla prawdziwych nadawców.
Czy rekord SPF z symbolem wieloznacznym ochroni wszystkie moje subdomeny?
Częściowo. Rekord TXT *.example.com z v=spf1 -all przechwytuje subdomeny, które nie mają własnych rekordów TXT, ale przestaje obowiązywać w chwili, gdy subdomena opublikuje jakikolwiek rekord TXT. Jest więc przydatną siatką bezpieczeństwa dla długiego ogona nazw, a nie zastępstwem dla jawnego SPF na subdomenach, które wysyłają pocztę.