Mails envoyés avec la fonction php mail() considérés comme SPAM

J'ai testé l'envoi des mail avec 1tester.com,tester.com, et il s'avère que le scoring "spam" est très mauvais (ce qui n'etait pas le cas avant).
Cela vient notamment du point suivant :
"Nous n'avons pas trouvé de serveur mail (MX Record) derrière votre nom de domaine 1out.cluster002.hosting.ovh.net.out.cluster002.hosting.ovh.net."
mail-tester me dit :
"Vous devriez publier une entrée DNS (de type MX) sur votre nom de domaine 1out.cluster002.hosting.ovh.netout.cluster002.hosting.ovh.net ou utiliser une adresse de rebond différente."

Mais je ne pense pas avoir la main la dessus ?

Je pense que cela vient de la migration de cluster faite par OVH :
http://travaux.ovh.net/?do=details&id=37604&PHPSESSID=0da75441571e22684d21963c001a9a20

Je ne vois pas quoi faire concrètement ??
Merci de votre aide

Bonjour,

J'aimerai avoir l'entête originale, pouvez-vous ouvrir un ticket ?

Avez-vous un spf sur votre zone dns : Received-SPF: None (mailfrom) .
https://docs.ovh.com/fr/domains/le-champ-spf/


Cordialement AntoineB1

Merci Antoine pour le réponse.
Quand je vérifie dans mon manager, j'ai bien le SPF suivant
SPF "v=spf1 include:mx.ovh.com ~all"

Que faut-il faire pour que le SPF soit pris en compte ? Je ne voudrais pas bidouiller la dendant sans être sûr.
(je t'envoie l'entête originale en MP).

SPF est périmé, faire un enregistrement **TXT**

Merci kyodev,
Suite à ton conseil j'ai ajouté un enregistrement TXT :

Le résultat est toujours le même :
- l'entête des mail envoyés contient toujours "Received-SPF: None "
- le scoring spam est le même

Faut il supprimer l'enregistrement de Type SPF ?
pour l'enregistrement TXT, j'ai laissé TTL par défaut (0) mais ce n'est peut être pas bon ?

Merci pour l'aide apportée

Faut il supprimer...: oui tu peux
TLL 0: c'est ok, similaire à TTL par défaut

pour le reste, tu pourrais peut-être communiquer le lien de l'analyse de mail tester?

Merci pour les infos.
Voici le lien de l'analyse par mail tester :

aie, ton TTL par défaut est très haut (86400), il serait mieux de définir ton TTL pour le TXT spf à 600 comme précédent, au moins le temps des tests

mais le plus gros souci est que le rebond de Ovh est mal configuré (tu n'y peux rien)
par contre tu devrais mettre une version texte de tes mails, juste du html c'est pas top

J'ai suivi ton conseil de mettre le TXT spf a 600

(mais je dois attendre jusqu'a 24h le temps de propagation).
Je vais ajouter un version texte.
Sinon le plus gros soucis est effectivement l'adresse de rebond OVH qui est mal configurée. Tu confirmes ce que je craignais, de ne pas avoir la main dessus.
J'espère vraiment qu'OVH va corriger rapidement ce problème car c'est extrèmenent pénalisant, les clients ne recoivent plus aucun mails!

24h sont passées (temps de propagation maximal indiqué dans le manager) et je n'ai toujours pas de SPF dans les entêtes des mails envoyé (toujours Received-SPF: None).
Le fait d'avoir défini un SPF de type TXT avec TTL de 600 n'a rien changé.

Sinon j'ai inclu une version texte des mails, ca fait toujours gagner un point dans le scoring, mais pas suffisant pour que les mails ne soient plus considérés comme spam.

J'ai ouvert un ticket pour le problème de l'adresse de rebond, et j'espère qu'OVH va pouvoir résoudre ça rapidement, car là ca devient critique.

Quelqu'un aurait une piste ?
Merci d'avance pour votre aide.

Bonjour,
juste pour signalé le même problème depuis la migration de datacenter. Pas de réponse à mon ticket.

@DimitriC3 / @DominiqueC5

Puis-je avoir les n° de tickets.

J'ai envoyé le N° de ticket en mp.

Bonjour,
J'ai le même problème depuis la migration de Paris à Gravelines.
Je vérifie le taux d’indésirabilité (spam) des messages envoyés par le serveur web avec https://www.mail-tester.comwww.1tester.comtester.com
L’objectif est de tendre vers le score de 10/10 pour que le message ne soit pas du tout considéré comme spam.

En principe, mes messages obtiennent une note entre 7/10 et 9/10, mais depuis la migration à Gravelines, mes messages obtiennent une note de 4,6 /10. Il semble que cela vienne d’une configuration différente du MX Record ou de l’adresse de rebond.
J’ai une pénalité de -3 points dans la section « Vous n’est pas parfaitement authentifié » que je n’avais pas quand le site était hébergé à Paris.
Le message d'erreur est :
> Nous n'avons pas trouvé de serveur mail (MX Record) derrière votre nom de domaine 1out.cluster006.hosting.ovh.net.out.cluster006.hosting.ovh.net. Vous devriez publier une entrée DNS (de type MX) sur votre nom de domaine 1out.cluster006.hosting.ovh.netout.cluster006.hosting.ovh.net ou utiliser une adresse de rebond différente.

La réponse d'OVH à mon ticket n°174538758 est :
> Votre demande concerne un outil externe à nos solutions. Je vous invite donc à contacter le support de cet outil à ce sujet ou à en consulter la documentation, afin d'obtenir plus d'informations sur les éléments remontés.
Cordialement,
—
Gildas L.
Technicien Support IT - Web

Tu signales une erreur de configuration qui n'existait pas avant et on t'envoie une réponse standardisée qui laisse penser que le technicien n'a soit rien compris ou soit s'en fout complètement.
Mon alerte visait à améliorer les services d'OVH, mais ça ne semble pas intéresser OVH. Dommage, et probablement tant mieux pour la concurrence !

Bonne journée,
Cyril

Bonjour,

J'ai exactement le même problème de mon côté ([TICKET#3844413149], "Nous n'avons pas trouvé de serveur mail (MX Record) derrière votre nom de domaine 1out.cluster014.hosting.ovh.net.out.cluster014.hosting.ovh.net.") et je n'ai aucune solution apportée par OVH alors que nous ne semblons pas avoir la main sur la configuration. La plupart de nos mails envoyés par php mail() tombent en SPAM alors qu'il n'y avait pas ce problème avant la migration.

Est ce qu'OVH a réussi à résoudre le problème de votre côté? Sinon, pour quelle solution avez-vous opté? Ce problème est très pénalisant.

Bonne journée.

Simon

1out.cluster014.hosting.ovh.netout.cluster014.hosting.ovh.net

Ca c'est bien::

root@v2:~# dig 1out.cluster014.hosting.ovh.netout.cluster014.hosting.ovh.net +short
87.98.143.107
root@v2:~# host 87.98.143.107
107.143.98.87.in-addr.arpa domain name pointer 1out.cluster014.hosting.ovh.net.out.cluster014.hosting.ovh.net.

Ca c'est bien aussi


root@v2:~# dig ovh.net mx +short
1 mx1.ovh.net.
5 mx2.ovh.net.

Depuis quand faudrait-il un MX pour 1out.cluster014.hosting.ovh.netout.cluster014.hosting.ovh.net ? Jamais.
Qui a fait ce bête diagnostic ?

Par contre les mails sortant d'OVH classés comme spam, c'est une plaie et je n'entrevois pas le bout du tunnel.
Sauf à donner une IP personnelle à chaque client, et à chacun de se bâtir sa réputation.
Ceci avait même fait l'objet d'un projet chez OVH à une certaine époque. Il s'est évaporé. Disparu. Fondu.

Comme indiqué dans un message précédent un MX pour 1out.cluster014.hosting.ovh.netout.cluster014.hosting.ovh.net est une recommandation de www.1tester.comtester.com
Certains clusters OVH ont un MX, exemple :
https://dnschecker.org/#MX/mail-out.cluster020.hosting.ovh.net
D'autres n'en n'ont pas, exemples :
https://dnschecker.org/#MX/mail-out.cluster006.hosting.ovh.net
https://dnschecker.org/#MX/mail-out.cluster014.hosting.ovh.net
Et dans la pratique, il apparait en effet que les que les e-mails envoyés avec la fonction mail() depuis un cluster sans MX sont plus souvent considérés comme spam.

Même problème ici, avec le cluster 1out.cluster011.hosting.ovh.net.out.cluster011.hosting.ovh.net.
On a aussi une pénalité de -3 points qui est apparue pendant nos tests (sur http://www.mail-tester.com www.1tester.comtester.com) et on ne va probablement pas pouvoir faire cet envoi dans les temps.
Quelqu'un aurait une nouvelle piste à ce sujet ?

si tu indiquais le lien du test mail-tester, certains pourraient analyser
là personne ne peut t'aider

L'erreur est exactement la même que celle rapportée par cyrcle ou SimonL8 par exemple, à savoir :
"Nous n'avons pas trouvé de serveur mail (MX Record) derrière votre nom de domaine 1out.cluster011.hosting.ovh.net.out.cluster011.hosting.ovh.net."

je n'ai pas vraiment l'habitude de me casser la tête avec ça. mais je dois être le seul à lire ton message ? :/

je fais l'hypothèse que tu veux faire un envoi de masse, des pistes:

* - changer d'hébergement chez ovh pour avoir un autres cluster (mais je ne sais pas si les nouveaux ont ce problème)
* - utiliser un smtp tiers, mais celui d'Ovh n'a pas que des avantages
* \+ utiliser un service tiers (genre sendingblue, mailjet, mailpoet) avec un smtp propre
* \+ utiliser un autre hébergeur (j'obtiens des scores parfaits, avec dkim)

```text

Depuis quand faudrait-il un MX pour mail-out.cluster014.hosting.ovh.net ?

car il y a cette adresse de rebond formée:

> Received-SPF: ...bounce-id=d353=u904520.cluster011.ovh.net=1576744736.73-jvylh@mail-out.cluster011.hosting.ovh.net

```text
dig +short mail-out.cluster011.hosting.ovh.net MX
<>
```
et donc mail-tester dit:

> Vous devriez publier une entrée DNS (de type MX) sur votre nom de domaine mail-out.cluster011.hosting.ovh.net ou utiliser une adresse de rebond différente.

ce que je ne sais pas c'est qui forme cette adresse bounce, Ovh ou PHPMailer 5.2.19 ?

analyse complète: http://www.mail-tester.com/test-tyuly ```

1out.cluster011.hosting.ovh.netout.cluster011.hosting.ovh.net

Bonjour,

Je ne suis pas trop d'accord avec toi.
Imagine que ton adresse est kyodev@1cola.com.cola.com. Si tu envoies ton mail et que le mail sort d'un server14.pool2.mail-out.1cola.comcola.com c'est parfaitement valide et ce serveur ne doit pas avoir de MX.

Dans l'exemple OVH ci-dessus on a bien la correspondance
1out.cluster011.hosting.ovh.netout.cluster011.hosting.ovh.net has address 5.135.58.85
85.58.135.5.in-addr.arpa domain name pointer 1out.cluster011.hosting.ovh.net.out.cluster011.hosting.ovh.net.

Je ne suis pas d'accord avec mail-tester non plus.

analyse complète: http://www.1tester.com/test-tyulytester.com/test-tyuly

Cette adresse bounce vient du php mail() où OVH a implémenté une sorte de gestion de file d'attente d'envoi.

Je suis épaté de voir un mail sortant du mutu avec un enregistrement DKIM.

je ne suis pas suffisamment expert pour trancher, j'essaye de comprendre les affirmations de mail-tester (un outil mailpoet)

(pour le dkim, je ne parlais pas de mutu Ovh)

Après réflexion, j'avais tort.

C'est OVH qui est dans l'erreur.

L'infâme moulinette d'OVH change l'adresse d'expéditeur que tu as spécifiée sur l'enveloppe SMTP par un truc qui ressemble à ceci:
_bounce-id=d353=u904520.cluster011.ovh.net=1576744736.73-jvylh@mail-out.cluster011.hosting.ovh.net_
et effectivement 1out.cluster011.hosting.ovh.netout.cluster011.hosting.ovh.net qui est le domaine d'expéditeur devrait posséder un MX.

@AlexL @Maxime.R une petite remontée vers les admins, svp ?
(et vérifier tous les clusters par la même occasion.)

je fais l'hypothèse que tu veux faire un envoi de masse

Bonjour, non je ne fais pas d'envoi de masse, il s'agit de mails de confirmation de commande.

mails de confirmation de commande

Pour des mails transactionnels (confirmation de commande, réinitialisation de mot de passe, etc) c'est vraiment galère car

* le canal de sortie d'OVH n'est vraiment pas fiable en raison de sa réputation de plus en plus médiocre
* divers blocages non documentés et non constants des hébergements web en sortie sur 465/tcp ou 587/tcp empêchent d'utiliser valablement des opérateurs SMTP tiers pour la soumission de mails.

Du coup je n'ai pas de conseils à donner si ce n'est de chercher une autre crèmerie, sauf si @AlexL @Maxime.R pouvaient donner leur avis qui serait bienvenu ici.

Cela va bientôt faire un an que le problème a été signalé (plusieurs tickets ont été ouverts par plusieurs utilisateurs), et nous en sommes toujours au même point !!!!

J'ai reçu une réponse (plutôt encourageante) du support qui me dit que
l'IP du serveur 1out.cluster002.hosting.ovh.netout.cluster002.hosting.ovh.net est désormais propre et bien opérationnelle.

J'ai aussitôt fait un nouveau test avec Mail tester et là surprise , le problème reste le même ("Vous devriez publier une entrée DNS (de type MX) sur votre nom de domaine 1out.cluster002.hosting.ovh.netout.cluster002.hosting.ovh.net ou utiliser une adresse de rebond différente"), et le scoring spam est le même qu'avant.

Je rapporte cette info au support qui me répond "Le serveur 1out.cluster002.hosting.ovh.netout.cluster002.hosting.ovh.net n'aura pas de MX, c'est un serveur d'envoi (mail-out).
C'est l'hébergement qui génère l'envoi et passe par les mail-out associés."

Qu'en pensez vous ?

Je réagis un peu tard, je ne suis pas expert du sujet, mais tout ce que j'en pense c'est qu'OVH a la faculté de se moquer de plus en plus de ses clients, remettant systématiquement la faute sur les solutions externes utilisées sans jamais remettre en cause sa propre solution pour l'adapter (qui plus est lorsque nous n'avons pas la main sur la configuration de cette solution et qu'elle a manifestement été modifiée suite à une migration que nous n'avons pas choisi).

Plus d'un an après avoir signalé le problème, OVH a beau le réfuter, le résultat reste le même : les mails de confirmation de commande tombent la majorité du temps en SPAM et nous payons pour un service qui s'est dégradé suite à une migration et qu'ils refusent de paramétrer comme avant.

Je désespère d'avoir un jour une configuration similaire à celle d'avant migration ou une solution apportée par OVH et envisage donc de changer d'hébergeur pour mes hébergements et ndd, malgré tout le travail de migration que cela engendre. La qualité de service semble avoir définitivement disparu chez OVH, plutôt que de résoudre les problèmes techniques propre à la configuration de leurs outils et sur lesquels ils sont les seuls à avoir la main, ils se réfugient derrière un bouclier de termes techniques pour se dédouaner de toute responsabilité et réfuter toute erreur. Chers admins, si nous payons un hébergement mutualisé et des solutions "clefs en main", c'est justement pour déléguer cette partie dont nous ne voulons / pouvons pas nous charger, tout ce que nous demandons en temps que client est d'avoir un système fonctionnel et capable d'envoyer des mails qui n'arrivent pas plus de 50% du temps en spam. Ce problème de MX record a été remonté sur différents fils, depuis plusieurs années, ne semble présent que sur certains clusters mais n'a pourtant pas été résolu. Attendez-vous de vos futurs clients qu'ils paient leur hébergement comme il paie un ticket de loterie, espérant tomber sur le bon cluster avec MX record pour pouvoir envoyer un mail automatique via phpmail (solution très démocratisée) sans que celui-ci tombe en spam?

@Maxime.R peut-on espérer voir OVH enfin bouger et avancer sur ce problème un jour ou a-t-il été définitivement abandonné?

> les mails de confirmation de commande tombent la majorité du temps en SPAM

sur le fond tu as raison, sur la forme, utilise de fournisseur par si enjeux
si tu veux persister chez Ovh, prends un smtp tiers chez mailjet ou confrères