Envoyer des emails depuis n8n avec le node Send Email (SMTP) : configuration, HTML et délivrabilité

n8n sait envoyer des emails de trois façons, et la plus universelle est aussi la plus ancienne : le node Send Email, qui parle SMTP à n'importe quel serveur — la boîte OVH ou Infomaniak de votre domaine, un compte Gandi, le serveur d'entreprise, ou l'interface SMTP d'un service transactionnel comme Mailgun ou Postmark. Pas d'OAuth, pas d'API propriétaire, pas de dépendance à un fournisseur : un hôte, un port, un identifiant, et vos workflows notifient, confirment et alertent depuis une adresse de votre propre domaine.

La configuration prend cinq minutes. Ce qui en prend davantage — et que la plupart des tutoriels passent sous silence — c'est tout ce qui décide si l'email arrive en boîte de réception ou en spam : le bon port avec le bon chiffrement, un HTML que les clients mail acceptent, et surtout l'authentification SPF/DKIM/DMARC de votre domaine. Ce guide couvre l'ensemble, du credential à la délivrabilité.

Trois façons d'envoyer un email depuis n8n : laquelle choisir

Situons d'abord le node Send Email par rapport à ses deux alternatives :

• Le node Gmail : le plus rapide si votre équipe vit dans Google Workspace. Il envoie via l'API Gmail (OAuth), profite de la réputation de Google, mais vous lie à Gmail et à ses quotas. Notre guide de connexion Gmail détaille la configuration OAuth, peu triviale la première fois.
• Le node d'un service marketing comme Brevo : le bon choix pour les campagnes, newsletters, listes de contacts et statistiques d'ouverture. Notre guide sur l'automatisation email marketing avec Brevo couvre ce terrain.
• Le node Send Email (SMTP) : le généraliste. Il fonctionne avec n'importe quel fournisseur qui expose un serveur SMTP — c'est-à-dire à peu près tous — et convient parfaitement au transactionnel simple : notification d'erreur, confirmation de formulaire, alerte de stock, rapport hebdomadaire. Ses trois atouts : l'indépendance vis-à-vis du fournisseur (en changer ne change qu'un credential), l'envoi depuis une adresse de votre domaine professionnel (notifications@votre-domaine.fr plutôt qu'un Gmail), et aucun OAuth à maintenir.

La règle de décision est simple : Gmail si vous y êtes déjà et que le volume est faible, Brevo (ou équivalent) pour tout ce qui ressemble à du marketing, SMTP pour le transactionnel depuis votre propre domaine.

Le credential « SMTP account » : hôte, port et chiffrement

Dans n8n, créez un credential de type SMTP account. Quatre champs comptent :

• Host : le serveur SMTP de votre fournisseur — par exemple ssl0.ovh.net chez OVH, mail.infomaniak.com chez Infomaniak, ou la valeur indiquée dans la documentation de votre hébergeur.
• Port : 465 ou 587 selon le fournisseur (voir ci-dessous).
• User / Password : en général l'adresse email complète et son mot de passe — ou un mot de passe d'application si le fournisseur en impose un (fréquent dès que la double authentification est activée).
• SSL/TLS : l'option qui doit être cohérente avec le port choisi.

C'est ce dernier point qui fait trébucher. Deux mécanismes de chiffrement coexistent en SMTP :

• Port 465 — SSL/TLS implicite : la connexion est chiffrée dès l'ouverture, avant le moindre échange SMTP. Dans n8n, activez l'option SSL/TLS.
• Port 587 — STARTTLS : la connexion s'ouvre en clair, puis le client demande immédiatement le passage en chiffré via la commande STARTTLS. Dans n8n, désactivez l'option SSL/TLS : le node négocie STARTTLS de lui-même. Activer SSL/TLS sur le port 587 produit une erreur de connexion incompréhensible — c'est l'inversion classique.

Les deux combinaisons sont sûres une fois établies ; suivez celle que documente votre fournisseur (587 + STARTTLS est la recommandation la plus courante, 465 reste parfaitement valable). Le seul réglage à proscrire est le port 25 : conçu pour les échanges de serveur à serveur, non chiffré par défaut, et bloqué en sortie par la plupart des hébergeurs. Cliquez sur Test dans l'écran du credential avant d'aller plus loin : un credential qui passe le test élimine d'emblée la moitié des causes de panne.

Le node Send Email : champs, expressions et destinataires

Le node lui-même est volontairement simple. Les champs à connaître :

• From Email : l'adresse d'expédition. Elle doit appartenir au domaine que votre fournisseur authentifie — l'adresse du compte SMTP ou un alias du même domaine. Mettre un From fantaisiste (noreply@gmail.com depuis un SMTP OVH) est le raccourci le plus direct vers le dossier spam, voire vers un rejet pur et simple.
• To Email : le ou les destinataires, séparés par des virgules (compta@exemple.fr, direction@exemple.fr). Les options du node ajoutent CC et BCC sur le même format.
• Subject : accepte les expressions n8n comme n'importe quel champ texte :

Commande {{ $json.numero }} — {{ $json.client }} ({{ $json.total }} €)

• Email Format : Text, HTML, ou Both. Préférez Both dès que vous envoyez du HTML : le node transmet alors une version texte en parallèle, que les clients mail affichent si le HTML est bloqué — et l'absence de version texte est un signal négatif pour certains filtres antispam.
• Attachments (dans les options) : le nom de la ou des propriétés binaires de l'item entrant à joindre, séparées par des virgules — typiquement data si le fichier vient d'un node HTTP Request ou Read/Write Files. Le fichier doit exister dans les données binaires de l'item entrant ; si la notion vous échappe, notre guide sur les données binaires dans n8n explique comment les fichiers circulent entre nodes.

Pour envoyer un email distinct à chaque destinataire d'une liste, inutile de boucler : le node s'exécute une fois par item entrant. Dix items avec chacun un champ email produisent dix envois personnalisés — il suffit de mettre {{ $json.email }} dans To Email.

Un HTML qui s'affiche partout (et que l'IA peut rédiger)

Les clients mail — Outlook en tête — interprètent le HTML comme en 2005 : pas de flexbox, pas de CSS externe, support partiel des styles dans <head>. La recette fiable : tables pour la structure, styles inline pour la mise en forme, largeur maximale autour de 600 px.

<table width="100%" cellpadding="0" cellspacing="0" style="max-width:600px;font-family:Arial,sans-serif;">
  <tr>
    <td style="padding:16px;background:#1a1a2e;color:#ffffff;">
      <strong>Nouvelle commande {{ $json.numero }}</strong>
    </td>
  </tr>
  <tr>
    <td style="padding:16px;color:#333333;">
      <p>Client : {{ $json.client }}</p>
      <p>Total : <strong>{{ $json.total }} €</strong></p>
      <p><a href="{{ $json.url }}" style="color:#0f4c81;">Voir la commande</a></p>
    </td>
  </tr>
</table>

Les expressions {{ }} fonctionnent directement dans le champ HTML : le gabarit ci-dessus se personnalise item par item sans node intermédiaire. Et si le corps doit être rédigé plutôt que gabarisé — un résumé, une réponse contextuelle — placez un node IA en amont qui génère le HTML ou le texte, sur le principe de nos brouillons de réponse email par IA : l'IA rédige, le node Send Email expédie.

Délivrabilité : SPF, DKIM, DMARC — la partie que tout le monde néglige

Un workflow qui envoie sans erreur n'est que la moitié du travail : encore faut-il que le message arrive. Les serveurs de réception ne jugent pas votre email d'abord sur son contenu, mais sur l'authentification de votre domaine :

• SPF : un enregistrement DNS qui liste les serveurs autorisés à envoyer pour votre domaine. Si le SMTP de votre fournisseur n'y figure pas, le destinataire ne peut pas vérifier la légitimité de l'envoi.
• DKIM : une signature cryptographique apposée par le serveur d'envoi, dont la clé publique est publiée dans votre DNS. Elle prouve que le message n'a pas été altéré et vient bien du domaine annoncé.
• DMARC : la politique qui dit aux destinataires quoi faire d'un message qui échoue SPF ou DKIM (ne rien faire, mettre en quarantaine, rejeter) et vous envoie des rapports.

Ces mécanismes ne sont pas une paranoïa récente. Dès 2015, l'étude de mesure à grande échelle de Durumeric et ses co-auteurs, « Neither Snow Nor Rain Nor MITM… An Empirical Analysis of Email Delivery Security » (Internet Measurement Conference 2015 — voir sur Google Scholar), constatait une adoption encore incomplète de STARTTLS, SPF et DKIM à travers l'écosystème — avec une conséquence qui structure encore l'email aujourd'hui : les serveurs de réception traitent avec méfiance tout expéditeur mal authentifié, quel que soit le contenu du message.

Concrètement, pour vos envois n8n :

• Configurez SPF, DKIM et DMARC chez votre fournisseur et dans votre zone DNS — la procédure est documentée partout, généralement quelques enregistrements TXT et CNAME à copier.
• Vérifiez en envoyant un test vers un compte Gmail : « Afficher l'original » montre le verdict SPF/DKIM/DMARC ligne par ligne.
• Envisagez un sous-domaine d'envoi (notif.votre-domaine.fr) pour les emails automatisés : si un workflow part en vrille, la réputation de votre domaine principal — et de vos emails humains — reste isolée.
• Ne poussez pas de volume marketing par SMTP brut. Le node Send Email n'a ni gestion des bounces, ni désinscription, ni pilotage de réputation : c'est le rôle d'une plateforme comme Brevo. Le SMTP direct est fait pour le transactionnel, pas pour une newsletter à mille adresses.

Deux cas d'usage concrets

Notification d'erreur de workflow. Le duo naturel du node Send Email est l'error workflow : un workflow dédié, déclenché par le node Error Trigger à chaque échec d'un autre workflow, qui envoie l'alerte par SMTP avec le nom du workflow fautif, le node en cause et le message d'erreur — le tout depuis alertes@votre-domaine.fr, sans dépendre d'un Slack ou d'un Gmail. Le montage complet est détaillé dans notre guide sur la gestion des erreurs avec un error workflow.

Accusé de réception après un formulaire. Un formulaire n8n collecte une demande, et le répondant reçoit immédiatement une confirmation personnalisée : Form Trigger, puis Send Email avec {{ $json.email }} en destinataire et un récapitulatif des réponses dans le corps HTML. Notre guide du Form Trigger et des formulaires multi-étapes couvre la partie formulaire ; l'accusé de réception SMTP en est le prolongement naturel — et comme il part de votre domaine authentifié, il arrive en boîte de réception, pas en spam.

Résoudre les trois erreurs classiques

• ECONNREFUSED ou ETIMEDOUT : n8n n'atteint pas le serveur. Vérifiez l'hôte et le port, puis — cause la plus fréquente en self-hosted — le blocage du port sortant par votre hébergeur : beaucoup de fournisseurs de VPS bloquent le port 25 en sortie par défaut (mesure antispam), et certains filtrent davantage. Testez depuis le serveur avec nc -vz smtp.votre-fournisseur.fr 587 ; si 587 et 465 sont eux aussi bloqués, un ticket au support ou un relais SMTP autorisé s'impose.
• Invalid login / 535 Authentication failed : identifiants refusés. Au-delà de la faute de frappe, pensez au mot de passe d'application : plusieurs fournisseurs refusent le mot de passe principal du compte pour le SMTP dès que la double authentification est active, et exigent un mot de passe dédié généré dans leur console.
• Emails envoyés mais reçus en spam : ce n'est pas un bug n8n, c'est une authentification manquante. Reprenez la section délivrabilité — SPF, DKIM, DMARC, et un From cohérent avec le domaine authentifié.

Pièges fréquents

• Activer SSL/TLS sur le port 587 (ou l'inverse) : STARTTLS sur 587 avec l'option désactivée, SSL/TLS implicite sur 465 avec l'option activée — toute autre combinaison échoue.
• Utiliser le port 25 : non chiffré par défaut, bloqué en sortie par la plupart des hébergeurs, jamais le bon choix.
• Un From hors du domaine authentifié : rejet ou spam quasi garanti, même avec un credential valide.
• Envoyer du HTML sans version texte : choisissez le format Both, le fallback texte améliore l'affichage et la délivrabilité.
• Ignorer SPF/DKIM/DMARC parce que « ça marche en test » : le test vers votre propre boîte passe, les envois vers vos clients tombent en spam.
• Faire du volume marketing en SMTP brut : sans gestion des bounces ni des désinscriptions, la réputation du domaine s'érode vite — c'est le travail d'un outil comme Brevo.
• Oublier que le node envoie une fois par item : cent items entrants, cent emails partis. Agrégez en amont si vous vouliez un seul récapitulatif.

En résumé

Le node Send Email est la voie la plus robuste pour le transactionnel depuis votre propre domaine : un credential SMTP bien réglé (587 + STARTTLS ou 465 + SSL/TLS, jamais 25), un From aligné sur le domaine authentifié, un HTML sobre avec fallback texte, des pièces jointes tirées des données binaires. La vraie différence entre un email reçu et un email en spam ne se joue pas dans n8n mais dans votre DNS : SPF, DKIM et DMARC d'abord, sous-domaine d'envoi si le volume grandit. Une fois ce canal fiable en place, l'étape logique suivante est de le brancher sur votre boîte de réception elle-même : le Pack Inbox IA (79 €) fournit les workflows prêts à l'emploi pour trier, prioriser et pré-rédiger les réponses aux emails entrants — le node Send Email que vous venez de configurer en est la dernière brique.