Czy rekordy SPF dla domeny podstawowej mają zastosowanie do poddomen?


52

Mam szybkie pytanie dotyczące rekordów SPF: czy muszą być obecne we wszystkich poddomenach?

Powiedzmy, że mam rekord TXT z informacjami SPF dla domeny.com

Powiedzmy też, że mam oddzielną domenę e-mail dla subdomain.domain.com

Czy zasady / informacje SPF dla domain.com będą miały zastosowanie również do subdomeny? Czy też muszę do tego dodać osobny rekord TXT?


2
Pamiętaj, że możesz mieć SPF z symbolami zastępczymi dla poddomen: wyszukaj symbole wieloznaczne poniżej.
EML

Odpowiedzi:


59

Musisz mieć osobne rekordy SPF dla każdej subdomeny, z której chcesz wysłać pocztę. http://www.openspf.org/FAQ/The_demon_question

Pytanie Demona: A co z poddomenami?

Jeśli otrzymam pocztę od pielovers.demon.co.uk i nie ma danych SPF dla pielover, czy powinienem wrócić o jeden poziom i przetestować SPF dla demon.co.uk? Nie. Każda subdomena w Demon jest innym klientem i każdy klient może mieć własne zasady. Domyślnie polityka Demona nie miałaby zastosowania do wszystkich swoich klientów; jeśli Demon chce to zrobić, może skonfigurować rekordy SPF dla każdej subdomeny.

Tak więc rada dla wydawców SPF jest następująca: należy dodać rekord SPF dla każdej subdomeny lub nazwy hosta, która ma rekord A lub MX.

Witryny z symbolami wieloznacznymi A lub MX powinny również mieć symbol wieloznaczny SPF w postaci: * IN TXT „v = spf1 -all”

Ma to sens - subdomena może znajdować się w innym miejscu geograficznym, które będzie miało zupełnie inną definicję SPF.

Dyrektywę „include:” dla SPF można zastosować, aby zapewnić wszystkim subdomenom te same wpisy. Na przykład w rekordzie SPF dla subdomeny mailfr.example.com wpisz „include: example.com”. W ten sposób za każdym razem, gdy aktualizujesz definicję na przykład example.com, subdomeny automatycznie będą pobierać zaktualizowane wartości.


link do openspf nie działa dla mnie w bankomacie, ale na szczęście archiwum internetowe nas obejmuje: web.archive.org/web/20190129091342/http://www.openspf.org/FAQ/…
Legolas

18

Oprócz innych odpowiedzi, jeśli subdomena jest tworzona jako rekord CNAME, rekord SPF jest tym dla domeny, na którą wskazuje , np. sub.domain.comJest CNAME otherdomain.com, SPF, który otrzyma serwer poczty, gdy wyszukuje, mail@sub.domain.comznajduje się w DNS rekord dla otherdomain.com.

Tak samo jest w praktyce, jeśli rekord CNAME mówi sub.domain.com => othersub.domain.com, więc twój rekord TXT musiałby być inny sub, a nie sub. Jest to w przeciwieństwie do DKIM, który potrzebuje osobnego rekordu TXT dla klucza publicznego, nawet jeśli twoja subdomena to CNAME.


4

Należy jednak pamiętać, jak napisano w często zadawanych pytaniach, do których odnosi się zaakceptowana odpowiedź, że można mieć SPF z symbolami wieloznacznymi dla domeny dla rekordów A lub MX z symbolami wieloznacznymi. Mam wieloznaczne domeny MX i to działa dla mnie:

*.mydomain.org. 3600 IN  TXT  "v=spf1 ip4:IPADDR -all"

z IPADDR zastąpiony twoim adresem / zakresem IP.


3

Nie, ale można je zwierać za pomocą include:maindomain.invaliddyrektywy.


Czy możesz to rozwinąć? Jestem ciekawy ... Jak działałaby ta dyrektywa?
Mike B,

2
*.mydomain.org. 3600 IN  TXT  "v=spf1 ip4:IPADDR -all" 

jak napisano powyżej, nie działa, jeśli spamer używa subdomeny, która jest już w dDNS. Na przykład www.domain.com rekordy AA poprzedzają znak wieloznaczny w tym przypadku.


0

Należy pamiętać, że instrukcja include zawiera tylko rekordy A z określonej domeny, a nie subdomeny. Nie pobiera więc rekordów A z poddomen i dlatego działa tylko wtedy, gdy wszystkie poddomeny znajdują się na tym samym serwerze lub wysyłają z tego samego serwera.


Nie sądzę, że ta odpowiedź w ogóle dotyczy pytania (które dotyczy zapisów SPF TXT).
Felix Frank

Myślę, że ostrzeżenie w tej odpowiedzi dotyczyło przypadku, w którym 1) domena najwyższego poziomu określiła rekord SPF, w tym „a” 2) subdomena obejmowała domenę najwyższego poziomu SPF, oczekując, że pobierze dokładnie ten sam zestaw Adresy IP, ale faktycznie pobrano rekord subdomeny A.
AdamS
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.