What you are actually buying
Every service in this category will accept your message and put it on the wire. That part is close to solved. What you are choosing between is how much of the operation around the wire comes with it: authentication, queueing, retries, bounce classification, suppression, and a sending reputation somebody has to watch.
So the split worth using is not transactional against marketing, and it is not cheap against expensive. It is the pipe, or the operation of the pipe.
Rent the pipe and you get transport at a low per-message rate and you own everything above it. Rent the operation and you pay more per message for suppression that enforces itself, bounces that arrive already classified, and reputation managed per sending domain rather than left to you.
Three groups sit along that line, and most of this page is those three. The ranked selection criteria themselves live on the transactional email services hub, because one argument split across four pages is a worse argument than one argument in one place.
Underneath all of it there is now a second question, and it is the one I care about. If the thing making the send call is an AI agent rather than a person or a deploy pipeline, who operates the operation? A dashboard is not an answer to that. An agent cannot look at one.
Email dashboards had a good run. Two decades, billions of emails, entire companies built on them, including two of mine. After building email tools for that long the thing I came away with is this: the dashboard was never the product, it was the bottleneck. Every platform in the three groups below was designed on the other assumption, that a human would be sitting in front of it with time to spare.
Transactional and developer-focused services
These serve mail triggered by an individual user action: receipts, password resets, verification codes, alerts. The integration surface is an HTTP API or SMTP credentials, and the product is judged on latency, delivery reporting and uptime.
Established names in this group include Resend, SendGrid, Postmark and MailerSend. They differ mainly in how much of the surrounding stack they carry, from a narrow send-and-report service through to platforms that also handle campaigns.
They are reliable, and they are built on legacy infrastructure. What they lack is the flexibility and intelligence that modern, personalized communication needs, which is the gap I started Nitrosend to close.
What matters at evaluation is the reporting layer rather than the send call. Per-message delivery status, bounce classification separating hard from soft failures, automatic suppression, and a searchable history long enough to investigate a complaint that arrives a week later.
Latency is a functional requirement for a specific subset of this mail. A one-time passcode arriving ninety seconds late has failed even though it was delivered.
Mass marketing and newsletter platforms
These serve mail the sender initiates to a list: campaigns, newsletters, announcements. The product is a composer, a segmentation engine, scheduling and reporting on opens and clicks.
Brevo, Sender and Mailchimp sit in this group, along with most tools marketed as email marketing platforms rather than as infrastructure.
The buying criteria are different from the transactional side. List management, consent capture, unsubscribe handling and template editing carry more weight than per-message latency, because a campaign scheduled for Tuesday does not care about a two-second delay.
Compliance obligations are heavier here. Marketing mail requires a working unsubscribe mechanism, a valid physical postal address, and honoring opt-outs within ten business days under CAN-SPAM, plus one-click unsubscribe headers for bulk senders under RFC 8058.
Raw infrastructure
A third category sells sending capacity with minimal tooling, of which Amazon SES is the clearest example. The per-message cost is low and everything above the transport is your responsibility.
That trade is real and worth stating plainly. Bringing your own infrastructure and building a light automation layer costs meaningfully less at scale, and it costs engineering time to build and maintain suppression, bounce classification, authentication management and reporting.
The decision is not about price per message. It is whether you want to own that layer.
I have run this math for real senders, and it is something I only started sharing publicly this year. For anyone with decent dev resources, your own Mailgun or SES plus a lightweight automation layer cuts costs by 70 to 80 percent at scale. At 100K contacts sending twice a month, Mailgun or SES costs about $0.80 to $1.00 per thousand emails, roughly $160 a month in sending costs, against $400 to $600 for the same volume in Mailchimp or Klaviyo.
What an agent needs from one
The operation half of this category was always a set of screens. Somebody logs in, reads a bounce report, decides to pause a domain, clears a suppression. That is the part an AI agent cannot do, and pretending otherwise is how you end up with an agent that sends confidently and cannot tell you anything afterwards.
Here is the frame I would evaluate the whole category on. Deliverability failures are almost always silent, and the design problem is making them loud. The failure I have actually watched is not a rejected send. It is a sending account reporting every message sent and nothing delivered, because the feedback path back from the provider was never wired up. Nothing errors. If your bounce feed has a gap like that, your guard rails are not running and nothing tells you. A person eventually notices. An agent never will, because the only signal it has is the one the send call returned, and that call succeeded.
The same trap has a smaller, more common version, and I have said it before now: "Verified" only means the DNS records are valid. It does not mean allowed to send right now. Those are two different states and most services only publish the first one.
None of this is a new problem. It is an old problem that a new caller makes acute, and the protocol underneath the whole category says so in plain language. RFC 5321 puts it this way: when the receiver accepts a piece of mail by sending a 250 OK in response to DATA, it is accepting responsibility for delivering or relaying the message. After that moment there is nothing the sender can query. A failure comes back later as a separate email, if it comes back at all, and there is no identifier to ask about and nothing to reconcile against.
The same section is candid about what happens when the acknowledgement goes missing. To avoid receiving duplicate messages as the result of timeouts, it says, the receiver must seek to minimize the time required to respond to the final end of data indicator. Be quick is the entire mitigation. That is survivable when the thing retrying is a person who will go and look. It is not survivable when the thing retrying is a model that tries again the instant a socket times out.
So everything a modern sending service sells above the transport is, in effect, the state the protocol never kept for you. Which makes the criterion on an agent-driven stack narrower and harder. It is not how good the reporting is. It is whether the service's own operating state is readable by the same caller that makes the send, and whether the caller can tell which of those reads are binding.
Three reads are worth checking any candidate for. Ours are documented at docs.nitrosend.com, which is the standard I would hold the rest of the category to.
The first is suppression. GET /v1/my/suppressions lists the account's active email suppressions and covers hard bounces, soft-bounce suppressions, complaints, manual suppressions, and the bounded provider diagnostic text kept from the source feedback event, filterable by email, reason and source_provider. That is the difference between an agent that reports a send failed and an agent that reports why it failed and on whose say-so.
The second is per-message status, so a question about one recipient has an answer that is not a guess.
The third is capacity, and it carries the caveat that matters most. GET /v1/my/delivery/status returns a read-only delivery projection with pacing and a bounded public reason and remediation, and the documentation is explicit that the endpoint never authorizes or reserves a send, and that clients must not calculate headroom from a plan name. The send still passes through a single delivery authority. An agent that treats the capacity read as permission will be wrong at exactly the moment being right matters.
That is the shape of the criterion, and it is the same shape as the verified problem. The state has to be readable, and the reader has to know which reads are advice and which are decisions. Almost nobody publishes the second half, and it is the half an autonomous caller needs.
The numbers the operation is actually managing to are published by the mailbox providers, not by the vendors. Google's sender guidelines tell bulk senders to keep the spam rate reported in Postmaster Tools below 0.30% and ideally below 0.10%, and they state that the DMARC enforcement policy can be set to none. Any service claiming a deliverability product is claiming to hold you under those numbers. Ask how it will tell you when you are drifting toward them, and whether it will tell the agent or only the screen.
Stream separation is the older version of the same idea and it still decides purchases. The thing worth internalizing is that a sending identity is not a label on an account. Reputation attaches to the domain the mail leaves from, which is why our own documentation tells you to verify more than one subdomain and route product mail through one and campaigns through another, so a large promotional send cannot drag down receipts and password resets. A service running transactional, marketing and cold outreach through one identity lets the worst stream degrade the best. Cold infrastructure is not marketing email: different domains, different mailboxes, different volumes, different deliverability rules.
The same model decides how a new sender earns volume, and this is where I would read a candidate's documentation closely rather than its pricing page. Most of the category publishes a warmup ramp: so many on day one, twice that on day two, a table you follow. Ours says the opposite in plain text. The term in our documentation is sender standing, with three states, Probation, Standard and Trusted. Capacity for a sending identity grows from its own matured clean delivered volume and it is explicitly not an age-based schedule. Standing combines attributable delivery history, current list verification, domain strength and account signals, and sufficient evidence can qualify an account on day one, because payment alone does not earn trust.
The reason I care about that distinction is that manual warmup was never a job worth a human's time. Porting a list to a conventional tool used to be hours of setup and weeks of warming up and optimization. It was the single worst part of changing providers, and it was worst precisely because it was a person watching a number climb.
That distinction matters more for an autonomous sender than for a person. A ramp table is something an agent can read and plan against and be wrong about, because the table was never the real constraint. Delivered volume is the real constraint, and it is worth knowing which one your provider is actually applying.
Consolidation is my answer to the two-vendor problem. A single API handles both transactional and marketing email in one stack, so the streams stay separate without the data splitting across two products.
Integration surface is the last one, and the options across the category are not equivalent. SMTP credentials suit a drop-in replacement for existing sending code. An HTTP API gives access to templates, suppression and event history that SMTP cannot express. Ours is the REST API and SDK for application sends, plus an MCP server and a CLI, on every plan including the free one.
Design for switching before you need to switch
The question worth asking of any sending service is not how good it is today but how expensive it would be to leave. That cost is usually paid in DNS, and it is paid by the customer rather than the vendor.
The architectural answer we chose is to have verification records point at us rather than at the underlying provider, specifically so the sending provider can change without customers redoing their DNS. Stay provider-agnostic in the records, and the provider becomes an implementation detail rather than a commitment. A customer-owned sending subdomain is the version of this you control yourself, and the reputation it builds is portable with the domain.
That is not hypothetical. We have had to plan for switching the underlying transport at short notice while an account review was pending, with Mailgun as the standby transport, and the plan only works because the customer-facing records do not name the provider.
Bringing your own provider is the strongest version of the same principle. Paid plans can bring their own keys for SES, Resend, Postmark, Mailgun or SendGrid, so the sending account, its reputation history and its pricing stay yours, and the platform above it becomes replaceable in a way it is not when the two are fused. I have made the same argument about model providers, where I have moved between three of them since 2022 with zero lock-in and switched in minutes. Email should be no different, and the reason it usually is comes down to DNS.
Every comparison above is still a person picking a vendor and wiring up an integration. I think that is the wrong layer to be shopping at, and I think it is the layer that goes away first. There is a version of this I have already seen twice. An agent went looking in our own documentation for a provider integration we had genuinely shipped, could not find a page for it, and concluded we did not support it. And a model talked a prospect out of us on the strength of a stale landing page, then flagged two of our own pricing pages for disagreeing with each other. Nothing on the marketing site mattered in either case. That is who is evaluating email sending services now, and a page that contradicts another page is not an editorial problem any more.
So the default is changing, and it is changing to an agent that plans the send, makes the call, reads the result back and tells you what happened. That is exactly why we built Nitrosend MCP-first: describe the email in Claude, ChatGPT, Cursor or Codex and let the agent handle the sending, not the dashboard. It is not an email tool with AI features bolted to the side. It is email where the agent is the operator.
Be realistic about what remains coupled. Templates, flows, segments and analytics live in the platform, so provider portability is not the same as platform portability, and a vendor offering the first while implying the second is answering an easier question than the one you asked. If you want the full selection argument, including where we rank and on what criterion, it is on the services hub, and the email API page covers the call itself.