Ovh Web Plesk n'a pas SSL sur les boites emails, SOLUTION ici

Bonjour @EmmanuelP5,

Je vous remercie pour cette remontée complète et détaillée et je vous prie de bien vouloir m'excuser pour le délai de retour.

Je tiens à vous confirmer que le support est formé pour vous guider sur l'utilisation de Plesk néanmoins ces derniers n'ont en effet aucun accès à votre panel pour les raisons évoquées, et ne peuvent donc pas intervenir sur votre service.
Ils disposent toutefois d'un Plesk de test afin de vous guider dans la navigation.

Cependant, nos administrateurs disposent quant à eux des accès en tant qu'infogérants du service et peuvent effectuer des vérifications.

Plesk supporte en effet la gestion des SSL pour l'accès au webmail, et le flag présent sur votre screenshot indique bien que votre SSL est valide pour les domaines suivants:

webmail.domain.tld
www.domain.tld
domain.tld

Si le champ DNS webmail.domain.tld pointe sur votre serveur Hosting-Reseller, vous aurez donc accès au webmail de votre choix en https, avec le certificat associé à votre domaine.
Il n'est par contre pas valable pour le serveur de mail smtps/pop3s/imaps dans le sens où il s'agit uniquement d'un SSL pour le webmail.

Notre recommandation est donc d'utiliser le domaine de votre service : hrxxxx.reseller.mis.ovh.net comme host sur vos configurations de messagerie autre que webmail.

En effet, le serveur mail ne permettant pas de gérer plusieurs certificats SSL (SNI), un seul certificat peut être proposé.

Ceci est une restiction imposée par Plesk, mais vous pouvez leur remonter le besoin via le lien suivant :

https://plesk.uservoice.com/forums/184549-feature-suggestions/suggestions/32081650-assign-separate-ssl-certificates-for-multiple-mail

Ces derniers proposent actuellement une solution de contournement en commandant un certificat SAN auprès de l'autorité de votre choix :

https://support.plesk.com/hc/en-us/articles/115001446174-How-to-assign-separate-SSL-certificates-for-different-domains-on-a-local-mail-server-in-Plesk

Il faut toutefois savoir que le coût d'un tel certificat est relativement élevé.

Nous pouvons, là aussi sur demande, modifier le SSL associé au panel et / ou au serveur de mail.
Notre support prendra en charge votre demande si vous lui fournissez le nom de votre certificat et le domaine associé.

Cela vous permettrait de faire marque blanche avec le service, mais vous devrez fournir dans le champ Host de votre messagerie un domaine qui peut être différent du domaine de la boite mail de votre client final.

Cordialement,
Ghislain G.

Plesk supporte en effet la gestion des SSL pour l'accès au webmail, et le flag présent sur votre screenshot indique bien que votre SSL est valide pour les domaines suivants:

httpS://webmail.domaine.fr fonctionne très bien et n'est pas en rapport avec ce ticket et cette capture d'écran n'a rien avoir avec httpS://webmail.domaine.fr

La capture d'écran ci dessous, c'est le message d'erreur dans Outlook qu'il est impossible de faire disparaitre parce que domaine.fr expédie avec hrxxxx.reseller.mis.ovh.net qui utilise un certificat SSL différent.
Les dernières mises à jour de OUTLOOK n'autorise plus dans le paramétrage manuel de changer le nom du Smtp. Il est donc imposé mail.domaine.fr et impossible d'utiliser hrxxxx.reseller.mis.ovh.net
Il n'y a plus d'alternative de contournement, Il est devenu impossible de se débarrasser de ce message d'erreur en capture d'écran, avoir Plesk veut dire ne pas pouvoir utiliser Outlook, c'est pas n'importe quoi ça ?

Et les clients sont comme toujours pris en otage, **Ovh n'est plus une petite entreprise, elle doit réagir auprès de ces partenaires comme Plesk.**


Le problème est indiqué en rouge dans la capture d'écran, avec Outlook ou d'autres applis et logiciels de messagerie il n'est pas possible d'utiliser :
mail.domaine.fr pour le Smtp, pop, Imap parce que le certificat SSL de hrxxxx.reseller.mis.ovh.net (Smtp expéditeur) est différent de mail.domaine.fr (le compte email)
Et Outlook ne permet plus de changer le nom du serveur Smtp...donc impossible de suprimer cette erreur dans la capture d'écran.

En effet, le serveur mail ne permettant pas de gérer plusieurs certificats SSL (SNI), un seul certificat peut être proposé.

Je suis bien obligé de vous dire, oui probablement, et c'est aussi en rapport avec http://www.postfix.org/TLS_README.html">Postfix

**MAIS**

En effet, le serveur mail ne permettant pas de gérer plusieurs certificats SSL (SNI), un seul certificat peut être proposé.
Ceci est une restiction imposée par Plesk, **mais vous pouvez leur remonter le besoin** via le lien suivant :

Allons bon ! et on doit aussi le dire à nos clients de laisser un message sur le support de Plesk.
J'ai un client que j'ai fais partir de chez Gsuite (Gmail), j'ai tout fait pour le faire passer chez Ovh avec Plesk, maintenant quand il ouvre Outlook il a un message d'erreur, et bien sur le client final qui n'est pas "technique" il se plaint ou ? a votre avis ?
Est ce que j'ai commis une erreur en le faisant venir chez Ovh ?

**Permettez moi de vous rappellez (Ovh et pas seulement GhislainG)) que vous vendez ça :**


Il y a quand même un "hic" dans la pratique et l'utilisation, surtout si vos clients doivent formuler une demande tout seul auprès de Plesk en cas de problème majeur. (pas de Outlook avec cette offre)

OVH est maintenant le 1er hébergeur en Europe, vos demandes auprès de Plesk n'auront pas le même impact que vos clients, ET ce n'est pas au client d'améliorer les offres Ovh auprès du support de Plesk mais à Ovh de le faire. Cette culture d'entreprise n'est bonne pour personne et tire tout le monde vers le bas...

Si OVH tape du poing sur la table contre Plesk, nous (clients Ovh) osons encore croire que vous pouvez faire bouger les choses et certainement pas vos clients individuellement.

C'est à OVH de résoudre ce problème, pas aux clients...

Voici ce que Plesk répond aux clients Ovh


Ce problème est identifié chez Plesk et planifié pour être implémenté mais n'est pas dans les taches prioritaires.
Une exigence de Ovh très appuyé par les administrateurs peut peser dans la balance pour que Plesk fasse ce changement.
En quelque sorte tout cela dépend de Ovh comme je l'affirmais dès le départ...

En effet, le serveur mail ne permettant pas de gérer plusieurs certificats SSL (SNI), un seul certificat peut être proposé.

Concrètement, que compte faire OVH ?
1- Attendre que les clients Ovh fasse des doléances tout seul directement chez Plesk ?
2- Ou **faire réellement pression sur Plesk** ?

Bonjour,
Une remontée a été faite auprès des administrateurs afin de contacter Plesk à ce sujet.
Toutefois, vous pouvez également leur faire la remontée en tant qu'utilisateur.
Cordialement,
Ghislain G.

Toutefois, vous pouvez également leur faire la remontée en tant qu'utilisateur.

Arf, relisez mon post précédent à ce sujet ;-)

La fonctionnalité de multi SSL sur le serveur de mail n'est pas disponible, ce n'est pas une question de pression ou d'accord.

Actuellement la version de postfix (serveur de mail utilisé par plesk par défaut) ne commence à supporter le SNI que depuis la version 3.4 (avril 2018), hors cette version n'est pas encore disponible dans les distributions linux supportées par Plesk.

Par exemple debian 9 https://packages.debian.org/stretch/postfix https://packages.debian.org/stretch/postfix
On est en version 3.1.8, même sid ne propose que la version 3.3.
Sur CentOS 7 on est en version 2.10 pour postfix.

Tant que le serveur de mail ne supporte pas cette fonction, Plesk ne peut pas développer de solution pour le faire, mais peut déjà planifier de l'implémenter.

Le support du SNI est "récent", et les logiciels clients (outlook, thunderbird, mail, ...) ne le supportent pas forcement.

Tous ses elements font que cela ne sera pas disponible avant longtemps et n'est pas dépendant de la volonté des acteurs que vous citer.
La bonne pratique actuelle est donc d'utiliser un nom de serveur unique en tant que serveur de mail.

Si vous voulez simplifier la configuration des boites mails pour vos clients, il vous est possible de créer des champs SRV et autodiscover dans votre zone DNS.

Ceci est une restiction imposée par Plesk, mais vous pouvez leur remonter le besoin via le lien https://plesk.uservoice.com/forums/184549-feature-suggestions/suggestions/32081650-assign-separate-ssl-certificates-for-multiple-mail">suivant :

Bonjour,
Une remontée a été faite auprès des administrateurs afin de contacter Plesk à ce sujet.
Toutefois, vous pouvez également leur faire la remontée en tant qu'utilisateur.
Cordialement,

La fonctionnalité de multi SSL sur le serveur de mail n'est pas disponible, ce n'est pas une question de pression ou d'accord.

C'est @GhislainG qui avait proposé que les clients OVH doivent faire des demandes individuellement, ce qui m'a laisser exposer que c'est OVH qui doit faire cela pas les clients.

Mais au final ces demandes ne serviront à rien -:) puisque le problème vient de Postfix. Je suis d'accord avec @QuentinG j'ai lu http://www.postfix.org/TLS_README.html">la documentation
> To receive DANE secured mail for multiple domains, use the same hostname to add the server to each domain's MX records. There are no plans to implement SNI in the Postfix SMTP server.

En fait nous sommes bloqués à cause de la magie de l'Open Source avec Postfix et Linux ?
On doit attendre que les contributeurs de Postfix et Linux bossent gratuitement pour effectuer des innovations et mettre en place le SNI afin que Plesk puisse l'intégrer gratuitement pour pouvoir le revendre dans une solution globale qu'on appelle Plesk que OVH va ensuite revendre...
**C'est magique l'Open Source !** et très lucratif mais seulement pour certains...

Bref... Malgré cela, je tiens à vous remercier @QuentinG pour cette réponse qui relève le débat et en plus propose une solution avec les champs SRV et autodiscover dans la zone DNS.

Je suis bien sur ouvert à toutes les solutions (même si je râle beaucoup :-) )
Pourriez vous s'il plait indiquer d'une façon plus précise la procédure pour utiliser ce champ SRV ? avec clairement ce qu'il faut ajouter dans les champs.
OVH ou @GhislainG pourrait intervenir dans ce fil de discutions.... et donner ces réponses.


**Sachant que la configuration avec Plesk n'est pas :**
IP = ip de clientdomaine.fr
HELO (serveur) = hrxxxxxxxxx.reseller.mis.ovh.net
rDNS = clientdomaine.fr
Config qui donne un reverse faux et corrigé depuis https://community.ovhcloud.com/community/fr/ovh-web-plesk-est-mal-configure-c-est-impossible-d-envoyer-des-emails-chez?id=community_question&sys_id=5fdee5c058da42d02d4c51cec5fc96b8">ce post

**Mais avec cette configuration sur Plesk**
IP = ip de clientdomaine.fr
HELO (serveur) = clientdomaine.fr
rDNS = clientdomaine.fr
Le HELO (serveur) est identique à rDNS pour une meilleure délivrabilité des emails.

Idem pour ajouter le champ autodiscover dans la zone DNS, champs TXT ou pas ?

Ces réponses seront très utile pour ceux qui utilise l'Offre Reseller Plesk Ovh qui pourrons d'une façon simple et précise utiliser cette éventuelle solution parce que pour le moment les réponses à ce sujet dans https://www.google.com/search?q=plesk+onyx+add+srv.">Google ne sont pas d'une grande utilité en fonction des champs à remplir ci dessus

Merci d'avance

Bonjour,

Je vous ai en effet proposé de contacter Plesk à ce sujet en parallèle afin de multiplier les requêtes mais cela s'avère au final inutile comme vous l'avez souligné suite au retour de QuentinG.

Afin de prendre en charge votre demande et vous guider dans la configuration, pourriez-vous ouvrir un échange par ticket depuis votre espace client (section Assistance), puis me communiquer le numéro s'il vous plaît ?

Cordialement,
GhislainG

@GhislainG **ce n'est pas MA demande**, ma démarche dans ce fil de discution n'est pas de résoudre uniquement mon propre cas. Sinon effectivement, je sais parfaitement que je peux ouvrir un ticket au support.

100% de vos clients pour cette offre ont besoin d'obtenir ces informations qu'on ne peut trouver nul part.

C'est totalement contre productif de me proposer de ne les donner qu'a moi.
SVP communiquez ces informations ici s'il vous plait, pour que toute monde puisse en profiter...

En retour vous pourriez directement insérer les réponses dans cette image ci dessous sans oublier de répondre à propos du champ autodiscover dans la zone DNS.



Merci pour votre partage.

Bonjour,
Un modification de la configuration par défaut va être apportée ainsi qu'une mise à jour de notre documentation à ce sujet.
Ce forum étant un espace public, je ne procéderai pas à la configuration de votre service par ce biais, et vous invite à créer un ticket comme demandé s'il vous plaît.
Cordialement,
Ghislain G.

Ce forum étant un espace public, je ne procéderai pas à la configuration de votre service par ce biais, et vous invite à créer un ticket comme demandé s'il vous plaît.

Tous ceux qui ont besoin de configurer le champs SRV en ayant l'offre Plesk Reseller devront formuler une demande au support alors qu'ils auraient pu trouver la réponse ici, c'est justement le but d'un espace public.
Ce champs SRV ne sera pas vraiment différent d'un client à l'autre, dommage...

Un modification de la configuration par défaut va être apportée ainsi qu'une mise à jour de notre documentation à ce sujet.

Ravis de voir que le temps et l'énergie passé ici, peut donner parfois un résultat positif.
Car il est exact que les champs SRV et le champ autodiscover auraient du être dans la config DNS par défaut depuis longtemps...

Il semble que le problème soit plus complexe que je ne le pensais, tous les clients mails n’implémentent pas le même mode d'auto configuration.

Dans ton cas, le srv devrait te simplifier le travail, mais cela n'est pas vrai sur la configuration par défaut en hrxxx.reseller.mis.ovh.net.

Dans ta zone DNS du domaine de ton client "mondomaine.tld" tu peux ajouter, où domain.fr est le domaine associé au CommonName du SSL.
_imap.tcp IN SRV 0 1 143 domain.fr.
_imaps.tcp IN SRV 0 1 993 domain.fr.
_pop3.tcp IN SRV 0 1 110 domain.fr.
_pop3s.tcp IN SRV 0 1 995 domain.fr.
_submission.tcp IN SRV 0 1 587 domain.fr.
_smtps.tcp IN SRV 0 1 465 domain.fr.

Modifier le MX également :
IN MX 10 domain.fr.

J'ai testé sous outlook, l'auto-configuration prend bien domain.fr et comme le SSL correspond : pas d'avertissement.
J'ai pas encore d'auto configuration pour thunderbird, gmail(android), et mail (ios).

Dans ton cas, le srv devrait te simplifier le travail, mais cela n'est pas vrai sur la configuration par défaut en hrxxx.reseller.mis.ovh.net.

L'utilisation de hrxxx.reseller.mis.ovh.net. par défaut n'est pas franchement la meilleure sur le serveur...(sur Outlook c'est une autre histoire)
Si un client se fait blacklister avec hrxxx.reseller.mis.ovh.net. il va blacklister TOUT le serveur et les autres clients.
Chaque nom de domaine doit avoir son IP dédié (très facile à obtenir quasi gratuitement) pour pouvoir faire cette config sur le serveur :
IP = ip de clientdomaine.fr
HELO (serveur) = clientdomaine.fr
rDNS = clientdomaine.fr

Un autre sujet traite de https://community.ovh.com/t/ovh-web-plesk-est-mal-configure-cest-impossible-d-envoyer-des-emails-chez-gmail/ ce problème ICI

Tu devrais bien y réfléchir et ne plus utiliser la configuration du serveur avec hrxxx.reseller.mis.ovh.net.

J'ai testé sous outlook, l'auto-configuration prend bien domain.fr et comme le SSL correspond : pas d'avertissement.

Tu peux m'en dire plus sur ce point Stp, parce que le SSL ne peut pas correspondre.
Actuellement avec le Smtp il n'y a pas de SSL pour chaque nom de domaine. Le seul SSL valide est celui de hrxxx.reseller.mis.ovh.net.
Si dans Outlook tu utilise pour le smtp : domaine.fr et pas hrxxx.reseller.mis.ovh.net. Outlook va t'afficher un panneau au démarrage et t'indiquer que le SSL n'est pas valide.

Un très bon outil pour tester le SSL et Smtp TLS d'une adresse email : https://www.checktls.com/TestReceiver CheckTLS.com

Je viens d'avoir une conversation téléphonique très constructive avec un administrateur Plesk de chez Ovh.

Même si le problème vient de Postfix et Plesk et pas forcement de Ovh, les administrateurs Ovh recherchent une solution pour contourner le problème.

Je tenais à le dire, contrairement à ce que je pouvais croire, les administrateurs Ovh sont impliqués dans leurs tâches. Ils sont peut être trop discret et ne le font pas savoir :-)

Gros encouragement à vous et dans vos recherches et merci.

Bonjour, où en sommes nous actuellement à la date du 25 janvier 2019 ?

merci.

cdt,
J.ROTSAERT

Ce problème extrêmement bloquant pour la bonne dérivabilité des emails n'est pas prêt de se résoudre !

Le SSL SNI de Plesk fonctionne sous la dépendance Open Source de http://www.postfix.org/ POSTFIX
Tant que les développeurs de POSTFIX n'auront pas travaillé gratuitement pour intégrer cette fonctionnalité SSL SNI, Plesk ne pourra proposer cette fonctionnalité SSL.

C'est la magie de l'open source !
Plesk assemble de l'open source obtenu gratuitement pour le revendre à ses clients et n'a ensuite aucun pouvoir pour faire évoluer son offre et par conséquent OVH aussi ;-)

Pour confirmation vous pouvez lire ça directement https://support.plesk.com/hc/en-us/articles/115001446174-How-to-assign-separate-SSL-certificates-for-different-domains-on-a-local-mail-server-in-Plesk chez Plesk

@GhislainG @QuentinG
Est-ce que OVH envisage de fournir la même offre avec https://documentation.cpanel.net/display/68Docs/SSL+FAQ+and+Troubleshooting#SSLFAQandTroubleshooting-WhatisSNIsupport? Cpanel qui n'a pas ce problème de SSL SNI ?
Étant donné que ce problème avec Plesk ne sera surement pas solutionné en 2019, une alternative serait la bien venu en étant infogéré comme cette offre Plesk.

> la dépendance Open Source de POSTFIX
Tant que les développeurs de POSTFIX n'auront pas travaillé gratuitement...

je note la méconnaissance totale du principe, en quoi openSource signifie que le dev doit être bénévole?

tu fais partie des *gens*, nombreux, qui font cet amalgame (sûrement pour dénigrer alors que eux se pensent rassuré de payer pour des logiciels obscurs)

les projets openSource n'existeraient pas sans le financement (on parle de millions de dollars/projet) d'entreprises privées
tu as besoin d'une fonctionnalité? tu payes pour la faire développer sur Postfix, **si tu veux**, sinon tu attends... c'est assez logique

si tu veux te plaindre, fais le chez Plesk qui aujourd'hui abuse selon toi
jusqu'alors tu devait te targuer d'utiliser cette solution obscure qui pouvait flatter ton ego?
tu payes, donc c'est top, c'est fiable?

si tu n'avais pas fais confiance les yeux fermés à une solution propriétaire, tu aurais une solution, possiblement full openSource
si ce panel n'étais pas fermé, peut-être aurais tu pu toi-même intéger un autre MTA... mais voilà, c'est fermé, tu ne peux pas, tu n'as pas le droit
ne te trompe pas sur la cause de tes ennuis

openSource signifie liberté, bien souvent, rien n'oblige personne à utiliser...
sauf Plesk, fermé, propriétaire et payant :o/
crois tu que tout doit passer par Plesk pour utiliser un serveur?

@kyodev Félicitations on avance bien sur la problématique de ce sujet, ton intervention va aider les autres à comprendre pourquoi ils ont ce problème de bonne dérivabilité des emails avec Plesk !

Je n'ai JAMAIS dit que les dev de Postfix ou que les autres Dev Open source doivent travailler gratuitement ! (justement le contraire, tu n'as rien compris et tu écris trop vite...)

J'ai dis que Plesk n'a aucune intention de contribuer ou de payer les Dev de Postfix pour obtenir la fonctionnalité SSL SNI pour résoudre ce problème, et que c'est ça la magie de l'Open Source !
Plesk prend des choses gratuitement sans y contribuer ou payer, pour ensuite les revendre à ses clients.

C'est pour cette raison qu'il va falloir attendre jusqu'en 2020 ou plus pour que Plesk propose la fonctionnalité SSL SNI, parce que Plesk veut continuer d'utiliser Postfix gratuitement sans y contribuer...
Ce qui rend l'utilisation de Plesk impossible pour une bonne dérivabilité des emails.

Et pour ton information bien sur que j'ai échangé à plusieurs reprises en direct avec Plesk, https://plesk.uservoice.com/forums/184549-feature-suggestions/suggestions/32081650-assign-separate-ssl-certificates-for-multiple-mail et je ne suis pas le seul, des centaines de personnes sont dans le même cas sur cette problématique.

Et pour répondre à ta question : crois tu que tout doit passer par Plesk pour utiliser un serveur?
Si certain utilise des solutions infogéré par OVH comme Plesk c'est surement pour de bonnes raisons,
et pas forcement par méconnaissance mais justement le contraire...
Si tu veux t'amuser à démontrer qu'il est préférable et beaucoup plus facile d'utiliser Debian ou CentOs directement en SSH en ligne de commande pour créer des adresses emails ou gérer un hébergement, n'hésite pas à ouvrir un nouveau sujet et à faire des tutoriels ;-)

Tant que les développeurs de POSTFIX n'auront pas travaillé gratuitement pour intégrer cette fonctionnalité ...

biensûr je ne sais pas lire...
tellement simple de critiquer !

si tu ne sais pas, paye un professionnel

> Si tu veux t'amuser à démontrer qu'il est préférable

en quoi un panneau d'administration peut remplacer un système?
surtout que ton Plesk peut tourner sur Debian :o)

mais as tu testé d'autres panneaux?

> n'hésite pas à

les clients qui piétinent car ils ont payés, je fais tout pour les éviter et ne pas leur rendre service

quant à vouloir me donner des leçons sur mes contributions et mes partages, tu me fais rire d'avance

> et je ne suis pas le seul

et bien, réunissez vous, et financez un développement, c'est comme cela que fonctionnent *le libre*, que tu confonds avec openSource

@kyodev Je te trouve marrant :-)
bonne journée

Pour ceux qui suivent ce problème de SLL SNI de PLESK (@QuentinG), l'équipe PLESK semble maintenant à l'écoute de ce problème, c'est le bon moment d'intervenir https://support.plesk.com/hc/en-us/articles/115001446174?page=1#comment_360001655933 sur le fil chez Plesk Support.

Petit résumé du problème SSL SNI
Chaque nom de domaine doit avoir son IP dédié (très facile à obtenir quasi gratuitement) pour pouvoir faire cette config sur le serveur :
IP = ip de clientdomaine.fr
HELO (serveur) = clientdomaine.fr
rDNS = clientdomaine.fr

MAIS il n'est pas possible d'utiliser le SSL SNI pour chaque nom de domaine, donc le smtp utilisé pour expédier sera toujours le nom du serveur, ce qui donne une configuration fausse pour une bonne délivabilité des emails.

Ovh a toujours refusé d'intervenir officiellement sur le https://support.plesk.com/hc/en-us/articles/115001446174-How-to-secure-a-Plesk-mail-server-with-different-SSL-certificates-SNI-support-">fil de discussion chez Plesk pour résoudre ce problème.

Après plus d'un an d'attente, c'est confirmé, Plesk à décidé de ne pas solutionner le problème sur la version Plesk Onyx utilisé par OVH

bonjour,
Est ce que vous avez trouver une solution pour ce problème ? J'ai le même soucis. Nous avons pris un plesk chez ovh et malheureusement nous ne pouvons pas gérer nos mails via plesk car nos mails sont soit mis en spam soit refusés.
Après quelques recherches et quelques tests sur 1tester.com,tester.com, mon soucis viendrait du reverse DNS qui ne correspond pas à mon domaine d'envoi.

Bonjour @ tous,

Pour tout ceux qui ciblent un 10/10 sur www.1tester.comtester.com avec ces histoires de @#% rDNS, voila comment je m'en suis sortit:

Affecter une IP unique par domaine et modifier le rDNS par IP
----------------------------------------------------------------------------------
https://docs.ovh.com/gb/en/plesk/decouvrir-utiliser-plesk/#failover-ipv4-management_1
Hé voui... impossible de commander des IP sup avec le seul service de type web plesk...
J'ai commandé un VPS de base rikiki (~30€/an) qui m'a permis dans l'ovh manager, onglet serveur, section IP d'en commander 4 (~8€).
Déplacer ces IP du service VPS sur le service Plesk (VPSxxxx ->HR-xxxx).
Toujours sur cet écran, par IP, vous pouvez indiquer un reverse!, indiquer pour chaque le domaine client (n'oubliez pas le . final)
Sur votre plesk, affecter ces IP unique par domaine client en fonction des reverse que vous avez définit.
Modifier vos DNS client pour pointer sur ces nouvelles IP et non plus l'IP shared de base du plesk.
Et hop, un test d'envoi sur www.1tester.comtester.com indique bien:
IP = ip clientdomaine
HELO = clientdomaine
rDNS = clientdomaine
Ô joie.