Why SMTP is no longer the default for app email
SMTP is the lingua franca of mail servers. It earned that status for good reasons. It is also an awkward default for a modern app backend.
What SMTP quietly costs you
Running product email over SMTP usually means:
- SMTP users, passwords, and ports in every environment
- Firewall and provider quirks (587 vs 465, STARTTLS fights, “works on my laptop”)
- Weak observability unless you build logging yourself
- A slow slide into operating a tiny ESP you did not intend to own
Libraries like Nodemailer made the code pleasant. They did not make deliverability, bounce handling, complaint feedback, or domain authentication disappear. Those problems moved to whoever owns the relay.
What an HTTPS email API changes
One POST. An API key. JSON in, acceptance out.
Domain verification lives in a UI. Delivery events show up as logs. Webhooks push bounces without you parsing DSNs from a mailbox you forgot existed.
You still care about SPF and DKIM. You still own the message body. You stop pretending your Next.js route handler is a mail transfer agent.
When SMTP still wins
SMTP is the right tool when:
- You are talking to ancient on-prem systems that only speak SMTP
- You already operate a hardened relay and like operating it
- Compliance paperwork literally requires a specific SMTP path
- You are debugging mail infrastructure, not shipping a SaaS feature
Those are real cases. They are not the median startup shipping auth email.
The default should match the job
If the job is “send this HTML to this user when they click forgot password,” the default should be an HTTPS API with clear failure modes — not a protocol designed for store-and-forward between MTAs.
SMTP is not dead. It just should not be the first thing you reach for when the product question is transactional email.