I spent several hours trying to get a basic Python cron job to send a weekly web-scraping summary. I originally expected to use smtplib with a Gmail app password, but that workflow is no longer straightforward. I also tried installing an official SDK from a major email provider, only to find it brought in several asynchronous dependencies for sending a plain-text message. Rather than deal with a large SDK and email authentication requirements, I used requests.post() to call a transactional email service's webhook and let it handle subscribers, formatting, and delivery. That worked, but it still feels excessive that a small script can require so much setup. Is there a lightweight, reliable approach for sending transactional email in Python without managing a full mail server or pulling in a bloated SDK?
4 Answers
This is less a Python problem and more an email-authentication and deliverability problem. Providers have moved away from insecure or overly convenient authentication, and that is necessary to reduce abuse. If you want the easiest path with a managed provider, Amazon SES is fairly straightforward: use its API or SMTP credentials, configure the required DNS records, and let it handle delivery. Hosting your own SMTP server is possible, but getting messages accepted reliably is much harder than simply sending them.
You do not necessarily need the provider's full SDK. Most transactional email services expose a simple HTTP endpoint, so a small requests.post() call is perfectly reasonable for a cron script. You can also use smtplib with the SMTP credentials from a transactional provider, which keeps the Python side close to the old four-line approach while avoiding the limitations of personal Gmail accounts. The SDKs often include retries, batching, telemetry, and other features that are useful at scale but unnecessary for one weekly report.
Exactly. smtplib still works; what changed is that using a consumer mailbox as a free outbound relay is no longer convenient. A provider's SMTP endpoint or raw API is usually enough for a small script.
A managed email service is probably the right fit here. Mailgun supports both SMTP and an API, and Resend is designed to be simple to set up. Brevo also has a useful free tier with daily sending limits. These services still require domain verification and DNS records such as SPF and DKIM, but they avoid the much bigger headache of maintaining your own server and building a reputation with receiving providers.
SES worked well for me too, although the DKIM records took a while to verify. The DNS setup is annoying once, but it is still less work than operating a full SMTP server.
Email itself has become complicated because providers have to fight spam, spoofing, and poor sender reputation. That is why even a basic message now involves authentication, DNS configuration, throttling, and delivery policies. For a small scheduled report, your webhook approach is reasonable: keep the Python script responsible for collecting and summarizing the data, and delegate formatting, subscriber management, retries, and delivery to a transactional email service.
That makes sense. I was treating the authentication setup as pointless friction, but it is really part of the deliverability problem. I may try SES instead of setting up a complete mail server.