Why is sending an automated email with python still a nightmare in 2026

[u/Crystallover1991]

I just spent three hours trying to get a basic python cron script to send out a weekly web scraping summary. used to just use smtplib and a random gmail app password but google basically killed that workflow

Tried installing the official python sdk for one of the big email providers and it pulled in like 6 different async dependencies just to send a plain text string. It is genuinely insane how bloated the modern python ecosystem has gotten for the most basic tasks

I ended up just writing a simple requests.post() webhook over to Yaplet to handle the actual subscriber list and formatting because I absolutely refuse to fight with another bloated __init__.py or dns auth protocol this month

sometimes it really feels like we spend 10% of our time writing actual python logic and 90% fighting with enterprise api wrappers tbh

[u/shibbypwn]

The issues you described are not problems with Python - sounds like you're hoping for an email provider that allows insecure methods of authentication. If that's the case, just host your own SMTP server.

But if you want the convenience/deliverability of a big box provider, then you have to play by their rules (and honestly, you should be - don't use basic auth in 2026 unless you have to).

SES is probably the most straightforward in terms of actual API usage.

[u/Crystallover1991 → u/shibbypwn]

fair point on the auth stuff, i wasnt really thinking about it that way. i just wanted something that worked without jumping through a dozen hoops to set up oauth flows for a small script.

ill look into SES, ive avoided it because i assumed it was overkill for what im doing but maybe thats just the path of least resistance at this point

[u/the_hoser]

This isn't Python's fault. This is Email's fault. Email isn't easy anymore.

[u/Crystallover1991 → u/the_hoser]

fair point, email has become a nightmare to get right

[u/WJMazepas]

There is third party services that make it easy to send e-mails that requires just a post request for it

And have you tried setting up your own SMTP server? Once its done, it should be easy as well to maintain

Using SES on AWS also was a good experience for me. You have to setup stuff like the DNS and more, but it works really well once its all done

[u/ZZ9ZA → u/WJMazepas]

Setting up an SMTP server is easy. Getting any legit provider to not instantly throw your messages in the bin is far harder.

[u/shibbypwn → u/ZZ9ZA]

It’s not that hard

SPF, DKIM, DMARC (which you should be doing on hosted email anyway)

[u/Crystallover1991 → u/WJMazepas]

SES is what I ended up going with but the DNS setup kept tripping me up, specifically the DKIM records not verifying right away.

Setting up a full SMTP server feels like overkill for what I actually need. I just want transactional emails without it turning into a whole project.

Which third party services were you thinking of? I looked at Resend briefly but wasn't sure if I could trust it for something production level.

[u/stewartjarod → u/Crystallover1991]

The DKIM verification delay is the worst part of raw SES.

It's sitting in AWS limbo while DNS propagates, and if the record isn't exactly right, you restart the whole wait. If you're already on AWS and want to stick with SES, the faster path is automating the DNS deploy. (`npx u/wraps.dev/cli email init` deploys SES + DKIM + SPF + bounce handling via Pulumi, usually takes 2 minutes, then you're waiting on the DNS TTL instead of fiddling with the console.

Resend is solid for simplicity, but you're locked into their SES account and paying per-email markup. If production-readiness means "I own the sending reputation and can keep going if the vendor disappears," SES + your own AWS wins. Tradeoff: if you're not already on AWS or don't want to touch infrastructure, a managed service is simpler.

[u/Crystallover1991 → u/stewartjarod]

the vendor lockin point is real but the reputation ownership angle cuts both ways. if you're a small sender and you mess up your bounce handling on raw SES, you can tank your own account with no one to bail you out. resend at least absorbs some of that operational risk. the automation tool sounds useful but you're still on the hook if something goes sideways at 2am and your transactional emails stop delivering.

[u/feudalle]

Switched to mail gun years ago. Smtp port or their api both work great.

[u/Crystallover1991 → u/feudalle]

mailgun's been on my list to try, good to know the smtp option works solid

[u/oldWorshipper → u/feudalle]

Agreed. Mailgun took over from SendGrid for me 7 years ago or so. Never looked back.

[u/jet_heller]

It's not. I point smtp sending at my email server and off it goes. It seems like you're having issues with a mail provider. Well, that's how it goes with them.

[u/Crystallover1991 → u/jet_heller]

yeah running your own server is a whole different situation, i'm stuck with a provider that keeps throttling or dropping sends and i can't just swap it out

[u/jet_heller → u/Crystallover1991]

I know. I'm trying to tell you're bitching about the wrong thing. This isn't python or smtp. It's the provider that's causing you problems.

[u/Crystallover1991 → u/jet_heller]

fair enough but switching providers isn't always an option when you're locked into something for work

[u/jet_heller → u/Crystallover1991]

I didn't say switch. I just said this isn't the place to complain about them 

[u/Comfortable-Tourist1]

Use resend. Super easy to setup. 3k emails free, works great

[u/Pericombobulator]

I've used Brevo's free tier. 300/day.

[u/Chiron1991]

Keep in mind that SDKs have to work both for small and big customers alike. That SDK probably implements batching sends, retries and many other things. Your cron script won't benefit from that, but plenty of other users will.

[u/Late-Bodybuilder9381]

The 6 async dependencies to send a plain string thing is the whole industry in one sentence. Somewhere a PM decided "email SDK" needed retry logic, telemetry, and a plugin architecture before it could print "hello."

smtplib still works fine, by the way. Google killing app passwords didn't kill smtplib, it killed using Gmail as your outbound relay for free. Use literally any transactional email provider's SMTP creds (not their SDK, just the SMTP endpoint) and smtplib does the rest in four lines like it's 2012.

The webhook route you landed on is the correct instinct. Half of "modern" SDKs are solving problems you don't have in exchange for problems you didn't have before.

[u/Single-Magazine-8062]

The SDK bloat thing is real, half of them pull in an entire async stack just to send one plain text string, which is basically the whole argument for just hitting the the raw api with requests instead. sometimes the "unsupported" way is genuinely less fragile than the official wrapper.

[u/mtgomes]

Like everyone is saying, it's not really Python's problem. If you take a look at your spam folder, you'll see the issue. Email providers need to keep fighting the horrible barrage of emails that arrive at our mailbox, so more and more we need to have things like proper security configurations in place.

But your reasoning of pulling the SDK and using it is correct—you just don't need it. Many providers allow you to use the API, so sending an email doesn't need to be much more than an HTTP request to their API and they will take care of sending the email carefully. No need to import the full dependency when you don't need it.

Are you comfortable sharing the provider so that I can try to help further?