Choosing a transactional email API on deliverability grounds

For a SaaS product, the deliverability question about an email API is not "how good are their IPs". It is: can I keep password resets away from marketing mail, can I see why a specific message failed three weeks ago, can I control suppressions programmatically, and what happens when my own sending gets worse. Those four answers differ far more between providers than throughput does.

The criteria that actually separate providers

1. Stream separation. Transactional and promotional mail must not share reputation. Postmark enforces this with message streams and will not let you blur them. On Amazon SES you build it yourself with separate verified identities, subdomains and configuration sets. On SendGrid and Mailgun you use separate subdomains and, with dedicated IPs, separate pools. Any provider can do it; only some make it the default.

2. Log retention and searchability. You will be asked "did this user get the email on the 3rd". Retention varies by provider and plan, and SES keeps nothing at all unless you attached an event destination before the send. Assume you must store events yourself: subscribe to a webhook, write the events to your own database, and keep the receiver's raw SMTP response string.

3. Suppression control via API. You need to list, add and remove suppressions programmatically, because your application's state and the provider's must agree. SES exposes an account-level suppression list with API access; SendGrid exposes its five suppression types; Mailgun exposes bounces, unsubscribes and complaints per domain. Check this before you build, not after.

4. Authentication model. All of them sign DKIM for your domain once configured. The difference is the return path: SES needs a custom MAIL FROM subdomain (an MX plus an SPF record on that subdomain) before SPF can contribute to DMARC alignment; SendGrid's domain authentication creates a mail subdomain for the same purpose; Mailgun verifies a sending domain with SPF and DKIM records plus a tracking CNAME. Get the alignment right on day one and verify it from a received message's headers.

5. Sandbox and test behaviour. SES starts every account in a sandbox limited to verified recipients at low volume, which you leave by requesting production access from the *Account dashboard* — per Region. Some providers are built around a capture-and-inspect sandbox for development and offer production sending as a separate stream; that separation is genuinely useful for a team that keeps accidentally emailing real users from staging.

6. What happens when you misbehave. AWS publishes its thresholds: account review at 5% bounce or 0.1% complaint. Others act on patterns without naming a number. Either way, budget for the possibility of a review and keep your own bounce handling tight enough that it never triggers.

A comparison that fits on one row each

Pricing is deliberately absent here: it changes often, and it is the one criterion you can check yourself in a minute.

How to run a fair trial

1. Pick one real stream — password resets, say — and send it from a dedicated subdomain on each candidate.
2. Authenticate properly on both, including the return path, and confirm dkim=pass and dmarc=pass from a received message.
3. Keep volume and content identical, run for two to three weeks, and store the events yourself so the comparison is not limited by either provider's retention.
4. Measure: per-provider seed placement, deferral and bounce mix from the SMTP strings, time to delivery at the 95th percentile, and the Gmail spam rate per sending subdomain in Postmaster Tools.
5. Test the failure path deliberately — send to an address you know bounces and confirm your suppression sync works.

What not to do

• Do not run marketing campaigns through a transactional API on the same subdomain as your product email. One complaint spike and your receipts are in Junk.
• Do not pick a provider because a benchmark page shows a higher inbox rate. Those tests use their own lists, content and reputation, none of which are yours.
• Do not skip the custom return-path step on SES. DKIM-only alignment survives most paths but breaks under forwarding.
• Do not rely on the provider's dashboard as your source of truth for user support. Store events.
• Do not use a shared link-tracking domain for product email. Brand it on your own subdomain or drop tracking.

MailPilot connects over SMTP and IMAP to SendGrid, Amazon SES, Mailgun, Postmark and custom SMTP hosts, and over OAuth to Gmail and Outlook — so the same warm-up, SPF/DKIM/DMARC checks, per-provider inbox placement measurement and daily per-mailbox reputation tracking apply whichever API you choose, including during a migration when both are live.