J'ai une question rapide concernant les enregistrements SPF : doivent-ils être présents pour tous les sous-domaines ?
Disons que j'ai un enregistrement TXT avec des informations SPF pour domain.com
Disons également que j'ai un domaine de messagerie séparé pour subdomain.domain.com
Est-ce que la politique/info SPF pour domain.com s'applique également au sous-domaine ? Ou dois-je ajouter un enregistrement TXT séparé pour cela aussi ?
Vous devez avoir des enregistrements SPF distincts pour chaque sous-domaine à partir duquel vous souhaitez envoyer des emails.
Le texte suivant a été initialement publié sur openspf.org, qui était auparavant une excellente ressource pour ce type de choses.
Dernier lien http://www.open-spf.org/FAQ/The_demon_question/
La question du démon : que faire des sous-domaines ?
Si je reçois un email de pielovers.demon.co.uk, et qu'il n'y a pas de données SPF pour pielovers, devrais-je remonter d'un niveau et vérifier SPF pour demon.co.uk ? Non. Chaque sous-domaine chez Demon est un client différent, et chaque client peut avoir sa propre politique. Il n'aurait pas de sens que la politique de Demon s'applique par défaut à tous ses clients ; si Demon veut le faire, il peut mettre en place des enregistrements SPF pour chaque sous-domaine.
Donc, le conseil aux éditeurs SPF est le suivant : vous devriez ajouter un enregistrement SPF pour chaque sous-domaine ou nom d'hôte qui a un enregistrement A ou MX.
Les sites avec des enregistrements A ou MX génériques devraient également avoir un enregistrement SPF générique, de la forme : * IN TXT "v=spf1 -all"
Cela a du sens - un sous-domaine peut très bien se trouver dans un endroit géographique différent et avoir une définition SPF très différente.
La directive 'include:' pour SPF peut être utilisée pour fournir à tous les sous-domaines les mêmes entrées. Par exemple, sur l'enregistrement SPF pour le sous-domaine mailfrom.example.com, entrez 'include:example.com'. De cette manière, chaque fois que vous mettez à jour la définition pour example.com, vos sous-domaines récupéreront automatiquement les valeurs mises à jour.
Le lien vers openspf ne fonctionne pas pour le moment, mais heureusement l'archive internet nous sauve : web.archive.org/web/20190129091342/http://www.openspf.org/FAQ/…
Lien actuel vers la question du démon : open-spf.org/action_browse_diff_1_id_FAQ/The_demon_question
En plus des autres réponses, si un sous-domaine est créé en tant qu'enregistrement CNAME, l'enregistrement SPF est celui du domaine vers lequel il pointe, par exemple sous.domaine.com est un CNAME de autredomaine.com, le SPF qu'un serveur de messagerie obtiendra lorsqu'il recherchera mail@sous.domaine.com se trouve dans l'enregistrement DNS de autredomaine.com.
C'est la même chose en pratique si l'enregistrement CNAME dit sous.domaine.com => autressous.domaine.com, donc votre enregistrement TXT devrait être autressous, pas sous. C'est en contraste avec DKIM, qui nécessite un enregistrement TXT séparé pour la clé publique, même si votre sous-domaine est un CNAME.
Mais notez, comme indiqué dans la FAQ mentionnée dans la réponse acceptée, vous pouvez avoir des SPFs génériques pour un domaine pour les enregistrements A ou MX génériques. J'ai des domaines MX génériques, et cela fonctionne pour moi :
*.mondomaine.org. 3600 IN TXT "v=spf1 ip4:ADRESSEIP -all"avec ADRESSEIP remplacée par votre adresse IP/plage.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
3 votes
Notez que vous pouvez avoir des SPF génériques pour les sous-domaines : recherchez des caractères génériques ci-dessous.