Paramétrer Mailrelay Business MX bloque souvent sur les mêmes points. Les identifiants, le port SMTP (protocole d’envoi d’e-mails) et les réglages DNS (adresses techniques du domaine) créent vite de la confusion. Pas de panique, c’est plus simple qu’il n’y paraît.
Les données disponibles permettent d’avancer avec une méthode claire. Cet article s’appuie sur 4 sources utiles, la documentation technique SEA-WEST, les repères Microsoft 365, des retours OVH et des paramètres SMTP concrets partagés par Orange. Le tableau ci-dessous donne une vue rapide avant le détail.
| Méthode | Usage principal | Réglage clé | Coût ou accès |
|---|---|---|---|
| Mailrelay via Plesk | Relayer les mails du serveur | smtp.unyc.io, port 25, sans authentification | Selon l’offre fournisseur |
| Application métier | Rappels, alertes, notifications | Serveur, port et compte expéditeur corrects | Variable selon l’outil |
| Appareil multifonction | Scan vers e-mail | Tester 25, 465 ou 587 selon le service | Selon le fournisseur SMTP |
| Test telnet ou openssl | Vérifier la connexion SMTP | Contrôler bannière, port et chiffrement | Gratuit |
| DNS du domaine | Améliorer la délivrabilité | SPF, DKIM, DMARC cohérents | Gratuit |
🔍 À RETENIR
✅ RÉGLAGES DE BASE À VÉRIFIER
-
→
Serveur SMTP : pour la configuration SEA-WEST sur Plesk, la valeur indiquée est smtp.unyc.io avec l’IP 79.99.166.227. -
→
Port utilisé : le relais fonctionne sur le port 25, sans authentification SMTP dans ce cas précis. -
→
Adresse d’envoi : il faut privilégier une adresse liée au domaine propre. Les adresses génériques seront bloquées chez SEA-WEST dès le 01/12/2024. -
→
Limites techniques : 1500 mails par heure par IP, 20 sessions simultanées et 30 Mo par e-mail au maximum.
🌐 RESSOURCES UTILES
🌐 PLESK
L’accès se fait en général via https://votre-serveur:8443. Le chemin donné par SEA-WEST passe par Outils & Paramètres puis Paramètres du serveur de messagerie.
🌐 DNS SPF
Le SPF conseillé dans ce contexte est v=spf1 include:_spf.unyc.io ~all. Il aide les serveurs de réception à reconnaître les envois autorisés.
🌐 SUPPORT
Si les tests restent négatifs, le support SEA-WEST peut être contacté à [email protected]. La documentation OVH peut aussi aider en cas de configuration mixte.
⚠️ POINT À SURVEILLER AVANT TOUT TEST
Les erreurs viennent souvent d’un mélange entre mauvais identifiants, mauvais port et domaine mal autorisé. Il faut donc vérifier ces trois points avant de modifier des réglages plus avancés.
Les informations à réunir avant de paramétrer Mailrelay Business MX
Mailrelay Business MX demande d’abord quelques données simples. Il faut réunir le nom du serveur, le port, le mode d’accès et l’adresse d’envoi autorisée. Cette vérification évite une grande partie des échecs de connexion, surtout les erreurs 535 et les refus de relais.
Le rôle d’un relais SMTP reste assez simple. Il reçoit l’e-mail sortant puis le remet au serveur du destinataire. Ce mécanisme suit le protocole SMTP, créé en 1982, et sert à livrer les messages de manière plus fiable.
Serveur SMTP, identifiants, ports et mode d’authentification
Le premier point consiste à savoir si le relais demande une authentification SMTP. Dans le cas documenté par SEA-WEST pour Plesk, le serveur est smtp.unyc.io et le port utilisé est 25, sans authentification.
Ce cas ne vaut pas pour tous les fournisseurs. Microsoft 365 distingue par exemple la soumission SMTP authentifiée, le relais SMTP et l’envoi direct. Les paramètres changent selon la méthode retenue. Pour aller plus loin, il faut comparer la documentation exacte du service utilisé.
Domaine d’envoi, adresse expéditrice et limites du service
Le domaine d’envoi doit rester cohérent avec le relais utilisé. SEA-WEST précise qu’à partir du 01/12/2024, les adresses génériques comme @orange.fr ou @wanadoo.fr seront bloquées pour ces envois.
Il faut aussi vérifier les limites du service avant de lancer des tests. Les valeurs annoncées sont 1500 mails par heure par IP, 20 sessions simultanées et 30 Mo par message. Pour aller plus loin, il faut lister ces limites avant toute mise en production.
Comment obtenir les identifiants SMTP pour Mailrelay Business MX ?
La recherche des identifiants crée souvent le plus de confusion. Certains relais demandent un compte complet, avec adresse e-mail et mot de passe. D’autres, comme le cas smtp.unyc.io sur Plesk, fonctionnent sans authentification SMTP.
Les retours d’utilisateurs montrent bien ce blocage. Sur le forum Dolibarr, un utilisateur écrit « Pour l’ID SMTP et le mot de passe SMTP, je ne sais pas quoi mettre ». Le même fil mentionne aussi l’erreur 535 5.7.1 Authentication failed.
La bonne méthode consiste à partir de la documentation du fournisseur, pas d’un essai au hasard. Si la notice parle de relais sans authentification, aucun identifiant ne doit être saisi. Si elle parle de soumission SMTP authentifiée, il faut saisir l’adresse complète de la boîte et son mot de passe.
Le cas Orange illustre cette différence. Les paramètres partagés sur le forum indiquent smtp.orange.fr, le port 465, la sécurité SSL et l’identifiant sous forme d’adresse complète. Pour aller plus loin, il faut vérifier si le service attendu relève d’un relais ou d’un envoi client authentifié.
Préparer le domaine et les enregistrements DNS nécessaires
Le DNS influence directement la réception des messages. Si les enregistrements sont incohérents, les mails peuvent partir mais finir en spam. Pas de panique, cette étape repose sur quelques lignes techniques faciles à contrôler une par une.
Les recommandations restent constantes chez plusieurs acteurs. IONOS, Mailjet et SEA-WEST insistent sur SPF et DKIM. Microsoft précise aussi que certains modes d’envoi ne contournent pas l’anti-spam. Pour aller plus loin, il faut vérifier le domaine avant de tester l’application.
Faut-il ajouter un enregistrement MX spécifique pour Mailrelay ?
Le relais SMTP ne demande pas toujours un nouvel enregistrement MX. Le MX sert surtout à recevoir les e-mails d’un domaine. Pour un serveur de sortie, la priorité porte souvent sur le serveur SMTP déclaré dans l’application ou dans Plesk.
Il faut donc lire la notice du fournisseur. Dans les données SEA-WEST disponibles, la consigne porte sur le relais SMTP et le SPF. Aucun ajout d’un MX dédié à Mailrelay Business MX n’est indiqué dans ce cas. Pour aller plus loin, il faut distinguer réception du courrier et envoi du courrier.
Comment configurer SPF, DKIM et DMARC pour améliorer la délivrabilité ?
Le SPF indique quels serveurs peuvent envoyer pour le domaine. SEA-WEST recommande la valeur v=spf1 include:_spf.unyc.io ~all. Cette ligne aide les serveurs distants à reconnaître les expéditeurs autorisés.
Le DKIM (signature cryptée du message) ajoute une preuve technique d’origine. Le DMARC définit la règle à suivre si SPF ou DKIM échoue. Les données disponibles ne donnent pas une valeur unique pour tous les cas, car chaque domaine a sa propre configuration. Pour aller plus loin, il faut contrôler SPF, puis activer DKIM, puis poser un DMARC simple.
Quel port utiliser pour envoyer des mails via Mailrelay Business MX ?
Le port choisi décide souvent du succès de la connexion. Un mauvais numéro bloque l’envoi même si le serveur est correct. Les ports 25, 465 et 587 reviennent le plus souvent dans les documentations et les retours de forums.
Les données fournies montrent trois usages distincts. SEA-WEST documente le port 25 sans authentification pour son relais. Orange recommande le port 465 avec SSL. Un échange OVH mentionne aussi le port 587 dans un cas de copieur multifonction. Pour aller plus loin, il faut relier le port au mode d’envoi réel.
Quand choisir le port 25, 465 ou 587
Le port 25 sert encore à certains relais serveur à serveur. C’est le cas de smtp.unyc.io chez SEA-WEST. Cette configuration convient surtout au relais configuré sur un serveur ou un panneau d’administration comme Plesk.
Le port 465 sert plutôt aux clients ou appareils qui envoient avec chiffrement SSL. Orange partage ce réglage avec smtp.orange.fr et authentification. Le port 587 apparaît souvent pour la soumission authentifiée. Pour aller plus loin, il faut choisir le port indiqué par le fournisseur, pas le plus courant.
Quel niveau de chiffrement TLS ou SSL activer
Le chiffrement protège la connexion entre l’appareil et le serveur SMTP. Si le fournisseur demande SSL, il faut l’activer. Si le fournisseur demande TLS (chiffrement transport), il faut choisir cette option dans l’application.
Dans le cas SEA-WEST documenté ici, le relais Plesk fonctionne sans authentification sur le port 25. Dans le cas Orange, le forum indique SSL sur le port 465. Pour aller plus loin, il faut aligner port, chiffrement et méthode d’authentification dans le même réglage.
Comment paramétrer Mailrelay Business MX sur Plesk
Plesk permet de centraliser les envois du serveur. Cette méthode convient bien pour un site, une application interne ou plusieurs boîtes du même hébergement. Le chemin documenté reste simple et évite des réglages dispersés dans chaque outil.
L’accès à Plesk se fait en général via https://votre-serveur:8443. Il faut ensuite ouvrir Outils & Paramètres puis Paramètres du serveur de messagerie. SEA-WEST donne ce parcours et le serveur de relais attendu. Pour aller plus loin, il faut préparer le domaine avant de valider Plesk.
Activer le relais SMTP dans les paramètres du serveur mail
Dans la section Relais SMTP, il faut activer l’option dédiée. Cette action dit à Plesk d’utiliser un serveur de sortie externe pour les messages du serveur. Le réglage ne demande pas d’outil supplémentaire.
Cette étape convient si le serveur local ne doit pas envoyer seul vers Internet. Microsoft rappelle d’ailleurs que plusieurs applications et appareils ne savent pas envoyer seuls. Ils ont besoin d’un serveur relais. Pour aller plus loin, il faut noter l’état exact de chaque case cochée dans Plesk.
Renseigner le smarthost, le port et l’authentification
Le smarthost (serveur relais externe) à saisir dans le cas fourni est smtp.unyc.io. Le port à saisir est 25. Il faut laisser l’option d’authentification SMTP désactivée pour cette configuration précise.
Après enregistrement, un test d’envoi doit partir depuis le serveur ou depuis un site hébergé. Si le message échoue, il faut d’abord vérifier SPF, le pare-feu et l’adresse expéditrice utilisée. Pour aller plus loin, il faut conserver une capture des réglages validés.
Configurer l’envoi depuis une application métier ou un appareil multifonction
Une application métier ou un copieur ne sait pas toujours envoyer des e-mails seul. Microsoft cite des scanners réseau et des outils de rendez-vous comme cas fréquents. Il faut donc leur fournir un serveur SMTP, un port et parfois un compte d’accès.
Le réglage de base reste toujours le même. Il faut saisir le nom du serveur, le port, le chiffrement et l’adresse d’expédition. Ensuite, il faut lancer un test vers une boîte interne puis vers une boîte externe. Pour aller plus loin, il faut tester avec un message très simple, sans pièce jointe.
Les retours d’expérience montrent des situations mixtes. Un membre de la communauté Orange indique avoir utilisé son propre SMTP avec tests en port 25, puis en 465 avec SSL et TLS. Un autre partage les paramètres concrets de smtp.orange.fr en 465/SSL.
Cette variété montre une règle simple. Il faut suivre les paramètres du serveur choisi, pas ceux d’un autre fournisseur. Une configuration OVH ne se copie pas sur Orange, ni l’inverse. Pour aller plus loin, il faut vérifier quel service envoie réellement le message final.
Comment tester la connexion SMTP avec telnet ou openssl ?
Tester la connexion SMTP permet de savoir vite si le problème vient du réseau ou des identifiants. C’est une étape utile avant de modifier l’application. Pas de panique, le but consiste seulement à voir si le serveur répond sur le bon port.
Avec telnet, le test porte surtout sur le port 25 ou 587. Avec openssl, le test convient mieux à une connexion chiffrée, par exemple en 465. Si la connexion s’ouvre, le serveur renvoie en général une bannière SMTP. Pour aller plus loin, il faut noter le message exact reçu.
Si aucune réponse n’arrive, le blocage vient souvent du pare-feu, du port fermé ou d’une translation NAT (redirection réseau) incorrecte. Si la réponse apparaît mais refuse l’envoi, la cause se trouve plus souvent dans les identifiants, l’adresse expéditrice ou le domaine. Pour aller plus loin, il faut tester d’abord depuis le serveur lui-même.
Résoudre les erreurs courantes de configuration Mailrelay Business MX
Les erreurs courantes suivent quelques modèles bien connus. Le plus fréquent reste l’échec d’authentification. Les blocages réseau et les soucis DNS arrivent juste après. Une vérification ordonnée évite de changer plusieurs paramètres en même temps.
Les avis d’utilisateurs confirment ce schéma. Sur Dolibarr, un message cite « 535 5.7.1 Authentication failed » puis « Invalid Authentication Credentials ». Cette remontée montre qu’une erreur très précise peut avoir plusieurs causes. Pour aller plus loin, il faut isoler chaque piste une par une.
Résoudre les erreurs d’authentification 535 et 534
L’erreur 535 indique souvent un identifiant ou un mot de passe erroné. Elle apparaît aussi si le service utilisé ne demande en réalité aucune authentification, mais que des identifiants ont été saisis malgré tout.
Il faut donc vérifier trois points. Le premier est la méthode d’envoi attendue. Le deuxième est la forme exacte de l’identifiant, parfois une adresse e-mail complète. Le troisième est l’état de l’option d’authentification. Pour aller plus loin, il faut refaire un test après une seule correction.
Vérifier les ports, le pare-feu et la translation NAT
Un pare-feu local ou réseau peut bloquer le port de sortie. Une box ou un routeur peut aussi perturber la translation NAT. Dans ce cas, le serveur SMTP reste correct mais la session ne démarre jamais.
Le bon réflexe consiste à tester le port depuis la machine qui envoie. Il faut aussi comparer le port saisi à la documentation du service. Les exemples disponibles citent 25, 465 et 587. Pour aller plus loin, il faut vérifier si un fournisseur d’accès filtre encore le port 25.
Corriger les problèmes liés aux enregistrements MX, SPF ou à la délivrabilité
Si les mails partent mais arrivent en spam, le problème touche souvent le domaine. Il faut d’abord vérifier le SPF. Ensuite, il faut contrôler DKIM et DMARC. Les documents techniques cités recommandent ce trio pour améliorer la délivrabilité.
Il faut aussi éviter les adresses génériques quand le relais les refuse. SEA-WEST annonce un blocage des adresses comme @orange.fr à partir du 01/12/2024. Pour aller plus loin, il faut utiliser une adresse du domaine propre et vérifier sa réputation d’envoi.
Que faire si mes mails sont marqués comme spam après envoi via Mailrelay ?
Le spam ne signifie pas toujours que le serveur est mal réglé. Le message peut partir correctement mais présenter des signaux faibles. Les filtres regardent le domaine, le contenu, l’alignement SPF/DKIM et parfois le volume d’envoi.
Microsoft rappelle que le relais SMTP et l’envoi direct ne contournent pas l’anti-spam. Les e-mails suspects peuvent donc être filtrés. La recommandation donnée consiste à utiliser un enregistrement SPF correct. Pour aller plus loin, il faut tester avec un message court et neutre.
Il faut aussi contrôler l’adresse expéditrice. Une adresse liée au domaine inspire plus de cohérence qu’une adresse tierce. C’est encore plus vrai avec la règle SEA-WEST sur les adresses génériques. Enfin, il faut surveiller le volume envoyé, surtout si plusieurs outils partagent la même IP.
Les forums montrent que l’entraide reste utile quand les logs restent flous. La documentation OVH et le support [email protected] peuvent servir de point d’appui. Pour aller plus loin, il faut conserver les messages d’erreur complets et les en-têtes des e-mails testés.
Mailrelay Business MX se règle plus facilement quand trois points sont fixés dès le départ, la méthode d’envoi, le bon port et le domaine autorisé. Les données montrent aussi qu’un SPF cohérent et une adresse expéditrice liée au domaine réduisent les blocages. Si un doute persiste, un test SMTP simple et la documentation du fournisseur permettent souvent d’éviter des heures de réglages inutiles.
