What is SMTP, and why does your app still need it?
SMTP — the Simple Mail Transfer Protocol — is how one mail server hands a message to another. It has been doing that job since 1982, and almost every email your application sends still travels over it at some point.
What SMTP actually does
SMTP moves a message from a sender to a receiving server. That is the whole job. A session is a short conversation:
- The client opens a connection and identifies itself.
- It states who the mail is from, and who it is for.
- It sends the message body.
- The receiving server accepts the message, or rejects it with a status code.
Everything else people associate with email — templates, open tracking, unsubscribe handling, bounce processing, reputation management — sits around SMTP, not inside it.
What SMTP does not do
This is where most confusion starts.
- It does not guarantee delivery to an inbox. A 250 response means the receiving server accepted the message, not that a human will see it. Spam filtering happens after that.
- It does not authenticate you by itself. SPF, DKIM and DMARC are separate DNS-level mechanisms, and they are what modern inbox providers actually check.
- It does not track anything. Open and click tracking are added by rewriting the message body before it is sent.
SMTP versus an email API
Providers usually offer both. The practical differences:
SMTP speaks a standard protocol, so any language and any library can use it, and you can move providers by changing a hostname and credentials. It is connection-oriented, which makes very high volume slightly more work to manage.
An email API is an HTTP endpoint owned by one vendor. It is easy to call and often exposes richer per-message features, but the integration is provider-shaped: moving vendors means rewriting the calls.
If portability matters to you, SMTP is the safer default. If you are deeply committed to one vendor's feature set, their API may be more convenient.
Deliverability is mostly not an SMTP problem
Teams often try to fix inbox placement by changing how they send. Usually the fix is elsewhere:
- Publish SPF, DKIM and DMARC records for your sending domain.
- Send from a domain you control, not a free mailbox provider.
- Keep hard bounces and spam complaints low by removing dead addresses.
- Warm a new sending domain gradually rather than starting at full volume.
Where Retainza fits
Retainza is provider-agnostic for email. You connect your own SMTP endpoint — SendGrid, Amazon SES, Postmark, or a server you run — and Retainza sends through it, as multipart HTML and text, throttled to stay inside your provider's rate limit.
That means your sending reputation and your per-message cost stay yours. Retainza does not resell delivery, and moving providers is a credential change rather than a migration.