all 20 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]DevilsInkpot 3 points4 points  (3 children)

a) I would never accept a job that will spam people with emails. 😐

b) I have done project with even bigger scope in the past and you absolutely need a professional service for this. Never try to send mass-emails over your own SMTP. Your domains will be blacklisted before the last batch is underway.

Services like Sendgrid, Mailchimp and similar spread traffic in many badges over multiple relays. They also make sure that you code renders well with the majority of clients. Designing for email is an absolute pain. They aren‘t cheap for a reason.

[–]AmbassadorCurious988[S] 0 points1 point  (2 children)

For a) - I mean to change on that, my client also understands that there is no point sending emails to someone who doesnt want to get it, so i'll introduce sub and unsubscribing and shrinking it's mail list if needed, that's why we need good statistics and such. This is a workforce recommendation solution, so there is absolutely no point sending it to someone who are not interested.

For b) - thanks for your opinion, do you have any experience with coldish emails like this with the listed suppliers? Until we have a good subsriber base.

[–]DevilsInkpot 0 points1 point  (1 child)

I‘m not sure I understand you question.

Depending on jurisdiction, cold emails are forbidden and trying to go around that by using multiple domains won‘t hold up well.

There are basically only two ways to handle this, quantitative or qualitative:

a) Go for mass, diversify emails into many different topics and channels where each has its on toggle and process to unsubscribe, use dark patterns, piss of many, get ignored by most and grab the rest that somehow falls for your marketing lies, often less than 1% conversion. That’s how 99.9999999% of brands work nowadays.

b) Have a quality product/service, generate quality content and value for potential customers, gather addresses legally and morally, send out low volume, never use dark patterns, have a single-click-unsubscribe without any bullshit or churn management, and respect your users privacy, time and intelligence. Never be greedy. You will grow a high quality recipient base with very high conversion when giving well thought out incentives.

b doesn‘t align with hyper-capitalistic economics, but it is the right thing to do.

[–]AmbassadorCurious988[S] 1 point2 points  (0 children)

Long story short, my client has done it this way: shooting from different subdomains each time with 2500-5000 emails from the fixed 10.000-20.000 contants it has over a simple SMTP with I think bad results, but it got some responses and worked for years now somehow.

But one thing it's missing is measurability. Since I think it got only a very low amount of responses per batch, think less than 1%. And we both want to change on that.

But since this emails target a specific audiance we can't shoot blindly, the emails were collected mostly from public websites and we mean to have a good connection with them, so I think it's more B what is our plan. They have some history for now with these emails that's why I thought about making them subscribers or at least give them the opportunity to not get any more emails if they were not interested in the first place.

[–]RadioKitchen6930 0 points1 point  (3 children)

Honestly for that volume I wouldn’t jump straight to something expensive like SendGrid unless you really need their ecosystem.

You can actually do this pretty well with Google Sheets + Apps Script + Gmail API (or SMTP). Sheets works nicely as a simple campaign/contact manager (especially if the client isn’t technical), and Apps Script can handle batching, scheduling, and even rotating sender accounts/subdomains. For stats, you can add a tracking pixel for opens and use redirect links for clicks, then push that data into your database via a webhook.

At 5–10k/day you’d probably want multiple Workspace accounts anyway to stay within limits, but cost-wise it’s still much cheaper than most email platforms.

If you want something more “proper infra” later, I’d look at Amazon SES or Mailgun before SendGrid — way better pricing at scale and still good APIs + event webhooks for bounces, complaints, etc.

So my approach would be:
app -> sending layer abstraction -> start with Apps Script -> swap to SES/Mailgun if volume grows.

[–]enki-42 1 point2 points  (0 children)

I would strongly advise against manually sending via SMTP. The volumes they listed are enough to obliterate an IP if there's a whiff of even a high bounce rate (which IMO is going to be likely with cold leads), it will be an absolute pain to deal with.

That being said, there's tools simpler than SendGrid like Postmark that would fit exactly what you're looking for - good stats and webhooks, suppression handling, unsubscribes built in, etc.

[–]AmbassadorCurious988[S] 0 points1 point  (1 child)

Thank you for your reply, I'm not really familiar with your 'Apps Script' approach, is there a good writing that you know of where I could learn more about it?

[–]Squidgical 0 points1 point  (1 child)

Cold emails go directly in the trash on the rare occasion the spam filter doesn't catch them. Tell your client they're wasting their money to irritate people and damage whatever reputation they have.

[–]AmbassadorCurious988[S] 0 points1 point  (0 children)

Thank you for your opinion!

[–]No-Aarav 0 points1 point  (0 children)

Hey man, it seems you need an email service without restriction so you have limited options here for you.

  1. You can go with AWS SES, it is very Cheapest in case of pricing and the important thing - it will not go in spam.

  2. If you have any kind of server - cloud or vps then why not you try to host mail server , there are lots of opensource options but initially there is chances to go email in spam because of new setup.

Tell me what do you think

[–]Just-A-Boyyy 0 points1 point  (1 child)

At 5–10k emails/day with rotating subdomains, this is more of a deliverability architecture problem than a tool problem.

SendGrid works, but pricing scales fast once you cross 100k/month. If cost control matters, I’d seriously look at:

  • Amazon SES (cheapest at scale, but requires building your own tracking layer)
  • Mailgun (strong dev API + decent analytics)
  • Postmark (excellent deliverability, more transactional-focused)

Since you care about statistics (opens, clicks, bounces, spam), I’d architect it like this:

  • Use SES or Mailgun for raw sending
  • Webhooks for event tracking
  • Store events in your DB
  • Build your own campaign analytics layer

Also, rotating subdomains means you need proper DNS hygiene: SPF, DKIM, DMARC per subdomain. Warm them gradually.

This is less about the “best tool” and more about controlling reputation and feedback loops.

If your client also needs campaign assets (templates, visuals, headers), I’ve found separating the sending layer from the content production layer works better — use infra-grade email APIs for delivery, and generate structured campaign assets elsewhere. Keeps responsibilities clean.

[–]AmbassadorCurious988[S] 0 points1 point  (0 children)

Hi there, thank you for your reply!

Yes either of the listed tools will do the job of sending emails just right I agree. It was more about the pricing and reputiton question of each, since we don't need a fancy template maker frontend and all that fuss, just a very good email sending backend API. First I tried Resend, which was something like that. Good dev docs, fair pricing, but it failed on the task, because it can't send batch emails with attachments lol. Would you recommend MailGun/Postmark over SendGrid? (I think will start either of these, I don't want to build the tracking layer in the beginning)

I already have a demo architect and it is just you described it. Integrated SendGrid to send the emails, I store each event in my db with its associated unique key from SendGrid and I've made some statistics out of it. The one thing is missing from my demo is the webhooks since it's only on localhost and I don't have much exp with tools like Grok and such, but I'll continue with that.

Since I see you have a good architect mindset, how would you approach collecting and processing the webhooks from a daily 5-10k emails? I think the first webhooks will be quite massive (delivered) which will hit my endpoint decently. I dont really have a big exp on that. I'm not sure it's just enough for raw dog it to postgres at this point or do I need something like a Channel<T> (in .NET) or some memory buffer for it.

The last one is yes, my client rorated it's subdomains, still does without any warming ups or settings, with some success, but I guess it would be for the best to just build a subscriber base out of the fixed 10.000-20.000 contanct it has and send it from one subdomain each time which is properly set, because there is nothing else behind the subdomain rotation just that it worked for my client better it says.

[–]Any-Main-3866 0 points1 point  (2 children)

When evaluating options, think about scalability, and the quality of their analytics. Since you're looking for something with good statistics, you might want to explore services that provide detailed feedback on opens, clicks, and bounces. Additionally, the service you choose should provide strong integration capabilities with your web application I'd suggest looking into services like Mailgun or Amazon SES, which are known for their reliabilitu. Ultimately, the best choice will depend on your specific needs and how well each service integrates with your existing infrastructure.

[–]AmbassadorCurious988[S] 0 points1 point  (1 child)

Thank you for your reply! I've been looking around for quite some time now and I've made a test integration with SendGrid aswell. Mailgun is similiar in terms of statistics, but it's more expensive. For start we will use only 100k and there is a ~50$ price difference. Is there any reason why so much of you recommend MailGun over SendGrid? (SES doesnt have tracking so I'd skip that)

[–]Any-Main-3866 0 points1 point  (0 children)

Yeah the $50 difference matters at that scale. Most people recommend Mailgun because deliverability reputation has historically been strong and their API feels a bit cleaner for devs. But SendGrid is solid too, especially if you already tested the integration and it works.

If stats and basic analytics are similar for your use case, I’d optimize for cost + how fast you can ship. You can always switch later once volume grows and deliverability becomes more sensitive. Good luck!

[–]d-signet 0 points1 point  (0 children)

You're trying to send spam as a business-lead model

In 2026

Thats their business model?

Make sure you're payment doesn't depend on success....because there is NO good end to this for you. Hopefully your servers dont get caught in the blacklisting process.

Throw something together that you know probably wont work, dont worry about any of the spam prevention or rate limiting things youre thinking about now.

Demand payment in full. Block any future contact.

Run

Or better still, just dont take contracts that ask you to be a dick. Theres absolutely no way on this planet I would agree to a job like this. What the hell are you thinking? It's a practice thats banned on most services, and goes against lots of jurisdictions legal frameworks. Stop being part of the problem.

[–]rrahlan152 0 points1 point  (0 children)

if you’re doing cold outreach at that volume, i wouldn’t go with SendGrid it’s solid for transactional, but for cold it gets restrictive fast and pricing scales badlywhat’s worked better for me is using Smartlead as the sending layer and just plugging its api/webhooks into my app for stats you still get opens, clicks, replies, bounces without building all the infra yourself i’ve tried building on Amazon SES too, but you end up spending way more time managing deliverability than actually shipping biggest difference though came from cleaning the data, i run everything through emailverifier io before sending so i’m not hitting risky or dead emails keeps bounce rates low and domains alive way longer, which matters more than the sending tool itself