
Relais SMTP Synology MailPlus : Correction des e-mails rejetés grâce à la fonction de renvoi
15 min de lecture
- Afficher en Markdown Ouvrir cette page en Markdown simple (ouvre dans un nouvel onglet)
- Ouvrir dans ChatGPT Posez des questions à propos de cette page (ouvre dans un nouvel onglet)
- Ouvert à Claude Posez des questions à propos de cette page (ouvre dans un nouvel onglet)
- Ouvrir dans Google AI Studio Posez des questions concernant cette page (compte Google requis) (ouvre dans un nouvel onglet)
Un relais SMTP est un second serveur de messagerie qui envoie vos messages en votre nom, de sorte que le destinataire se fie à sa réputation plutôt qu'à la vôtre. Le 9 octobre 2026, nous en avions besoin d'un en urgence. SynoPower Club fonctionne entièrement sur Synology, et chaque confirmation de commande et clé de licence transite par Synology MailPlus. Ce soir-là, un client belge a payé une licence, et l'e-mail contenant la clé est arrivé immédiatement. 552 5.2.0 Votre message est considéré comme un spam. Les contrôles SPF, DKIM et DMARC étaient tous validés. Cet article d'introduction à l'hébergement NAS explique comment nous avons configuré Resend comme relais SMTP uniquement pour les domaines destinataires qui nous rejettent, les enregistrements nécessaires, la procédure de test et les modifications discrètes apportées par le service à vos messages.
Point SynoPower Club : J'ai passé des années au support technique de Synology, et la délivrabilité était la principale raison pour laquelle la plupart des utilisateurs abandonnaient la gestion de leur messagerie. Ils pensaient que la solution consistait à migrer toutes les boîtes mail vers une suite hébergée. Or, c'est rarement le cas. Dans notre situation, le serveur de messagerie fonctionnait correctement, le DNS était correct, et un seul serveur de sortie avait un nom de domaine problématique auprès de quelques fournisseurs stricts. Synology MailPlus permet de modifier ce serveur uniquement pour ces fournisseurs, grâce à une règle que nous avons créée en dix minutes. Les boîtes mail, les journaux et les données clients sont toujours restés sur notre NAS.
Pourquoi des courriels correctement signés provenant d'un NAS sont-ils encore rejetés ? #
L'authentification prouve qui vous êtes, mais pas que vous êtes le bienvenu. SPF, DKIM et DMARC indiquent au serveur de réception qu'un message provient bien de votre domaine. Ensuite, le serveur pose une deuxième question : qu'a-t-il déjà vu de l'adresse IP qui transmet le message ?
Un serveur de messagerie auto-hébergé perd généralement la réponse à cette deuxième question de deux manières. S'il envoie directement, l'adresse IP publique est souvent associée à un nom DNS inverse générique fourni par le fournisseur d'accès Internet, que de nombreux destinataires interprètent comme une connexion domestique. S'il passe par le serveur sortant du fournisseur, comme c'était le cas pour le nôtre, le message hérite de la réputation d'une machine partagée avec des milliers d'autres clients.

Voilà notre situation. Le message d'erreur ne mentionnait ni notre domaine ni notre signature. Il s'agissait d'un problème de routage, et les grands fournisseurs de messagerie européens comme Telenet et GMX sont connus pour filtrer rigoureusement ce type de signal. Rien au niveau du serveur de messagerie ne pouvait y remédier, car le problème se situait un saut après le NAS.
Ce que change un relais SMTP, et ce qu'il ne change pas #
Un relais SMTP remplace ce dernier saut. Votre serveur s'authentifie auprès de lui sur le port 587, lui transmet le message, et le relais SMTP le livre depuis ses propres adresses IP, avec son propre historique d'envoi. Les services de messagerie transactionnelle existent précisément pour cette fonction : leurs adresses n'envoient que des accusés de réception, des réinitialisations de mot de passe et des notifications, ce qui leur confère une plus grande confiance qu'à un serveur d'envoi classique.
Un bon relais SMTP signe également le message avec une clé DKIM pour votre domaine, de sorte que le destinataire voit toujours votre adresse et que le DMARC est toujours validé. En revanche, il ne peut pas corriger un contenu erroné, un enregistrement SPF manquant ou une liste de destinataires qui n'ont jamais demandé à recevoir vos e-mails. Commencez par résoudre les problèmes d'authentification, puis examinez le chemin d'accès.
Pourquoi avons-nous choisi Resend comme relais SMTP ? #
Notre première tentative a été Amazon SES. Nous avons vérifié le domaine, indiqué un volume de 20 à 50 e-mails transactionnels par jour, et notre demande d'accès à la production a été refusée le lendemain sans explication. C'est une situation courante pour un nouveau compte, et cela a laissé notre boutique avec des clés de licence en attente de livraison.

Resend était la deuxième tentative, et l'envoi de courriels signés pour notre domaine a commencé une dizaine de minutes après l'inscription. Trois éléments en faisaient une solution idéale pour une petite boutique hébergée chez Synology :
- Il utilise le protocole SMTP standard. Aucun plugin ni intégration API n'est nécessaire ; un serveur de messagerie sur un NAS peut donc l'utiliser comme relais SMTP sans logiciel supplémentaire.
- Le forfait gratuit couvre un petit magasin. En octobre 2026, il autorise 3 000 e-mails par mois, 100 par jour et 3 domaines, ce qui est bien supérieur à notre volume de commandes.
- La vérification du domaine est automatique avec Cloudflare. Un seul écran d'autorisation a généré tous les enregistrements DNS pour nous.
- Chaque message est répertorié sur un tableau de bord. Vous pouvez voir si le serveur de réception a accepté ou renvoyé chaque requête.

Un détail nous a fait sourire. Les en-têtes de notre premier test indiquaient que le message transitait par l'infrastructure Amazon SES à Tokyo. Resend est construit sur la plateforme même qui avait refusé notre application, la réputation de l'expéditeur et l'approbation étant déjà assurées.
Tout relayer, ou seulement les domaines qui vous rejettent ? #
La plupart des guides recommandent d'envoyer tous les courriels sortants via le nouveau relais SMTP. Nous ne l'avons pas fait, et c'est grâce à Synology MailPlus. Ses paramètres de relais SMTP acceptent des exceptions, et chaque exception utilise son propre serveur, port et identifiants. Les courriels destinés aux domaines listés dans une exception empruntent ce chemin, tandis que tous les autres continuent d'utiliser le chemin par défaut.
Répartir le trafic de cette manière présente de réels avantages pour un serveur de messagerie d'entreprise :
- La correspondance ordinaire reste inchangée. Les réponses, les fils de discussion et les messages comportant plusieurs destinataires conservent leurs en-têtes d'origine.
- Une moindre partie de votre courrier transite par un tiers. Seuls les messages destinés aux domaines listés quittent votre infrastructure en amont.
- Vous restez dans les limites de votre forfait. Cent courriels par jour, c'est largement suffisant pour une poignée de domaines, mais peu pour une entreprise entière.
- Le retour en arrière se résume à cocher une seule case. Désactivez la règle et ces domaines retrouveront leur itinéraire par défaut.
Nous avons commencé avec deux domaines : celui qui a généré un rebond et un autre jouissant d’une réputation similaire en matière de rigueur. D’autres fournisseurs européens suivront à mesure que les commandes réelles confirmeront le résultat.
Configuration d'un relais SMTP MailPlus avec renvoi en 4 étapes #
La configuration complète du relais SMTP s'effectue dans deux onglets du navigateur : le tableau de bord Resend et la console du serveur MailPlus dans DSM. S'il s'agit d'un système de production, effectuez d'abord une capture instantanée ou exportez la configuration du serveur de messagerie.
Ajoutez votre domaine dans Resend et publiez les enregistrements DNS. #
Créez un compte Resend, ouvrez la section Domaines et ajoutez le domaine d'envoi. Choisissez la région à cette étape. Resend affiche alors un enregistrement DKIM et deux enregistrements pour le sous-domaine de rebond. Avec Cloudflare DNS, le bouton « Configuration automatique » les crée après une seule authentification. Avec tout autre fournisseur DNS, copiez les enregistrements manuellement. Laissez vos enregistrements SPF, DKIM et DMARC existants inchangés.
Attendez la vérification, puis créez une clé API d'envoi uniquement. #
La vérification a pris quelques minutes. Une fois le statut du domaine affiché comme « Vérifié », ouvrez les clés API et créez une clé avec l'autorisation d'envoi, limitée à ce domaine si vous le souhaitez. Copiez-la immédiatement, car la clé complète n'est affichée qu'une seule fois. Cette clé sert de mot de passe pour le relais SMTP.
Créez une règle de destinataire sur le serveur MailPlus #
Dans le serveur MailPlus, ouvrez « Distribution du courrier », puis « Paramètres de relais », puis « Règles d'exception » et créez une règle dans l'onglet « Règle du destinataire ». Saisissez smtp.resend.com comme serveur et 587 comme port, cochez les cases « Connexion sécurisée » et « Authentification », saisissez « resend » comme compte et collez la clé API comme mot de passe. Ajoutez chaque domaine destinataire à la liste, puis confirmez et appliquez.
Envoyez un test et lisez le résultat des deux côtés #
Envoyez un message à une boîte mail de l'un des domaines listés. Sur le serveur MailPlus, la page File d'attente devrait être vide quelques secondes plus tard. Dans la section Renvoyer les e-mails, le message devrait apparaître comme distribué. Enfin, ouvrez le message chez le destinataire et vérifiez que les authentifications SPF, DKIM et DMARC sont réussies pour votre domaine.



La partie DNS mérite une précision : Resend utilise son propre sélecteur DKIM et son propre sous-domaine pour les rebonds, évitant ainsi tout conflit avec les enregistrements DNS déjà utilisés par votre serveur de messagerie. Les deux routes restent authentifiées simultanément, garantissant la sécurité d'une configuration partagée.
Comment vérifier que le relais SMTP est bien en service ? #
Notre première tentative d'enregistrement de la règle était erronée, et rien ne l'indiquait à l'écran. Le gestionnaire de mots de passe du navigateur avait prérempli le champ « Mot de passe » avec le mot de passe de connexion DSM pendant que nous saisissions les autres champs, et le formulaire l'a accepté sans problème. Un message d'erreur d'authentification aurait dû s'afficher pour ces domaines.
Trois vérifications permettent de savoir si le relais SMTP fonctionne avant même qu'un client ne le fasse :
- Collez la clé en dernier et vérifiez sa longueur. Une clé de renvoi commence par
concernant_et comporte 36 caractères. Une courte ligne de points indique que le navigateur a saisi autre chose. - Surveillez la file d'attente. Après l'envoi d'un message de test, la page File d'attente du serveur MailPlus devrait être vide. Un message différé y indiquera la raison renvoyée par le relais SMTP.
- Attention à la clé. La colonne « Dernière utilisation » de la page « Renvoyer les clés API » indique « Aucune activité jusqu'à ce que le premier message soit authentifié avec succès ».
Nous avons également testé le relais SMTP directement, avant même d'accéder au serveur de messagerie, en envoyant des messages à l'une de nos propres boîtes mail via SMTP. Ces messages sont arrivés avec les certificats SPF, DKIM et DMARC validés pour notre domaine. Un sujet non anglais, un corps HTML avec une partie en texte brut, une pièce jointe PDF et un en-tête personnalisé ont tous été reçus intacts. Le relais SMTP ne compromet donc pas le contenu des messages. C'est un point crucial pour une boutique dont les e-mails de confirmation de commande sont envoyés en 16 langues.
Puis vint le test décisif. Le 11 octobre, nous avons renvoyé l'e-mail de confirmation de commande au client belge, le même message qui avait été rejeté deux jours auparavant. Le journal de messagerie indiquait que le serveur MailPlus l'avait transmis 3,2 secondes après son entrée dans la file d'attente, et le tableau de bord affichait la mention « Distribué », ce qui signifie que le serveur du fournisseur a accepté le message au lieu de le refuser.

Un message est un résultat, pas une statistique. La mention « Distribué » indique que le serveur destinataire a confirmé la réception, mais ne précise pas le dossier de destination du message. Nous continuerons d'observer les commandes réelles adressées à ces fournisseurs avant de transférer davantage de domaines.
Que réécrit Resend dans vos messages #
Un relais SMTP qui reconstruit les messages n'est pas un canal transparent, et il est important de connaître les différences avant d'y acheminer des données importantes. La comparaison des messages envoyés et reçus a révélé quatre différences :
- L'en-tête « À » devient le destinataire unique. Chaque destinataire reçoit un exemplaire qui lui est personnellement adressé, la liste originale des destinataires n'est donc plus visible.
- L'identifiant du message est remplacé. Les clients de messagerie utilisent cette valeur pour regrouper les réponses, ce qui permet de scinder les fils de discussion.
- L'en-tête Date est converti en UTC. L'heure est la même, mais le fuseau horaire affiché est différent.
- Les lignes « Reçu de votre serveur » sont supprimées. Le destinataire ne voit plus le chemin interne.
Tout ceci n'a aucune importance pour une confirmation de commande envoyée à un seul client. En revanche, c'est crucial pour une conversation avec trois personnes en copie, et c'est l'argument le plus convaincant pour limiter le relais SMTP aux seuls domaines sélectionnés.
Pourquoi notre courrier est toujours hébergé sur Synology MailPlus #
L'ajout d'un relais SMTP externe pour deux domaines ne modifie pas l'emplacement de notre messagerie. Chaque boîte aux lettres, chaque message envoyé et chaque journal de distribution restent sur notre propre NAS. Synology MailPlus Le système décide toujours, message par message, de l'itinéraire à emprunter. Une suite de messagerie hébergée ne nous aurait pas offert ce choix. Nous aurions eu un seul chemin de sortie, celui du fournisseur, et aucune règle pour contourner un problème.
C’est aussi pourquoi la solution est gratuite. Le serveur inclut cinq comptes de messagerie gratuits, les licences supplémentaires s’achètent une seule fois au lieu d’être louées mensuellement, et les règles de relais SMTP sont incluses. Si vous envisagez de gérer votre propre messagerie, vous trouverez toutes les informations nécessaires dans notre guide : Guide du serveur de messagerie Synology MailPlus.
Limites et mises en garde concernant le relais SMTP #
Un relais SMTP résout un problème spécifique, mais il en engendre quelques autres.
Les messages que vous y acheminez sont traités par un tiers. Nos serveurs contiennent des clés de licence ; c’est pourquoi nous limitons la liste des domaines et utilisons une clé qui ne permet que l’envoi de messages. Veuillez vérifier vos propres engagements en matière de protection des données avant d’envoyer des courriels à vos clients via un service externe, notamment pour les clients situés dans l’Union européenne.
Le forfait gratuit est limité par un nombre d'e-mails quotidien. Cent e-mails par jour, c'est généreux pour certains domaines, mais un envoi à l'ensemble de votre liste de clients atteindrait cette limite en quelques minutes. Les newsletters devraient faire l'objet d'un forfait distinct, et idéalement être hébergées sur un sous-domaine séparé, afin que les plaintes relatives au marketing n'affectent jamais la réputation de vos e-mails de confirmation de commande.
La réputation se gagne, elle ne s'acquiert pas. Les adresses d'envoi partagées sont bien gérées, mais vous ne contrôlez pas qui les utilise. Si un fournisseur vous refuse toujours après la modification, consultez le message d'erreur dans le tableau de bord avant de conclure que le problème vient du chemin d'accès.
Enfin, toute clé API collée dans une conversation, un ticket ou une capture d'écran doit être remplacée. Créez une nouvelle clé, mettez à jour la règle de relais SMTP, envoyez un test et supprimez l'ancienne. Cela ne prend que deux minutes et élimine un risque qui pourrait autrement persister pendant des années.
Questions fréquemment posées #
Qu'est-ce qu'un relais SMTP ? #
Un relais SMTP est un serveur de messagerie qui reçoit les messages de votre serveur et les achemine pour vous. Le destinataire se fie alors à la réputation du relais plutôt qu'à l'adresse d'envoi de votre serveur.
Pourquoi les courriels provenant de mon NAS Synology atterrissent-ils dans les spams alors que les vérifications SPF, DKIM et DMARC sont réussies ? #
Ces trois vérifications prouvent que le message provient bien de votre domaine. Les destinataires évaluent également l'adresse IP de l'expéditeur. Un nom DNS inverse générique ou un serveur sortant partagé avec un historique hétérogène peuvent, à eux seuls, entraîner l'échec du deuxième test.
Synology MailPlus prend-il en charge un relais SMTP uniquement pour certains domaines ? #
Oui. Dans la section « Distribution du courrier », sous « Paramètres de relais », puis « Règles d'exception », vous pouvez créer des règles de destinataires, chacune correspondant à un relais SMTP distinct. Chaque règle possède son propre serveur, port et identifiants, et s'applique uniquement aux domaines ou adresses figurant dans sa liste.
Resend est-il gratuit à utiliser comme relais SMTP ? #
Le forfait gratuit autorisait 3 000 e-mails par mois, 100 par jour et 3 domaines lorsque nous nous sommes inscrits en octobre 2026. C'est suffisant pour les e-mails transactionnels d'une petite boutique, surtout lorsque seuls quelques domaines l'utilisent.
Quel serveur relais SMTP, quel port et quel identifiant Resend utilise-t-il ? #
Le serveur est smtp.resend.com. Le port 587 avec STARTTLS est utilisé avec le serveur MailPlus, et le port 465 est disponible pour le TLS implicite. Le nom d'utilisateur est toujours « resend » et le mot de passe est votre clé API.
Dois-je modifier mes enregistrements SPF ou DKIM existants ? #
Non. Resend ajoute une clé DKIM sous son propre sélecteur et utilise son propre sous-domaine pour les retours. Les enregistrements utilisés par votre serveur de messagerie sont conservés ; ainsi, la route par défaut et le relais SMTP restent authentifiés.
Les clients verront-ils toujours ma propre adresse comme expéditeur ? #
Oui. L'adresse de l'expéditeur reste inchangée et le message est signé pour votre domaine ; le contrôle DMARC est donc validé. Lors de nos tests, les modifications visibles se sont limitées aux en-têtes « À », « ID du message », « Date » et « Received ».
Puis-je choisir le relais SMTP en fonction de l'expéditeur plutôt que du destinataire ? #
Le serveur MailPlus dispose également d'un onglet « Règle de l'expéditeur » à côté de l'onglet « Règle du destinataire », permettant le routage selon l'adresse d'envoi. Lorsque les deux types de règles correspondent au même message, la console indique que la règle du destinataire est prioritaire.
Références et visites guidées vidéo #
- Renvoyer la documentation SMTP, en indiquant le nom du serveur, les ports disponibles et le format de connexion.
- Renvoyer le prix, pour les allocations actuelles des forfaits gratuits et payants.
- Aide à la distribution du courrier du serveur Synology MailPlus, la description officielle des paramètres de livraison et de relais.
- Règles d'envoi d'e-mails de Google, les règles d'authentification et de réputation que Gmail applique aux courriers entrants.
- Aperçu de DMARC, expliquant comment l'alignement SPF et DKIM détermine si un message est transmis.
Ces vidéos Synology couvrent le serveur de messagerie sur lequel cet article est basé, de la première installation aux paramètres de sécurité.
Suite de cette série sur l'hébergement d'une entreprise sur un NAS : Envoi massif d'emails via un formulaire de contact. Vous prévoyez de créer votre propre serveur de messagerie ? Commencez par un pack de licences MailPlus, ou consultez toutes les licences sur SynoPower Club.