N8n Cloud: Send Email (SMTP) node hangs and fails silently — is outbound SMTP (465/587) blocked on Cloud?

Questions
,
1

Can you answer the following:

  1. Does n8n Cloud block, restrict, or rate-limit outbound SMTP connections on ports 465 or 587 from its infrastructure?
  2. If there is a restriction, is it specific to my plan tier, or applied to all n8n Cloud accounts?
  3. Is there a recommended workaround for sending email via SMTP through n8n Cloud specifically (as opposed to self-hosted n8n)?
2

Hi @Kalon Welcome!
As n8n Cloud uses dynamic IPs for outbound traffic. If your external SMTP provider is blocking connections, you can try whitelisting n8n Cloud’s outbound IP ranges.

I think that is the most probable cause.

4

Yeah, this is expected behaviour on n8n Cloud rather than something broken on your side. Cloud blocks raw outbound SMTP on 25, 465 and 587 across all tiers, so the Send Email node just sits there until the connection times out, which is why you get a hang with nothing useful in the log. The other replies are right that the fix is to stop using raw SMTP and send through an API instead. The Gmail or Microsoft Outlook nodes work because they go over the provider API on https, not SMTP, and for anything transactional a provider like Resend, SendGrid or Mailgun through the HTTP Request node (or their dedicated node) is the clean path. If you genuinely need raw SMTP, self-hosting is the only place you control the outbound ports.

One thing worth sorting while you are changing this, since you already noticed it fails silently: email stays a silent failure even after you switch. An API call can come back accepted and the node goes green, but the message still never lands because the sending domain is not verified, or it gets filed as spam, or the provider suppressed that address. So once it is wired up, send a real message to an inbox you control and check the provider delivery logs, not just that the node finished green. Are you sending transactional mail like resets and receipts, or more of a notification to yourself? That changes which route is least painful.

5

@Kalon we shouldn’t be blocking the outbound smtp ports, I suspect the mail service is blocking the connection rather than this being on the cloud side. It could be the ssl/tls settings.

6

Welcome, Kalon :waving_hand:

On your three:

  1. n8n Cloud doesn’t publicly document blocking or rate-limiting outbound SMTP on 465/587, and it works fine for plenty of Cloud users — so a true port block is unlikely. A silent hang is almost always either a port/SSL mismatch (465 needs SSL/TLS ON; 587 needs it OFF for STARTTLS — mismatch it and the connection just sits there until timeout) or the provider rejecting you (Gmail/Outlook usually need an app password, and they block unfamiliar sending IPs). I can’t speak for n8n’s internal infra limits, though — if you suspect an actual block, support can confirm.

  2. Not aware of any tier-specific SMTP restriction — same behavior across Cloud accounts as far as I know.

  3. The reliable workaround on Cloud: skip raw SMTP and send via a transactional email API over HTTPS — SendGrid, Brevo, Postmark, Resend, or Mailgun (their node or the HTTP Request node). That sidesteps the port/TLS pain entirely, gives better deliverability, and just works on Cloud. If you want to stay on SMTP: try 587 with SSL off, use an app password, and open the failed execution — the real error (auth vs TLS vs timeout) is usually in there even when it looks silent.