Bonjour,
J'ai un serveur mutualisé Pro chez OVH et j'utilise la fonction mail php pour envoyer notamment les mail de validation de compte sur notre site web.
En vérifiant sur https://www.mail-tester.com/ l'envoi d'un email simple le score anti-spam est de 5/10, ce qui ne permet pas de garantir l'envoi de mail pour tous les utilisateurs.
Ce faible score n'est ni dû à un blacklistage, ni au contenu (texte simple, sans lien et image).
Mail-tester indique que le principal problème vient d'une authentification incorrecte.
L'hébergement utilise les réglages DNS par défaut établit par ovh :
3 champs MX pour les serveurs mails (mx1.mail.ovh.net, mx2...)
1 champ SPF v=spf1 include:mx.ovh.com ~all
Mail-tester indique les problèmes suivants :
* Sender Policy Framework (SPF) is an email validation system designed to prevent email spam by detecting email spoofing, a common vulnerability, by verifying sender IP addresses.
* We check if there is a mail server (MX Record) behind your domain name mail-out.cluster027.hosting.ovh.net.
* We check if there is a server (A Record) behind your hostname 2.mo152.mail-out.ovh.net.
* DomainKeys Identified Mail (DKIM) is a method for associating a domain name to an email message, thereby allowing a person, role, or organization to claim some responsibility for the message.
* A DMARC policy allows a sender to indicate that their emails are protected by SPF and/or DKIM, and give instruction if neither of those authentication methods passes. Please be sure you have a DKIM and SPF set before using DMARC.
Questions :
1- Comment améliorer la configuration DNS pour faire disparaitre ces messages ?
2- Un hébergement mutualise utilise t-il toujours le même serveur d'envoi (mail-out.cluster027.hosting.ovh.net) ?
Merci pour votre aide, qui je pense pourra être utile à tous les utilisateurs de serveurs mutualisés chez OVH !
Manuel
E-mails et solutions Office - Améliorer le score anti-spam avec mail() php ?
Related questions
- Compte bloqué pour Spam, impossible de le débloquer
123549 
03.01.2024 08:02
- Changer le mot de passe email depuis roundcube
120912 24.06.2017 14:28
- Email frauduleux au nom de OVH
120764 13.08.2017 18:14
- Autodiscover et Microsoft Outlook 2016
96754 23.11.2016 15:15
- Question sur antispam OVH
94726 17.03.2017 16:11
- OVH sur un iPhone "Échec de l'envoi de l'e-mail : l'adresse de l’expéditeur est incorre
93458 07.08.2017 08:45
- Arrêt de la commercialisation du MX plan
89020 30.11.2017 11:26
- Mail non délivrés ou en spam chez nos clients
84914 15.11.2017 10:30
- Envois de mails / erreur 521
81659 05.04.2017 11:42
- Comment configurer une entrée DNS de type DKIM chez OVH ?
81574 12.03.2019 17:41
La réponse est en plusieurs points.
1) Les mails sortants d'OVH prennent tous des routes différentes, depuis des IP différentes dans des subnets différents.
2) OVH ne signe pas ses mails sortants avec DKIM et ne laisse pas ses clients signer avec DKIM (quand on met DKIM en place, il faut publier la clé publique dans la zone DNS du domaine qui va signer DKIM). C'est le serveur mail de sortie qui insère la signature DKIM. Mais pas chez OVH.
3) Si pas de DKIM alors il ne faut pas même pas penser à DMARC. DMARC ne fonctionne réellement bien que lorsque SPF et DKIM sont tous les deux implémentés de façon irréprochable.
Les mails de sortie mail() php portent une adresse d'expéditeur (sur l'enveloppe SMTP) de OVH et non de ton domaine.
Salut à tous,
On doit en conclure qu'il n'y a rien faire de plus au niveau des dns ?
Et partir du principe que les mails envoyé depuis ovh.net sont considéré comme sûr par les serveurs qui reçoivent les mails ?
Merci.
a+
@Fritz2cat : merci pour votre réponse !
Donc on est condamné à plafonner à un score de 5/10 car finalement il n y aurait aucune possibilité d'améliorer l'authentification ?
Mail-tester me suggère ces modifications :
* Pour le champ SPF v=spf1 **a mx** include:mx.ovh.com ~all
Je suis pas sur de comprendre les implications de cette modification.
* D'ajouter un champ MX avec 1out.cluster027.hosting.ovh.netout.cluster027.hosting.ovh.net
Mais visiblement on pourrait très bien avoir un autre serveur d'envoi non ?
Merci !
```text > 1 champ SPF v=spf1 include:mx.ovh.com ~all
SPF est déprécié/périmé/pas utilisé
pour cela que mail-tester de parle de spf, une entrée TXT dans la zone:
```text
600 IN TXT "v=spf1 include:mx.ovh.com ~all"
``` ```
@kyodev : j'ai ajouté le champ TXT pour remplacer le SPF mais aucune amélioration dans mail-tester.
Toujours 5/10. Enfin même 4.8 !
Le rapport est consultable ici : https://www.1tester.com/mootools-TRWYtester.com/mootools-TRWY
Le point le plus bloquant (-3 dans le score anti-spam) est :
Nous n'avons pas trouvé de serveur mail (MX Record) derrière votre nom de domaine 1out.cluster027.hosting.ovh.net.out.cluster027.hosting.ovh.net.
Gloups!
En effet, OVH avec son architecture trop compliquée a oublié de respecter les bases du fonctionnement du mail.
L'enveloppe SMTP contient une adresse qui se termine par @1out.cluster027.hosting.ovh.netout.cluster027.hosting.ovh.net
Un petit test:
> root@v2:~# dig 1out.cluster027.hosting.ovh.netout.cluster027.hosting.ovh.net mx +short
> root@v2:~# dig 1out.cluster027.hosting.ovh.netout.cluster027.hosting.ovh.net +short
> 54.36.151.98
donc: pas de MX, et une adresse A qui n'est pas celle du serveur qui envoie.
Si (avec un de mes serveurs) je reçois un mail avec une adresse d'expéditeur (sur l'enveloppe, SMTP.MailFROM) contenant un domaine qui n'a pas de MX, c'est quasiment légitime de le refuser durant la transaction.
Ce qui sauve OVH c'est qu'il y a quand même un enregistrement de type A, et que les systèmes mail utilisent le 'A' si le 'MX' fait défaut.
Mais ça fait tache et ce n'est pas pro. Et l'IP ne correspond pas.
@Fritz2cat : Merci pour ces précisions.
Je découvre tout ça, n'étant pas spécialiste du toute de l'infrastructure réseau.
Ce que je comprends, c'est que côté utilisateur, on a pas vraiment de possibilité pour améliorer ce score et que le système mail d'OVH, c'est OVH--
Quel pourrait être une solution de contournement ?
OVH Email Pro ? Une solution externe d'envoi de mail ?
Merci !
Une solution externe qui offre des services sur des ports non standard (donc autres que 25, 465, 587) me semble un meilleur choix.
Perso je n'ai plus confiance dans le mutualisé car dans le passé les règles ont souvent changé sans avertissement, souvent en réaction épidermique à un abus/hack/campagne de spam, et alors par exemple on ne peut plus utiliser le port 587 du jour au lendemain, sauf une exception française (Mailjet pour ne pas le citer) et les autres peuvent s'asseoir et pleurer.
Faire un serveur (un VPS le plus petit modèle) à usage privatif et IP privative pour l'envoi du mail mais pas de réception, ce n'est pas si difficile que ça à construire, dommage que OVH ne propose pas une config prête à l'emploi. Il y a un marché qui n'attendrait que ça.
Merci pour votre aide:-)