Bonjour,
J'ai une question concernant la résolution de l'enregistrement SPF de mon nom de domaine sur offre gold. Je cherche à savoir pourquoi les ptr vers les MX d'OVH sous-jacents ne sont pas résolus
Voici un extrait de l'enregistrement de la zone principale :
IN NS ns11.ovh.net.
IN NS dns11.ovh.net.
IN MX 100 mx3.mail.ovh.net.
IN MX 200 mx4.mail.ovh.net.
IN MX 1 mx0.mail.ovh.net.
IN MX 50 mx2.mail.ovh.net.
IN MX 5 mx1.mail.ovh.net.
600 IN TXT "v=spf1 mx include:mx.ovh.com ~all"
Sur dmarcadvisor, je demande une analyse poussée sur la santé de mon enregistrement SPF (caractérisé par la dernière ligne ci-dessus), mais le résultat produit 2 alertes sur des ptr dadditionnels vers des domaines internes à OVH qui semblent liés à mon instruction include:mx.ovh.com :
4 100% domain.tld 0 / 7 netblocks authenticate 0 emails using domain.tld 0 / 7 netblocks authenticate 0 emails using 0 other domains
v=spf1 mx include:mx.ovh.com ~all
1 71.4% +mx:domain.tld:178.32.124.207/32 no domain.tld volume
+mx:domain.tld:178.33.252.245/32 no domain.tld volume
+mx:domain.tld:188.165.36.237/32 no domain.tld volume
+mx:domain.tld:87.98.160.167/32 no domain.tld volume
+mx:domain.tld:91.121.53.175/32 no domain.tld volume
3 28.6% +include:mx.ovh.com 0 / 2 netblocks authenticate 0 emails using domain.tld 0 / 2 netblocks authenticate 0 emails using 0 other domains
v=spf1 ptr:mail-out.ovh.net ptr:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all
1 +ptr:mail-out.ovh.net
WARNING The ptr mechanism ptr:mail-out.ovh.net should not be used and cannot be resolved using this diagnostic tool.
1 +ptr:mail.ovh.net
WARNING The ptr mechanism ptr:mail.ovh.net should not be used and cannot be resolved using this diagnostic tool.
14.3% +ip4:8.33.137.105/32 no domain.tld volume
14.3% +ip4:192.99.77.81/32 no domain.tld volume
?all
~all
Le problème quand j'enlève l'instruction, ces ptr sont tout de même fournis de force.
Donc sur mon SPF dans le cadre de mon utilisation des MX OVH et où les ptr sous-jacents à mon enregistrement SPF ne sont pas résolvables, sont-ils indispensables ?
Si oui, y-a-t'il moyen de dégager leur présence dans l'analyse ?
Merci par avance de vos lanternes éclairées.
Si oui, y-a-t'il moyen de dégager leur présence dans l'analyse ?
Bonjour, le mot 'mx' est superflu et indésirable dans votre SPF. Tout comme la clause 'a' que OVH semble avoir mise chez certains.
Pour la bonne raison (mx) que les MX qui reçoivent les mails n'en envoient pas, et (a) que les serveurs web n'envoient pas de mails depuis leurs IP.
Ces mots superflus provoquent des query DNS indésirables chez tous ceux qui reçoivent vos mails.
Cela avec la phrase include:mx.ovh.com alors que ça n'a rien à voir avec des mx,
ovh.com par-ci, ovh.net par là, tout ça fait preuve d'un grand amateurisme et d'une absence de cohérence et de contrôle qualité avant de prodder des choses qui vont rester à vie et traîner comme des boulets.
Dans la même veine, pourquoi ssl0.ovh.net ? et pas mail.ovh.net ?
Pourquoi avoir rendu encore plus compliqué ce qui n'est déjà pas simple ?
Bonsoir Fritz2cat,
Merci pour cette réponse enflamée et passionnée !
Je partage d'ailleurs tout à fait ton point de vue, et je retrouve les mêmes travers chez beaucoup de fournisseurs connus.
Disons, qu'avoir un peu de désorganisation et du désurbanisme IT dans une grosse boite, alors OK c'est pas génial, mais ça arrive à peu près tout le temps.
Mais, quand ça se voit côté client final c'est pas joli joli.
Pour en revenir au sujet d'origine, j'ai effectivement laissé l'instruction mx inutile dans mon cas… = > update effectué
Pour ce qui est de la pollution sur la résolution de noms de domaine des relais OVH… on va devoir faire avec, si je comprend bien.
J'ai beau essayé moulte formes d'écriture d'instruction(s) include, mais rien ne me permet de faire du « propre ».
Tant pis, ça consommera un peu plus en coût d'interrogation du SPF que si j'avais géré moi-même les services de messagerie…