n8n Send Email vs Gmail Node: Which to Use for Your Workflow
Knowing the Send Email node uses SMTP and the Gmail node uses OAuth doesn't tell you which one to actually wire into your CRM alert or inbox triage pipeline. This guide skips the feature definitions and maps six real workflow types to the node that handles each one correctly, with production data from Rain Automatio...
You've already read that the Send Email node runs on SMTP and the Gmail node runs on OAuth. That's the foundational comparison, and the companion post on this site covers it in full detail.
What that post can't answer is the follow-up question that actually matters when you're building: which node do I wire into this specific workflow?
The answer changes depending on what your workflow is doing. Six workflow types. Six clear recommendations. Each one backed by what we've observed running n8n in production across multiple client products.
Our production instance currently runs 80 workflows. Twelve use the Send Email node, four use the Gmail node. That 3:1 ratio isn't arbitrary. It reflects the genuine split between outbound-only automation (the majority of what businesses automate) and inbox-interactive workflows (which require Gmail's read capability). If you're curious about what it costs to run a self-hosted n8n stack at that scale, this guide has the server specs and monthly cost data from our production environment.
For CRM Notification Workflows: Send Email Node
The scenario: a deal stage changes, a lead gets assigned, or a form is submitted. The workflow fires an email alert to a salesperson or sends a client notification. It's one-directional, no reply expected, no inbox state to manage.
Send Email is the right node here for two reasons.
First, you can send from a business domain address ([email protected] instead of someone's personal Gmail). CRM alerts that come from a generic Gmail address look wrong to recipients, and in a multi-salesperson setup, you don't want notifications tied to any individual's OAuth credentials.
Second, and more practically: OAuth tokens expire. Gmail's refresh token can be revoked by Google during periodic security sweeps, after 6 months of no consent screen interaction, or when a Google account's password changes. CRM notification workflows that depend on a single Gmail OAuth credential will silently break when that token dies, and you'll find out when a salesperson asks why they stopped receiving lead alerts.
SMTP credentials don't work this way. Once configured with an app password or API key from your email provider, they continue working without re-authorization. Our SMTP credentials for the Rain and FTH workflows haven't been touched in months. They just run.
Bonus: if your CRM notification workflow needs human approval before advancing (a manager approving a quote, for example), the Send Email node's Send and Wait for Response operation handles that natively. More on this in the approval workflow section below.
For a step-by-step look at pairing the Send Email node with a CRM lead notification, see the n8n Mailgun + CRM lead notification guide.
For Lead Follow-Up Sequences: Send Email Node
The scenario: a contact enters a drip sequence. Day 1 intro, day 3 follow-up, day 7 check-in. Each email is independent. No threading, no inbox reading. Just timed outbound sends.
Send Email is the correct choice for three reasons.
Custom domain sending is table stakes. A lead who submitted a form on yourbusiness.com and receives follow-up email from a @gmail.com address is going to notice. The domain mismatch undermines trust and deliverability.
Volume is the second reason. Gmail's API caps personal accounts at 500 emails per day and Google Workspace accounts at 2,000. A lead sequence that seems fine at 50 contacts per month will hit that cap when the list grows. When it does, the Gmail node doesn't queue the overflow. It throws 429 errors, and depending on your error handling configuration, contacts get silently skipped rather than retried.
For sequences, we use Resend as the SMTP provider connected to the Send Email node. Resend's free tier covers 3,000 emails per month with good deliverability and no daily cap. The FTH Lead Follow-up Cadence workflow in our production instance has logged 859 successful executions across 18 days with zero errors, running 48 times per day on a 30-minute poll cycle. That kind of sustained cadence isn't something you want on a credential that can expire without notice.
For Inbox Triage and Email Classification: Gmail Node
The scenario: the workflow watches an inbox for incoming support requests, vendor invoices, or lead inquiries. It reads the email body, classifies it, routes to the right handler, and marks the original message as processed.
This is where the Gmail node is the only option. The Send Email node has no read capability at all. It can't poll an inbox, read message bodies, retrieve thread context, or apply labels. It sends. That's it.
The Gmail node can do all of this: read new messages, extract sender and body, apply labels, mark as read, and pass the parsed content into the next node in your workflow.
A practical pattern we use: a Gmail Trigger polls every minute for new messages matching a specific label. The workflow extracts sender, subject, and body, passes it to a classifier (rules-based or AI), then applies one of three labels (urgent, normal, or junk) before posting a summary to Slack.
One thing to note about the Gmail Trigger: it polls on an interval, not a true push webhook. For near-real-time triage, set the poll interval to 1 minute and accept that there's some latency. If you need sub-minute response times on inbound email, you'll need a different inbound routing setup.
Our Prospect Reply Detector workflow runs on this pattern, polling Gmail every 30 minutes, logging 859 executions across 18 days with a 100% success rate. It never sends. It only reads and routes.
For credential setup on the Gmail node, the n8n Gmail node OAuth setup tutorial covers the full configuration.
For Approval Workflows: Send Email Node with "Send and Wait"
The scenario: a workflow pauses execution until a human replies with approval or rejection. Budget sign-offs, content review, quote confirmations.
The Send Email node has a Send and Wait for Response operation. When you use it, the workflow literally suspends at that node until the recipient replies. The reply content then passes into the next node for branching logic. The workflow can check whether the reply contains "approved" or "rejected" and route accordingly.
The Gmail node has no equivalent. There's no pause-and-resume mechanic available through Gmail's API in n8n. If you need an email-based human-in-the-loop gate, Send Email is the only option.
We use this pattern for client-facing approval loops: a manager receives an email, replies with a single word, and the workflow advances the deal automatically. The approval email comes from a business domain address (Send Email handles this natively), and the workflow resumes without any manual intervention on the automation side.
This is one of the most under-documented differentiators between the two nodes. It's the single deciding factor for any workflow that requires a human gate before proceeding.
For Support Reply Threads and Conversation Context: Gmail Node
The scenario: a customer emails support. The workflow generates a response and needs to send it inside the original thread, not as a new unrelated message.
The Gmail node's Reply operation handles this correctly. It sets the In-Reply-To and References headers automatically, which is what keeps a message inside an existing Gmail thread. The customer sees the reply nested under their original message.
The Send Email node sends fresh SMTP messages with no thread context. If you try to fake threading by manually setting In-Reply-To headers through the Send Email node, you'll run into inconsistent behavior across email clients. Some will thread it, others won't. Deliverability can also take a hit depending on how your SMTP provider handles those headers on outgoing messages.
For any workflow where reply context matters to the customer experience, use the Gmail node's Reply operation and let the API handle the headers correctly. This is the one scenario where Gmail's deep integration with the Gmail threading model is a genuine technical advantage, not just a credential preference.
For High-Volume Transactional Email (Order Confirmations, Alerts, Reports): Send Email Node
The scenario: the workflow sends order confirmations, daily digest reports, system alerts, or batch notifications. Volume can reach hundreds or thousands per day.
Gmail's API limits are the deciding factor here:
| Provider | Daily Send Cap |
|---|---|
| Gmail (personal) | 500 emails/day |
| Gmail (Google Workspace) | 2,000 emails/day |
| Resend (free tier) | ~100/day (3,000/month) |
| Amazon SES | No daily cap ($0.10 per 1,000 emails) |
| Mailgun | No daily cap (pay-per-send) |
Transactional workflows that start on the Gmail node reliably hit the cap around month 2 as usage grows. When that happens, the migration to Send Email node with a dedicated SMTP provider becomes a forced rebuild under time pressure, not a planned upgrade. Build it on Send Email from the start.
For high-volume transactional, Amazon SES through the Send Email node is the production choice: no daily cap, strong deliverability reputation, and $0.10 per 1,000 emails makes the cost negligible at most business volumes.
MyGolfBridge, one of the products running on our platform, uses the Send Email node for all five of its email workflows: email verification, parent invite, parent notification, password reset, and contact form notification. Zero Gmail node usage across the entire product. That's not a coincidence. App-to-user transactional email (especially verification and password reset) requires a system sender identity, not a personal OAuth account.
For Google Workspace-Native Pipelines: Gmail Node
The scenario: your workflow already connects Google Sheets, Google Drive, and Google Calendar. You're adding email sending as one more step in the same pipeline.
The Gmail node works cleanly here because all Google nodes share the same OAuth2 credential. Your workflow reads a row from Sheets, creates a Calendar event, and sends a confirmation email. One credential set manages all three operations. There's no second authentication layer to configure or maintain.
This credential consolidation is a real convenience in complex multi-step workflows. When you're already deep in a Google Workspace stack, adding the Gmail node for email is the path of least resistance.
One exception: if the confirmation email needs to come from a custom domain rather than @gmail.com, switch to the Send Email node even inside a Google Workspace pipeline. Domain matters more than credential convenience. A confirmation email from [email protected] is worth the extra credential setup.
The Hybrid Pattern: Use Both Nodes in the Same Workflow
The pattern that no competing guide covers: Gmail node for inbound, Send Email node for outbound, in the same workflow.
Here's the architecture. A Gmail Trigger watches an inbox for new support emails. The workflow reads the message body, passes it to an AI node to draft a response, then hands off to the Send Email node to send the reply from [email protected] via SMTP.
Why this beats using only one node: the Gmail node handles the one thing only it can do (read from an inbox). The Send Email node handles the one thing it does better than Gmail (send from a custom domain). Each node is doing exactly what it's optimized for.
This is the architecture we use for client support automation workflows. The inbound reading uses Gmail's polling capability. The outbound response uses SMTP with a branded domain. You don't have to choose one node for both directions, and you shouldn't.
Quick Reference: Workflow Type to Node Mapping
| Workflow Type | Recommended Node | Key Reason |
|---|---|---|
| CRM notifications | Send Email | Custom domain + no OAuth expiry risk |
| Lead follow-up sequences | Send Email | Volume headroom + custom domain |
| Inbox triage / classification | Gmail | Only node that can read an inbox |
| Approval workflows with human gate | Send Email | "Send and Wait" operation (Gmail has no equivalent) |
| Support thread replies | Gmail | Reply operation preserves thread headers |
| High-volume transactional (confirmations, alerts) | Send Email | No API daily cap via dedicated SMTP |
| Google Workspace pipelines | Gmail | Shared OAuth credential across all Google nodes |
| Hybrid inbound + outbound | Both | Gmail reads, Send Email sends from custom domain |
Frequently Asked Questions
Can I switch from the Gmail node to the Send Email node without rebuilding my workflow?
In most cases, yes. If your workflow only sends (no reading, labeling, or replying), swapping the Gmail node for a Send Email node is usually a node-level replacement. You'll need to reconfigure the credential and map the To, Subject, and Body fields, but the surrounding workflow logic stays intact. The exception is reply workflows. If you're using Gmail's Reply operation to maintain thread context, there's no direct equivalent in Send Email, and you'd need to rethink that step.
Does the n8n Gmail node work for bulk sends?
It works up to the API limits: 500/day for personal accounts, 2,000/day for Google Workspace. Below those thresholds, yes. Above them, the Gmail node will throw errors. For anything where volume might grow, use the Send Email node with a dedicated SMTP provider instead.
Which n8n email node is better for a CRM?
For CRM notification use cases (deal stage alerts, lead assignment notifications, client updates), the Send Email node is the better choice. It sends from a business domain, doesn't depend on OAuth tokens that can expire mid-workflow, and includes the Send and Wait operation for approval gates. For CRM workflows that also need to detect inbound replies (a salesperson replying to a follow-up email, for example), pair the Gmail node for inbox monitoring with the Send Email node for outbound.
Can the Gmail node send from a custom domain?
Not natively. The Gmail node sends from the authenticated Google account's address. If that account is [email protected] on Google Workspace, the email comes from that address. But if you want to send from [email protected], [email protected], or a shared alias not attached to a real Google account, the Gmail node can't do it. The Send Email node handles any SMTP-accessible address, including custom shared inboxes.
Wrapping Up
The better node is determined by what your workflow is doing, not by which node has more features on a comparison sheet.
Send Email for outbound-only workflows where domain identity and volume headroom matter. Gmail for inbox-interactive workflows where reading, labeling, or threading are part of the logic. And the hybrid pattern when one workflow needs to do both.
If you want the credential setup comparison and a side-by-side feature breakdown, the Send Email vs Gmail node companion post covers that ground in detail. For a hands-on configuration walkthrough of the Send Email node specifically, see the Send Email node tutorial.
If you're building a workflow and want a second opinion on the architecture, get in touch. We build n8n automation stacks for client businesses and can help you avoid the credential and volume issues that tend to surface a few months into production.
Disclosure: This post contains affiliate links. If you sign up for n8n through our link, we may earn a commission at no additional cost to you.