Sending email from an n8n workflow without wrecking your domain

An n8n workflow that sends email is four clicks of work. That is the problem: the easy path puts a Send Email node in front of whatever SMTP credentials were nearest to hand, and nobody looks at it again until deliverability is already damaged.

Unattended senders deserve more care than interactive ones, not less. When a person clicks “send” and nothing arrives, they notice. When a workflow fires at 03:00 and its mail is silently filtered, the first signal is a customer asking why they never got anything.

Use SMTP, and use a real relay

n8n’s Send Email node speaks SMTP. That is all you need — there is no plugin to install and no custom node to maintain.

What matters is what is on the other end. Three common choices, in ascending order of sense:

• A personal mailbox (a Gmail or Outlook account). Works in testing, throttles quickly, and mixes automated mail into an identity built for human correspondence. Providers notice.
• A mail server on the box that runs n8n. Almost always a fresh IP with no reputation, frequently no reverse DNS, and often on a hosting range that receivers already treat with suspicion.
• A relay built for the job, with authentication configured and a sending reputation someone is actively maintaining.

Only the third one is a decision rather than a default.

The configuration

Five credentials, and two of them are where mistakes happen:

Host:      smtp.your-relay.example
Port:      587
SSL/TLS:   STARTTLS
User:      your relay username
Password:  your relay password

Port 587 with STARTTLS, not 465, and not 25. Port 25 between hosts is for server-to-server delivery and is blocked outbound by most providers; 465 is implicit TLS and works, but 587 with STARTTLS is the submission standard and the one relays document.

The From address must be on a domain you have verified with the relay. This is the field people get wrong. Putting noreply@yourcompany.com in the node while the relay has only verified mail.yourcompany.com produces mail that either fails authentication or is refused outright — and n8n will show you a green node either way if the relay accepted the handoff.

What to check after the first send

Trigger the workflow once, to yourself, and read the raw headers of what arrives. You are looking for one line:

Authentication-Results: mx.google.com;
  spf=pass; dkim=pass; dmarc=pass header.from=yourcompany.com

Three passes. If dmarc says anything else, stop and fix it before you turn the workflow on — an unattended sender failing alignment will do damage steadily and invisibly.

Give the workflow its own credentials

One more habit worth forming: issue this workflow its own API key or SMTP user rather than reusing the one your application holds.

Workflows get retired, duplicated, exported to share with a colleague, and pasted into support threads. A credential scoped to one workflow can be revoked when any of that happens, without taking your production sending down with it. A credential shared across everything cannot be revoked at all in practice, which means it never is.

The failure mode to design for

The specific risk with automation is the retry loop. A workflow that errors and re-runs can attempt the same dead address dozens of times, and repeatedly mailing an address that has already rejected you is one of the strongest negative signals a sender can generate.

Use a relay that suppresses automatically on hard bounces and complaints, so a loop stops at the first rejection rather than the fiftieth. If yours does not, the workflow needs that logic itself — and workflow logic is exactly the thing nobody revisits.

Where Pharos fits

Pharos is an SMTP relay with the authentication side already handled: verified sender domains, DKIM signing, enforced alignment, and automatic suppression that stops a retry loop hitting a dead address twice. The n8n side is the five fields above and nothing else.