SMTP vs Email API: What’s the Difference?

Maybe Claude Code has asked whether your project should send email over SMTP or through an email API, or a tool you use wants "SMTP settings". This guide explains SMTP vs email API in plain English, so you can make the call and get back to building.

What are SMTP and an email API?

Both are ways of passing an email from your project to an email service, which then delivers it. SMTP is the long-standing standard for moving email between servers. An email API does the same handoff as a single web request.

SMTP stands for Simple Mail Transfer Protocol: the shared set of rules email systems use to pass messages to each other. The current standard, RFC 5321 from 2008, describes a step-by-step exchange. The sender connects, says who the email is from, lists who it's for, then sends the message, and the server replies to each step with a three-digit code, such as 250 for "OK". For more background, see our guide to what SMTP is.

An email API (application programming interface: a set of instructions one piece of software can send to another over the web) does the handoff in one go. Your project sends a single request to the email service with the sender, recipient, subject and content. The service replies with an ID it uses to track that email. Resend's send-email API works this way, for example.

Either way, the same email service does the delivery, so both routes need the same basics:

• A secret key. This is an API key: a long, private password that lets your project use the service. With SMTP, many services use it as your password. Resend and SendGrid both do.
• A verified sending domain. Domain verification means adding a few DNS records (settings for your domain) where your domain is registered, to prove you own it.

These are usually transactional emails: automatic, one-to-one messages like welcome emails, password resets and receipts.

How do SMTP and an email API differ in practice?

The main differences are how your project connects, what it gets back and where it can run. For a SaaS sending emails as things happen, an email API is usually the smoother fit. SMTP fits when a tool only offers SMTP settings.

A port is a numbered entry point on a server, a bit like a door number. SendGrid lists 25, 2525, 587 and 465 for SMTP and typically recommends 587. Resend offers 25, 465, 587, 2465 and 2587.

Ports matter because some hosting companies block them. DigitalOcean blocks ports 25, 465 and 587 on its Droplets (its virtual servers) by default to prevent spam, and recommends using an email service instead. An email API sends over the same kind of secure web connection your site already uses, so SMTP port blocks don't affect it.

Which one does Claude Code usually set up?

For a new SaaS, site or tool, Claude Code will usually set up the email API. Email services lead with their APIs for projects like this, and most publish an SDK (software development kit: a ready-made library for using their API from code). Resend's send-email page shows examples in eight programming languages.

With the API, Claude Code writes a small piece of sending code and stores your secret key in a safe place, such as your hosting settings. Our guide to where to put API keys explains why the key shouldn't sit in your code.

SMTP usually comes up in two situations:

1. A tool that only has SMTP settings. Form builders, website platforms and plugins that send email for you often ask for a server address, port, username and password, because they can't run your code.
2. A project that already uses SMTP. If it works and you're not hitting port blocks, there may be no reason to switch yet.

SMTP vs email API: what are the pros and cons?

SMTP's biggest strength is that it works almost anywhere. An email API's is that it's built for code you control, with clearer replies and more options.

If a tool asks you for SMTP settings, these are the four you'll fill in:

Where does an email MCP server fit?

An email MCP server isn't a third way to send your live emails. It's a connector for building time. MCP (Model Context Protocol) is a standard way for Claude Code to use outside tools, and a connector is one of those links.

Through an email MCP server, Claude Code can set things up, send test emails and check send logs while you work in the chat. Once your SaaS is live, real emails go out from your project, using its secret key and sending code. Nothing goes through the chat.

With SimpleSends, Claude Code can also look into problems for you: if a user says an email never arrived, it reads the send logs and explains what happened. See how to check whether your emails actually sent.

What should you tell Claude Code?

You don't need to choose the route yourself. Tell Claude Code what you're building and ask for a recommendation in plain English.

For a new project:

I need my SaaS to send emails like welcome messages and password resets. Should we use SMTP or the email service's API for this? Explain your recommendation in plain English before you set anything up.

You'll get a short recommendation and the reasons for it. For most new projects, that's the API.

If a separate tool asks for SMTP settings:

My form builder wants SMTP settings: server address, port, username and password. Help me work out what goes in each box for my email service, and tell me which values I need to copy from my account.

You'll get the four settings, with a note on which ones are private.

If emails stopped after a hosting change:

Our emails stopped sending after we moved hosting. Check whether the new host blocks SMTP ports. If it does, suggest the simplest fix and wait for my go-ahead before changing anything.

You'll get a diagnosis and a proposed fix, often the email API or an alternative port.

Building with Claude Code? Connect SimpleSends and Claude Code can handle your transactional emails from here.