Short answer: We could design “email over HTTP,” but SMTP isn’t just an old text protocol. It’s an entire global, store-and-forward, federated delivery system with built-in retry, routing, and spam-control semantics. HTTP was never designed for that.
What actually happens today is: • HTTP/JSON at the edges (webmail, Gmail API, Microsoft Graph, JMAP, etc.) • SMTP in the core (server-to-server email transport across the internet)
SMTP is not being “phased out”; it’s being hidden behind HTTP APIs.
⸻
Email is designed as:
“I hand this message to my server, and the network of mail servers will eventually get it to yours, even if some servers are down for hours or days.”
SMTP + MTAs (Postfix, Exim, Exchange, etc.) do this natively: • If the next hop is down, the sending server queues the message on disk. • It retries automatically with backoff (minutes → hours → days). • Custody of the message is handed from server to server along the path.
HTTP is designed as:
“Client opens a connection, sends a request, and expects an answer right now.”
If an HTTP POST fails or times out: • The protocol itself has no standard queueing or retry schedule. • All logic for retries, backoff, de-duping, etc. must be implemented at the application level.
You can bolt on message queues, idempotency keys, etc., but then every “mail server over HTTP” on Earth would need to implement the same complex behavior in a compatible way. At that point you’ve reinvented SMTP on top of HTTP.
SMTP already provides this behavior by design.
⸻
One of email’s killer features is universal federation: • [email protected] can email [email protected] without their admins ever coordinating.
This works because of DNS MX records: • example.com publishes MX records: “these hosts receive mail for my domain.” • Any MTA does an MX lookup, connects to that host on port 25, and can deliver mail.
If we move email transport to HTTP, we need a standardized way to say:
“This URL is the official Email API endpoint for example.com.”
That requires, globally: • A discovery mechanism (SRV records, /.well-known/... conventions, or similar). • An agreed-upon email-over-HTTP API. • Standard semantics for retries, error codes, backoff, etc.
Getting every ISP, enterprise, and government mail system to move to that at the same time is a massive coordination problem. MX + SMTP already solve routing and discovery and are deployed everywhere.
⸻
Modern email is dominated by spam/abuse defense, and those defenses are wired into SMTP’s world: • IP reputation (DNSBL/RBLs) – blocking or throttling based on connecting IP. • SPF – which IPs are allowed to send mail for a domain. • DKIM – signing the message headers/body for integrity. • DMARC – policy tying SPF + DKIM to “what should receivers do?”
All of these assume: • A dedicated mail transport port (25) and identifiable sending IPs. • A stable, canonicalized message format (MIME / RFC 5322). • SMTP envelope concepts like HELO, MAIL FROM, RCPT TO.
Move transport onto generic HTTPS and you immediately get new problems: • Shared IPs behind CDNs and API gateways (can’t just “block that IP” without collateral damage). • JSON payloads whose field order and formatting are not naturally canonical for signing. • No built-in distinction between “this POST is a mail send” and “this POST is some random API.”
You’d need to redesign and redeploy SPF/DKIM/DMARC equivalents for HTTP, and then get global adoption. That’s a huge, risky migration for users who mostly wouldn’t see a difference.
⸻
When you do any of: • Call Gmail’s HTTP API • Call Microsoft Graph sendMail • Use SendGrid/Mailgun/other REST “send email” APIs
you are sending email over HTTP – to your provider.
Under the hood, they: 1. Receive your HTTP/JSON request. 2. Convert it into a standard MIME email. 3. Look up the recipient domain’s MX record. 4. Deliver over SMTP to the recipient’s server.
So: • HTTP is used where it’s strong: client/app integration, OAuth, web tooling, firewalls, etc. • SMTP is used where it’s strong: inter-domain routing, store-and-forward, spam defenses.
Same idea with JMAP: it replaces IMAP/old client protocols with a modern HTTP+JSON interface, but the server still uses SMTP to talk to other domains.
⸻
Even if you designed a perfect “Email over HTTP” protocol today, you still have: • Millions of existing SMTP servers. • Scanners, printers, embedded devices, and old systems that only know SMTP. • Monitoring, tooling, and operational practices built around port 25 and SMTP semantics. • A global network that already works.
There’s no realistic “flip the switch” moment where everyone migrates at once. What’s happening instead is: • Core stays SMTP for server-to-server transport. • Edges become HTTP (APIs, webmail, mobile clients).
⸻
Because the problem email solves is: • asynchronous • store-and-forward • globally federated • extremely spam-sensitive
and SMTP is designed and battle-tested for exactly that.
HTTP is fantastic for: • synchronous request/response • APIs • browsers and apps
So the real answer is: • We already use HTTP where it makes sense (clients, APIs, management). • We keep SMTP where it makes sense (inter-domain, store-and-forward transport).
SMTP isn’t still here just because it’s old. It’s still here because, for global email delivery between independent domains, nothing better has actually replaced it in practice.