Os registros SPF para domínio primário se aplicam a subdomínios?

52

Tenho uma pergunta rápida sobre os registros SPF: eles precisam estar presentes para todos os subdomínios?

Digamos que eu tenho um registro TXT com informações de SPF para domain.com

Digamos também que eu tenho um domínio de email separado para subdomínio.domínio.com

A política / informações do SPF para domain.com também se aplica ao subdomínio? Ou preciso adicionar um registro TXT separado para isso também?

Mike B
fonte
2
Observe que você pode ter SPFs curinga para subdomínios: pesquise curingas abaixo.
EML

Respostas:

59

Você precisa ter registros SPF separados para cada subdomínio do qual deseja enviar email. http://www.openspf.org/FAQ/The_demon_question

A questão do demônio: E os subdomínios?

Se eu receber mensagens de pielovers.demon.co.uk e não houver dados SPF para pielovers, devo voltar um nível e testar o SPF para demon.co.uk? Não. Cada subdomínio da Demon é um cliente diferente e cada cliente pode ter sua própria política. Não faria sentido que a política da Demon se aplicasse a todos os seus clientes por padrão; se o Demon quiser fazer isso, poderá configurar registros SPF para cada subdomínio.

Portanto, o conselho para os editores do SPF é este: você deve adicionar um registro SPF para cada subdomínio ou nome de host que possua um registro A ou MX.

Sites com registros curinga A ou MX também devem ter um registro SPF curinga, no formato: * IN TXT "v = spf1 -all"

Isso faz sentido - um subdomínio pode muito bem estar em um local geográfico diferente, que terá uma definição de SPF muito diferente.

A diretiva 'include:' para SPF pode ser usada para fornecer todos os subdomínios com as mesmas entradas. Por exemplo, no registro SPF para o subdomínio mailfrom.example.com, digite 'include: example.com'. Dessa forma, sempre que você atualizar a definição para example.com, seus subdomínios automaticamente capturam os valores atualizados.

Tim Brigham
fonte
O link para o openspf não funciona para mim, mas felizmente o arquivo da Internet nos cobriu: web.archive.org/web/20190129091342/http://www.openspf.org/FAQ/…
Legolas
18

Além das outras respostas, se um subdomínio for criado como um registro CNAME, o registro SPF será o do domínio para o qual ele aponta , por exemplo, sub.domain.comé um CNAME de otherdomain.com, o SPF que um servidor de correio obterá quando procurar [email protected]estiver no DNS gravar para otherdomain.com.

Isso é o mesmo na prática se o registro CNAME indicar sub.domínio.com => outrosub.domínio.com, portanto, seu registro TXT precisaria ser outros, não sub. Isso contrasta com o DKIM, que precisa de um registro TXT separado para a chave pública, mesmo que seu subdomínio seja um CNAME.

Sam_Butler
fonte
4

Mas observe, como diz a FAQ mencionada na resposta aceita, que você pode ter SPFs curinga para um domínio para registros A ou MX curinga. Eu tenho domínios MX curinga e isso funciona para mim:

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

com o IPADDR substituído pelo seu endereço IP / intervalo.

EML
fonte
3

Não, mas você pode causar um curto-circuito com a include:maindomain.invaliddiretiva.

mailq
fonte
Você pode elaborar sobre isso? Estou curioso ... Como essa diretiva funcionaria?
Mike B
2
*.mydomain.org. 3600 IN  TXT  "v=spf1 ip4:IPADDR -all" 

conforme escrito acima não funcionará se o remetente de spam usar um subdomínio que já esteja no dDNS. Por exemplo, www.domain.com registros AA prevê o curinga nesse caso.

user1659733
fonte
0

Esteja ciente de que a instrução include inclui apenas registros A do domínio especificado e também não os subdomínios. Portanto, ele não obtém registros A dos subdomínios e, portanto, funciona apenas quando todos os subdomínios estão no mesmo servidor ou são enviados do mesmo servidor.

Jeff
fonte
Acho que essa resposta não se refere à pergunta (que diz respeito aos registros SPF, por exemplo TXT)?
Felix Frank
Acho que o aviso nesta resposta foi sobre o caso em que 1) o domínio de nível superior especificou um registro SPF incluindo 'a' 2) o subdomínio incluiu o SPF do domínio de nível superior, esperando obter exatamente o mesmo conjunto de Endereços IP, mas na verdade pegou o registro de subdomínio A.
Adams