# Mailgun vs SMTP2GO Source: https://wraps.dev/versus/mailgun-vs-smtp2go Two vendors that both accept SMTP all day and are built for opposite customers. One wants to be the routing layer in your architecture. The other wants to be the thing your appliances point at and nobody thinks about again. The overlap here is real — both take SMTP, both deliver at volume, both have a dedicated IP story — and it hides two quite different products. Mailgun is a platform with a rule engine, a validation service and tenant isolation, sold to people who are building something that moves mail around. SMTP2GO is a relay sold to people who have systems that emit mail and want them to arrive, with reporting good enough to debug from when they do not. The December 2025 repricing made this comparison urgent for a cohort who had never needed to make it. ## At a glance |   | Mailgun | SMTP2GO | | --- | --- | --- | | What it is | High-volume email API with routing and validation | SMTP relay with strong reporting | | Published pricing | 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. | Free 1,000/mo (200/day). Starter $10/mo at 10K. Professional from $75/mo at 100K, which is where dedicated IPs and inbound parsing unlock. Overage $1 per 1,000 on Starter, $0.85 on Professional. | | Best for | High-volume sending where routing, validation, and log search need to come from one vendor. | Apps and appliances that need a relay to just work, with reporting good enough to debug from. | | Watch out for | 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. | Relay-first by design: no modern SDK, no lifecycle automation, and no React template rendering. | 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 ### What the vendor thinks you are building Mailgun An application. Mailgun's surface assumes you will write code against it: routing rules with match expressions, a validation API, tagging so you can slice a cohort of messages later, subaccounts because you might be a platform with tenants. All of that is real capability and all of it presumes somebody is engineering the mail flow. SMTP2GO Nothing. SMTP2GO assumes the mail is already being produced by software that exists and cannot be changed, and that your job is configuration rather than development. The product's intelligence is therefore applied after the message arrives — routing it well, reporting on it clearly, and warning you when a sending address gets blocklisted. ### Two takes on what reporting is for Mailgun Searching and slicing. Tags and custom variables let you attach your own dimensions to sends and then filter events by them, which is how you answer a question like how did the onboarding sequence perform this month. It is powerful, it assumes you set the tags at send time, and it is useless for traffic from a system that cannot set anything. SMTP2GO Standing sender health. Delivery and bounce rates per sending address and per receiving domain, complaint tracking, blocklist monitoring, and reports that arrive on a schedule rather than waiting to be opened. For traffic you cannot instrument, vendor-side aggregate reporting is the only telemetry that exists. ### Credentials and the systems that hold them Mailgun API keys and SMTP credentials scoped per domain, with subaccounts available if you need harder separation. The model is coherent for an engineering team with a secret store, and it was designed with code in mind rather than with a wiki page full of device configurations. SMTP2GO Per-sender SMTP users are the core operational idea: one credential per system, revocable independently, with its own reporting slice. That is precisely the right shape when credentials get typed into an appliance's settings page by somebody who later leaves, and it is the habit that makes an estate of twenty senders manageable rather than terrifying. ### Entry-level pricing after December 2025 Mailgun Flex closed to new signups and the legacy rate doubled, which pushed a cohort of small senders into the market. What is available now is the named plan ladder, and the entry rung is priced for a business rather than for a side project. If your volume is modest and you are not using routes, validation or subaccounts, you are paying for a platform you do not touch. SMTP2GO A free tier with a daily cap, an inexpensive entry plan, and a Professional tier where dedicated IPs and inbound parsing unlock together. The ladder is shaped around what a relay customer actually needs next, which is usually isolation or inbound rather than raw volume, and the overage rates are published rather than negotiated. ### When a message does not send Mailgun Mailgun surfaces the failure in its event stream with a reason, and suspensions recur often enough in public reviews to be a planning input rather than a rumour. Large platforms are conservative about shared reputation and act first when a pattern looks unusual. If your traffic is spiky, budget for the possibility and keep a fallback path configured. SMTP2GO The failure shows up in the reporting, and the support conversation on the other end is with people who spend their days helping customers configure devices and networks. That is a different competence from an API support queue, and it is the more useful one when the real problem turns out to be a firewall rule, a TLS negotiation or an appliance that quietly drops messages instead of retrying. ### Dedicated addresses and warming Mailgun Dedicated IPs are included from the mid plans with additional ones at a published monthly rate, which makes a multi-IP setup straightforward to price. If you send enough to warm several addresses and want traffic classes separated across them, this is the more capable of the two on that axis. SMTP2GO Dedicated IPs unlock at the Professional tier, bundled with inbound parsing, so that tier is a capability step rather than a volume step. Below it you are on a shared pool with blocklist monitoring watching over it, which for a mid-size sender is frequently the better economics than an IP with too little volume behind it to stay warm. ### Receiving mail, and how conditional it can be Mailgun Routes are a genuine rule engine: match expressions on recipient, sender and headers, ordered by priority, with actions attached. A single inbound domain can fan out to different destinations under different conditions. If inbound is a real part of what you are building, nothing in the relay category comes close. SMTP2GO Inbound parsing forwards messages to an endpoint you nominate, from the Professional tier. It is the right amount of product for the audience — the device sends, a human replies, something catches it — and it is not conditional fan-out. Know which of those two you need before you choose, because retrofitting the difference is not a config change. ### Where the mail is processed Mailgun Mailgun offers a US or EU region selected when a domain is created, and that selection cannot be changed afterwards. The capability is genuine and the footgun is genuine: a domain created hastily in the wrong region has to be recreated and re-warmed, and that usually surfaces during a compliance review long after the fact. SMTP2GO Relay endpoints in several regions with account processing pinnable to one, which is a shorter answer to a residency question than most of this category can give. For an organisation pointing a fleet of systems at one supplier and needing a single sentence for the auditor, that simplicity has real value. ### What you are not getting from either Mailgun Not a marketing platform and not a template experience for non-engineers. Mailgun has a templating syntax stored vendor-side and it is aimed at developers. Anything resembling lifecycle automation, segmentation or a campaign builder is a separate purchase, and its own deliverability tooling is packaged separately too. SMTP2GO Not a developer platform. No idiomatic SDK, no rendering, no lifecycle tooling, and an API that manages the account rather than being the primary send path. Choosing it because it is inexpensive and then wanting the things a platform gives you is the most common route to being unhappy with it. ## Pros and cons, side by side ### Mailgun Strengths - Sending is one capability among several. Validation, routing and tenant isolation come from the same account, so a product that grows into needing any of them does not have to acquire a second supplier to get it. - Events are pushed to an endpoint as they happen, which means the numbers your business reads can be assembled from data you hold rather than from whatever view the vendor decided to build. - An unsubscribe link can be inserted by the platform at send time, so bulk mail emitted by software with no such feature of its own still leaves the building carrying one. - A test flag on the send call has a message fully accepted and then discarded, which lets application code exercise the entire real path without a real recipient at the end of it. Trade-offs - Since December 2025 the entry rung is priced for a business rather than a side project, so a modest sender pays platform rates for work a relay would have done for a fraction of it. - Almost everything useful about the reporting depends on dimensions attached at send time, and traffic from an appliance or a purchased plugin will never attach any. - The free arrangement is a sandbox domain with an explicit list of permitted recipients, which makes it a smoke test rather than anything you could point a staging environment at. - The API hostname changes with the region a domain was created in, so a client library configured once years ago becomes a failure the day somebody adds a European domain to the same account. ### SMTP2GO Strengths - The entire product assumes the sender cannot be changed, so the documentation, the support queue and the known failure modes are all about configuration rather than about code somebody could rewrite. - Health arrives on a schedule instead of waiting to be searched for, which is the only telemetry available at all for traffic nothing in your estate can be made to annotate. - The conversation with the receiving server is kept per message, so a refusal comes back in the remote end's own words rather than as a category somebody at the vendor chose for it. - Credentials can be issued one per system and revoked alone, which turns a leaked appliance password into a single revocation rather than an estate-wide rotation nobody has an inventory for. Trade-offs - There is no idiomatic SDK and the API administers the account more than it sends, so a team that wanted to build against it is building against a relay's afterthought. - Suppression is held at the account rather than per sending domain, so one misbehaving system's collection of dead addresses is suppressed for everything else the account sends too. - Nothing inserts an unsubscribe link, so bulk mail from software that does not generate one leaves without one, and that is your compliance exposure rather than the vendor's. - It will not grow into a platform. No rule engine, no validation product, no lifecycle tooling, and nothing in the roadmap that suggests any of those are coming. ## Pick in thirty seconds ### Choose Mailgun if - Inbound mail is part of your product and you need conditional routing with ordered rules rather than one forwarding destination. - You send on behalf of tenants and need per-tenant credentials, suppression and reporting. - You want to tag sends with your own dimensions and slice the event stream by them later. - Your volume supports several dedicated addresses and you want the per-IP price published. ### Choose SMTP2GO if - The senders are business systems, appliances and plugins, and none of them will ever be rewritten. - You want one revocable credential per sending system, with its own reporting slice. - Blocklist monitoring and scheduled health reports are the visibility you need, because you cannot instrument the sender. - Your volume is modest and you would rather not pay for a routing engine and a validation service you never call. ## 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. Audit what your code calls the vendor's API for that is not sending a message, because those calls have no counterpart on a relay. A signup form checking an address before accepting it, a nightly job reading events, a script creating a credential for a new tenant: none of that is visible to whoever is working through the list of devices, and each one is a separate small project that surfaces after the cutover date has been announced. 2. Enumerate the From addresses your estate emits under, not the systems that emit them. A relay that checks the sender against an approved list is a safety feature and a cutover trap in one: the printer sending as a noreply address, the backup job sending as root, and the plugin sending as whoever installed it are three approvals nobody has requested. The list is always longer than the inventory of machines, because several machines send under several identities. 3. Decide how you will rehearse, given that one side's test facility is a flag set on the send call. An application can set a header that has the message accepted and quietly discarded; an appliance cannot set anything at all. For traffic you do not control, the only honest rehearsal is a real send to an address you own, from the actual device, over the actual network — which is a calendar problem about getting access to the device rather than an engineering one. 4. Check whether the relay hostname or the API base is hardcoded anywhere your configuration management cannot see. One side's API host varies with the region a domain was created in and the other publishes several endpoints and fallback ports; either way the string is sitting in an appliance's settings page, a container image and at least one shell script. Find them before the cutover rather than during it, because the ones you miss fail silently at the sender. 5. Work out what happens to suppression scope, because the two hold it at different levels. Per-domain suppression means one system's dead addresses stay that system's problem; account-level suppression means an address one machine burned is an address every machine is now refused. That is usually the safer default and occasionally the wrong one, and either way somebody should know which behaviour they are inheriting before the first bad list arrives. 6. Find out who is inserting the unsubscribe link into your bulk mail today. If the answer is the platform rather than the software, moving to a relay removes it, and the newsletter your operations team sends from a departmental tool starts going out without one. Either the sending software gains the ability to write a link, or that traffic does not move, and finding out which after the first campaign is a compliance conversation rather than a technical one. 7. Agree what a support answer looks like afterwards, because the two products store different evidence. One keeps an event stream you filter by dimensions you attached yourself — which traffic from a black box never populates — and the other keeps the transcript of the exchange with the receiving server, including its refusal text. Match the evidence to the kind of traffic you actually have rather than to the dashboard somebody preferred in the demo. 8. Choose the credential model deliberately, because changing your mind later means visiting every device twice. A domain-scoped relay password is quick and makes any rotation an estate-wide outage; one credential per sending system costs an hour now and makes a leak a single revocation with its own reporting slice. A migration is the only moment when the second option is free, and it never gets cheaper afterwards. ## 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. What are we calling the vendor's API for that is not sending a message, and would any of those calls survive the move? 2. Can somebody produce every From address our estate emits under, including the ones nobody deliberately chose? 3. Is a relay hostname or API base hardcoded anywhere our configuration management cannot see or change? 4. Who inserts the unsubscribe link into our bulk mail today, and what sends it if the vendor stops doing that for us? 5. How would we rehearse a cutover for a device nobody can log into, and who actually holds admin access to it? 6. If one sending credential leaked this afternoon, how many systems would we touch to rotate it and how long would that take? 7. When somebody asks why a message failed, do we need a dimension we attached ourselves or the receiving server's own words? ## Common questions ### I was on Mailgun's Flex plan — what are my options now? Flex closed to new signups in December 2025 and the legacy rate doubled, so the question is whether the platform features justify the named plan you would move onto. Audit honestly: do you use routes, validation, subaccounts or tagging? If none of them, you are paying a platform price for relay work and a relay is the cheaper and better-fitting answer. If you use even one of them meaningfully, replacing it elsewhere is likely to cost more in engineering than the plan difference saves. ### Does an SMTP relay deliver worse than an API? No. Placement is decided by authentication, reputation and content, not by the protocol the message arrived over. Both vendors sign with DKIM and align SPF correctly when configured properly, and both will restrict you for a bad list. The one indirect risk is that legacy senders are likelier than fresh code to emit unauthenticated or malformed mail, and to use an envelope sender that does not align with the visible From address — which is a problem with the sender, fixable in its configuration. ### How many sending credentials should I create? One per system, always, and it costs nothing to do. The value shows up the day a credential leaks or a system starts misbehaving: you revoke exactly one thing rather than rotating a shared secret across an estate nobody has a complete inventory of. It also makes the reporting useful, because you can see which system's mail is bouncing without correlating by From address. Shared credentials are the single most common operational mistake in relay setups. ### What should I check on the receiving side before switching? Your DNS, three records deep. SPF has to include the new vendor and must not exceed ten lookups, which is easy to breach when you are temporarily including both the old and new providers during a cutover. DKIM keys are per-vendor, so both need publishing while you run in parallel. And DMARC alignment needs verifying with a real test send, because a legacy sender that sets an envelope From on a different domain will fail alignment silently and land in spam while every dashboard shows delivered. ### Can I keep long-term records of what was sent? Not from either vendor's own retention, which is plan-dependent on both sides and finite everywhere. If you have a contractual or regulatory reason to prove what was sent to whom two years ago, the only durable arrangement is to consume the webhook or event stream as it happens and write it into storage you control. It is inexpensive to build and impossible to build retroactively, which is why the people who need it almost always discover the requirement one quarter too late. ### Can I point a staging environment at Mailgun's test mode? You can if the sender is code you control, and you cannot if it is not, which is precisely the split this comparison is about. Test mode is a flag set on the outgoing message: the platform accepts it, runs it through the same validation and reporting path, and then discards it instead of delivering. That is genuinely useful for an application, because you exercise the real integration without a real recipient. An appliance, a purchased plugin or a device with a settings page cannot set a flag on anything, so for that half of your estate the facility does not exist. The practical arrangement most teams land on is code pointed at test mode, everything else pointed at an address they own and monitored by a human on cutover day, and nobody pretending the second group has been rehearsed the way the first one has. ### What is a sandbox domain and why can it not send to my users? It is the domain Mailgun gives a new account before any domain of your own has been verified, and it will only deliver to addresses you have explicitly added to an authorised-recipients list, each of which has to confirm by clicking a link. The purpose is abuse prevention: a free account that could mail arbitrary strangers is a spam cannon. The consequence for an evaluation is that the free tier is a smoke test rather than a trial — you can prove the integration works to yourself and to four colleagues, and you cannot point a staging environment at it and let it mail whatever addresses your seed data happens to contain. If proving the thing end to end against realistic traffic is part of your evaluation, verify a real subdomain and use a paid plan for the fortnight rather than trying to make the sandbox do work it was designed to refuse. ### Is suppression held per domain or per account? It differs between these two and the difference is worth knowing before a bad list arrives. Mailgun scopes bounces, complaints and unsubscribes to a sending domain, so an address burned by one system stays burned for that system and remains mailable by another. A relay generally holds suppression at the account, so the same address is refused for everything the account sends. Account-level is usually the safer default — it stops several systems independently rediscovering that a mailbox is dead — and it is occasionally wrong, most obviously when a marketing list and a receipt path share an account and somebody's marketing bounce quietly stops their invoices. If you are moving between the two scopes, the thing to do on arrival is not to trust the default: pull the list, decide category by category which entries should be global, and load only those. ### Do I lose the unsubscribe link if I move to a relay? If the platform was generating it, yes. Mailgun can substitute an unsubscribe URL into a message at send time and track the resulting opt-out on your behalf, which is a feature a plain relay does not have because a relay's job is to deliver a message somebody else has already finished writing. For transactional mail that changes nothing, since it should not carry one. For anything bulk it matters a great deal: a newsletter sent from a departmental tool that never learned to write a footer will start going out without one, which is a legal exposure in most jurisdictions and a placement problem everywhere. Work out which of your senders relies on the platform for that link before the move. Usually the answer is that one or two do, and either they gain the capability or that traffic stays where it is.