If your n8n workflow says the email sent and the client says they never got it, both are true. n8n hands your message to an SMTP server or an API and marks the node green the instant that server accepts it. Everything that decides whether the message lands in the inbox — domain authentication, sender reputation, complaint rate, the presence of an unsubscribe header — happens after n8n is done and reports nothing back. That is the entire problem. A workflow can show a 100% success rate for months while delivering almost nothing to the primary inbox, and nothing in the n8n UI will hint at it.
We run 200+ production workflows for clients, and a large share of them touch email — lead nurture, review requests, quote follow-ups, internal alerts. Deliverability is the single most common thing agencies get wrong when they move email into automation, and it's the one nobody notices until a client asks why their follow-up sequence stopped producing replies.
Why n8n emails go to spam when the workflow says success
n8n is a workflow engine. It is not an email service provider, and it does not try to be one. The Send Email node opens an SMTP connection, delivers the message, and reports whether the handoff was accepted. That's the contract.
What n8n does not do: warm an IP, manage a sending domain's reputation, handle bounce processing, suppress complainers, or set the headers that mailbox providers now demand. Those responsibilities belong to whatever you point the node at. If you pointed it at your web host's shared SMTP server — the one your WordPress contact form uses — you inherited that host's IP reputation, which is shared with several hundred other sites you have never met.
The three failure patterns we see most often, in order:
- Shared hosting SMTP. The credentials were sitting right there in cPanel. The IP is pooled, the reputation is whatever the worst neighbor on it is doing, and there is no delivery reporting at all.
- A personal or Workspace mailbox used as a bulk sender. The Gmail node works beautifully for ten emails a day and quietly falls over at scale, which we'll get to.
- No sending domain strategy. Everything goes out of the agency's own domain because that's the account that was already connected, and every client's complaint rate now lives in one shared reputation bucket.
None of these produce an error in n8n. They produce silence.
The header the n8n Send Email node can't send
This one is genuinely non-obvious and it catches experienced builders.
Gmail and Yahoo require one-click unsubscribe for marketing and subscribed messages at volume. Not a link in the footer — the actual RFC 8058 headers, List-Unsubscribe-Post: List-Unsubscribe=One-Click alongside List-Unsubscribe: <https://yoursite.com/unsubscribe>, so the mailbox client can render its own unsubscribe button.
The n8n Send Email (SMTP) node cannot set them. n8n's documentation states plainly that the node "does not support setting headers like In-Reply-To and References," and the reason is that there is no custom-header field in the node at all. The docs call out the threading headers because that's what people complain about most, but the limitation is general: whatever header you need, you can't add it.
So if you built a nurture sequence on the SMTP node and it sends anything a mailbox provider would classify as marketing mail, you are structurally non-compliant and there is no setting you can toggle to fix it. You have to change how the message is sent.
Three ways out, all of them fine:
- Use an email API node. Most transactional providers have a first-party n8n node, and they set List-Unsubscribe for you when the message is part of a broadcast or when you pass the header through.
- Use the HTTP Request node against your ESP's send endpoint. More work, total control, and you get the provider's message ID back so you can correlate delivery events later.
- Install a community node that exposes custom headers. Works, but you now own a dependency that has to survive every n8n upgrade. We avoid this on client instances.
The rule we use: transactional and internal mail can go over SMTP. Anything a human could plausibly want to unsubscribe from goes through an API.
Gmail node, SMTP node, or an email API — which should you use?
There's no universally right answer, but there is a right answer per use case.
The Gmail node is the correct choice when the email genuinely comes from a person. Replying in an existing thread, sending a personalized quote from the account executive's own mailbox, following up on a conversation. It threads properly, it comes from a real human address, and recipients treat it as real mail because it is. Its ceiling is a hard one: a standard Google Workspace account allows 2,000 messages per day, 3,000 external recipients per day, and 2,000 unique external recipients per day, measured over a rolling 24-hour period rather than resetting at midnight. Trial accounts get 500. Hit the wall and Google blocks sending from that account for up to 24 hours — which takes down every other workflow using the same credential, not just the one that overran.
The Send Email (SMTP) node is right for internal notifications, alerts to your own team, and low-volume transactional mail where nobody will ever unsubscribe. It's simple, it's provider-agnostic, and it does not need OAuth. It is the wrong tool for anything marketing-shaped, for the header reason above.
An email API — Resend, Postmark, SendGrid, Mailgun, Brevo, whichever — is right for everything else, and it's what we default to on client builds. You get per-message delivery, bounce, and complaint webhooks, which is the part that actually matters: it's the only one of the three options that tells you what happened after the handoff. You can wire those webhooks straight back into an n8n workflow that suppresses hard bounces in the CRM before the next run.
That last point is worth sitting with. The Gmail and SMTP nodes give you a boolean. An API gives you a feedback loop. If you're building anything resembling a lead follow-up system, the feedback loop is the product.
What Gmail, Yahoo, and Microsoft actually require now
Google's sender guidelines apply to anyone sending around 5,000 or more messages a day to Gmail addresses, and Yahoo and Microsoft enforce materially the same rules. The requirements are short:
- SPF and DKIM configured on the sending domain, and a DMARC record published.
- One-click unsubscribe via the List-Unsubscribe headers for marketing and subscribed mail, plus a clearly visible unsubscribe link in the body.
- TLS for transmission.
- Valid forward and reverse DNS, meaning a PTR record that resolves back.
- Spam rate below 0.10% as reported in Postmaster Tools, and never reaching 0.30%.
The threshold that surprises people is 0.30%. That's three complaints per thousand delivered messages. On a 20,000-message send, sixty people hitting "report spam" is enough to put you in trouble — and a stale list re-engaged by a new automation will produce that easily.
One detail worth checking even if you think you're already authenticated: passing SPF and DKIM is not the same as aligning them. A message can pass both checks against the ESP's own domain while your visible From address is a completely different domain. DMARC evaluates alignment, not just passage. This is the most common silent misconfiguration we find during audits, and it's usually the result of copying an SPF record from a tutorial rather than from the provider's own setup screen.
The setup we run on every client email automation
This takes about thirty minutes at onboarding and it's non-negotiable on our builds.
Sending subdomain, always the client's domain. Something like mail.clientdomain.com or send.clientdomain.com, delegated to the ESP. Automated mail reputation stays separate from the client's human email, so a bad campaign can't poison the sales team's ability to reach anyone. And when the client leaves, the reputation leaves with them, which is how it should be.
Authenticate, then verify alignment. SPF, DKIM, DMARC published, then send a test to a seed address and read the raw headers. dmarc=pass with an aligned header.from is the thing you're looking for, not three green checkmarks in the ESP dashboard.
Start DMARC at p=none with rua reporting on, and actually read the reports for two weeks before moving to quarantine. Half the time the reports surface some forgotten system — an old CRM, a booking tool, a WordPress plugin — still sending as the client's domain. Move to enforcement before you find those and you break something the client cares about.
Bounce and complaint webhooks into n8n. A small workflow that receives the ESP's events, writes hard bounces back to the CRM as invalid, and adds complainers to a suppression list. Without this, every run re-mails the same dead addresses and your bounce rate climbs on its own. This is the same pattern as any other error handling and monitoring workflow — the email system just happens to be the thing being monitored.
Volume ramp on anything new. A new sending domain has no reputation. Starting a 15,000-contact reactivation campaign on a domain that sent its first message yesterday is the fastest way to get filtered, and it's a self-inflicted wound because the fix is just spreading it over two weeks.
Postmaster Tools, checked weekly. Free, takes five minutes to set up, and it's the only place you'll see your actual spam rate. If you're building email sequences for clients, this is the report you should be pulling into the monthly deck.
How to tell whether it's already broken
Before you change anything, get evidence. Three checks, none of which take long:
Pull the raw headers from a message your workflow actually sent — not a test you triggered manually from a different account — and read the Authentication-Results line. You want spf=pass, dkim=pass, and dmarc=pass with the domain matching your visible From. Anything else is your answer.
Compare workflow executions against ESP delivery events for the same day. If n8n ran 1,400 sends and your provider recorded 1,400 deliveries, the handoff is clean and your problem is placement. If the numbers don't match, something is failing silently between them.
Look at reply rate by day rather than open rate. Open rates have been unreliable since Apple's Mail Privacy Protection started pre-fetching pixels, but replies are real human behavior. A sequence that produced steady replies and then went flat on a specific date usually means something changed on that date — a DNS edit, a provider switch, a volume jump, or an account hitting its rolling limit.
That last one is the pattern behind most "the automation stopped working" tickets we get. The workflow didn't stop. The mail stopped arriving, and the workflow had no way to know.
Get a free automation audit
If you've got n8n workflows sending client email and you don't know your actual inbox placement — or a sequence that used to produce replies and quietly went flat — that's a specific, fixable problem and usually a fast one. Get a free automation audit and we'll check your authentication and alignment, look at how your workflows are sending versus what they're sending, and tell you whether it's a DNS fix, a node change, or a list problem. If your setup is already clean, we'll tell you that and point at what's actually causing the drop instead.
Worth reading next if you're building out the rest of the stack: the n8n workflows every agency needs, and the missed-call text-back automation that catches the leads email never reaches.
Carlos Aragon is the founder of VIXI, an AI-first automation agency in Allen, TX (Dallas area), running 200+ production automation workflows on n8n. Sender requirements summarized here are from Google's published Email sender guidelines and n8n's node documentation as of August 2026; both change, so check the source before you architect around them.