Autoryzacja SPF: Przegląd i najlepsze praktyki
Ptak
19 gru 2016
1 min read
Kluczowe Wnioski
SPF (Sender Policy Framework) jest protokołem uwierzytelniania e-maili opartym na ścieżkach, który weryfikuje, czy serwer wysyłający jest upoważniony do wysyłania poczty dla danej domeny.
Zasady SPF istnieją jako rekordy DNS TXT, sformatowane z mechanizmami definiującymi, które serwery, IP lub sieci są uprawnione do wysyłania w imieniu domeny.
Walidacja SPF jest powiązana z domeną Return-Path (domeną odbicia) lub nazwą hosta HELO — nie z widocznym adresem od.
Ponieważ SPF sprawdza tylko ścieżkę wysyłania, może być zweryfikowany wcześnie w transakcji SMTP, co czyni go przydatnym do szybkiego odrzucania nieautoryzowanej poczty.
SPF jest skuteczny, ale nie doskonały — jest podatny na fałszywe negatywy, zwłaszcza przy przekazywaniu e-maili i listach mailingowych.
Rekordy SPF opierają się na mechanizmach takich jak
mx,a,ipv4,ipv6,include,redirect,exists, i muszą kończyć się modyfikatoremall(-all,~all,?all,+all).Obowiązują limity zapytań DNS: ocena SPF nie może przekraczać 10 zapytań DNS, co czyni ważnym planowanie rekordów.
Mechanizm
ptrjest obecnie uważany za „nie używać”, ale walidatory nadal muszą go akceptować. Niektórzy nadawcy nadal go używają z powodu luk w kompatybilności.SPF sam w sobie nie gwarantuje, że e-mail jest autentyczny — tylko, że został wysłany z autoryzowanego serwera. Działa najlepiej w połączeniu z DKIM, DMARC i innymi technikami przeciwdziałania oszustwom.
Q&A Highlights
Co to jest SPF w prostych słowach?
SPF pozwala domenie zadeklarować, które serwery mogą wysyłać e-maile w jej imieniu. Serwery odbierające sprawdzają to, aby wykryć nieautoryzowanych nadawców.
Dlaczego SPF nazywa się „path-based”?
Ponieważ SPF weryfikuje ścieżkę, którą przeszła wiadomość — konkretnie adres IP serwera wysyłającego — a nie cokolwiek w treści wiadomości.
Gdzie jest przechowywana polityka SPF?
A: Jako rekord DNS TXT, zaczynający się od
v=spf1, a następnie mechanizmy definiujące dozwolonych nadawców.Który z domen sprawdza SPF?
Return-Path (nazywany również domeną zwrotów).
Jeśli Return-Path jest pusty (NULL sender), SPF sprawdza zamiast tego domenę HELO.
Czy SPF może być sprawdzane wcześniej w transakcji SMTP?
Tak. Ponieważ zależy to tylko od adresu IP i domeny serwera wysyłającego, SPF może być zweryfikowany przed odebraniem treści wiadomości—co czyni go efektywnym przy filtrowaniu.
Dlaczego SPF czasami zawodzi nawet dla prawidłowych emaili?
Typowe przyczyny to:
Przekazywanie Email (przekierowujący nie znajduje się w oryginalnym rekordzie SPF domeny)
Listy mailingowe (wiadomości są wysyłane ponownie przez inny serwer)
To prowadzi do fałszywych negatywów, które są nieodłączne dla uwierzytelniania opartego na ścieżce.
Jaka jest rola mechanizmów takich jak include, redirect i exists?
include— autoryzować rekord SPF innej domeny (np. Twój ESP)redirect— ponownie używać polityki SPF innej domenyexists— dynamicznie autoryzować na podstawie zapytania DNS (przydatne dla skomplikowanej infrastruktury)
Jak działają modyfikatory „all”?
-all→ odrzucić wszystko, co nie jest wymienione (surowe)~all→ softfail (zaakceptuj, ale oznacz)?all → neutralny+all→ przepuść wszystko (efektywnie wyłącza SPF)
Dlaczego mechanizm ptr jest odradzany?
Jest wolne, niewiarygodne i przestarzałe w nowoczesnej specyfikacji — ale walidatory SPF nadal muszą je obsługiwać.
Czy SPF sam w sobie wystarczy do uwierzytelnienia e-mail?
Nie. SPF weryfikuje infrastrukturę wysyłania, ale:
Nie chroni integralności wiadomości
Nie jest zgodny z widocznymi domenami nadawcy
Nie działa poprawnie przy przekazywaniu dalej
SPF jest najskuteczniejszy, gdy jest połączony z DKIM i DMARC.
Zanim zagłębimy się w techniczne aspekty, warto zrozumieć ewolucję i różnorodność dostępnych technik walidacji email. Od prostego sprawdzania składni po nowoczesne podejścia oparte na danych, różne metody walidacji oferują różne poziomy dokładności i niezawodności.
Kiedy mówimy o „uwierzytelnianiu email”, mamy na myśli technikę, która ma zapewnić odbiorcy wiadomości pewien poziom pewności, że wiadomość faktycznie pochodzi od zadeklarowanego źródła wiadomości. Idea polega na zapewnieniu pewnego poziomu obrony przed oszukańczymi emailami, takimi jak phishing i spoofing, które mogą podważyć zaufanie odbiorcy do otrzymywania emaili. Dla organizacji wymagających szyfrowania wiadomości na poziomie wyższym niż uwierzytelnianie, S/MIME zapewnia bezpieczeństwo end-to-end, z automatycznym zbieraniem publicznych kluczy odbiorców co czyni wdrożenie bardziej skalowalnym. To powiedziawszy, samo wysłanie uwierzytelnionego emaila nie oznacza samo w sobie, że email jest dobry czy pożądany; oznacza jedynie, że email jest taki, że reputacja uwierzytelnionej strony może być niezawodnie ustanowiona i używana do podejmowania decyzji o akceptacji i umieszczeniu wiadomości email.
Dzisiaj istnieją dwie główne formy uwierzytelniania email—Sender Policy Framework (SPF) i DomainKeys Identifed Mail (DKIM). W tym wpisie na blogu wyjaśnię, czym jest SPF i jak działa.
Zanim zagłębimy się w techniczne aspekty, warto zrozumieć ewolucję i różnorodność dostępnych technik walidacji email. Od prostego sprawdzania składni po nowoczesne podejścia oparte na danych, różne metody walidacji oferują różne poziomy dokładności i niezawodności.
Kiedy mówimy o „uwierzytelnianiu email”, mamy na myśli technikę, która ma zapewnić odbiorcy wiadomości pewien poziom pewności, że wiadomość faktycznie pochodzi od zadeklarowanego źródła wiadomości. Idea polega na zapewnieniu pewnego poziomu obrony przed oszukańczymi emailami, takimi jak phishing i spoofing, które mogą podważyć zaufanie odbiorcy do otrzymywania emaili. Dla organizacji wymagających szyfrowania wiadomości na poziomie wyższym niż uwierzytelnianie, S/MIME zapewnia bezpieczeństwo end-to-end, z automatycznym zbieraniem publicznych kluczy odbiorców co czyni wdrożenie bardziej skalowalnym. To powiedziawszy, samo wysłanie uwierzytelnionego emaila nie oznacza samo w sobie, że email jest dobry czy pożądany; oznacza jedynie, że email jest taki, że reputacja uwierzytelnionej strony może być niezawodnie ustanowiona i używana do podejmowania decyzji o akceptacji i umieszczeniu wiadomości email.
Dzisiaj istnieją dwie główne formy uwierzytelniania email—Sender Policy Framework (SPF) i DomainKeys Identifed Mail (DKIM). W tym wpisie na blogu wyjaśnię, czym jest SPF i jak działa.
Zanim zagłębimy się w techniczne aspekty, warto zrozumieć ewolucję i różnorodność dostępnych technik walidacji email. Od prostego sprawdzania składni po nowoczesne podejścia oparte na danych, różne metody walidacji oferują różne poziomy dokładności i niezawodności.
Kiedy mówimy o „uwierzytelnianiu email”, mamy na myśli technikę, która ma zapewnić odbiorcy wiadomości pewien poziom pewności, że wiadomość faktycznie pochodzi od zadeklarowanego źródła wiadomości. Idea polega na zapewnieniu pewnego poziomu obrony przed oszukańczymi emailami, takimi jak phishing i spoofing, które mogą podważyć zaufanie odbiorcy do otrzymywania emaili. Dla organizacji wymagających szyfrowania wiadomości na poziomie wyższym niż uwierzytelnianie, S/MIME zapewnia bezpieczeństwo end-to-end, z automatycznym zbieraniem publicznych kluczy odbiorców co czyni wdrożenie bardziej skalowalnym. To powiedziawszy, samo wysłanie uwierzytelnionego emaila nie oznacza samo w sobie, że email jest dobry czy pożądany; oznacza jedynie, że email jest taki, że reputacja uwierzytelnionej strony może być niezawodnie ustanowiona i używana do podejmowania decyzji o akceptacji i umieszczeniu wiadomości email.
Dzisiaj istnieją dwie główne formy uwierzytelniania email—Sender Policy Framework (SPF) i DomainKeys Identifed Mail (DKIM). W tym wpisie na blogu wyjaśnię, czym jest SPF i jak działa.
SPF nie jest niezawodny
Chociaż wydaje się to stosunkowo prosty sposób uwierzytelniania poczty e-mail, SPF jest podatny na błędy w postaci fałszywych negatywów. Te błędy mogą występować częściej, niż wielu osobom odpowiada.
Oto dwa powszechne scenariusze, w których całkowicie legalna poczta może nie zdać weryfikacji SPF i wydawać się oszukańcza:
Zautomatyzowane przekazywanie, gdzie wiadomość wysłana do jsmith@alumni.university.edu, skrzynka pocztowa ustawiona na automatyczne przekazywanie całej poczty do jsmith@isp.com
Listy mailingowe, gdzie poczta wysłana do talk-about-stuff@listserv.foo.com zostaje „rozłożona” i wysłana do każdego subskrybenta
W obu tych przypadkach, jeśli Return-Path nie jest zmieniona od oryginału, poczta może nie przejść sprawdzeń SPF (w zależności od modyfikatora użytego z mechanizmem 'all'). Dzieje się tak, ponieważ dociera do swojego ostatecznego miejsca przeznaczenia z serwera pośredniego, a nie oryginalnego, i ten serwer pośredni prawdopodobnie nie znajduje się w rekordzie SPF domeny. Technika zwana „Sender Rewriting Scheme” lub „SRS” może zmniejszyć to ryzyko, i niektóre większe strony ją przyjęły, ale nie jest to rozwiązanie uniwersalne.
Chociaż wydaje się to stosunkowo prosty sposób uwierzytelniania poczty e-mail, SPF jest podatny na błędy w postaci fałszywych negatywów. Te błędy mogą występować częściej, niż wielu osobom odpowiada.
Oto dwa powszechne scenariusze, w których całkowicie legalna poczta może nie zdać weryfikacji SPF i wydawać się oszukańcza:
Zautomatyzowane przekazywanie, gdzie wiadomość wysłana do jsmith@alumni.university.edu, skrzynka pocztowa ustawiona na automatyczne przekazywanie całej poczty do jsmith@isp.com
Listy mailingowe, gdzie poczta wysłana do talk-about-stuff@listserv.foo.com zostaje „rozłożona” i wysłana do każdego subskrybenta
W obu tych przypadkach, jeśli Return-Path nie jest zmieniona od oryginału, poczta może nie przejść sprawdzeń SPF (w zależności od modyfikatora użytego z mechanizmem 'all'). Dzieje się tak, ponieważ dociera do swojego ostatecznego miejsca przeznaczenia z serwera pośredniego, a nie oryginalnego, i ten serwer pośredni prawdopodobnie nie znajduje się w rekordzie SPF domeny. Technika zwana „Sender Rewriting Scheme” lub „SRS” może zmniejszyć to ryzyko, i niektóre większe strony ją przyjęły, ale nie jest to rozwiązanie uniwersalne.
Chociaż wydaje się to stosunkowo prosty sposób uwierzytelniania poczty e-mail, SPF jest podatny na błędy w postaci fałszywych negatywów. Te błędy mogą występować częściej, niż wielu osobom odpowiada.
Oto dwa powszechne scenariusze, w których całkowicie legalna poczta może nie zdać weryfikacji SPF i wydawać się oszukańcza:
Zautomatyzowane przekazywanie, gdzie wiadomość wysłana do jsmith@alumni.university.edu, skrzynka pocztowa ustawiona na automatyczne przekazywanie całej poczty do jsmith@isp.com
Listy mailingowe, gdzie poczta wysłana do talk-about-stuff@listserv.foo.com zostaje „rozłożona” i wysłana do każdego subskrybenta
W obu tych przypadkach, jeśli Return-Path nie jest zmieniona od oryginału, poczta może nie przejść sprawdzeń SPF (w zależności od modyfikatora użytego z mechanizmem 'all'). Dzieje się tak, ponieważ dociera do swojego ostatecznego miejsca przeznaczenia z serwera pośredniego, a nie oryginalnego, i ten serwer pośredni prawdopodobnie nie znajduje się w rekordzie SPF domeny. Technika zwana „Sender Rewriting Scheme” lub „SRS” może zmniejszyć to ryzyko, i niektóre większe strony ją przyjęły, ale nie jest to rozwiązanie uniwersalne.
SPF Przegląd
Sender Policy Framework (SPF), parafrazując RFC 7208, to protokół, który nie tylko pozwala organizacji autoryzować hosty i sieci do używania jej nazw domenowych przy wysyłaniu e-maili, ale także zapewnia sposób, w jaki host odbierający może sprawdzić tę autoryzację.
Po przeczytaniu tego posta mam nadzieję, że dowiesz się następujących rzeczy:
SPF to system uwierzytelniania oparty na "ścieżkach".
Polityki SPF są deklarowane w rekordach DNS TXT.
Weryfikacja jest związana z domeną Return-Path (co tutaj w SparkPost nazywamy "bounce domain") lub domeną HELO.
Weryfikacja może być wykonana wcześnie w transakcji SMTP, więc to dobry sposób, aby szybko odrzucić nieautoryzowaną pocztę.
Jest narażony na stosunkowo wysoki odsetek fałszywych negatywów.
Sender Policy Framework (SPF), parafrazując RFC 7208, to protokół, który nie tylko pozwala organizacji autoryzować hosty i sieci do używania jej nazw domenowych przy wysyłaniu e-maili, ale także zapewnia sposób, w jaki host odbierający może sprawdzić tę autoryzację.
Po przeczytaniu tego posta mam nadzieję, że dowiesz się następujących rzeczy:
SPF to system uwierzytelniania oparty na "ścieżkach".
Polityki SPF są deklarowane w rekordach DNS TXT.
Weryfikacja jest związana z domeną Return-Path (co tutaj w SparkPost nazywamy "bounce domain") lub domeną HELO.
Weryfikacja może być wykonana wcześnie w transakcji SMTP, więc to dobry sposób, aby szybko odrzucić nieautoryzowaną pocztę.
Jest narażony na stosunkowo wysoki odsetek fałszywych negatywów.
Sender Policy Framework (SPF), parafrazując RFC 7208, to protokół, który nie tylko pozwala organizacji autoryzować hosty i sieci do używania jej nazw domenowych przy wysyłaniu e-maili, ale także zapewnia sposób, w jaki host odbierający może sprawdzić tę autoryzację.
Po przeczytaniu tego posta mam nadzieję, że dowiesz się następujących rzeczy:
SPF to system uwierzytelniania oparty na "ścieżkach".
Polityki SPF są deklarowane w rekordach DNS TXT.
Weryfikacja jest związana z domeną Return-Path (co tutaj w SparkPost nazywamy "bounce domain") lub domeną HELO.
Weryfikacja może być wykonana wcześnie w transakcji SMTP, więc to dobry sposób, aby szybko odrzucić nieautoryzowaną pocztę.
Jest narażony na stosunkowo wysoki odsetek fałszywych negatywów.
„Path-Based” Authentication
SPF jest uważany za system uwierzytelniania oparty na ścieżce, ponieważ jest związany wyłącznie ze ścieżką, którą przeszedł komunikat od swojego pochodzenia do miejsca przeznaczenia. Gdy serwer wysyłający inicjuje transakcję SMTP z serwerem odbierającym, serwer odbierający ustala, czy serwer wysyłający jest uprawniony do wysłania tej wiadomości na podstawie polityki SPF domeny. Jest to wyłącznie decyzja oparta na tym, skąd pochodzi wiadomość, i nie ma nic wspólnego z jej treścią.
SPF jest uważany za system uwierzytelniania oparty na ścieżce, ponieważ jest związany wyłącznie ze ścieżką, którą przeszedł komunikat od swojego pochodzenia do miejsca przeznaczenia. Gdy serwer wysyłający inicjuje transakcję SMTP z serwerem odbierającym, serwer odbierający ustala, czy serwer wysyłający jest uprawniony do wysłania tej wiadomości na podstawie polityki SPF domeny. Jest to wyłącznie decyzja oparta na tym, skąd pochodzi wiadomość, i nie ma nic wspólnego z jej treścią.
SPF jest uważany za system uwierzytelniania oparty na ścieżce, ponieważ jest związany wyłącznie ze ścieżką, którą przeszedł komunikat od swojego pochodzenia do miejsca przeznaczenia. Gdy serwer wysyłający inicjuje transakcję SMTP z serwerem odbierającym, serwer odbierający ustala, czy serwer wysyłający jest uprawniony do wysłania tej wiadomości na podstawie polityki SPF domeny. Jest to wyłącznie decyzja oparta na tym, skąd pochodzi wiadomość, i nie ma nic wspólnego z jej treścią.
Deklarowanie polityki SPF
Rekord polityki SPF domeny to po prostu specjalnie sformatowany rekord DNS TXT, zwykle zawierający jeden lub więcej z następujących „mechanizmów”:
v=spf1 – Wymagany pierwszy token wskazujący, że rekord TXT jest rekordem SPF (domena może mieć wiele rekordów TXT)
ipv4, ipv6 – Używane do określenia adresów IP i sieci, które mają uprawnienia do wysyłania poczty w imieniu domeny
a – Jeśli wysyłająca domena posiada rekord DNS „A” rozwiązujący się na wysyłający IP, adres IP jest dozwolony
mx – Jeśli wysyłający IP jest również jednym z rekordów MX dla wysyłającej domeny, adres IP jest dozwolony
all – Wymagany ostatni token, zawsze modyfikowany:
-all – Tylko to, co jest tu wymienione, może przejść; odrzuć niepowodzenia.
~all – Coś, czego tu nie ma, powinno delikatnie zawieść; zaakceptuj to, ale zanotuj to.
?all – Niezdecydowane, czy to, czego tu nie ma, powinno przejść.
+all – Uważamy, że SPF jest bezużyteczne; przepuść wszystko.
Inne mniej powszechne mechanizmy, które nadal są szeroko stosowane to:
include – Używane, gdy domena nie tylko posiada własne serwery, ale także korzysta z serwerów kogoś innego. Musi być używane ostrożnie. Każde include jest kolejnym zapytaniem DNS, a rekordy SPF nie mogą wymagać więcej niż dziesięciu zapytań DNS do rozwiązania.
redirect – Gdy domena A i domena B są własnością tego samego podmiotu i używają tej samej infrastruktury. Właściciele zwykle chcą utrzymać tylko jedną kopię rekordu SPF dla obu i skonfigurować B do przekierowywania zapytań do A.
exists – Jeśli domena ma wiele małych, nieciągłych bloków sieciowych, może użyć tego mechanizmu do określenia swojego rekordu SPF, zamiast wymieniać je wszystkie. Przydatne, aby pozostać w wierszu limitu rozmiaru (512 bajtów) dla odpowiedzi DNS.
Notatka dotycząca mechanizmu „ptr”
Ostateczny mechanizm „ptr” istniał w pierwotnej specyfikacji SPF, ale został ogłoszony jako „nie do użycia” w obecnej specyfikacji. Mechanizm ptr był używany do deklaracji, że jeśli wysyłający adres IP miał rekord DNS PTR, który rozwiązywał się do nazwy domeny będącej przedmiotem zapytania, to ten adres IP był uprawniony do wysyłania poczty za domenę.
Obecny status tego mechanizmu jest taki, że nie należy go używać. Jednak witryny przeprowadzające weryfikację SPF muszą zaakceptować go jako ważny.
Mechanizm | Co robi | Uwagi / Wskazówki dotyczące użytkowania |
|---|---|---|
v=spf1 | Deklaruje, że rekord TXT jest polityką SPF | Wymagany pierwszy token |
ipv4 / ipv6 | Autoryzuje określone adresy IP lub bloki CIDR | Najbardziej bezpośrednia i niezawodna metoda autoryzacji |
a | Autoryzuje adresy IP odpowiadające rekordowi A domeny | Dobre dla prostej infrastruktury |
mx | Autoryzuje adresy IP wymienione w rekordach MX domeny | Przydatne, gdy serwery MX również wysyłają pocztę |
include | Importuje politykę SPF innej domeny | Liczone do limitu 10 zapytań DNS; używaj oszczędnie |
redirect | Deleguje politykę SPF do innej domeny | Używane, gdy wiele domen dzieli jedną definicję SPF |
exists | Autoryzuje przez niestandardową regułę zapytania DNS | Przydatne dla dużych, rozdrobnionych zasięgów IP; walidator musi to obsługiwać |
ptr | Autoryzuje na podstawie odwrotnego mapowania DNS | Przestarzałe („nie używać”), ale walidatory muszą go wciąż honorować |
all | Określa, jak traktować wszystko, co nie jest wyraźnie dozwolone | Warianty: -all odrzuć, ~all delikatna porażka, ?all neutralny, +all pozwól na wszystko (nie zalecane) |
Rekord polityki SPF domeny to po prostu specjalnie sformatowany rekord DNS TXT, zwykle zawierający jeden lub więcej z następujących „mechanizmów”:
v=spf1 – Wymagany pierwszy token wskazujący, że rekord TXT jest rekordem SPF (domena może mieć wiele rekordów TXT)
ipv4, ipv6 – Używane do określenia adresów IP i sieci, które mają uprawnienia do wysyłania poczty w imieniu domeny
a – Jeśli wysyłająca domena posiada rekord DNS „A” rozwiązujący się na wysyłający IP, adres IP jest dozwolony
mx – Jeśli wysyłający IP jest również jednym z rekordów MX dla wysyłającej domeny, adres IP jest dozwolony
all – Wymagany ostatni token, zawsze modyfikowany:
-all – Tylko to, co jest tu wymienione, może przejść; odrzuć niepowodzenia.
~all – Coś, czego tu nie ma, powinno delikatnie zawieść; zaakceptuj to, ale zanotuj to.
?all – Niezdecydowane, czy to, czego tu nie ma, powinno przejść.
+all – Uważamy, że SPF jest bezużyteczne; przepuść wszystko.
Inne mniej powszechne mechanizmy, które nadal są szeroko stosowane to:
include – Używane, gdy domena nie tylko posiada własne serwery, ale także korzysta z serwerów kogoś innego. Musi być używane ostrożnie. Każde include jest kolejnym zapytaniem DNS, a rekordy SPF nie mogą wymagać więcej niż dziesięciu zapytań DNS do rozwiązania.
redirect – Gdy domena A i domena B są własnością tego samego podmiotu i używają tej samej infrastruktury. Właściciele zwykle chcą utrzymać tylko jedną kopię rekordu SPF dla obu i skonfigurować B do przekierowywania zapytań do A.
exists – Jeśli domena ma wiele małych, nieciągłych bloków sieciowych, może użyć tego mechanizmu do określenia swojego rekordu SPF, zamiast wymieniać je wszystkie. Przydatne, aby pozostać w wierszu limitu rozmiaru (512 bajtów) dla odpowiedzi DNS.
Notatka dotycząca mechanizmu „ptr”
Ostateczny mechanizm „ptr” istniał w pierwotnej specyfikacji SPF, ale został ogłoszony jako „nie do użycia” w obecnej specyfikacji. Mechanizm ptr był używany do deklaracji, że jeśli wysyłający adres IP miał rekord DNS PTR, który rozwiązywał się do nazwy domeny będącej przedmiotem zapytania, to ten adres IP był uprawniony do wysyłania poczty za domenę.
Obecny status tego mechanizmu jest taki, że nie należy go używać. Jednak witryny przeprowadzające weryfikację SPF muszą zaakceptować go jako ważny.
Mechanizm | Co robi | Uwagi / Wskazówki dotyczące użytkowania |
|---|---|---|
v=spf1 | Deklaruje, że rekord TXT jest polityką SPF | Wymagany pierwszy token |
ipv4 / ipv6 | Autoryzuje określone adresy IP lub bloki CIDR | Najbardziej bezpośrednia i niezawodna metoda autoryzacji |
a | Autoryzuje adresy IP odpowiadające rekordowi A domeny | Dobre dla prostej infrastruktury |
mx | Autoryzuje adresy IP wymienione w rekordach MX domeny | Przydatne, gdy serwery MX również wysyłają pocztę |
include | Importuje politykę SPF innej domeny | Liczone do limitu 10 zapytań DNS; używaj oszczędnie |
redirect | Deleguje politykę SPF do innej domeny | Używane, gdy wiele domen dzieli jedną definicję SPF |
exists | Autoryzuje przez niestandardową regułę zapytania DNS | Przydatne dla dużych, rozdrobnionych zasięgów IP; walidator musi to obsługiwać |
ptr | Autoryzuje na podstawie odwrotnego mapowania DNS | Przestarzałe („nie używać”), ale walidatory muszą go wciąż honorować |
all | Określa, jak traktować wszystko, co nie jest wyraźnie dozwolone | Warianty: -all odrzuć, ~all delikatna porażka, ?all neutralny, +all pozwól na wszystko (nie zalecane) |
Rekord polityki SPF domeny to po prostu specjalnie sformatowany rekord DNS TXT, zwykle zawierający jeden lub więcej z następujących „mechanizmów”:
v=spf1 – Wymagany pierwszy token wskazujący, że rekord TXT jest rekordem SPF (domena może mieć wiele rekordów TXT)
ipv4, ipv6 – Używane do określenia adresów IP i sieci, które mają uprawnienia do wysyłania poczty w imieniu domeny
a – Jeśli wysyłająca domena posiada rekord DNS „A” rozwiązujący się na wysyłający IP, adres IP jest dozwolony
mx – Jeśli wysyłający IP jest również jednym z rekordów MX dla wysyłającej domeny, adres IP jest dozwolony
all – Wymagany ostatni token, zawsze modyfikowany:
-all – Tylko to, co jest tu wymienione, może przejść; odrzuć niepowodzenia.
~all – Coś, czego tu nie ma, powinno delikatnie zawieść; zaakceptuj to, ale zanotuj to.
?all – Niezdecydowane, czy to, czego tu nie ma, powinno przejść.
+all – Uważamy, że SPF jest bezużyteczne; przepuść wszystko.
Inne mniej powszechne mechanizmy, które nadal są szeroko stosowane to:
include – Używane, gdy domena nie tylko posiada własne serwery, ale także korzysta z serwerów kogoś innego. Musi być używane ostrożnie. Każde include jest kolejnym zapytaniem DNS, a rekordy SPF nie mogą wymagać więcej niż dziesięciu zapytań DNS do rozwiązania.
redirect – Gdy domena A i domena B są własnością tego samego podmiotu i używają tej samej infrastruktury. Właściciele zwykle chcą utrzymać tylko jedną kopię rekordu SPF dla obu i skonfigurować B do przekierowywania zapytań do A.
exists – Jeśli domena ma wiele małych, nieciągłych bloków sieciowych, może użyć tego mechanizmu do określenia swojego rekordu SPF, zamiast wymieniać je wszystkie. Przydatne, aby pozostać w wierszu limitu rozmiaru (512 bajtów) dla odpowiedzi DNS.
Notatka dotycząca mechanizmu „ptr”
Ostateczny mechanizm „ptr” istniał w pierwotnej specyfikacji SPF, ale został ogłoszony jako „nie do użycia” w obecnej specyfikacji. Mechanizm ptr był używany do deklaracji, że jeśli wysyłający adres IP miał rekord DNS PTR, który rozwiązywał się do nazwy domeny będącej przedmiotem zapytania, to ten adres IP był uprawniony do wysyłania poczty za domenę.
Obecny status tego mechanizmu jest taki, że nie należy go używać. Jednak witryny przeprowadzające weryfikację SPF muszą zaakceptować go jako ważny.
Mechanizm | Co robi | Uwagi / Wskazówki dotyczące użytkowania |
|---|---|---|
v=spf1 | Deklaruje, że rekord TXT jest polityką SPF | Wymagany pierwszy token |
ipv4 / ipv6 | Autoryzuje określone adresy IP lub bloki CIDR | Najbardziej bezpośrednia i niezawodna metoda autoryzacji |
a | Autoryzuje adresy IP odpowiadające rekordowi A domeny | Dobre dla prostej infrastruktury |
mx | Autoryzuje adresy IP wymienione w rekordach MX domeny | Przydatne, gdy serwery MX również wysyłają pocztę |
include | Importuje politykę SPF innej domeny | Liczone do limitu 10 zapytań DNS; używaj oszczędnie |
redirect | Deleguje politykę SPF do innej domeny | Używane, gdy wiele domen dzieli jedną definicję SPF |
exists | Autoryzuje przez niestandardową regułę zapytania DNS | Przydatne dla dużych, rozdrobnionych zasięgów IP; walidator musi to obsługiwać |
ptr | Autoryzuje na podstawie odwrotnego mapowania DNS | Przestarzałe („nie używać”), ale walidatory muszą go wciąż honorować |
all | Określa, jak traktować wszystko, co nie jest wyraźnie dozwolone | Warianty: -all odrzuć, ~all delikatna porażka, ?all neutralny, +all pozwól na wszystko (nie zalecane) |
Niektóre przykładowe rekordy SPF
Oto kilka przykładowych rekordów i ich znaczenie. Ten przykład pokazuje adresy RFC 1918, ale zdaję sobie sprawę, że takie adresy nigdy nie pojawią się w prawdziwych rekordach SPF.
Rekord MX, jeden adres IP, jedna sieć IP, miękki brak sukcesu dla reszty:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Rekord A, dwie sieci IP, odrzucić resztę:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Nie wysyłamy żadnej poczty:
“v=spf1 -all”
Uważamy, że SPF jest głupie:
“v=spf1 +all”
Rekord SPF dla domeny sparkpostmail.com (użyty mechanizm przekierowania)
“v=spf1 redirect=_spf.sparkpostmail.com”
Rekord SPF dla _spf.sparkpostmail.com (użyto mechanizmów exists i ptr):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
W SparkPost obecnie używamy mechanizmu ptr w naszym rekordzie SPF. Uznaliśmy to za konieczne z powodu braku powszechnego wsparcia dla walidacji mechanizmu exists. Do tej pory nie zauważyliśmy żadnych awarii SPF wynikających z używania mechanizmu ptr.
Oto kilka przykładowych rekordów i ich znaczenie. Ten przykład pokazuje adresy RFC 1918, ale zdaję sobie sprawę, że takie adresy nigdy nie pojawią się w prawdziwych rekordach SPF.
Rekord MX, jeden adres IP, jedna sieć IP, miękki brak sukcesu dla reszty:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Rekord A, dwie sieci IP, odrzucić resztę:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Nie wysyłamy żadnej poczty:
“v=spf1 -all”
Uważamy, że SPF jest głupie:
“v=spf1 +all”
Rekord SPF dla domeny sparkpostmail.com (użyty mechanizm przekierowania)
“v=spf1 redirect=_spf.sparkpostmail.com”
Rekord SPF dla _spf.sparkpostmail.com (użyto mechanizmów exists i ptr):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
W SparkPost obecnie używamy mechanizmu ptr w naszym rekordzie SPF. Uznaliśmy to za konieczne z powodu braku powszechnego wsparcia dla walidacji mechanizmu exists. Do tej pory nie zauważyliśmy żadnych awarii SPF wynikających z używania mechanizmu ptr.
Oto kilka przykładowych rekordów i ich znaczenie. Ten przykład pokazuje adresy RFC 1918, ale zdaję sobie sprawę, że takie adresy nigdy nie pojawią się w prawdziwych rekordach SPF.
Rekord MX, jeden adres IP, jedna sieć IP, miękki brak sukcesu dla reszty:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Rekord A, dwie sieci IP, odrzucić resztę:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Nie wysyłamy żadnej poczty:
“v=spf1 -all”
Uważamy, że SPF jest głupie:
“v=spf1 +all”
Rekord SPF dla domeny sparkpostmail.com (użyty mechanizm przekierowania)
“v=spf1 redirect=_spf.sparkpostmail.com”
Rekord SPF dla _spf.sparkpostmail.com (użyto mechanizmów exists i ptr):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
W SparkPost obecnie używamy mechanizmu ptr w naszym rekordzie SPF. Uznaliśmy to za konieczne z powodu braku powszechnego wsparcia dla walidacji mechanizmu exists. Do tej pory nie zauważyliśmy żadnych awarii SPF wynikających z używania mechanizmu ptr.
Jak działa uwierzytelnianie SPF?
Oto jak wygląda typowa transakcja SMTP, gdy zaangażowane jest SPF:
Serwer wysyłający (klient) łączy się z serwerem odbierającym
Serwer odbierający notuje adres IP, z którego łączy się klient
Wymieniają się powitaniami, w tym nazwą hosta HELO klienta
Klient wydaje polecenie SMTP MAIL FROM
Serwer odbierający może teraz sprawdzić rekord SPF dla domeny MAIL FROM lub nazwy hosta HELO, aby ustalić, czy łączący się adres IP jest uprawniony do wysyłania poczty dla domeny i zdecydować, czy zaakceptować wiadomość.
Oto jak wygląda typowa transakcja SMTP, gdy zaangażowane jest SPF:
Serwer wysyłający (klient) łączy się z serwerem odbierającym
Serwer odbierający notuje adres IP, z którego łączy się klient
Wymieniają się powitaniami, w tym nazwą hosta HELO klienta
Klient wydaje polecenie SMTP MAIL FROM
Serwer odbierający może teraz sprawdzić rekord SPF dla domeny MAIL FROM lub nazwy hosta HELO, aby ustalić, czy łączący się adres IP jest uprawniony do wysyłania poczty dla domeny i zdecydować, czy zaakceptować wiadomość.
Oto jak wygląda typowa transakcja SMTP, gdy zaangażowane jest SPF:
Serwer wysyłający (klient) łączy się z serwerem odbierającym
Serwer odbierający notuje adres IP, z którego łączy się klient
Wymieniają się powitaniami, w tym nazwą hosta HELO klienta
Klient wydaje polecenie SMTP MAIL FROM
Serwer odbierający może teraz sprawdzić rekord SPF dla domeny MAIL FROM lub nazwy hosta HELO, aby ustalić, czy łączący się adres IP jest uprawniony do wysyłania poczty dla domeny i zdecydować, czy zaakceptować wiadomość.
MAIL FROM lub HELO – Które sprawdzić?
Specyfikacja SPF stanowi, że odbierające serwisy MUSZĄ sprawdzać SPF dla domeny MAIL FROM i ZALECA się jej sprawdzanie dla nazwy hosta HELO. W praktyce sprawdzanie odbywa się tylko na domenie MAIL FROM, chyba że w przypadkach, gdy adres MAIL FROM jest adresem nadawcy NULL (tj. "<>"), w takim przypadku jedyną dostępną tożsamością jest nazwa hosta HELO.
Specyfikacja SPF stanowi, że odbierające serwisy MUSZĄ sprawdzać SPF dla domeny MAIL FROM i ZALECA się jej sprawdzanie dla nazwy hosta HELO. W praktyce sprawdzanie odbywa się tylko na domenie MAIL FROM, chyba że w przypadkach, gdy adres MAIL FROM jest adresem nadawcy NULL (tj. "<>"), w takim przypadku jedyną dostępną tożsamością jest nazwa hosta HELO.
Specyfikacja SPF stanowi, że odbierające serwisy MUSZĄ sprawdzać SPF dla domeny MAIL FROM i ZALECA się jej sprawdzanie dla nazwy hosta HELO. W praktyce sprawdzanie odbywa się tylko na domenie MAIL FROM, chyba że w przypadkach, gdy adres MAIL FROM jest adresem nadawcy NULL (tj. "<>"), w takim przypadku jedyną dostępną tożsamością jest nazwa hosta HELO.
