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, personalised 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 honouring 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 actually separates them
Four things, once price is set aside.
Deliverability infrastructure means authentication handled as configuration, suppression enforced automatically, and reputation managed per sending domain rather than left to each customer.
Stream separation determines whether the platform understands that transactional, marketing and cold outreach are different systems. A service running all three 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.
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.
Observability is the feature teams underrate at purchase and want most during an incident.
Integration surface is the last one, and the options 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.
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. Nick's framing is the right one: stay provider-agnostic in the records, and the provider becomes an implementation detail rather than a commitment.
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. 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.
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.