n8n Send Email Node Not Working: 5 Common Errors and Fixes

The n8n Send Email node fails most often because of incorrect SMTP credentials, specifically using a regular Gmail password instead of a 16-character App Password. Here is how to fix it in 3 steps: generate an App Password at myaccount.google.com/apppasswords, paste it into your n8n Send Email credential's Password field, and test the connection. Beyond authentication, the node also breaks from port-and-encryption mismatches, missing Gmail OAuth scopes, cloud hosting blocking outbound SMTP, or binary property name mismatches on attachments. This guide maps each error message to its root cause and walks you through the fix.

Disclosure: Some links on this page are affiliate links. If you sign up for n8n through one of these links, we may earn a small commission at no extra cost to you.

n8n Send Email Node Not Working: Error Message Lookup Table

Every common n8n email error maps to one of five root causes. The table below lets you match your exact error string to the right fix section in this guide, so you skip the troubleshooting steps that don't apply to your situation.

If you're seeing an error in your n8n Send Email node setup guide execution log, find the closest match below.

Error Message	Root Cause	Fix Section
535 5.7.8 Error: authentication failed	Wrong password type (regular password instead of App Password) or incorrect username	Error 1: SMTP Authentication
454 4.7.0 Cannot authenticate due to temporary system problem	Google temporarily locked the account after failed attempts	Error 1: SMTP Authentication
Bad request - please check your parameters (item 0)	Gmail node missing required OAuth scope (gmail.send)	Error 2: Gmail OAuth Scope
self signed certificate in certificate chain	TLS/SSL mismatch or corporate CA certificate not trusted	Error 3: TLS/SSL Certificate
ECONNRESET	Connection dropped mid-handshake, usually port/encryption mismatch	Error 3: TLS/SSL Certificate
Connection closed unexpectedly	Port 587 configured with SSL/TLS instead of STARTTLS	Error 3: TLS/SSL Certificate
Client network socket disconnected before secure TLS connection was established	STARTTLS negotiation failed or port blocked at network level	Error 3 or Error 4
Connection timeout (no error, node hangs)	VPS/cloud provider blocking outbound SMTP port	Error 4: VPS Port Blocking
Email sends successfully but attachment is missing	Binary Property name doesn't match output key from previous node	Error 5: Attachment Binary

Error 1: SMTP Authentication Failed (535 5.7.8)

The 535 5.7.8 Error: authentication failed message means your SMTP server rejected the credentials you provided in the n8n Send Email node. For Gmail and Google Workspace accounts with 2FA enabled (which Google now requires for most accounts), you need an App Password, not your regular login password.

This is the single most common reason the n8n Send Email node stops working. Here's why it happens and how to fix it.

Why Regular Passwords Don't Work

Google disabled Less Secure Apps for consumer Gmail in 2022 and completed the rollout to Workspace accounts by May 2025. If you have two-factor authentication enabled (and you should), Google requires a 16-character App Password for SMTP connections from third-party applications like n8n.

Your regular Gmail password will return 535 5.7.8 every time, even if you triple-check the spelling. The password itself is correct for Google's login page. It just isn't valid for SMTP.

How to Generate a Gmail App Password

1. Go to myaccount.google.com/apppasswords
2. Sign in with your Google account
3. Select "Mail" as the app and "Other" as the device (name it "n8n" for clarity)
4. Click Generate
5. Copy the 16-character password Google provides (spaces don't matter)
6. In n8n, open your Send Email credentials and paste this App Password into the Password field
7. Test the connection

The 454 Lockout Error

If you see 454 4.7.0 Cannot authenticate due to temporary system problem, Google has temporarily locked authentication for your account. This happens after multiple rapid failed login attempts, which is common when you're testing different password combinations.

The fix: based on community reports, waiting 15 to 30 minutes before retrying is typically sufficient, though Google does not publish a specific cooldown window. Don't keep retrying, as each failed attempt extends the lockout.

In our own n8n stack at Rain Automation, we use Google Workspace SMTP relay (smtp-relay.gmail.com on port 587 with STARTTLS) instead of standard Gmail SMTP. The relay authenticates at the domain level rather than per-user, which avoids App Password management entirely and supports up to 10,000 emails per day. If you're running n8n for business workflows, Google Workspace SMTP relay is worth the setup time. For a full inventory of every credential field and option the node exposes, see the full node parameter reference for n8n-nodes-base.emailsend.

Error 2: Gmail OAuth Scope Issues (Bad Request)

The Gmail node error Bad request - please check your parameters (item 0) is misleading because it sounds like a formatting problem. The actual cause is a missing or incorrect OAuth scope on your Google Cloud project, meaning the Gmail API doesn't have permission to send email on your behalf.

This error only affects the Gmail node (not the Send Email / SMTP node). The Gmail node uses OAuth 2.0 through the Google Cloud Console, and its permissions are controlled by the scopes you requested during setup.

Common Scope Problems

Three situations cause this error:

• Missing gmail.send scope. During OAuth setup, you need to explicitly add https://www.googleapis.com/auth/gmail.send (or the broader gmail.modify) to your Google Cloud project's OAuth consent screen. Without it, the token your n8n credential holds can read email but can't send.
• OAuth consent screen in "Testing" mode. Google Cloud projects start with the consent screen in testing mode, which limits access to test users you've explicitly added. If the Google account you're trying to send from isn't listed as a test user, the API silently rejects the request. Move the consent screen to "Production" or add your email as a test user.
• Service account without domain-wide delegation. If you're using a service account (common in automated workflows), the service account needs domain-wide delegation enabled in Google Admin, with impersonation configured for the sending user's email address.

How to Fix Gmail Node OAuth

1. Open the Google Cloud Console
2. Go to APIs & Services, then OAuth consent screen
3. Under Scopes, confirm gmail.send or gmail.modify is listed
4. If it's missing, click Edit App, then Add or Remove Scopes, search for Gmail API, and check the send scope
5. Under Test Users, confirm your sending email address is listed (if still in Testing mode)
6. Back in n8n, delete the existing Gmail credential and create a new one (re-authentication picks up the new scopes)
7. Re-authorize when prompted and test the node

So here's the thing: deleting and recreating the credential is not optional. Existing OAuth tokens don't automatically pick up new scopes. You have to re-authorize to get a fresh token that includes gmail.send.

If you're unsure whether to use the Gmail node or the Send Email node, we wrote a detailed comparison in our n8n Send Email Node vs Gmail Node guide. If you've already decided on the Gmail node and need to work through the OAuth credential setup, the step-by-step OAuth configuration guide covers the Google Cloud Console project, consent screen, and the 7-day token expiry fix that breaks most self-hosted credentials.

Error 3: TLS/SSL Certificate Mismatch

The self signed certificate in certificate chain and ECONNRESET errors mean n8n can't establish a secure connection to your mail server. The most common cause is a mismatch between the port number and the encryption type configured in your Send Email credentials.

This error catches a lot of people because the symptoms look identical to an authentication failure. The connection dies during the TLS handshake before credentials even get sent, but n8n sometimes surfaces it as a vague connection error rather than a clear TLS message.

Port and Encryption Pairing Table

There are exactly three valid combinations. Anything else will fail.

Port	Encryption Setting in n8n	Protocol	Common Providers
25	None	Unencrypted SMTP	Internal/relay servers only
465	SSL/TLS	Implicit TLS (connection starts encrypted)	Older Gmail config, some corporate servers
587	STARTTLS	Starts plain, upgrades to TLS	Gmail, Google Workspace, Outlook, most modern providers

The two most common mismatches:

1. Port 587 + SSL/TLS (should be STARTTLS). Port 587 expects a STARTTLS upgrade handshake. Setting it to SSL/TLS makes n8n try to start the connection encrypted, which port 587 doesn't understand. The server drops the connection and you see Connection closed unexpectedly. Multiple n8n community threads confirm this is the most-reported configuration error.

2. Port 465 + STARTTLS (should be SSL/TLS). Port 465 expects the connection to be encrypted from the start. Sending a STARTTLS upgrade request to a port that's already expecting TLS causes an ECONNRESET.

Fix Steps for TLS Errors

1. Open your Send Email credentials in n8n
2. Check the port number and match it against the table above
3. Set the correct encryption type for that port
4. If you're using Gmail SMTP: port 587 with STARTTLS is the current recommended configuration per Google's documentation
5. Save and test

Self-Signed Certificates (Corporate/Internal Servers)

If your mail server uses a self-signed certificate or an internal CA (common behind corporate firewalls), n8n's Node.js runtime won't trust it by default.

Why the Most Upvoted TLS Fix Is Wrong for Production

The most upvoted answer on virtually every n8n TLS thread, including GitHub Issue #1491 and multiple n8n community posts, is to set NODE_TLS_REJECT_UNAUTHORIZED=0. That answer is wrong for production. Here is why:

Setting that variable to 0 tells Node.js to accept any certificate, including forged ones. In practice, this means a compromised network device between your n8n server and the SMTP host can intercept every email your workflows send, including ones containing customer data, invoices, or password reset links. The connection looks encrypted to your logs, but the attacker holds the keys. This is a textbook man-in-the-middle vulnerability, and it affects every outbound TLS connection your n8n instance makes, not just email.

The correct fix depends on why the certificate fails:

• Self-signed or internal CA: Add the CA certificate to n8n's trust store by setting the NODE_EXTRA_CA_CERTS environment variable to point to your CA's .pem file. In Docker, mount the certificate file and add NODE_EXTRA_CA_CERTS=/path/to/ca.pem to your environment variables.
• Port/protocol mismatch causing a TLS handshake failure: Fix the port and encryption pairing using the table above (port 587 + STARTTLS, port 465 + SSL/TLS). This resolves most ECONNRESET and Connection closed unexpectedly errors without touching any environment variable.
• Expired certificate on the mail server: Renew the certificate. If it's a third-party provider, contact their support. If it's your own server, certbot renew or equivalent.

We run production n8n workflows that handle customer notifications and CRM updates. Disabling certificate verification was never on the table for us, and it shouldn't be for you either.

After changing environment variables, restart your n8n instance. Docker users need to restart the container (docker compose restart n8n), not just reload the workflow.

Error 4: VPS or Cloud Hosting Blocking Outbound SMTP

If your n8n Send Email node hangs with no error, times out, or silently fails to deliver, your cloud hosting provider is likely blocking outbound SMTP traffic on ports 25, 465, and/or 587. This is a default security measure on DigitalOcean, AWS EC2, Oracle Cloud, and most major VPS providers.

This one is particularly frustrating because the node might show a green checkmark (execution succeeded) while no email actually arrives. Or the node just hangs indefinitely with no error message at all.

That same green-checkmark-but-nothing-happened symptom shows up across n8n workflows well beyond email, and we cover the silent failure patterns that make n8n workflows look successful when they aren't in a companion guide.

If your node executes cleanly but nothing lands in the inbox, there is more going on than a simple port block. See what to check when n8n sends email but nothing arrives for a full SPF, DKIM, and relay walkthrough that goes beyond the SMTP error log.

Which Providers Block SMTP

Per DigitalOcean's own documentation, new accounts have outbound SMTP blocked by default. You can request removal after verifying your account and explaining the use case. AWS EC2 restricts outbound traffic on port 25 by default and requires a request to remove the restriction. We run our production n8n on Oracle Cloud, where port 25 is blocked by default on compute instances, so we route all outbound email through an authenticated SMTP relay instead of direct delivery.

A Reddit user in r/n8n described this exact scenario: credentials worked perfectly on a local machine, but after migrating n8n to a DigitalOcean droplet, emails stopped delivering with no error. The SMTP node appeared to execute successfully.

How to Diagnose Port Blocking

SSH into your server and test outbound connectivity:

# Test port 587 (STARTTLS)
telnet smtp.gmail.com 587

# If telnet hangs or times out, the port is blocked
# If you see "220 smtp.gmail.com" the port is open

If the port is blocked, you have two paths forward.

Option A: Request Port Unblocking

Contact your hosting provider's support and request outbound SMTP access. Review times vary, and DigitalOcean evaluates requests on a case-by-case basis with no guaranteed approval timeline. Include your domain, SPF records, and a brief description of what emails you're sending.

Option B: Use an External SMTP Relay (Recommended)

But the more reliable long-term solution is routing through an external SMTP service that uses API-based delivery or non-standard ports. At Rain Automation, rather than fighting port restrictions on our Oracle Cloud instance, we route outbound email through Google Workspace SMTP relay on port 587, which Oracle Cloud permits for authenticated connections.

Popular relay options include:

• SendGrid (60-day trial: 100 emails/day, then paid plans from $19.95/month)
• Mailgun (free tier: 100 emails/day, no expiration)
• Amazon SES (pennies per email, requires AWS account)
• Google Workspace SMTP relay (up to 10,000/day for Workspace accounts)

Before committing to a relay, it helps to see what Gmail relay, Mailgun, SendGrid, and Postmark each offer for production n8n workflows, including the authentication requirements and sending limits that matter most when you are self-hosting on a VPS.

This brings up an important volume consideration. Gmail free accounts are limited to 100 emails per day via SMTP (500 per day via the web interface), and Google Workspace accounts are limited to 2,000 per day per Google's documentation. If your email marketing automation workflows need more volume, SendGrid, Mailgun, or Amazon SES are the standard alternatives.

Error 5: Attachment Not Sending (Binary Property Mismatch)

When your n8n Send Email node executes successfully and the email arrives without the attachment you expected, the cause is almost always a mismatch in the Binary Property field name. This field is case-sensitive and must exactly match the key name from the previous node's binary output.

This isn't a permissions issue or a file size problem. It's a naming problem.

How Binary Properties Work in n8n

When a node outputs binary data (like a Read File node, HTTP Request node downloading a file, or a Spreadsheet node generating a CSV), the output panel shows the data under a specific key name. Common defaults include data, attachment, or file.

The Send Email node's Attachments section has a Binary Property field where you specify which binary key to attach. If you type attachment but the previous node output uses data, the Send Email node won't find any binary data to attach. It doesn't throw an error. It just sends the email without the attachment.

Fix Steps

1. Click on the node that produces the file (the node connected before your Send Email node)
2. Run it and check the Output panel
3. Look at the Binary Data section and note the exact key name (e.g., data, attachment_0, file)
4. Copy that key name exactly, including capitalization
5. Paste it into the Send Email node's Binary Property field
6. If attaching multiple files, separate key names with commas

Here is a real example from our own stack. Our automated invoice reminder workflow at Rain Automation sends roughly 200 transactional emails per day through smtp-relay.gmail.com. In March 2026, we added a Function node upstream that reformatted the PDF filename before attaching it. That Function node changed the binary output key from data to invoice_pdf, but the Send Email node three steps downstream still referenced data in its Binary Property field. The workflow ran for eleven days, sending 2,200+ emails with no attachment and no error, before we caught it in a delivery audit. The fix took 30 seconds: update the Binary Property field to invoice_pdf.

The lesson when building n8n workflows: any time you edit a node that touches binary data upstream, check every downstream node that references that binary key. n8n won't warn you about the mismatch.

n8n Send Email Node Not Working: The CAP-T Diagnostic (Credentials, Access, Ports, Transfer)

Before working through the five error sections above, run the CAP-T diagnostic to narrow down your issue in under two minutes. CAP-T stands for Credentials, Access (OAuth scopes and permissions), Ports (network connectivity), and Transfer (binary data and attachments). Start from the top and stop at the first failure point.

Step	Test	Expected Result	If It Fails
1	Open Send Email credentials, click "Test"	Green checkmark	Jump to Error 1 (auth) or Error 3 (TLS)
2	In credential settings, verify port + encryption match	Port 587 + STARTTLS or Port 465 + SSL/TLS	Jump to Error 3
3	SSH to server: telnet smtp.gmail.com 587	See 220 smtp.gmail.com	Jump to Error 4 (port blocked)
4	Run the Send Email node with test data	Email arrives in inbox (check spam)	Check recipient address, sender domain SPF/DKIM
5	Send with attachment, check Binary Property name	Attachment present in received email	Jump to Error 5
6	Run full workflow end-to-end	All items processed, all emails received	Check for loop/batch issues in upstream nodes

After changing any environment variable (like NODE_EXTRA_CA_CERTS or Docker compose settings), restart your n8n instance. Changes to .env files don't take effect until the n8n process restarts.

Send Email Node vs Gmail Node: When to Switch

If you've been troubleshooting the Send Email node and the fix requires infrastructure changes you can't make (like unblocking SMTP ports), switching to the Gmail node (or vice versa) might be the faster path. Here's when each node is the right choice.

We covered this comparison in depth in our n8n Send Email Node vs Gmail Node guide, but here's the quick decision framework.

Dimension	Send Email Node (SMTP)	Gmail Node (OAuth)
Provider support	Any SMTP server (Gmail, Outlook, custom)	Google/Gmail only
Authentication	Username + password (or App Password)	OAuth 2.0 via Google Cloud Console
Port requirements	Needs outbound 465 or 587	HTTPS only (port 443), works behind firewalls
Email threading	No In-Reply-To or References headers per n8n docs	Supports threading natively
Attachments	Binary Property field	Binary Property field (same)
Setup complexity	Lower (just SMTP credentials)	Higher (Google Cloud project + OAuth consent)
Best for	Multi-provider environments, transactional email	Google Workspace shops, threaded conversations

Choose Send Email (SMTP) If:

• You use a non-Google email provider
• You want simpler credential setup
• You need to send from multiple domains
• Your server allows outbound SMTP traffic

Choose Gmail Node If:

• Your VPS blocks SMTP ports (Gmail node uses HTTPS, which is never blocked)
• You need email threading for conversation replies
• You're already using Google Cloud for other n8n integrations
• You want token-based auth instead of managing App Passwords

If your workflow needs go beyond email (lead routing, CRM sync, client notification systems, reporting dashboards), our custom development page shows the kind of platforms we build for service businesses.

Frequently Asked Questions

The questions below cover the most common n8n email node errors. Each answer stands alone so you can bookmark the one that matches your situation.

How do I fix "535 5.7.8 Error: authentication failed" in the n8n Send Email node?

This error means your SMTP server rejected the password you provided. If you use Gmail or Google Workspace with 2FA enabled, generate a 16-character App Password at myaccount.google.com/apppasswords, paste it into your n8n credential's Password field, and retest. Regular Gmail passwords no longer work for SMTP.

What causes "ECONNRESET" or "Connection closed unexpectedly" in n8n email?

These errors indicate a port-and-encryption mismatch in your Send Email credentials. Port 587 requires STARTTLS, and port 465 requires SSL/TLS. If you set port 587 with SSL/TLS (or port 465 with STARTTLS), the mail server drops the connection immediately. Match the encryption type to the port number and save.

Why is my n8n workflow executing but not sending emails?

The most common cause is your VPS provider blocking outbound SMTP ports. The node executes and shows a green checkmark, but the email never leaves the server. Test with telnet smtp.gmail.com 587 from your server's command line. If the connection times out, switch to the Gmail node (which uses HTTPS) or use an SMTP relay service.

What Gmail App Password do I use for the n8n Send Email node?

Generate one at myaccount.google.com/apppasswords. It's a 16-character code specific to SMTP access. Use it in the Password field of your n8n Send Email credentials instead of your regular Gmail password. You need 2FA enabled on your Google account to access the App Passwords page.

Why does n8n Send Email work in testing but not in production?

Three likely reasons: (1) your local machine allows outbound SMTP but your production server blocks it, (2) you're hitting Gmail's 100 emails/day SMTP sending limit in production volume, or (3) environment variables like TLS settings differ between your local and production n8n instances. Check all three.

How do I fix "self signed certificate in certificate chain" in n8n?

Set the NODE_EXTRA_CA_CERTS environment variable to point to your CA's certificate .pem file. In Docker, mount the file and add it to your compose environment. Avoid NODE_TLS_REJECT_UNAUTHORIZED=0 as it disables all certificate checking and creates a security risk.

Should I use the Gmail node or the Send Email node in n8n?

Use the Gmail node if your server blocks SMTP ports or you need email threading for conversation replies. Use the Send Email node if you want simpler setup or need non-Google providers. Both nodes can send email reliably when configured correctly. Our full comparison is in the Gmail Node vs Send Email Node guide.

Does DigitalOcean block n8n from sending email?

Yes, by default. DigitalOcean blocks outbound SMTP on ports 25, 465, and 587 for new accounts. This applies to all new Droplets regardless of account age or plan tier. You can request removal through their support portal, or use an external relay service like SendGrid or Mailgun that doesn't rely on direct SMTP connections.

Why does my n8n Send Email node hang with no error message?

A node that hangs indefinitely or times out without an error usually means your cloud hosting provider (DigitalOcean, AWS EC2, Oracle Cloud) is blocking outbound SMTP ports. Test with telnet smtp.gmail.com 587 from your server. If it times out, switch to the Gmail node (uses HTTPS on port 443) or route through an external SMTP relay like SendGrid or Mailgun.

How to Prevent n8n Email Node Failures for Good

Most n8n Send Email problems come down to one of five causes: wrong credential type, missing OAuth scope, port/encryption mismatch, hosting provider port blocking, or a binary property name typo. If you haven't set up the node yet, start with our n8n Send Email node setup guide to get the configuration right the first time. The error message lookup table at the top of this guide should get you to the right fix in under a minute.

If you're building n8n workflows that rely on email delivery for notifications, lead follow-up, or customer communication, getting the email node configured correctly the first time saves hours of debugging later. And if your workflows go beyond a single Send Email node into multi-step automation sequences, the configuration patterns in this guide apply to every email-sending step in the chain.

And if your n8n email workflows are part of a larger CRM integration project, our n8n CRM integration hub maps out how the pieces fit together across HubSpot, Pipedrive, and custom CRM setups.

If you want to go beyond fixing individual nodes and build workflows that handle decisions end to end, see our guide to AI agents for business automation.

Disclosure: Some links in this article are affiliate links. If you sign up for n8n through our link, we may receive a commission at no extra cost to you. We only recommend tools we use in our own production workflows.