emails.sh vs SMTP2GO
SMTP2GO is an SMTP relay for mail code you already have. emails.sh is an API-first sender with logs, webhooks, and inbound, plus SMTP when you need it.
SMTP relays · SMTP2GO claims checked July 2026
What SMTP2GO is
SMTP2GO is a relay first. You point existing mail code, a WordPress plugin, a printer, a CRM, or an application server at their SMTP host, and mail that was landing in spam starts arriving. There is a REST API too, but the relay is the reason people arrive. The free plan is 1,000 emails a month with a 200 a day cap and no card required, which is unusually generous for a relay, and paid plans step up by monthly volume. Reporting, bounce handling, and global infrastructure come with it.
Where SMTP2GO is the better choice
If you have working mail code you are not going to rewrite, SMTP2GO is the correct answer and an API is beside the point. A legacy application, an appliance, a WordPress install, or anything speaking SMTP to a server that no longer has reputation gets fixed by changing four settings. Their free tier is also genuinely usable for a small site, which matters when the alternative is a rewrite.
Where emails.sh differs
We are API-first and there is an SMTP endpoint for the code you are not touching. The argument is what surrounds the send once you are writing it fresh: a JSON request you can read, per-message status at GET /v1/emails/:id, signed webhooks for bounces and complaints, nine language clients, batch sending up to 100 messages in one call, and inbound MX so replies come back. A relay gives you delivery; this gives you the send path and everything downstream of it.
An API you write against, not a protocol you configure
One JSON POST with from, to, subject, html, and text, a bearer key, and a response of {"id": "...", "status": "queued"} you can store. No connection pooling, no TLS negotiation, no port choice, and no timeout tuning against a host you do not control.
Events pushed to your code
SMTP tells you whether the server accepted the message and nothing after that. Signed webhooks for email.delivered, email.bounced, and email.complained let you write a bounce onto a user record the moment it happens, verified with x-emailssh-signature.
Receiving, batching, and scheduling
Inbound MX with parsed and threaded replies, POST /v1/emails/batch for up to 100 messages in one request, send_at for scheduling, and idempotency_key so a retried request cannot send twice. None of those exist in an SMTP transaction.
Side by side
Every row is a claim we could defend with their documentation open beside it. Where they are ahead, the row says so.
- Pricing shape
- emails.sh Per email sent, with the REST API and the SMTP relay drawing on one quota.
- SMTP2GO Monthly plans by email volume, relay and API on the same allowance.
- Free tier
- emails.sh 3,000 emails a month, 100 a day, no card, sending from your own verified domain.
- SMTP2GO 1,000 emails a month with a 200 a day cap, no card required.
- Sending domains
- emails.sh Domain authentication is the setup, not an optional step. You cannot send from an unverified domain, which is the behaviour you want.
- SMTP2GO Sender domain verification with SPF and DKIM, which also lifts the free hourly cap.
- Deliverability posture
- emails.sh Shared pools separated by send type, bounce and complaint tripwires below the thresholds that get senders suspended, dedicated IP on request.
- SMTP2GO The core of the product: high-reputation relay infrastructure across regions.
- Receiving mail
- emails.sh Inbound MX, parsed MIME, and In-Reply-To threading, so a reply arrives as part of a conversation you can query rather than as a raw webhook body.
- SMTP2GO Not a receiving product.
- Logs and retention
- emails.sh Every message searchable in the dashboard and readable at GET /v1/emails/:id, with its delivery, bounce, and complaint events attached.
- SMTP2GO Reporting and searchable activity, with retention by plan.
- Templates
- emails.sh Send html and text in the request, or store a template and reference it by id. No visual builder, because the markup belongs in your repo next to the code that sends it.
- SMTP2GO Basic template support. Not the reason to buy it.
- SDKs and frameworks
- emails.sh Nine language clients plus curl, and an SMTP endpoint for the code you are not rewriting.
- SMTP2GO An API with client libraries, though SMTP is the primary interface.
- Marketing and lifecycle
- emails.sh Audiences, broadcasts, and automations sit beside the relay, so the same account covers the mail your code sends and the mail somebody writes.
- SMTP2GO None. No contact list, audience, or campaign in their documentation; they recommend third-party mailing list software.
- Webhooks
- emails.sh email.delivered, email.bounced, and email.complained, each signed with x-emailssh-signature so you can verify the body before you act on it.
- SMTP2GO Webhooks for delivery events.
- Path for a coding agent
- emails.sh Every page served as markdown at the same path plus .md, an /llms.txt index of the whole site, and a Cursor and Claude Code skill you install once.
- SMTP2GO Human documentation and setup guides per platform. No installable assistant skill.
- Support
- emails.sh Email support on every plan including the free one, answered by the people who wrote the API. We are small, and that cuts both ways.
- SMTP2GO Well regarded, available on every plan including free.
Moving from SMTP2GO
You have a choice most migrations do not offer: change the credentials and keep the code, or take the chance to move to the API.
- 01
Swap the SMTP credentials first
Point your existing mailer at our SMTP host with credentials from the dashboard. Nothing in your application changes, mail flows, and you have a working baseline before you decide whether to rewrite anything.
- 02
Verify the sending domain
Publish our SPF, DKIM, and return-path records. Leave SMTP2GO's in place while both are live. A domain can carry several DKIM selectors, and the reputation you built stays with the domain rather than with either relay.
- 03
Move the paths worth moving to the API
Anything where you want the message id, the delivery events, scheduling, batching, or idempotency should become a POST /v1/emails call. Leave the appliance, the plugin, and the legacy service on SMTP. There is no prize for converting everything.
- 04
Add webhooks and watch a week
Subscribe to delivered, bounced, and complained, verify the signature, and compare the bounce rate against what SMTP2GO reported for the same traffic before you move the rest of the volume.
Questions
Does emails.sh have an SMTP relay?
Yes. The API is the primary interface and the one every doc leads with, but there is an SMTP endpoint for code you are not rewriting. Both draw on the same sending quota and appear in the same logs.
Is SMTP2GO good?
For its job, yes. If you need mail from an existing system to start arriving and you are not going to change that system, a relay is the right shape and theirs has a usable free tier and good support. We would rather say that than pretend a relay is a worse product than an API.
Why use an API instead of SMTP?
Because you get things SMTP has no way to give you: a message id to store, delivery and bounce events pushed to your endpoint, batch sends of up to 100 in one request, scheduling with send_at, and an idempotency key that stops a retry from sending twice.
Will switching hurt deliverability?
Reputation attaches to your domain and your content, not to the relay in front of them, so authenticating the same domain here is a smaller change than it feels. Run both for a week at a split you choose and compare the bounce and complaint rates on identical traffic.
Looking for a SMTP2GO alternative?
A relay is the right answer when you have working mail code and a delivery problem. When you are writing the sending code from scratch, an API you can hold in your head beats an SMTP transaction you have to configure, and the logs and webhooks come with it.
The free tier is 3,000 emails a month, 100 a day, no card, sending from your own verified domain, with delivery logs, webhooks, and inbound included. Enough to run real traffic through it before you decide.