# Amazon SES vs Mailgun Source: https://wraps.dev/versus/amazon-ses-vs-mailgun Mailgun is the closest thing on the market to SES with the missing parts filled in — routing, validation, searchable logs. That makes it the most direct comparison SES has, and the one where pricing stability matters most. Most comparisons in this category pit a primitive against a product with a completely different shape. This one does not. Mailgun is a sending API with inbound routing, address validation and log search bolted on, which is recognisably the list of things a team builds in its first year on SES. That makes the comparison unusually concrete: for each capability you can ask whether you would rather buy it or build it, and the answer differs per capability rather than being decided once by taste. ## At a glance |   | Amazon SES | Mailgun | | --- | --- | --- | | What it is | Raw sending infrastructure from AWS | High-volume email API with routing and validation | | Published pricing | $0.10 per 1,000 emails on à la carte. New accounts are defaulted to the Essentials plan at $0.16 per 1,000; Pro is $105/mo + $0.22 per 1,000 and Enterprise $500/mo + $0.23 per 1,000. Plans are per-account, per-Region. | Basic $15 at 10K. Foundation $35 at 50K and $75 at 100K. Scale $90 at 100K rising to $400 at 500K. Dedicated IP included from the $75/mo plans; extra IPs $59/mo each. | | Best for | Teams already on AWS with an engineer willing to own the plumbing. | High-volume sending where routing, validation, and log search need to come from one vendor. | | Watch out for | Production access is an application AWS can refuse, and new accounts start sandboxed to verified addresses. No dashboard, no templates, and nothing stores your events until you build it. | Flex closed to new signups in December 2025 and the legacy rate doubled to $2 per 1,000. The free tier is a hard 100/day cap, and suspensions recur in reviews. | Prices are each vendor's published list prices, verified August 2026. Check the vendor's own page before you sign anything. ## Where they actually differ ### Receiving mail, not just sending it Amazon SES SES can receive, in a subset of regions, through receipt rule sets that can drop a message into S3, invoke a Lambda, publish to SNS or bounce it. It is powerful and it is assembly. You get the raw MIME and everything after that — parsing, threading, attachment handling, deciding what a reply even is — is code you write, in a runtime you operate, with a rule set that is easy to misconfigure in ways that silently drop mail. Mailgun Mailgun Routes are expression-based and match on recipient, sender or header, then forward to a URL, an address or a store. The parsed fields arrive already extracted, which removes the least interesting week of work in any inbound project. The constraint is that the parsing is theirs, so an unusual message shape is handled the way they decided, and a route that behaves oddly is a support ticket rather than a debugging session. ### Address validation, which SES has no answer for at all Amazon SES There is nothing. SES will attempt delivery to whatever you hand it, and you discover the address was a typo when the bounce arrives — which is the expensive way to find out, because bounces are the metric AWS suspends accounts over. Teams on SES either accept a higher bounce rate on signup flows, or buy validation from a third vendor and wire it in, which is one more contract and one more integration. Mailgun Validation is a first-class product with syntax checks, domain checks and mailbox-level verification, callable at signup rather than at send time. For any product with a self-serve registration form this is a directly measurable improvement to the number AWS would have suspended you over, and it is the single clearest example on this page of something worth buying rather than building. ### Finding one message among millions Amazon SES SES has no log to search because SES stores no logs. You build the pipeline — configuration set event destination, a stream, somewhere to put it, an index, a query interface — and until all five exist, the answer to what happened to this message is unavailable. The pipeline is not hard. It is also not a weekend, and the half-finished version that captures deliveries but not complaints is worse than useless because it looks like it works. Mailgun Log search is in the console on day one, with retention that lengthens as the plan does. You can filter by recipient, status and time, read the SMTP response the receiving server gave, and hand the result to a support agent. The trade is the one every hosted log makes: retention is a plan feature, the window is not long on the cheaper tiers, and the history is not yours to keep when you leave. ### Price stability, and the December 2025 change Amazon SES AWS reprices SES rarely and moves in visible steps. The recent change worth knowing is that new accounts are defaulted to a metered plan rather than the old flat rate, and that plans are scoped per account and per region — but the per-message economics remain the reason large senders are here, and nothing about the pricing model punishes you for growing into it. Mailgun The Flex plan closed to new signups in December 2025 and the legacy rate doubled. That is the part of this comparison nobody arrives knowing, and it is the strongest argument for owning the account rather than renting it: the price of a hosted plan is a decision the vendor makes on its own schedule, and the only response available to a customer is to migrate. Teams still on grandfathered terms should confirm what they are actually paying before modelling anything. ### Dedicated addresses and warming Amazon SES SES offers dedicated IPs, including a managed option that handles the warm-up schedule, and standard ones you warm yourself. Because the account is yours, the warmed address stays yours across any tooling change above it — which is the piece people undervalue until they have spent six weeks warming something and then changed vendor. Mailgun Dedicated addresses come included from the mid plans upward, with extra ones charged monthly. That bundling is genuinely convenient at the volume where a dedicated address starts making sense. It is also a plan feature, meaning a downgrade takes it away and a migration leaves it behind, and the warm-up you paid for in patience does not travel with you. ### Regions, residency and where the mail physically is Amazon SES SES runs in a long list of AWS regions and the choice is yours per account, which makes an EU-only or a specific-jurisdiction deployment a configuration decision rather than a sales conversation. The caveat a European buyer will raise is ownership rather than geography, and it is a fair one: an EU region operated by a US company is not the same answer as an EU company, whatever the data map says. Mailgun Mailgun offers a European region and has done for years, which covers the common GDPR requirement cleanly. The region is selected at domain level and the API endpoint differs, which is a small but real source of confusion for teams that verify a domain in one region and then call the other one for a week wondering why nothing works. ### Who is actually behind each one Amazon SES AWS, with the stability and the indifference that implies. SES will not be discontinued, will not be acquired and will not change its API out from under you. It also will not call you, will not notice your problem and will not have an opinion about your sending practices until a threshold is crossed. For infrastructure, indifference is mostly a feature. Mailgun Sinch, following an acquisition, alongside several other messaging brands. The product is mature and well documented, and the honest risk is the ordinary one for an acquired platform: investment follows the parent's priorities rather than yours, and the December repricing is the kind of event that follows from that. Suspensions also recur in its reviews, on the same pattern as the rest of the hosted field. ## Pros and cons, side by side ### Amazon SES Strengths - The price list belongs to a company that reprices rarely and in visible steps, which is the direct answer to watching a plan close to new signups and a legacy rate double while you hold no lever at all. - A dedicated address you warmed stays yours through every change in the tooling above it, so six weeks of patient ramping is an investment rather than something you spend again at the next migration. - Jurisdiction is an account-level choice from a long list of regions, and because the identity belongs to you it is a configuration decision rather than a per-domain setting with a second API hostname attached to it. - It will not be discontinued, will not be acquired and will not change its API underneath you. For infrastructure, that indifference is the feature. Trade-offs - There is no address validation of any kind, so the typo that would have been caught at the registration form instead becomes a bounce against the precise metric AWS uses to decide whether you keep sending. - Inbound arrives as raw MIME behind a rule set that is easy to misconfigure into dropping mail silently, and parsing, threading, attachment handling and deciding what a reply even is are all yours to write and to maintain. - There is no log to search because nothing is stored, and the five moving parts that fix that are routinely estimated as a weekend by people who have not built them. - Nobody is watching the account on your behalf, so the first signal that something is wrong usually arrives as an enforcement rather than as a warning. ### Mailgun Strengths - Routes match on recipient, sender or header and deliver already-extracted fields to your endpoint, which removes the least interesting week of work in any inbound project and removes it permanently. - Validation is a real product — syntax, domain and mailbox-level, callable at the signup form rather than at send time — and it is the clearest case on this page of a capability worth buying rather than building. - Log search exists in the console from the first day and shows the receiving server's own SMTP response, which is the field that settles an argument about whether a message was delivered or merely accepted. - A dedicated address comes bundled from the middle plans upward, which is genuine convenience at exactly the volume where having one starts to make sense. Trade-offs - Flex closed to new signups in December 2025 and the legacy pay-as-you-go rate doubled, which is a concrete demonstration that a hosted price is somebody else's decision and migration is the only response a customer has. - Retention is a plan feature, so the searchable history shortens the moment you downgrade and none of it comes with you when you leave. - The European region is chosen per domain and has its own API hostname, so verifying in one and calling the other produces a week of failures that the error messages do not explain. - Investment now follows an acquiring parent's portfolio priorities rather than the sending product's, and a repricing is precisely the kind of event that follows from that. ## Pick in thirty seconds ### Choose Amazon SES if - You want the account, the reputation and the warmed addresses to belong to you, so that changing the tooling above them is never a migration. - Volume is high enough that a metered rate versus a plan ladder is worth real engineering, and someone is willing to own the event pipeline. - Inbound handling is genuinely unusual — custom parsing, odd attachment shapes, strict retention — and a vendor's parsed fields would not fit anyway. - A vendor changing its price list is a risk you specifically want removed from the plan. ### Choose Mailgun if - You need inbound routing and address validation now, and would rather buy two solved problems than spend a quarter building mediocre versions. - Support agents need searchable logs with the receiving server's response visible, without a data pipeline existing first. - A dedicated address bundled into a plan is more attractive than provisioning and warming one yourself. - The team has no AWS presence and adding one for email alone is more organisational work than the saving justifies. ## What actually moves when you switch In roughly the order you would do it. The expensive parts of an email migration are never the send call. 1. Work out which region can receive before choosing where to send from. SES inbound exists in a subset of regions and need not be the region you send in, so an inbound requirement can quietly dictate the whole account layout, and discovering that after the identities are verified is a rebuild rather than a setting change. 2. Open the production-access application early and write it as prose. It asks how addresses are collected and how bounces and complaints are processed; a person reads the answer, and the cases that take days are almost always the ones answered vaguely. 3. Decide what replaces validation before the signup form loses it. The realistic options are a third-party validation API, a syntax and MX check of your own, or accepting a higher bounce rate — and the third is riskier than it sounds, because bounce rate is the number the new provider watches to decide whether you keep sending. 4. Turn the Routes into receipt rules, then write the parser that Routes was. Mailgun hands your endpoint extracted fields; the replacement hands you raw MIME in object storage or a function invocation. Threading, attachments and what counts as a reply all become yours, and a misconfigured rule set drops mail with no error anywhere to notice. 5. Stand the event pipeline up before the cutover rather than beside it. Configuration set, event destination, a stream, somewhere to keep it, an index, an interface — until all six exist, what happened to this message has no answer at all, and the partial build that records deliveries but not complaints is the dangerous one. 6. Export suppressions and whatever searchable history still matters. Retention is a plan feature, so the window on your current tier is the whole of what you can take, and the console search that made a support agent self-sufficient is being replaced rather than moved. 7. Replace the webhook verification as well as the payload handling. Mailgun signs its posts with a timestamp and token scheme your handler checks; the replacement delivers through SNS, EventBridge or Firehose, each with its own authentication model and envelope, so the security review is separate work from the field mapping. 8. Warm a new dedicated address instead of expecting to keep the old one. The IP and everything the mailbox providers learned about it stay behind, and a managed warm-up option exists if you would rather not run the schedule by hand — but either way the unit is weeks, and the shared pool is the better place to be during them. ## Questions to ask before you sign Put these to a sales rep, or find the answer in the documentation before anyone quotes you a number. 1. Does our product receive mail, and if it does, are we willing to own the parser — or is that a subsystem we have quietly been assuming somebody else maintains? 2. What is the bounce rate on our signup traffic today, and what does it become if validation stops happening at the form? 3. Who answers a support ticket about one specific message, and which interface are they using on the morning after the switch? 4. How long is log retention on the exact plan being quoted, and what does extending it cost — because the tier's headline volume is not the number that decides this? 5. If the price list moves next December the way it moved last December, what is our response, and how many weeks would executing it take? 6. Does our residency requirement name a region, and does the inbound capability we need actually exist in the region that would satisfy it? 7. What does a dedicated address cost on each side once the warm-up period is counted as a cost rather than as free waiting? ## A third shape of answer Of every pair in this cluster, this is the one where the middle position is least hypothetical, because Mailgun's feature list is close to a specification for what teams build on top of SES. The reason to think about a platform over your own AWS account here is narrow and specific: it removes the December-2025 problem, where a vendor reprices and your only response is to migrate an account you never owned. Wraps is one way to take that shape. It does not match Mailgun feature for feature — there is no address validation product, and inbound is a thinner story. You will need an AWS account and SES production access, an approval AWS grants on its own timetable and not ours, our SDKs cover TypeScript and Python only, contacts and templates live in our database while sending data and delivery events stay in your AWS, and we are not SOC 2 certified. Wraps publishes this page. We are not one of the two vendors being compared here, and this note is on it because the tension above is one owning the AWS account actually addresses — not because it is on every page. ## Common questions ### Is Mailgun built on Amazon SES? No. Mailgun runs its own mail infrastructure and predates most of the vendors that do resell SES, so switching between these two genuinely changes the network, the IP pools and the sending relationships behind your mail. That is worth knowing because it makes deliverability differences between them real rather than an artefact of two accounts on the same substrate, which is the situation with several other hosted providers. ### Can SES receive inbound email? Yes, in a subset of regions, through receipt rule sets that can store to S3, invoke a Lambda, publish to SNS or reject the message. What it does not do is parse. You receive raw MIME and write everything after that yourself, including threading, attachment extraction and deciding what counts as a reply. If inbound is central to your product that control is worth having; if you just need replies to reach a webhook, it is a lot of work for a small feature. ### What replaced Mailgun's Flex plan? Flex closed to new signups in December 2025 and the pay-as-you-go rate for legacy accounts doubled, so new customers start on the plan ladder. The relevance to this comparison is structural rather than emotional: a hosted plan's price is set by the vendor and changed on the vendor's schedule, and a customer's only lever is to move. Owning the AWS account removes that lever from somebody else's hands, which is a different kind of value from a lower number. ### How do I do address validation on SES? You buy it separately or you do without. SES has no validation product, so the options are a third-party validation API called at signup, a lightweight syntax and MX check you write yourself, or accepting a higher bounce rate. The last of those is riskier than it sounds, because bounce rate is precisely the metric AWS uses to decide whether to pause your account, and a self-serve signup form with typos in it is the most common way that number climbs. ### Which is better for high-volume sending? SES on economics, decisively, once volume is high enough for the per-message rate to matter. Mailgun's argument at volume is not price, it is that routing, validation and log search arrive already built, and that a dedicated address comes with the plan. The real question is whether your team wants to operate a mail pipeline. If the answer is yes, SES is cheaper and more durable; if it is no, the saving becomes a backlog. ### Can SES receive mail in the same region I send from? Sometimes, and it is worth checking before anything else, because inbound is supported in fewer regions than outbound. The two do not have to match — you can receive in one region and send from another — but that is an architectural decision with latency, data-residency and IAM consequences, not a checkbox. Teams with an inbound requirement should pick the receiving region first and let the rest of the account layout follow, because reversing that order means re-verifying identities you have already warmed. ### How do Mailgun's webhooks compare to SES event notifications? They solve the same problem with different assumptions. Mailgun posts events to a URL you nominate and signs each request with a timestamp and token your handler verifies. SES publishes to SNS, EventBridge or Firehose, and you choose which — each with its own authentication story, its own delivery guarantees and its own envelope around the payload. The field names and the event vocabulary differ throughout, so migrating the consumer is a rewrite plus a security review rather than a configuration change. ### What happens to my Mailgun log history when I leave? It stays. Retention is a plan feature, the search interface belongs to the vendor, and there is no historical archive handed over on the way out — which is the ordinary arrangement everywhere, not a Mailgun peculiarity. If any of that history has a use beyond debugging, export it while the account is live, and treat the export as a dated task with an owner. The broader lesson is worth acting on early: history you need to outlive a vendor relationship has to land somewhere you own from the start. ### Can I keep tag-based reporting after moving to SES? The mechanism exists and the reporting does not. SES lets you attach message tags and configuration sets, both of which flow through to the events you publish, so the dimension you were slicing by survives. What does not survive is a console that aggregates by it — that becomes whatever your own store and query layer can do. If the tags were feeding a dashboard somebody reads weekly, rebuild that dashboard as part of the migration rather than as a follow-up, because a metric nobody can see is one nobody acts on.