Mailgun vs Amazon SES

Mailgun gives a developer team a managed email control plane

Mailgun, operated by Sinch, is shaped around the problems that appear after a product starts sending real messages: domain authentication, API delivery, SMTP compatibility, event inspection, inbound replies, and list hygiene. The REST API fits invitations, password resets, invoices, usage alerts, account notices, and sales-assist messages. SMTP keeps an older service moving while the application team replaces it. This lets a B2B SaaS group choose an integration surface per service instead of forcing a single rewrite on launch day.

The practical strength is the proximity of several operational tasks. A team can keep sending domains, routes, events, and logs under a Mailgun account, then give each service its own key and naming convention. That does not remove the need for an internal message ledger. Store the business event, template version, recipient consent state, provider identifier, and final outcome in your own systems. Mailgun should help an operator investigate a message; it should not be the only place where your company can explain why a renewal reminder was sent or suppressed.

Mailgun is useful where replies are part of the product. Inbound routes can match recipients or message properties and pass parsed content to an endpoint, forward it, or store it. A support workflow can turn replies into tickets, a procurement mailbox can attach a document to an account, and a sales response can return to the correct opportunity. Decide how to scan attachments, reject oversized messages, preserve headers, and protect personal data before enabling a public inbound address. The route is a delivery primitive, so your application still owns authorization and business rules.

Email validation is a material differentiator for teams that collect addresses in signup, invite, or import flows. Mailgun Optimize is an add-on for real-time and bulk validation. Use it before a list enters a campaign system, but keep a policy for disposable domains, role addresses, and an address that later bounces. Validation is not consent and it is not a guarantee of inbox placement; it is a quality signal that can reduce obvious delivery waste when joined to permission and suppression data.

Mailgun lists Foundation at $35 per month after the first month for 50,000 emails with 5 days of log retention, and Scale at $90 per month after the first month for 100,000 emails with 30 days of retention and 5,000 validations included. A team handling an incident weeks after it happened should export events to its own store rather than assume the plan log is an archive. Mailgun also lists one dedicated IP with Foundation 100k, Growth, and Scale, and $59 per month for each additional IP. A dedicated address needs authentication, warm-up, complaint review, and ownership before it becomes useful. "} />

• Separate domains and API keys by product, environment, and message class.
• Keep an internal message ledger with consent, template, provider ID, and outcome.
• Design inbound route authorization, attachment handling, and retention before opening a reply address.
• Treat Optimize validation as a quality signal that complements consent and suppression.
• Export important events when plan retention is shorter than your support or audit period.

Amazon SES is a low-cost AWS building block

Amazon SES makes the most sense when the platform team already operates AWS as a production discipline. The service supplies API and SMTP delivery, identities, quotas, configuration sets, and regional controls. Your team supplies template storage, approvals, retries, event consumers, suppression, dashboards, incident procedures, and the handoff between application and communications owners. That division can be efficient for an AWS-native company, but it is a poor fit for a team expecting a campaign editor or finished marketing workspace.

IAM is the center of the SES operating model. Create roles that can send only through the intended region and configuration set, and keep deployment permissions distinct from message-sending permissions. Use temporary credentials where possible, rotate SMTP credentials, and test a denied action as well as an allowed one. Separate AWS accounts can isolate environments, while scoped roles may be enough for a smaller organization. The right boundary is the one that the on-call engineer, security reviewer, and finance owner can all describe without guessing.

New SES accounts start in the sandbox. Before production traffic, verify identities, describe the sending purpose, document recipient permission, set expected volume, and request production access. Add that request to the launch plan alongside DNS records and application deployment. A successful local test is not proof that a production sender is ready: the team still needs quota decisions, bounce and complaint handling, suppression, event delivery, and a clear owner for a rejected or delayed message.

Configuration sets bridge a send call and operational visibility. Attach a set to a message stream and route events to SNS, CloudWatch, or another destination, then make the consumer idempotent. Store raw and normalized events so support can connect a provider event to an invoice, invitation, or security notification. Name sets by environment, region, product, and class of mail. Virtual Deliverability Manager adds an AWS-native reputation view and recommendations, but it does not replace authentication, permission, suppression, or an incident runbook.

SES lists Essentials at $0.16 per 1,000 emails and Pro at $0.22 per 1,000 emails for 0–10 million emails per month. Pro also lists $105 per account per region per month. Those figures make the delivery meter attractive, but the meter is only one part of the service. A platform team must budget the event pipeline, storage, dashboards, support plan, validation, and any dedicated IP choice. SES has no marketing UI, so a growth team needs a separate campaign product or governed internal interface. "} />

• Treat sandbox exit, identity verification, quota, and production access as launch dependencies.
• Use IAM roles and regional configuration sets with least privilege and explicit names.
• Make event consumers idempotent and retain enough data for support and incident analysis.
• Price AWS event, storage, support, and dedicated IP choices beside the email rate.
• Procure a separate marketing interface when campaign owners need editing and scheduling.

Which team should pick which service?

Choose Mailgun when the B2B SaaS has a small platform group and wants to reduce the amount of email infrastructure it must assemble. It fits a product with inbound replies, a signup or import flow that benefits from validation, multiple sending domains, or support staff who need a focused place to inspect delivery. Mailgun also suits a Rails, Django, or Node service that wants API and SMTP paths without adopting AWS concepts in every repository. The price is easier to forecast at listed 50,000, 100,000, and 250,000 email points, although validation and IP choices still deserve their own line.

Choose SES when the email path belongs inside an existing AWS platform. The team should already be comfortable with IAM, regions, CloudWatch, SNS, S3, Lambda, infrastructure-as-code, and the responsibility of building a durable event ledger. SES is compelling where volume is high and the organization can spread fixed engineering work across several products. A low per-1,000 charge does not make SES a campaign tool; there is no marketing UI and no native validation product.

A mixed decision is reasonable. Keep transactional mail on Mailgun for a product that needs inbound parsing and validation, while an AWS workload uses SES for a high-volume, narrowly controlled stream. If you split providers, define which system owns domain authentication, unsubscribe state, suppression, event normalization, and customer support. Two providers can reduce concentration risk, but they double the runbooks and sender reputations to monitor. Make the split visible in service configuration and finance reporting rather than letting teams choose silently.

• Mailgun fits managed operations, inbound replies, validation, and shorter implementation cycles.
• SES fits AWS-native platform teams with strong IAM and event-pipeline ownership.
• Use a split only when message classes have clear ownership and different operating needs.

Worked cost scenario: 250,000 emails each month

Assume a B2B SaaS sends 250,000 transactional and product messages every month, uses one sending domain, and does not add validation volume or a dedicated IP. Mailgun lists Scale at $215 per month for 250,000 emails on its pricing slider. The monthly Mailgun amount is therefore $215 before an add-on. If the team adds one extra dedicated IP, Mailgun lists $59 per IP per month, so the arithmetic becomes $215 + $59 = $274 per month.

Amazon SES Essentials lists $0.16 per 1,000 emails for the 0–10 million range. Divide 250,000 by 1,000 to get 250 billable units, then multiply: 250 × $0.16 = $40.00 per month. If the team selects Pro, the per-send arithmetic is 250 × $0.22 = $55.00, and Amazon SES lists an additional $105 per account per region per month. The Pro example is therefore $55 + $105 = $160 before other AWS charges. A standard dedicated IP is another line: Amazon SES lists $24.95 per month per IP, so Essentials plus one standard IP is $40 + $24.95 = $64.95 before adjacent services.

This arithmetic explains the tradeoff without pretending the products have the same operating scope. Mailgun’s $215 includes a managed product surface and listed Scale retention. SES’s $40 Essentials meter is attractive, but the team still needs an event destination, retention, IAM design, production access, suppression, validation, and any marketing interface. At this volume, compare the monthly invoice with engineering hours required to keep those systems healthy. "} />

Migration notes: Mailgun to SES

Start with an inventory rather than changing the send call first. List every Mailgun domain, template, tag, event, webhook, inbound route, validation decision, suppression rule, and SMTP credential. Mark each item transactional, product communication, or marketing handoff. In SES, choose the target region, verify identities, create IAM roles, define configuration sets, and request production access. Keep a test identity and separate configuration set so an accidental production send is visible immediately.

Rebuild the event path before moving volume. Map Mailgun delivery, bounce, complaint, and engagement events to SES destinations and normalize both into the same internal schema. Replace webhook signature checks with AWS destination controls, make the consumer idempotent, and replay representative events in staging. If Mailgun inbound routes create tickets or attach replies to an account, design the SES receiving rule, S3 or SNS handoff, parsing, malware scan, and retention before changing MX records.

SES does not provide Mailgun’s Optimize validation product. Select a validation service, write an adapter, or accept a narrower pre-send check, then decide how its result is stored. Preserve business-level suppression during migration; a provider list is not a complete consent database. Convert templates and variables deliberately, including escaping, locale selection, attachment behavior, headers, tags, and unsubscribe links. Run a canary stream, compare outcomes, and only then move remaining traffic.

1. Inventory Mailgun domains, templates, routes, events, keys, suppression, and validation use.
2. Verify SES identities, choose a region, create IAM roles, and request production access.
3. Build configuration sets, event destinations, normalization, retention, and alerting.
4. Replace inbound routes and validation with tested AWS and application components.
5. Canary a low-risk message class, compare events, then switch traffic with rollback ready.

Migration notes: SES to Mailgun

A move to Mailgun can shorten AWS-specific email code, but it is still a systems migration. Inventory SES identities, regions, configuration sets, templates, event destinations, IAM policies, receiving rules, S3 objects, SNS subscriptions, and Lambda consumers. Create Mailgun domains in the intended US or EU region, publish SPF and DKIM records, and verify them before changing application credentials. Keep SES available while the first Mailgun canary runs.

Translate configuration sets into Mailgun names for domains, tags, and webhooks. Replace SNS and CloudWatch consumers with an idempotent Mailgun event endpoint, preserving the internal schema so support and reporting do not change. Convert SES templates and rendering variables, including headers and attachments, then compare rendered messages. If a service uses SES receiving rules, create and test Mailgun routes before changing MX records; outbound cutover does not migrate inbound behavior.

Finally, choose the Mailgun plan and retention period that match support obligations. Foundation lists 5 days of logs, while Scale lists 30 days, so export older events if the company needs longer history. Check whether included or extra dedicated IPs make sense, and budget $59 per additional IP per month if required. Keep SES read-only until invoices, historic messages, and long-tail inbound senders have been accounted for.

1. Inventory SES regional resources and preserve the internal event schema.
2. Verify Mailgun domains, publish authentication records, and create scoped keys.
3. Rebuild webhooks, templates, routes, validation policy, and suppression handling.
4. Canary outbound and inbound traffic, comparing rendering and event outcomes.
5. Switch DNS and application traffic, then retain SES for audit and rollback.