# Resend vs SMTP2GO Source: https://wraps.dev/versus/resend-vs-smtp2go An API for code you are writing against a relay for systems you cannot change. The question is not which is more modern. It is whether the thing sending your mail is something you are allowed to rewrite. This pair gets miscast as old versus new. It is not. Resend is an HTTP API with SDKs, aimed at code you are actively writing, and a template story that assumes you have a React build. SMTP2GO is a relay built on the premise that a great deal of the world's business email is emitted by software nobody is permitted to modify, and that the vendor's job is to accept that traffic, deliver it, and tell you clearly what happened. Decide which of those describes your sender, and the rest follows without much argument. ## At a glance |   | Resend | SMTP2GO | | --- | --- | --- | | What it is | Developer-first email API built on SES | SMTP relay with strong reporting | | Published pricing | Free 3,000/mo (100/day). Pro $20 at 50K and $35 at 100K. Scale starts at $90 for the same 100K and runs to $350 at 500K. Overage $0.65–0.90 per 1,000. Marketing contacts billed separately at $40/mo per 5,000. | Free 1,000/mo (200/day). Starter $10/mo at 10K. Professional from $75/mo at 100K, which is where dedicated IPs and inbound parsing unlock. Overage $1 per 1,000 on Starter, $0.85 on Professional. | | Best for | The fastest path from an empty project to a sent email, especially with React Email. | Apps and appliances that need a relay to just work, with reporting good enough to debug from. | | Watch out for | Logs are purged at 30 days on every non-Enterprise plan, the API is capped at 2 requests per second on all tiers, and suspension during traffic spikes is the complaint that recurs in its public reviews. | Relay-first by design: no modern SDK, no lifecycle automation, and no React template rendering. | Prices are each vendor's published list prices, verified August 2026. Check the vendor's own page before you sign anything. ## Where they actually differ ### What is emitting the message Resend Application code you own, calling an HTTP endpoint with a JSON body. Resend's SDKs, its error shapes and its documentation all assume an engineer is typing. There is an SMTP interface, and it is genuinely usable, but it is a compatibility path rather than the product's spine — the features that make Resend worth choosing live on the API side. SMTP2GO Anything that speaks SMTP, which in practice means an enormous amount: backup appliances, monitoring agents, a fifteen-year-old ERP, a printer, a CMS whose mail plugin nobody dares upgrade. SMTP2GO's whole design assumes the sender cannot be rewritten, so the setup is a hostname, a port, a username and a password, and the product's intelligence is applied after the message arrives. ### What the reporting is trying to tell you Resend Per-message delivery state with a webhook stream behind it, oriented toward answering a question about a specific send from inside your own systems. The dashboard is clean and current. The history is finite: thirty days on every plan below Enterprise, after which the answer to what happened to that email is that nobody knows. SMTP2GO Reporting is the reason people stay. Delivery and bounce breakdowns, spam-complaint tracking, blacklist monitoring on the addresses you send from, and a report that arrives in your inbox rather than waiting for you to open a dashboard. For a sender you cannot instrument — because you did not write it — vendor-side reporting is the only visibility that exists, which is why the relay invests there. ### The throughput ceiling, and where each one puts it Resend Two requests per second on the API, on every tier, permanently. For request-response mail that is more than enough and you will never think about it. For anything that bunches, you build a queue and drain it, and the work is neither hard nor optional. SMTP2GO A relay is metered by volume rather than by request rate, and an SMTP connection can carry many messages sequentially without a per-call ceiling of that shape. The limit you meet instead is the plan's monthly allowance and, on the free and entry tiers, a daily cap that will stop a bulk run cold in the middle of a Tuesday afternoon. ### Rendering the email at all Resend React Email is the answer, and it is a good one: components in your repository, reviewed and versioned like the rest of your code, with a rendering step that produces HTML you can test. It presumes a JavaScript build, and a Python or Go shop gets a noticeably thinner version of the experience than the marketing implies. SMTP2GO There is essentially no template layer, and that is coherent rather than missing. A relay receives a fully-formed message from a sender that already decided what it looks like — your ERP's invoice template, WordPress's password reset. Adding a rendering feature would serve nobody, because by the time SMTP2GO sees the mail, rendering already happened somewhere it does not control. ### When the credential leaks Resend An API key is revocable in one place, scoped, and visible in a list with a creation date next to it. Rotating it is a deploy. The exposure surface is your codebase and your secret store, which are things a security review knows how to reason about. SMTP2GO SMTP credentials get typed into device configuration screens by people who then leave the company, and they end up in wiki pages, shell scripts and appliance backups. SMTP2GO's answer is per-sender users so you can issue one credential per system and revoke it without touching the others, which is the single most useful operational habit on the relay side and the one teams most often skip. ### Dedicated addresses and the unlock point Resend Resend sits on shared AWS reputation by default and dedicated sending is an upper-tier conversation rather than a self-serve toggle. For most senders on this platform shared is correct — the pool is enormous and well managed — but it does mean isolation is not a lever you can pull on a bad week. SMTP2GO Dedicated IPs unlock at the Professional tier, alongside inbound parsing, which makes that tier a capability step rather than a volume step. Below it you are on a shared pool, and the blacklist monitoring in the reporting is partly there so you find out about a neighbour's problem the same day rather than from a customer. ### Where the mail is processed Resend On AWS, in the regions Resend operates, with the account boundary belonging to Resend. If your compliance answer needs to name a processor and a region, you are naming a company that is itself a customer of another company, and the questionnaire gets longer than it looks. SMTP2GO SMTP2GO runs relay endpoints in multiple regions and will pin your account's processing to one, which is a shorter answer to a data-residency question than most vendors in this category can give. For an EU or APAC organisation whose lawyer asks where the message body physically goes, having a single supplier with a single answer is worth more than a feature comparison. ### Receiving replies Resend Inbound is the narrower half of Resend and arrived well after the outbound product. If reply handling is structural to what you are building rather than a convenience, verify the current capability against your requirement directly rather than assuming it matches the polish of the send path. SMTP2GO Inbound parsing exists and unlocks with the Professional tier, forwarding structured messages to an endpoint you nominate. It is a sensible fit for the relay's audience — the appliance sends out, the replies come back somewhere a human or a ticket system can see them — and it is not a routing engine with conditional fan-out if that is what you need. ### What neither of these is Resend Not a marketing platform. Broadcasts exist and are deliberately minimal — an audience, an email, a send — which is right for a changelog and nowhere near a lifecycle tool. Anything involving behavioural segmentation or a branching journey is a second vendor. SMTP2GO Not a developer platform. There is no idiomatic SDK, no React rendering, no lifecycle automation, and the API is a thin management surface rather than the primary way you are expected to send. Choosing it because it is cheap and then wanting the things an API product gives you is the most common way teams end up unhappy with it. ## Pros and cons, side by side ### Resend Strengths - SDKs, typed errors and documentation all assume an engineer is typing, so the integration reads like the rest of your application rather than like a configuration exercise. - Templates are components in the repository, reviewed and versioned with everything else, which is a better model than any hosted editor for a team that ships code weekly. - The delivery floor underneath belongs to AWS and costs you nothing to inherit, which is an unusually high starting point for a product this young. - A permanent free allowance means a prototype or a weekend project does not generate an invoice, which is why so many integrations start here by default. Trade-offs - Two requests per second on every tier means anything that bunches becomes a queue you build and then own forever, and no amount of spending removes the ceiling. - Records purge at thirty days on every plan short of Enterprise, so what happened to that email eventually has no answer at all rather than a slow one. - The React rendering story presumes a JavaScript build, and a Python or Go team gets a noticeably thinner version of the experience than the marketing suggests. - There is no per-sender credential model, so a fleet of systems sharing one API key is exactly as isolated as that sounds — which is to say, not at all. ### SMTP2GO Strengths - Setup is a hostname, a port, a username and a password, which is the only interface a great deal of business software will ever be capable of offering you. - Reporting is pushed rather than pulled: delivery and bounce breakdowns, complaint tracking and blocklist monitoring arrive whether or not anybody logs in. - Processing can be pinned to a named region, which answers a residency question in one sentence rather than in a questionnaire with three follow-ups. - The support organisation is used to firewalls, ports and appliance settings pages, which is a genuinely different competence from knowing an SDK. Trade-offs - There is no idiomatic SDK, no rendering and no lifecycle tooling, so a team that arrives on price and then wants what an API product offers is the archetypal unhappy customer. - Inbound parsing and dedicated addresses both sit on the higher tier, so a plan sized on volume can turn out not to include the capability the design assumed. - A daily cap sits under the monthly allowance on the lower plans, which stops a bulk run mid-afternoon while the month still looks like it has room to spare. - The API is a thin management surface rather than the send path, so anything you wanted to automate about the account itself is thinner than the dashboard implies. ## Pick in thirty seconds ### Choose Resend if - You are writing the code that sends, and want SDKs, typed errors and templates that live in the repository. - React Email is already how you want to author, and your stack has a JavaScript build to render it in. - Sending is steady request-response traffic that never bunches above a couple of messages a second. - You want the send path and the event stream to look like the rest of your application's infrastructure. ### Choose SMTP2GO if - Something in your estate speaks SMTP and nothing else, and rewriting it is not on anybody's roadmap. - You need vendor-side reporting good enough to debug from, because you cannot instrument the sender yourself. - Several separate systems send mail and you want one revocable credential per system rather than one shared secret. - A data-residency question needs a short answer naming one supplier and one region. ## What actually moves when you switch In roughly the order you would do it. The expensive parts of an email migration are never the send call. 1. Split the estate into code you deploy and things with a settings page, then cost each half on its own. This decision is almost never one answer for a whole company: the application is a straightforward integration either way, and the appliances, the ERP and the CMS plugin are a different project with a different owner. A plan that treats both halves as one migration underestimates the second half every time. 2. Confirm which outbound ports each sender can actually reach, because the two products need different holes in the network. An API integration goes out over the same port as every other HTTPS call and is already permitted; a relay needs a submission port that a surprising number of corporate networks block selectively and inconsistently. Test from the machine that will send, not from a laptop on the office wifi, and do it before anybody schedules a cutover. 3. Find out what each legacy sender does when a send fails temporarily, because half of them drop the message and say nothing. Old software that does not retry produces a failure visible only in the vendor's reporting and nowhere in your systems, which is an argument for the side whose reporting is the product. Where a sender does retry, check how aggressively, because a tight loop against a rejected message is its own incident. 4. Inventory the credentials as they exist rather than as the documentation describes them. A shared relay password has usually reached three wiki pages, two shell scripts and an appliance backup by now, and the migration is the only realistic opportunity you will get to issue one per system. Doing it later requires a reason, and a migration is a reason; a quiet Thursday in March is not. 5. Move the rendering responsibility explicitly, because it changes teams. A relay receives a finished message from a sender that already decided how it looks, so nothing about templates transfers in that direction. Coming the other way, your application inherits the job of producing HTML for mail that a vendor used to render. Whichever way it goes, write down who owns the output afterwards. 6. Rebuild the observability rather than assuming it transfers, since these two make you watch different things. One posts signed events to your endpoint and expects your systems to aggregate them; the other emails you a standing report and monitors your sending addresses against blocklists. A team that swaps one for the other without replacing the alerting simply stops noticing problems, and the gap is invisible until something has already gone wrong. 7. Give the two traffic classes separate subdomains if you end up running both, which a fair number of organisations should. The application you actively develop on the API, the fleet of unmodifiable systems on the relay, each with its own DKIM keys, so a misbehaving legacy box cannot reach the standing your password resets depend on. The extra cost is one DNS record and one vendor relationship. 8. Watch the daily ceiling rather than the monthly figure during the transition, because both sides have one on their lower plans and neither advertises it prominently. Draining a backlog on the first evening of a cutover is exactly the shape of traffic that meets it, the month still shows headroom, and to everybody who is not reading the plan page the result looks precisely like an outage. ## Questions to ask before you sign Put these to a sales rep, or find the answer in the documentation before anyone quotes you a number. 1. Which of our senders is code we deploy, and which has only a settings page somebody filled in years ago? 2. Can the machines that will send actually reach a submission port from where they sit on the network? 3. What does each legacy sender do when a send fails temporarily — retry, queue, or drop it and say nothing? 4. How many systems currently share one sending credential, and what would we have to touch to rotate it? 5. Who or what produces the HTML for our messages today, and does that change if the vendor stops rendering? 6. If our bounce rate doubled overnight, which of us would find out, and would it be from a report or a customer? 7. Do we need inbound parsing, and have we checked which tier on each side actually includes it? ## Common questions ### Resend supports SMTP — why would I use a relay instead? Because the SMTP interface and a relay product are different amounts of product. Resend's SMTP path exists so a legacy sender can be pointed at it, and it works. What it does not bring is the surrounding apparatus a relay-first vendor builds: per-sender credentials, blacklist monitoring on your sending addresses, long-lived aggregate reporting, and a support organisation whose customers are mostly people wiring up devices rather than writing integrations. If SMTP is the exception in your architecture, use Resend's. If it is the rule, buy the product built for it. ### Will a relay hurt my deliverability compared to an API? The protocol has no bearing on it. What decides placement is authentication, reputation and content: SPF and DKIM aligned to the domain in the From header, a DMARC policy, a clean list, and sensible complaint handling. Both vendors sign and align correctly when configured, and both will suspend you for a bad list. The one protocol-adjacent risk is that a legacy sender is more likely to emit malformed or unauthenticated mail than code you just wrote, which is a problem with the sender rather than with SMTP. ### Can I use both at once? Yes, and a fair number of organisations should. Point the application you are actively developing at the API, and point the appliances, the ERP and the wiki at the relay. Use different subdomains for the two so their reputations are independent, so a misbehaving legacy system cannot take down your password resets, and so the reporting for each is separable. The extra cost is one more vendor relationship and one more DNS record. ### What should I check before pointing a legacy system at either? Three things, in order. Whether the system lets you set the envelope and header From independently, because misalignment there is the most common cause of DMARC failures on old software. Whether it supports STARTTLS on a port your network allows outbound, since a surprising number of corporate networks block the submission ports selectively. And whether it retries on a temporary failure or drops the message silently — if it drops, your vendor's reporting is the only place that failure will ever be visible, which is an argument for the vendor whose reporting is the product. ### How long does each keep a record of a sent message? Resend purges at thirty days on every plan short of Enterprise. SMTP2GO keeps reporting history longer, with the window varying by plan, and its archive-style features are part of what its higher tiers sell. Neither gives you an archive you own. If you have a regulatory or contractual reason to prove what was sent to whom two years ago, the only answer that survives a vendor change is to write the events into your own storage as they happen, which costs very little to build and is impossible to build retroactively. ### Our appliance cannot connect — is that the vendor's problem? Usually not, and the first thing to check is the network rather than the account. Submission ports are blocked selectively on a great many corporate and hosting networks, sometimes only for particular subnets, sometimes only outbound from a VLAN somebody segmented three years ago. An API integration never meets this because it travels over the same port as every other outbound HTTPS request and is already permitted everywhere. Test from the machine that will actually be sending, not from a laptop on the office wireless, because those two are frequently on different sides of a rule. Once the connection is proven, TLS negotiation is the next most common failure and the one an appliance is least likely to report clearly. ### What happens to mail our legacy system fails to send? That depends entirely on the sender, and it is worth establishing per system rather than assuming. Software that implements SMTP properly queues a temporary failure and retries; a surprising amount of older software attempts the send once, discards the message on any error and logs nothing anybody reads. When that happens, the vendor's reporting is the only place the failure exists at all, which is a concrete argument for the side that pushes reporting at you rather than waiting to be searched. Where a sender does retry, check how aggressively — a tight loop hammering a rejected recipient is its own small incident and looks, from the receiving end, indistinguishable from abuse. ### How many credentials should we be issuing? One per system, and a migration is the only realistic opportunity you will get to make that true. A shared relay password has generally reached a couple of wiki pages, a shell script and at least one appliance backup by the time anybody counts, and nobody rotates it because nobody knows the full list of things that would break. Issuing one credential per sender means a leak is scoped to one device, a decommissioned machine can be revoked without a change-control meeting, and the reporting tells you which system is responsible for a bounce rate. Doing this later requires a reason. The migration is a reason. ### Do we have to move everything to one of these? No, and for a good number of organisations the split is the right architecture rather than a compromise. Point the application you are actively developing at the API, point the appliances, the ERP and the CMS at the relay, and give each its own sending subdomain with its own DKIM keys so a misbehaving legacy box cannot reach the standing your password resets depend on. The ongoing costs are honest and small: one more supplier relationship, one more DNS record, and two suppression records that nobody reconciles unless you decide up front which of them is authoritative about a bad address.