uCheckeruChecker
11 min read

SMTP relay: SendGrid vs Amazon SES vs Mailgun

You need to send email at scale. Not through Outlook, not through your hosting provider’s built-in mail server that caps at 500 messages per day. You need an SMTP relay — a service that accepts your messages and delivers them through infrastructure built specifically for high-volume sending. Three names come up in every conversation: SendGrid, Amazon SES, Mailgun. Each solves the same fundamental problem. Each does it differently enough that picking the wrong one costs you months of migration later.


What SMTP relay does (and doesn’t do)

An SMTP relay sits between your application and the recipient’s mail server. Your app hands off a message — via SMTP protocol or HTTP API — and the relay handles delivery: queue management, retry logic, TLS negotiation, bounce processing, feedback loops with ISPs. You get deliverability infrastructure without building it yourself.

What a relay does not do: fix bad sending practices. If your list contains 30% dead addresses, the relay will dutifully attempt delivery on every single one, rack up bounces, and watch your sender reputation decline. The relay is a pipe. What you push through that pipe determines outcomes.

All three services — SendGrid, SES, Mailgun — provide SMTP endpoints and HTTP APIs. All three handle DKIM signing, bounce tracking, and suppression lists. The differences are in pricing models, operational complexity, and how much hand-holding you get.

SendGrid

Twilio SendGrid is the most recognizable name in the space. Over a hundred billion emails per month across their platform. They offer both a marketing product (drag-and-drop campaigns) and a transactional API. For SMTP relay purposes, the transactional side is what matters.

The free tier gives you 100 emails per day. The Essentials plan starts around $20/month for 50,000 emails. Pro plans go up from there, with dedicated IPs becoming available at higher tiers. Pricing is straightforward compared to SES, but not cheap at volume. Sending a million emails per month on SendGrid will cost you meaningfully more than the same volume on SES.

The dashboard is polished. Activity feed, bounce classification, link tracking, open tracking — all built in. Event webhook delivers real-time notifications about delivery status, opens, clicks, bounces, spam reports. The v3 API is clean and well-documented. SDKs exist for every major language.

Where SendGrid frustrates: support. At lower tiers, you get ticket- based support with no SLA on response time. Accounts get suspended without warning when their automated systems flag unusual sending patterns — and getting unsuspended can take days. This is the single most common complaint across forums and reviews. If you are ramping up sending volume quickly, expect friction.

Dedicated IPs require manual warmup. SendGrid provides guidance, but the process is on you. Skip it and your mail ends up in spam.

Amazon SES

Amazon Simple Email Service is the budget option — and “budget” here is not pejorative. At $0.10 per 1,000 emails (plus data transfer), SES is an order of magnitude cheaper than SendGrid at scale. A million emails per month costs roughly $100. On SendGrid that same volume runs several hundred dollars at minimum.

The tradeoff: SES is infrastructure, not a product. There is no dashboard in the traditional sense. Configuration happens through the AWS console or CLI. Bounce and complaint notifications come via SNS topics that you configure yourself. Want event tracking? Set up a configuration set, create an SNS topic or Kinesis Firehose, write the glue code. The documentation is extensive but assumes familiarity with the AWS ecosystem.

New SES accounts start in sandbox mode: you can only send to verified addresses. Moving to production requires a support request explaining your use case, estimated volume, and bounce handling strategy. AWS reviews it manually. Approval can take anywhere from hours to days. This gating is more rigorous than SendGrid or Mailgun, which is partly why SES shared IPs tend to have better aggregate reputation.

SES gives you dedicated IPs for a flat monthly fee ($24.95/IP/month as of 2026). They also offer a managed warmup pool feature that handles IP warmup automatically — a significant improvement over the manual process required by SendGrid and Mailgun.

If your team already lives in AWS, SES is a natural fit. IAM roles for authentication, CloudWatch for metrics, S3 for storing received mail. If your team does not live in AWS, the learning curve is steep.

Mailgun

Mailgun (now owned by Sinch) positions itself between the two: developer-friendly like SES, but with a product layer like SendGrid. Their free trial includes 5,000 emails for the first month, then pricing starts at $35/month for 50,000 emails. Pay-as-you-go is available at roughly $0.80 per 1,000 for lower volumes.

The API is arguably the best of the three for developers. Sending, receiving, validating, routing — everything is a clean REST call. Mailgun also provides email parsing (inbound routing), which neither SendGrid nor SES offer natively with the same simplicity.

Deliverability tools include an inbox placement testing feature (Inbox Placement) and seed list testing — useful, though both are add-ons with separate pricing. Logs are detailed and searchable. Event webhooks work similarly to SendGrid’s.

Mailgun’s weakness is scale pricing. At high volumes (millions of emails per month), the per-message cost stays relatively flat compared to SES’s rock-bottom rates. For a startup sending 100K emails/month, Mailgun is competitive. For an enterprise sending tens of millions, the math favors SES heavily.

Support at paid tiers is responsive. Dedicated IP warmup is semi-automated. The EU region (eu.mailgun.org) is available for GDPR compliance, which matters if you process European personal data.

Criterion
SendGrid
Amazon SES
Mailgun
Price (1M emails/mo)
$250–600+
~$100
$300–500
Free tier
100 emails/day
None (sandbox)
5K first month
Dedicated IP
Pro plan+
$24.95/IP/mo
From $59/mo
IP warmup
Manual
Managed pool
Semi-automated
Dashboard
Full-featured
AWS Console
Clean UI
API quality
Good
Standard AWS
Excellent
Inbound parsing
Yes
Via S3 + Lambda
Yes, native
EU region (GDPR)
No choice
eu-west-1 etc.
eu.mailgun.org
Support
Slow on lower tiers
AWS Support (paid)
Fast on paid tiers
Setup barrier
Low
High (AWS experience)
Medium

Prices current as of early 2026. Check each service’s site for current rates.

Which one fits your situation

SendGrid is the right call when you need working infrastructure without going deep on DevOps. Marketing teams, early- stage SaaS products, companies without a dedicated email engineer. You set DNS records, connect, and send. The downside: once you clear a million emails a month, you start paying noticeably more per message than either competitor charges for the same throughput.

Amazon SES makes sense when volumes are high, budget is tight, and your team knows AWS. Fintech, e-commerce platforms with millions of transactional notifications, user-generated email at scale. The cost is an order of magnitude lower. The catch: you build all the surrounding infrastructure yourself — monitoring, alerts, bounce handling.

Mailgun fits when you want the balance between convenience and control. Developers who value a clean API but do not want to wire up SNS topics and Lambda functions. Mid-range volumes, inbound parsing requirements, European data residency. At high scale it loses to SES on price, but it saves engineering hours along the way.


What all three have in common

None of these services fix list quality problems. SendGrid, SES, and Mailgun are transport. They deliver what you give them. Feed in a list with 20% invalid addresses and the relay will attempt all of them, collect bounces, register complaints, and pull your domain reputation down. The service itself may then suspend your account for a high bounce rate. SendGrid does this automatically. SES cuts your sending quota. Mailgun sends a warning and then pauses sending.

Different mechanisms, same result: dirty lists break any relay.

An SMTP relay is a pipe. What you put in determines what comes out. List quality matters more than which service you choose.

Pitfalls when migrating between services

Switching relay services looks simple on paper: change the SMTP host and credentials. In practice, there are a few traps.

First: IP reputation. On your old service you built reputation on specific IP addresses. On the new one you start from zero. With a dedicated IP that means warmup. On shared IPs you depend on your pool neighbors’ behavior.

Second: suppression lists. Every service maintains its own list of addresses it refuses to send to — hard bounces, spam complaints, unsubscribes. These lists do not transfer between platforms. Move from SendGrid to Mailgun without exporting your suppressions and Mailgun will attempt delivery to addresses SendGrid already marked dead. Expect a bounce rate spike in the first few days after migration.

Third: DNS. DKIM keys are tied to each service. When you switch, you generate new keys, add them to DNS, and wait for propagation. Leave the old DKIM records in place and DMARC checks can produce unexpected results.

List validation as insurance

Before connecting to any of these three services, run your list through a validator. Not because it is standard practice, but because it directly affects both send cost and account safety.

On SES at $0.10 per thousand, the cost difference may seem small. But SES is the harshest on bounce rates: the threshold is 5%, after which your account goes into review, and repeated violations lead to suspension. SendGrid can auto-suspend your account mid-campaign when bounce rate spikes. Mailgun will send a warning, but by then your domain reputation has already taken a hit.

Cleaning your list before sending is the cheapest way to keep your account healthy. Cheaper than working through SendGrid support tickets. Cheaper than trying to restore your sending quota in SES after a suspension. Cheaper than warming a new IP from scratch.

Practical recommendations

Do not lock yourself into one relay. An architecture where swapping the transport requires rewriting half your codebase is a fragile architecture. Abstract your sending layer: an interface with send, get_status, and handle_bounce methods, with a concrete provider behind it. Changing provider means swapping one implementation.

Monitor bounce rate in real time. All three services provide webhook events. Wire them to alerts. If bounce rate after a send exceeds 2%, stop and investigate the segment — do not wait for the service to suspend your account.

Separate your streams. Transactional mail (order confirmations, password resets) and marketing campaigns should go from different subdomains and, ideally, different IPs. If a marketing blast draws complaints, that should not hurt transactional deliverability. SendGrid and Mailgun support multiple domains out of the box. On SES you configure this through configuration sets.

Validate your list before every large send. Addresses go stale faster than most people expect — 20 to 25% of a list per year. Quarterly validation is the minimum. Before migrating to a new relay, it is non-negotiable.

Before connecting a new SMTP relay, check your list in uChecker — 30 free verifications to see the real state of your list.

SMTP relaySendGridAmazon SESMailgunemail infrastructuredeliverabilitytransactional emailemail validationbounce rate