On Page Navigation
On Page Navigation
Weighing SendGrid against Amazon SES, or wondering whether Postmark earns its premium, or whether a nine dollar plan from Brevo or Mailjet is a bargain or a compromise? Each comparison below sets our managed service beside one platform and says plainly where that platform is the better call.
How it all works
Raw sending APIs, full marketing suites and managed delivery solve different problems. These pages sort out which problem you have.
1
Start with whatever is already on your shortlist. The API a developer suggested, the platform your last agency set up, or the one your billing system ships with by default.
2
Each comparison covers what you pay at real volume, how authentication and domain setup are handled, how long the logs live, and who carries the pager when mail stops arriving.
3
Match the platform to your sending volume and to how much a bounced password reset actually costs you. Some teams should run this themselves. We will say so on the page where it is true.
Every platform here places a different bet on who does the work.
VS
Enormous Scale
Marketing Plus API
Now Part of Twilio
SendGrid moves more mail than almost anyone, and its website is now folded into Twilio.com. That scale is real. So is the fact that you are the one configuring authentication, warming reputation and reading bounce logs.
Learn More
VS
Cheapest At Scale
AWS Native
You Build The Rest
At ten cents per thousand emails a la carte, nothing undercuts SES on price. That price does not include the IAM policy, the bounce handling, the SNS wiring, or the person who notices your sending quota got throttled.
Learn More
VS
Developer First
Priced Per Volume
Validation Add Ons
Mailgun gives you a proper sending API from fifteen dollars a month. Log retention on that plan is one day. When a customer says the invoice never arrived, one day of logs decides whether you can answer them.
Learn More
VS
Transactional Only
Separate Message Streams
Deliverability Reputation
Postmark is the one we tell people to buy when they want to run it themselves. Deliverability is excellent and the pricing is honest. The only thing it does not do is operate the thing for you.
Learn More
VS
Marketing Plus Transactional
One Shared Email Meter
Free Tier Never Expires
Brevo runs campaigns and transactional mail on one plan and one monthly allowance, from nine dollars a month with a free tier underneath it. That is genuinely cheap. It also means a large campaign and your password resets draw on the same number.
Learn More
VS
Marketing Plus Transactional
One Shared Email Meter
Free Tier Never Expires
Brevo runs campaigns and transactional mail on one plan and one monthly allowance, from nine dollars a month with a free tier underneath it. That is genuinely cheap. It also means a large campaign and your password resets draw on the same number.
Learn More
About the service
Managed transactional email is not a sending account with our name on it. We own the sending domain, the SPF and DKIM and DMARC records, the reputation of the address your mail leaves from, and the alert that fires at two in the morning when a receipt stops being delivered. You get an SMTP endpoint and an API key. We take everything behind them.
Transactional email is invisible when it works and catastrophic when it does not, because the messages it carries are password resets and receipts rather than newsletters. The comparison below is mostly about price per thousand, and on that measure the raw infrastructure providers win comfortably. What they do not include is anybody noticing when delivery quietly degrades.
The second thing worth understanding is the difference between sending and arriving. Every provider here will accept your message and report it sent, and that number looks reassuring on a dashboard. Whether it reached an inbox depends on domain reputation, authentication records, and whether you are sharing an IP pool with somebody sending worse mail than you.
So buy on price if somebody will watch the bounce and complaint rates and act on them, because at that point these providers are close to interchangeable. If nobody is watching, the cheapest option is only cheapest until the first outage nobody caught, and the difference between those two situations is a person rather than a product.
SPF, DKIM and DMARC are three short records and they are easy to get subtly wrong. We set them on the exact domain you send from and align them so a mailbox provider can verify the whole chain. Once the reports come back clean we move DMARC from monitoring to enforcement. Then we keep watching, because a new tool somebody adds in six months is the usual way alignment quietly breaks.
Gmail, Outlook and Yahoo each decide about you separately, and a single average delivery rate hides which one has stopped trusting you. We track delivery and complaint rates per mailbox provider and treat a drop at any one of them as an incident rather than noise. You hear it from us before your support queue does.
Receipts and campaigns should never share a sending identity. We put transactional traffic on its own domain and its own stream, so a bad marketing send cannot take your password resets down with it. Bounces, complaints and suppressions are then handled per stream, which is also what makes the numbers worth reading.
What is transactional email?
Mail your application sends to one person because that person did something. Password resets, receipts, order confirmations, shipping notices, invites. It is triggered by an event rather than scheduled by a marketer, and the recipient is usually sitting there waiting for it, which is why a ten minute delay becomes a support ticket.
Why do our password resets and receipts land in spam?
Almost always authentication or reputation. If SPF, DKIM and DMARC are not aligned on the exact sending domain, a mailbox provider has no reason to trust the message. Reputation is the slower problem. Sending receipts from the same domain and IP as your newsletter means one bad campaign drags your resets down with it. We separate the streams and keep the authentication correct as your infrastructure changes.
What is the difference between transactional and marketing email?
Intent and consent. Marketing mail goes to a list on a schedule and it can wait. Transactional mail goes to one person in response to something they just did. Mailbox providers score the two differently, so mixing them on one sending identity costs you deliverability on the mail you can least afford to lose.
Do we need a dedicated IP address?
Below roughly a hundred thousand messages a month, no. A dedicated IP only earns a reputation if you send enough volume to keep it warm, and a cold dedicated IP performs worse than a well run shared pool. We tell you when your volume crosses that line, and we handle the warmup when it does.
What are SPF, DKIM and DMARC, and who sets them up?
They are the DNS records that let a mailbox provider verify you sent what you claim to have sent. We set them up and align them to your sending domain. Then we monitor the DMARC reports afterward, which is the step most teams skip and the one where the useful signal lives.
What does a managed service do that a sending API does not?
A sending API accepts your message and hands it off. Everything after that is yours. We own the domain authentication, the reputation monitoring, the bounce and complaint handling, the suppression list, the DMARC reporting, and the response when a provider starts throttling you. What you put down is the operational work, not the sending.
How fast should transactional email arrive?
Seconds, not minutes. A password reset that takes four minutes produces a second reset request and then a support ticket. We monitor delivery time by mailbox provider and treat a sustained delay at any one of them as an incident.
What happens when a message bounces?
A hard bounce means the address does not exist, and it must never be sent to again. Repeated sends to dead addresses are one of the fastest ways to damage a sending reputation. We maintain the suppression list automatically and surface the pattern when bounces cluster, because a spike in hard bounces usually means something upstream in your signup flow broke.
Can you migrate us off our current provider without downtime?
Yes. We stand up the new sending identity, authenticate it, warm it against a slice of your traffic, and cut over once the delivery numbers hold. Your application keeps sending throughout. Migrations go wrong when somebody moves all the volume at once onto a domain with no history.
Do you handle the email templates?
We handle the sending layer and any templates that live in it. If your templates sit inside your application they stay there, and we work with your team on the parts that affect delivery, such as the plain text alternative and the list headers. Design work on a marketing template is a different service.
What sending volume does this make sense at?
It pays for itself once transactional mail is load bearing, meaning a delivery failure costs you a customer or a support hour. That is usually somewhere above ten thousand messages a month. A small business sending two thousand invoices is a better fit than a side project sending fifty thousand notifications nobody reads.
What if we already use Amazon SES and it is cheap?
Then keep it. SES is the cheapest way to move mail and it is the right answer if you have an engineer who enjoys owning deliverability. What you would be buying from us is that engineer time back. We are happy to run the managed layer on top of your existing SES account rather than move you off it.
How do you measure whether it is working?
Delivery rate by mailbox provider, time to inbox, bounce and complaint rates, and DMARC alignment. Open rates are close to meaningless on transactional mail and we do not report them as a success metric. If Gmail delivery drops two points, you hear it from us first.
Are we locked into one email provider?
No. The authentication, the suppression list and the monitoring sit with us and travel with you. We pick the sending provider that fits your volume and your compliance requirements, and we will move you when that stops being true.
What do we need to do to get started?
Give us DNS access for the sending domain and tell us what your application sends today. We audit what is going out, fix the authentication, and take over the sending path. Most migrations are live inside two weeks.
