n8n Email Sends But Never Arrives: 6-Step Delivery Fix Guide

If your n8n workflow shows a success status but the email never arrives, this is a delivery problem, not an SMTP connection error. After running 50+ production email workflows on our self-hosted n8n instance at Rain Automation, I've learned that a green checkmark only means the SMTP relay accepted the handshake. It says nothing about whether the recipient's inbox accepted the message. The three most common reasons emails vanish after a successful n8n execution are FROM domain mismatch with your SPF record, VPS outbound port blocking, and missing DKIM signatures.

Why n8n Email Sends But Is Not Received: The Delivery Gap Explained

n8n's green checkmark confirms one thing: the SMTP server at the other end returned a 250 OK response during the handshake. It does not confirm the email reached the recipient's inbox, passed spam filters, or even left the relay's outbound queue. These are three distinct failure layers, and conflating them is the reason most troubleshooting guides miss the real problem.

Here's how I think about email delivery failures in n8n. There are three layers, and each one produces a different symptom:

Layer	What Happens	n8n Status	User Experience
Layer 1: SMTP Handshake Failure	Node can't connect to the SMTP server	Red error in execution log	You see an error message immediately
Layer 2: Relay Accepts, Inbox Rejects	SMTP relay says 250 OK but recipient server rejects or drops the message	Green checkmark	Email never arrives, no error visible in n8n
Layer 3: Inbox Delivery, Hidden in Spam	Email reaches recipient server but lands in spam or Promotions tab	Green checkmark	Email "exists" but recipient never sees it

Layer 1 failures are connection errors. If you're seeing red error messages in your n8n execution log, check our existing guide on n8n Send Email node errors for SMTP connection issues, TLS mismatches, and port problems.

This post targets Layers 2 and 3: the email left n8n successfully but never showed up in the recipient's inbox. This is the exact scenario described in the n8n community thread "Emails being sent through n8n but not received" from 2025, where a user ran a Gmail node workflow to 30 recipients on a cron schedule. n8n execution logs showed complete. Emails appeared in the Gmail Sent folder. But recipients received nothing. The root cause: Gmail's automation detection moved all sends to recipient spam.

In my experience running n8n workflows across six production sites, most "sends but not received" problems trace back to one of six checkpoints. Let me walk through each one.

Step 1: Confirm the Email Actually Left n8n's SMTP Relay

Before troubleshooting DNS records or spam filters, verify the SMTP relay genuinely accepted your message. A 250 OK response in n8n's execution output confirms relay acceptance. Anything in the 4xx or 5xx range means the relay rejected or deferred the message, even if n8n's UI shows a green status.

Open your n8n execution log for the failed send. Click the Send Email node and expand the output panel. Look for the SMTP response code in the output data. What you want to see:

• 250 OK or 250 2.0.0 OK: The relay accepted the message for delivery. The problem is downstream (continue to Step 2).
• 421 or 450: Temporary rejection. The relay was too busy or rate-limiting you. Retry later.
• 550 or 553: Permanent rejection. The relay refused the message, usually due to authentication failure or a blocked sender address.

Now check your SMTP provider's dashboard. If you're using Gmail's SMTP relay (smtp-relay.gmail.com), check the Sent folder of the sending account. If you're using Mailgun, check Events > Delivered vs. Bounced. If you're using SendGrid, check Activity Feed.

Here's the thing. n8n does not track what happens after the SMTP handshake. The node's job ends when the relay says "accepted." Everything after that, delivery routing, spam classification, bounce handling, is invisible to n8n. That's why you need to check the relay's own logs, not just n8n's execution output.

A related scenario from the n8n community thread "I send an email via 'send email' but it doesn't reach the destination" from November 2022: a user got a positive SMTP response from their HostGator relay, but emails never arrived. The root cause was that the relay accepted the handshake but silently dropped messages due to missing SPF alignment on the FROM domain. The relay said "yes" and then did nothing.

If you want a deeper look at how the Send Email node handles SMTP responses, our n8n Send Email node tutorial covers the full configuration.

Step 2: Check the Recipient's Spam and Promotions Folders

Automated workflow emails almost always land in spam when the sending domain lacks SPF and DKIM records. Before assuming the email disappeared, have the recipient check their spam folder, Gmail Promotions tab, and Outlook Junk folder. Roughly 46-48% of all email worldwide is classified as spam according to 2026 spam traffic analysis from Email Tool Tester.

This sounds obvious, but I've solved more "missing email" tickets by checking spam folders than by touching DNS records. The check procedure varies by provider:

Gmail recipients:

1. Check the Spam folder directly
2. Check the Promotions tab (Gmail categorizes automated emails here by default)
3. Check the Updates tab (transactional emails sometimes land here)
4. Search for the sender's email address in the search bar with in:anywhere

Outlook/Microsoft 365 recipients:

1. Check Junk Email folder
2. Check Focused vs. Other inbox tabs
3. Check Quarantine (admin-level, if organization uses Exchange Online Protection)

Other providers:

1. Check the spam or junk folder
2. Check if the domain is on the provider's block list

If the email is in spam, the message was delivered successfully but classified as unwanted. This is a Layer 3 problem. The fix is in Steps 3 and 5 below (SPF/DKIM/DMARC records and transactional relay). If the email isn't in spam either, you have a Layer 2 problem, and you need to verify your domain's authentication records before going further.

One pattern I see repeatedly: a test email works fine (because it's a single send to yourself), but production emails to 10+ recipients fail. Gmail and Outlook apply stricter filtering to batch sends from unauthenticated domains. The n8n community reports confirm this. Sending from a shared VPS IP with no DKIM signing and no SPF record is a reliable recipe for landing in spam.

Step 3: Verify Your Domain's SPF, DKIM, and DMARC Records

If your FROM address sends from [email protected] but your domain's SPF record doesn't authorize your SMTP relay's IP, recipient servers will either reject the email or file it in spam. This is the number one silent delivery killer in n8n workflows, and it takes 2 minutes to diagnose with a free MXToolbox lookup.

Here's what each record does in plain terms:

• SPF (Sender Policy Framework): A DNS TXT record that lists which servers are allowed to send email on behalf of your domain. If your n8n instance sends through smtp-relay.gmail.com but your SPF record only authorizes mail.yourdomain.com, recipient servers see a mismatch and flag or reject the message.
• DKIM (DomainKeys Identified Mail): A cryptographic signature attached to each outgoing email. The recipient server checks the signature against a public key published in your DNS. If the signature is missing or doesn't match, trust drops significantly.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): A policy record that tells recipient servers what to do when SPF or DKIM checks fail: none (monitor only), quarantine (send to spam), or reject (block entirely).

To check your records right now:

1. Go to MXToolbox SPF Lookup and enter your FROM domain
2. Look for your SMTP relay in the SPF record. If you're using Gmail relay, you should see include:_spf.google.com. If you're using Mailgun, look for include:mailgun.org.
3. Go to MXToolbox DKIM Lookup and enter your domain + selector (your email provider gives you the selector during setup)

If you prefer the command line, run this from your n8n server:

dig TXT yourdomain.com +short | grep spf

A passing SPF record looks like:

"v=spf1 include:_spf.google.com ~all"

A failing or missing record returns nothing, or returns a record that doesn't include your relay's domain.

What I tell clients: if you're sending from [email protected] through Gmail's SMTP relay, your SPF record for yourbusiness.com must include _spf.google.com. If you're sending through Mailgun, it must include mailgun.org. The FROM domain and the SPF authorization must match. This single check resolves about 40% of the "sends but not received" cases I troubleshoot.

For a detailed comparison of how the Send Email node and the Gmail node handle authentication differently, see our n8n Send Email vs Gmail Node guide.

Step 4: Test Outbound SMTP Port Connectivity From Your Server

If you self-host n8n on a VPS (Oracle Cloud, DigitalOcean, AWS, Hetzner), your cloud provider likely blocks outbound port 25 by default and may restrict ports 465 and 587. Run a 2-command connectivity test from your server to confirm which ports are open before debugging anything else.

This is something I learned the hard way. Rain's n8n instance runs on Oracle Cloud VPS (Oracle Cloud Linux, Ampere). Oracle Cloud blocks outbound port 25 entirely, which means any SMTP configuration using port 25 will silently fail. The n8n node accepts the configuration, the workflow runs, but the TCP connection to the SMTP server never completes on that port. We route all n8n email sends through port 587 via smtp-relay.gmail.com with an app password.

Here's the 2-command verification procedure you can run from your n8n server's terminal:

# Test port 587 (STARTTLS, recommended)
nc -zv smtp.gmail.com 587 -w 5

# Test port 465 (implicit TLS)
nc -zv smtp.gmail.com 465 -w 5

Expected output if the port is open:

Connection to smtp.gmail.com 587 port [tcp/submission] succeeded!

Expected output if the port is blocked:

nc: connect to smtp.gmail.com port 587 (tcp) timed out: Operation timed out

If nc (netcat) isn't installed, use telnet instead:

telnet smtp.gmail.com 587

You should see a 220 greeting from the SMTP server. If the connection hangs or times out, the port is blocked at the network level.

What to do if ports are blocked:

1. Contact your VPS provider to request outbound SMTP port access. Oracle Cloud, DigitalOcean, and AWS all have processes for this (usually a support ticket with a business justification).
2. Try port 587 if you're currently using port 25 or 465. Port 587 is more widely permitted than port 25 or 465, but some VPS providers including DigitalOcean block all outbound SMTP ports by default and require a support ticket to unblock. Verify connectivity with the nc command above regardless of which port you configure.
3. Use a transactional email API (Step 5 below) that sends over HTTPS port 443 instead of SMTP ports entirely.

For more context on configuring SMTP ports and TLS settings in n8n, our n8n emailsend node reference covers every parameter.

Step 5: Use a Dedicated Transactional Email Relay Instead of Direct SMTP

When direct SMTP keeps failing silently, switch to a transactional email relay like Mailgun, SMTP2GO, or Resend. These services handle SPF/DKIM signing on your behalf, provide delivery logs that n8n can't, and route through high-reputation IPs that inbox providers trust. For most n8n users, this is the permanent fix.

Here's my rule of thumb: if you're sending fewer than 10 emails per day from n8n and they all go to your own team, direct SMTP through Gmail is fine. The moment you send to external recipients, customers, leads, or vendors, use a transactional relay.

Before picking a relay, compare the three most popular options for self-hosted n8n deployments:

Feature	Mailgun	Resend	SMTP2GO
Free Tier Limit	100 emails/day (~3,000/month)	3,000 emails/month (100/day)	1,000 emails/month
Free Tier Duration	Permanent	Free tier (verify at resend.com)	Permanent
DKIM Signing	Automatic	Automatic	Automatic
SMTP Host	smtp.mailgun.org	smtp.resend.com	mail.smtp2go.com
SMTP Port	587 (STARTTLS)	587 (STARTTLS)	2525 or 587
Paid Plans From	$35/month (50k emails)	$20/month (50k emails)	$15/month (10k emails)
Delivery Logs	Per-message events (delivered, opened, bounced)	Webhook events	Per-message logs + analytics

Here are the specific n8n SMTP credential settings for Mailgun, one of the most common relays for self-hosted n8n deployments:

Setting	Value
SMTP Host	smtp.mailgun.org
SMTP Port	587
SSL/TLS	STARTTLS
User	Your full Mailgun SMTP username (e.g., [email protected])
Password	Your Mailgun SMTP password (not your account password)
FROM Address	Must match a verified domain in Mailgun (e.g., [email protected])

To set this up in n8n:

1. Go to Credentials in your n8n dashboard
2. Create a new SMTP credential
3. Enter the Mailgun settings from the table above
4. Set the FROM address to match your Mailgun verified domain
5. Test by sending to yourself first, then check Mailgun's Events dashboard for the delivery status

Why this works: Mailgun (and similar relays) automatically sign every outbound email with DKIM using their infrastructure. They publish SPF records for their sending IPs. And they maintain sender reputation across their IP pool, which means your emails inherit a trust score that a random VPS IP address will never have.

Mailgun's free tier includes 100 emails per day (approximately 3,000 per month). SendGrid offers a 60-day trial with 100 emails per day; after the trial, paid plans start at $19.95/month, so it's not a permanent free option. Resend offers 3,000 per month free with a permanent free tier and has a particularly clean API if you later want to move beyond SMTP to HTTP-based sending. SMTP2GO is another solid choice with 1,000 free emails per month on a permanent free plan.

For a deeper look at how each of these providers fits a self-hosted n8n stack, Rain Automation's n8n SMTP configuration guide covers Gmail relay, Mailgun, SendGrid, and Postmark side by side, including setup steps and the tradeoffs that matter for production workflows.

If Mailgun is the relay you choose and you want to pair it with a CRM trigger, Rain Automation's n8n Mailgun node setup guide for CRM lead notifications walks through the full integration from domain verification to fired email.

The other advantage: delivery logs. When you send through Mailgun, you get per-message event tracking (delivered, opened, bounced, complained). n8n's execution log stops at "relay accepted." A transactional relay continues tracking all the way to the inbox. That visibility alone is worth the switch.

Disclosure: Links to n8n on this page are affiliate links. Rain Automation earns a referral commission at no extra cost to you.

Step 6: Add Delivery Confirmation Logic to Your n8n Workflow

For business-critical email workflows, add a verification loop inside n8n itself: send the email, wait, then check a webhook or bounce callback to confirm delivery. This turns a fire-and-forget send into a tracked, auditable process.

Here's the version I use in our production workflows at Rain:

1. Send Email node sends the message through your transactional relay
2. Wait node pauses the workflow for 60 to 120 seconds
3. HTTP Request node queries your relay's API for the delivery status of that specific message (Mailgun's Events API, SendGrid's Activity API)
4. IF node checks: was the message delivered, bounced, or deferred?
5. On bounce/defer: Log the failure to a Google Sheet or Airtable, trigger a Slack notification, and optionally retry with a different FROM address

This pattern catches two failure modes that would otherwise go unnoticed:

• Soft bounces (temporary failures that the relay retries but eventually gives up on)
• Spam complaints (the recipient marked your email as spam, which hurts future deliverability)

For the broader set of retry logic and error handling patterns in n8n beyond email delivery, see our companion guide to the workflows most likely to fail quietly.

n8n also offers a "Send and Wait for Response" pattern using the Webhook node that can listen for reply webhooks from email services. But for most delivery confirmation use cases, polling the relay's API after a wait is simpler and more reliable.

If you're building more complex automation workflows for your business, this send-verify-log pattern becomes a building block you can reuse across every email-dependent workflow.

Time-Sensitive: Microsoft Exchange Basic Auth Deprecation

If your n8n workflows send email through Outlook or Microsoft 365 SMTP, you need to act before December 2026. Microsoft is disabling Basic Authentication for Exchange Online by default at the end of December 2026, with full removal planned for H2 2027. n8n SMTP credentials using a username and password against smtp.office365.com will stop working unless your organization's admin explicitly re-enables Basic Authentication, which Microsoft allows as an interim measure.

This will produce exactly the symptom this post covers: n8n may still show a successful connection (depending on how Microsoft phases the deprecation), but emails will silently fail to deliver for any tenant whose admin has not re-enabled Basic Auth.

What to do now:

1. Check if your n8n SMTP credentials use smtp.office365.com with basic username/password authentication
2. Migrate to OAuth 2.0 authentication for Microsoft 365 (n8n supports this through the Gmail and Microsoft nodes)
3. Or switch to a transactional relay (Step 5 above) that doesn't depend on Microsoft's auth stack

This isn't speculative. Microsoft has published the deprecation timeline, and organizations that haven't migrated or explicitly re-enabled Basic Auth will see silent delivery failures starting late 2026. If you're running n8n email workflows that depend on Outlook SMTP, put this migration on your calendar now.

Quick Reference: n8n Email Delivery Checklist

Use this 10-point checklist to systematically diagnose any "sends but not received" problem in n8n. Work through each item in order. Most issues resolve by item 4 or 5.

#	Check	What to Look For	Tool
1	FROM domain matches SPF record	SPF TXT record includes your relay's domain	MXToolbox SPF
2	SPF record published	v=spf1 ... ~all exists for your domain	dig TXT yourdomain.com
3	DKIM signing active	DKIM public key published in DNS	MXToolbox DKIM
4	DMARC policy set	v=DMARC1; p=none minimum	dig TXT _dmarc.yourdomain.com
5	Port 587 open from server	nc -zv smtp.yourrelay.com 587 succeeds	Terminal on your VPS
6	App password used (not account password)	Gmail, Outlook require app-specific passwords for SMTP	Provider's security settings
7	TLS/STARTTLS enabled	n8n SMTP credential has SSL toggled on	n8n Credentials panel
8	Relay accepts message (250 OK)	n8n execution output shows 250 response	n8n execution log
9	Recipient spam folder checked	Email found in spam, junk, or promotions	Recipient's email client
10	Bounce logs reviewed	No bounces or complaints in relay dashboard	Mailgun/SendGrid/Gmail dashboard

If you work through all 10 items and the email still isn't arriving, the problem is likely at the recipient's organization level (corporate email gateway, custom filtering rules, or an aggressive spam appliance). At that point, ask the recipient's IT admin to check their mail flow logs and quarantine.

For more on configuring n8n's SMTP settings correctly from the start, our n8n Send Email node tutorial walks through every field.

Frequently Asked Questions

Why does n8n show email sent successfully but recipient doesn't receive it?

n8n's success status means the SMTP server accepted the message for delivery. It does not mean the email reached the recipient's inbox. The relay can accept the handshake (250 OK) and then drop the message due to SPF misalignment, DKIM failure, or sender reputation issues. Check your relay's delivery logs for the actual outcome.

How do I check if my n8n email is going to spam?

Ask the recipient to search their spam or junk folder for the sender address. In Gmail, use the search query in:spam from:[email protected]. If found, the email delivered successfully but was classified as unwanted. Fix this by adding SPF and DKIM records for your sending domain.

What SMTP port should I use in n8n, 465 or 587?

Use port 587 with STARTTLS. Port 587 is the standard submission port for authenticated email and is more widely permitted than port 25 or 465. But some VPS providers block all SMTP ports by default, so always verify connectivity with nc -zv before configuring. Port 25 is blocked by almost every cloud provider and should not be used for n8n.

Does n8n support DKIM signing for outbound emails?

n8n's Send Email node does not sign emails with DKIM directly. DKIM signing happens at the relay level. If you use a transactional relay like Mailgun or SendGrid, they sign outbound emails with DKIM automatically. If you use Gmail's SMTP relay, Gmail handles DKIM signing for verified domains.

Why does n8n email work when I test it but not in production?

Test emails typically go to your own address, which is less likely to apply strict spam filtering. Production emails go to external recipients whose mail servers check SPF, DKIM, and sender reputation more aggressively. Gmail also applies stricter filtering to batch sends (10+ recipients) from unauthenticated domains.

Can n8n send emails through Mailgun or SendGrid instead of SMTP?

Yes. Both Mailgun and SendGrid provide SMTP credentials that work with n8n's Send Email node. Enter the relay's SMTP host, port 587, and your relay credentials in n8n's SMTP credential settings. Mailgun's SMTP host is smtp.mailgun.org. SendGrid's is smtp.sendgrid.net. Both handle SPF/DKIM automatically.

When to Call in Help

If you've worked through all six steps and emails still aren't arriving, the problem likely sits in your recipient's organization, whether that's a corporate email gateway, custom filtering rules, or an aggressive spam appliance that Rain can help diagnose. At that point, infrastructure-level help is faster than continued solo troubleshooting.

At Rain Automation, we build and maintain production n8n deployments that handle email-dependent workflows across multiple business sites. Our own stack runs on Oracle Cloud with Gmail relay on port 587, and we've solved delivery problems for workflows ranging from lead notifications to automated deal stage alerts. If your automation setup depends on emails actually arriving, get in touch and we'll diagnose it together.

If you're evaluating whether n8n is the right automation platform for your business, our n8n vs Make comparison covers the practical differences for small business use cases.

This post contains affiliate links. Rain Automation may earn a commission when you sign up through our links, at no additional cost to you.