Sending emails from n8n with the Send Email node (SMTP): setup, HTML and deliverability

n8n can send email three different ways, and the most universal is also the oldest: the Send Email node, which speaks SMTP to any server — the OVH or Infomaniak mailbox tied to your domain, a Gandi account, the company Exchange server, or the SMTP interface of a transactional service like Mailgun or Postmark. No OAuth, no proprietary API, no vendor lock-in: a host, a port, a login, and your workflows can notify, confirm and alert from an address on your own domain.

The setup takes five minutes. What takes longer — and what most tutorials skip entirely — is everything that decides whether the email lands in the inbox or in spam: the right port with the right encryption, HTML that mail clients actually accept, and above all SPF/DKIM/DMARC authentication for your domain. This guide covers the whole path, from the credential to deliverability, with two concrete use cases at the end.

Three ways to send email from n8n: which one to pick

Before configuring anything, let's place the Send Email node next to its two alternatives:

• The Gmail node: the fastest route if your team lives in Google Workspace. It sends through the Gmail API (OAuth), benefits from Google's reputation, but ties you to Gmail and its quotas. Our Gmail connection guide walks through the OAuth setup, which isn't trivial the first time.
• A marketing service node like Brevo: the right choice as soon as you're dealing with campaigns, newsletters, contact lists and open-rate statistics. Our guide on email marketing automation with Brevo covers that ground.
• The Send Email node (SMTP): the generalist. It works with any provider that exposes an SMTP server — which is to say nearly all of them — and is a perfect fit for simple transactional email: error notifications, form confirmations, stock alerts, weekly reports. Its three strengths: provider independence (switching email hosts only means changing one credential), sending from an address on your professional domain (notifications@your-domain.com rather than a Gmail address), and zero OAuth to maintain.

The decision rule is simple: Gmail if you're already there and volume is low, Brevo (or equivalent) for anything that looks like marketing, SMTP for transactional email from your own domain.

The "SMTP account" credential: host, port and encryption

In n8n, create a credential of type SMTP account. Four fields matter:

• Host: your provider's SMTP server — for example ssl0.ovh.net at OVH, mail.infomaniak.com at Infomaniak, or whatever your host's documentation specifies.
• Port: 465 or 587 depending on the provider (see below).
• User / Password: usually the full email address and its password — or an app password if the provider requires one (which many do as soon as two-factor authentication is enabled).
• SSL/TLS: the option that must stay consistent with the chosen port.

That last point is where people trip. Two encryption mechanisms coexist in SMTP:

• Port 465 — implicit SSL/TLS: the connection is encrypted from the moment it opens, before any SMTP exchange. In n8n, enable the SSL/TLS option.
• Port 587 — STARTTLS: the connection opens in plain text, then the client immediately requests the upgrade to encryption via the STARTTLS command. In n8n, disable the SSL/TLS option: the node negotiates STARTTLS on its own. Enabling SSL/TLS on port 587 produces a baffling connection error — the classic mix-up.

Both combinations are secure once established; simply follow whichever your provider documents (587 + STARTTLS is the most common recommendation today, 465 remains perfectly valid). The one setting to rule out is port 25: designed for server-to-server exchanges, unencrypted by default, and blocked outbound by most hosts — more on that in the errors section.

Click Test on the credential screen before going any further: a credential that passes the test eliminates half the possible failure causes up front.

The Send Email node: fields, expressions and recipients

The node itself is deliberately simple. The fields to know:

• From Email: the sender address. It must belong to the domain your provider authenticates — the SMTP account's address or an alias on the same domain. Putting a fanciful From (noreply@gmail.com through an OVH SMTP) is the most direct shortcut to the spam folder, or to an outright rejection.
• To Email: one or several recipients, comma-separated (accounting@example.com, management@example.com). The node's options add CC and BCC in the same format.
• Subject: accepts n8n expressions like any text field:

Order {{ $json.number }} — {{ $json.customer }} (€{{ $json.total }})

• Email Format: Text, HTML, or Both. Prefer Both whenever you send HTML: the node then transmits a plain-text version alongside, which mail clients display if the HTML is blocked — and the absence of a text version is a negative signal for some spam filters.
• Attachments (in the options): the name of the binary property (or properties, comma-separated) of the incoming item to attach — typically data if the file comes from an HTTP Request or Read/Write Files node. The file must exist in the binary data of the item entering the node; if that notion is fuzzy, our guide on binary data in n8n explains how files travel between nodes.

To send a separate email to each recipient in a list, there's no need to loop manually: the node runs once per incoming item. Ten items each carrying an email field produce ten personalized sends — just put {{ $json.email }} in To Email.

HTML that renders everywhere (and that AI can write)

Mail clients — Outlook first among them — interpret HTML like it's 2005: no flexbox, no external CSS, partial support for styles in <head>. For a transactional email, the reliable recipe remains: tables for structure, inline styles for formatting, maximum width around 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>New order {{ $json.number }}</strong>
    </td>
  </tr>
  <tr>
    <td style="padding:16px;color:#333333;">
      <p>Customer: {{ $json.customer }}</p>
      <p>Total: <strong>€{{ $json.total }}</strong></p>
      <p><a href="{{ $json.url }}" style="color:#0f4c81;">View the order</a></p>
    </td>
  </tr>
</table>

The {{ }} expressions work directly inside the HTML field: the template above personalizes itself item by item without an intermediate node. And if the message body needs to be written rather than templated — a summary, a contextual reply — nothing stops you from placing an AI node upstream that generates the HTML or text, along the lines of our AI email reply drafts: the AI writes, the Send Email node ships.

Deliverability: SPF, DKIM, DMARC — the part everyone neglects

A workflow that sends without errors is only half the job: the message still has to reach the inbox. Receiving servers don't judge your email on its content first, but on your domain's authentication:

• SPF: a DNS record listing the servers authorized to send for your domain. If your provider's SMTP server isn't on it, the recipient has no way to verify the send is legitimate.
• DKIM: a cryptographic signature applied by the sending server, whose public key is published in your DNS. It proves the message wasn't altered and really comes from the claimed domain.
• DMARC: the policy telling recipients what to do with a message that fails SPF or DKIM (do nothing, quarantine, reject) and sending you reports.

These mechanisms aren't recent paranoia. Back in 2015, a large-scale measurement study by Durumeric and co-authors, "Neither Snow Nor Rain Nor MITM… An Empirical Analysis of Email Delivery Security" (Internet Measurement Conference 2015 — see on Google Scholar), found still-incomplete adoption of STARTTLS, SPF and DKIM across the ecosystem — with a direct consequence that still shapes email today: receiving servers treat any poorly authenticated sender with suspicion. A technically valid but unauthenticated email starts with a handicap, whatever its content.

Concretely, for your n8n sends:

• Set up SPF, DKIM and DMARC with your email provider and in your DNS zone — every provider documents the procedure, usually a few TXT and CNAME records to copy.
• Verify by sending a test to a Gmail account: "Show original" displays the SPF/DKIM/DMARC verdict line by line.
• Consider a dedicated sending subdomain (notif.your-domain.com) for automated email: if a workflow goes haywire and damages reputation, your main domain's — and therefore your human emails' — stays isolated.
• Don't push marketing volume through raw SMTP. The Send Email node has no bounce handling, no unsubscribe management, no reputation control: that's the job of a platform like Brevo. Direct SMTP is for transactional email — a few dozen targeted messages a day, not a thousand-address newsletter.

Two concrete use cases

Workflow error notification. The Send Email node's natural partner is the error workflow: a dedicated workflow, triggered by the Error Trigger node whenever another workflow fails, that sends the alert over SMTP with the failing workflow's name, the node at fault and the error message — all from alerts@your-domain.com, with no dependency on Slack or Gmail. The full setup is detailed in our guide on error handling with an error workflow; the Send Email node replaces or complements the Slack notification there in five minutes.

Acknowledgment after a form submission. An n8n form collects a request, and the respondent immediately receives a personalized confirmation: Form Trigger, optionally a Set node for formatting, then Send Email with {{ $json.email }} as the recipient and a recap of the answers in the HTML body. Our guide to the Form Trigger and multi-step forms covers the form side; the SMTP acknowledgment is its natural extension — and since it leaves from your authenticated domain, it lands in the inbox, not in spam.

Fixing the three classic errors

• ECONNREFUSED or ETIMEDOUT: n8n can't reach the server. Check the host and port, then — the most common cause in self-hosted setups — outbound port blocking by your host: many VPS providers block outbound port 25 by default (an anti-spam measure), and some filter more. Test from the server with nc -vz smtp.your-provider.com 587; if ports 587 and 465 are blocked too, a support ticket to the host or a switch to an allowed SMTP relay is the way out.
• Invalid login / 535 Authentication failed: credentials rejected. Beyond the typo, think app password: several providers refuse the account's main password for SMTP connections once two-factor authentication is on, and require a dedicated password generated in their console.
• Emails sent but landing in spam: this isn't an n8n bug, it's missing authentication. Go back to the deliverability section — SPF, DKIM, DMARC, and a From consistent with the authenticated domain.

Common pitfalls

• Enabling SSL/TLS on port 587 (or the reverse): STARTTLS on 587 with the option disabled, implicit SSL/TLS on 465 with the option enabled — any other combination fails.
• Using port 25: unencrypted by default, blocked outbound by most hosts, never the right choice for sending.
• A From address outside the authenticated domain: near-guaranteed rejection or spam, even with a valid credential.
• Sending HTML without a text version: pick the Both format — the plain-text fallback improves both rendering and deliverability.
• Skipping SPF/DKIM/DMARC because "it works in testing": the test to your own mailbox passes, the sends to your customers land in spam.
• Running marketing volume through raw SMTP: with no bounce or unsubscribe handling, domain reputation erodes fast — that's a job for a dedicated tool like Brevo.
• Forgetting the node sends once per item: a hundred incoming items, a hundred emails out. Aggregate upstream if you wanted a single recap.

In summary

The Send Email node is the most robust route for transactional email from your own domain: a properly configured SMTP credential (587 + STARTTLS or 465 + SSL/TLS, never 25), a From aligned with the authenticated domain, restrained HTML with a plain-text fallback, and attachments pulled from the workflow's binary data. The real difference between a delivered email and a spammed one isn't decided in n8n but in your DNS: SPF, DKIM and DMARC first, a sending subdomain if volume grows. Once this reliable channel is in place, the logical next step is to point it at your inbox itself: the Inbox AI Pack (€79) provides ready-to-use workflows to sort, prioritize and pre-draft replies to incoming email — the Send Email node you've just configured is its final building block.