Sending hundreds of emails safely

Questions
1

Hey guys, if I’m going to send hundreds of emails a day, what’s the best strategy to use? How many emails should I send at the same time?
How many seconds of delay should I do?
By the way, I use SMTP.

1 Like
2

When you’re sending hundreds of emails a day over SMTP, the biggest factor is sending behavior.

How many emails should I send at the same time?

One. Always one.

Avoid parallel sends or batches. Even small bursts are an easy automation signal for inbox providers. The safest pattern is:

  • send 1 email

  • wait

  • send the next

Your SMTP server might allow more, but inbox providers don’t care about those limits.

How much delay should I use?

A solid baseline that works well in practice:

  • ~45–75 seconds between emails

  • Some variation so it’s not perfectly uniform

If you’re using n8n, the Wait node is minute-based, so most people either:

  • Randomize between 1–2 minutes, or

  • Use a small Code node to add seconds-based jitter

You don’t need precision — just avoid robotic timing.

How many per hour / per day?

Even with delays, set caps:

  • Hourly: ~20–40 emails/hour

  • Daily:

    • New / warming domain: 30–100/day

    • Established domain: 200–300/day

Sending faster rarely improves results and often hurts deliverability.

Domain setup matters (a lot)

Before scaling at all, make sure:

  • SPF, DKIM, and DMARC are set correctly

  • You’re using a dedicated sending domain

  • You’re not blasting the exact same email to everyone

If auth or content is off, pacing won’t save you.

When to consider moving to a service like Amazon SES

This is the part people miss.

If you’re using shared or hosted SMTP (web host SMTP, Gmail SMTP, etc.), you’ll eventually hit a wall — especially if you’re sending similar or identical emails to many recipients. Shared SMTP servers are quick to block once patterns look automated.

Moving to a service like SES makes sense when:

  • Your SMTP provider starts throttling or blocking you

  • You want proper bounce/complaint feedback

  • You’re scaling beyond a few hundred emails/day

  • You want infrastructure built for automated sending

SES doesn’t magically improve inbox placement, but it gives you a cleaner, more tolerant pipe once volume and repetition increase.

TL;DR

  • Send 1 email at a time

  • ~1 minute delay (with some randomness)

  • ≤30–40/hour, ≤200–300/day

  • Domain auth done properly

  • Don’t expect shared SMTP or dedicated SMTP server to scale forever — if you send similar emails at volume, you’ll eventually get blocked

Send like a human first. Move infrastructure only when limits — not deliverability — become the bottleneck.

1 Like
3

Hi @Ali4 That is nice that you are going to create a Email-er project, some things i would say that you should be considering, it honestly does not matter you are using SMTP or Gmail node/service, what actually matter is that you do not fry their API keys by sending 10-20 emails per second, and there is not enough information you have given to me but i would curate 2-3 different examples for you to look at and take inspiration and that is how you should be starting out: So Follow Along Below+=

Let me know which approach suits you, glad it helped.

3 Likes
4

So, is 5 emails per second or less safe?.you also didn’t mention the length of the delay. By the way I don’t know why the workflow you shared isn’t showing up for me.Could it be because I’m using a phone? Or is there a mistake?

1 Like
5

Thank you, but please confirm that this information is from your own experience and not AI

1 Like
6

@Ali4 it is not particularly about 5s per email , it is about being less prone to errors and rate limits while being in the domain of not over limit your email API. The goal is to send bulk emails without errors and scale that upto n number of emails. The length of the delay I have mentioned in the 3 workflow I have shown , assume each of it as 4-8s of delay per email (I know it sounds a lot if you have a number of sending emails in mind, but in large scale this would be really helpful). I recommend using Desktop mode if accessing community all though mobile layout is really compact, just use a desktop device. Let me know if this helps.

2 Likes
7

I’m not sure what to make of that comment. if you don’t like the response, then ignore it. BUT for the record I send in excess of 500 emails a day. I can easily scale to 10, 000 emails a day

My response was was genuine. take it or leave it

1 Like
8

“It is not particularly about 5s per email, it is about being less prone to errors and rate limits while staying within your email API limits.”

I agree.

The delay isn’t a hard rule, t’s simply a tuning mechanism to keep bulk sending reliable at scale. The real objective is fewer send failures, no throttling, and predictable behavior as volume increases, not hitting an exact seconds-per-email number.

Considering the above, the intent of the three workflows is clear, and they’re good examples of how to structure bulk sending:

  • introduce a small delay per send

  • keep throughput predictable

  • stay comfortably under API / SMTP limits

Using something like ~4–8 seconds per email fits that goal well. Even at volumes like 10,000 emails, seconds-level spacing doesn’t meaningfully limit throughput — it smooths the send pattern and reduces pressure on the API.

One small suggestion is to randomize the delay slightly instead of using a fixed value. For example, in the Wait node (seconds): {{ Math.floor(Math.random() * (8 - 4 + 1)) + 4 }}

That keeps the same throughput while avoiding a perfectly uniform cadence, so the sending pattern doesn’t look overly automated.

Overall, this your response reads as a thoughtful, experience-based response, and the workflows support the point being made.

1 Like
9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.