¿Los registros SPF para el dominio primario se aplican a los subdominios?

Tengo una pregunta rápida con respecto a los registros SPF: ¿deben estar presentes para todos los subdominios?

Digamos que tengo un registro TXT con información SPF para domain.com

Digamos también que tengo un dominio de correo electrónico separado para subdominio.domain.com

¿La política / información de SPF para domain.com también se aplicará al subdominio? ¿O necesito agregar un registro TXT separado para eso también?

Debe tener registros SPF separados para cada subdominio desde el que desea enviar el correo. http://www.openspf.org/FAQ/The_demon_question

La pregunta del demonio: ¿Qué pasa con los subdominios?

Si recibo correo de pielovers.demon.co.uk, y no hay datos de SPF para pielovers, ¿debo retroceder un nivel y probar SPF para demon.co.uk? No. Cada subdominio en Demon es un cliente diferente, y cada cliente puede tener su propia política. No tendría sentido que la política de Demon se aplicara a todos sus clientes por defecto; Si Demon quiere hacer eso, puede configurar registros SPF para cada subdominio.

Por lo tanto, el consejo para los editores SPF es este: debe agregar un registro SPF para cada subdominio o nombre de host que tenga un registro A o MX.

Los sitios con registros comodín A o MX también deben tener un registro comodín SPF, de la forma: * IN TXT "v = spf1 -all"

Esto tiene sentido: un subdominio bien puede estar en una ubicación geográfica diferente que tendrá una definición SPF muy diferente.

La directiva 'include:' para SPF se puede usar para proporcionar todos los subdominios con las mismas entradas. Por ejemplo, en el registro SPF para el subdominio mailfrom.example.com ingrese 'include: example.com'. De esta manera, cada vez que actualice la definición de example.com, sus subdominios recogerán automáticamente los valores actualizados.

Además de las otras respuestas, si se crea un subdominio como un registro CNAME, el registro SPF es el que corresponde al dominio al que apunta , por ejemplo, sub.domain.comes un CNAME de otherdomain.com, el SPF que obtendrá un servidor de correo cuando busque [email protected]en el DNS grabar para otherdomain.com.

Esto es lo mismo en la práctica si el registro CNAME dice sub.domain.com => othersub.domain.com, por lo que su registro TXT debería ser othersub, no sub. Esto está en contraste con DKIM, que necesita un registro TXT separado para la clave pública, incluso si su subdominio es un CNAME.

Pero tenga en cuenta, como dice en las preguntas frecuentes a las que se hace referencia en la respuesta aceptada, que puede tener SPF comodín para un dominio para registros comodín A o MX. Tengo dominios MX comodín, y esto funciona para mí:

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

con IPADDR reemplazado con su dirección IP / rango.

No, pero puedes cortocircuitarlos con la include:maindomain.invaliddirectiva.

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

como se escribió anteriormente no funciona si el spammer usa un subdominio que ya está en dDNS. Por ejemplo, www.domain.com los registros AA prevén el comodín en ese caso.

Tenga en cuenta que la declaración de inclusión solo incluye registros A del dominio especificado y tampoco subdominios. Por lo tanto, no recoge registros A de subdominios y, por lo tanto, solo funciona cuando todos los subdominios están en el mismo servidor o se envían desde el mismo servidor.