SendGrid vs Mailgun

SendGrid: a broad Twilio stack with two operating centres

SendGrid is easiest to understand as two related products. The Email API serves product-generated mail such as invitations, password resets, invoices, usage notices and security alerts. It can be called over REST or SMTP, and the Event Webhook can stream delivery outcomes to an application service. Marketing Campaigns is a separate surface for contacts, campaign composition and scheduled communication. A B2B SaaS can use both, but it should give them separate owners, separate forecasts and a clear consent boundary.

The Twilio ownership context matters for procurement and account administration. A platform team may already have account controls, subusers and a central event pipeline. Subusers can help isolate a product, environment or customer-facing sender, but each additional boundary creates keys, domains, templates and support paths to govern. Set naming conventions before the first production send: include environment, product and message class in every sender identity and event ledger.

For transactional work, SendGrid’s useful pattern is a stable application contract. The service decides which template and category to use; SendGrid handles the delivery request and emits an event; the application stores the provider identifier with the business event. Categories and subusers can make reporting more useful, but they do not replace an internal message ledger. Keep invoice identifiers, account identifiers and consent state in the system that owns them.

Marketing Campaigns changes the operating model. The product lists contact limits and monthly-send limits of its own, so a campaign forecast should not be folded into Email API volume. Marketing can own the editor and calendar while engineering owns transactional templates and event handling. Document how unsubscribe groups, suppression and domain authentication are shared. That agreement prevents a campaign editor from accidentally changing the delivery behaviour of a password reset.

SendGrid lists Email API Pro with dedicated IPs included. A dedicated IP can make sense for a stable, high-volume sender with a deliberate warm-up plan; it is not a shortcut for weak authentication or inconsistent content. A smaller SaaS may prefer shared infrastructure while it establishes SPF, DKIM, DMARC, bounce handling and complaint review. Reassess when traffic is predictable and the operations team can monitor the IP every day.

• Assign one owner to Email API delivery and another to Marketing Campaigns when both products are active.
• Send Event Webhook events to an idempotent endpoint with signature checks, retries and a dead-letter path.
• Keep transactional and campaign suppression rules explicit, with a documented source of truth for consent.
• Use subusers for real operational boundaries, not as a substitute for a message inventory or access review.

Mailgun: developer-first sending, receiving and validation

Mailgun is a natural fit when engineers want email infrastructure close to application code. The API and SMTP relay cover ordinary outbound messages, while routes and inbound parsing let the service receive replies and forward structured payloads to an endpoint. This is useful for support aliases, ticket creation, reply-to workflows and product addresses that need machine processing. The design responsibility stays with the team: route precedence, untrusted input, attachment handling and loop prevention need explicit tests.

Mailgun’s inbound model changes what “email provider” means in an architecture. The team is not only sending a notification; it may also be accepting an email from the public internet. Create a receiving boundary that verifies the destination, logs the provider event, limits attachment size, scans or quarantines files and hands only the required fields to the product. Never let a route turn an arbitrary sender into a privileged product action without an application-level authorization check.

Email validation is another Mailgun distinction. Optimize can support checks at sign-up and bulk hygiene before a campaign or customer import. Decide whether a validation result is advisory or blocking, how long it is retained and whether the product can appeal a false positive. For a B2B SaaS, validation can protect a shared sending domain, but it should sit beside consent and suppression rather than replace them. An address that is deliverable can still be unwelcome.

Mailgun’s plans make operational limits visible. Free and Basic list one day of log retention, Foundation lists five days, and Scale lists 30 days. That affects support. If a customer reports a missing invite after the retention window, the application must still have its own message identifier, request time, recipient hash and final event. Export only the data needed for troubleshooting, apply access controls and set a deletion schedule that matches the company’s policy.

Mailgun lists Foundation at $35 per month for 50,000 emails and Scale at $90 per month for 100,000 emails. Scale also lists 5,000 validations and 30 days of logs, while a qualifying configuration includes one dedicated IP. The service lists US and EU sending regions, which can simplify a regional deployment conversation. Confirm the selected region, domains and data paths during implementation rather than assuming an account setting applies to every feature.

• Treat routes as internet-facing application ingress with authentication, limits and audit logs.
• Choose a log-retention tier that matches the support window, or export delivery events to a protected internal store.
• Use Optimize validation where it solves a measured hygiene problem; keep consent and suppression authoritative elsewhere.
• Separate inbound reply processing from outbound delivery permissions and rotate credentials by environment.

Worked cost scenario: 50,000 emails every month

Consider a B2B SaaS that sends 50,000 application messages each month: 16,000 invitations and verification links, 12,000 billing notices, 11,000 workflow alerts and 11,000 security or account messages. It needs REST API delivery, templates, bounce events and a support reply route. It does not need a campaign editor in this calculation. Both vendors list a plan at the same 50,000-email point, so the arithmetic uses those published selections.

SendGrid lists Email API Essentials at $19.95 per month for 50,000 emails. Mailgun lists Foundation at $35 per month for 50,000 emails after the first month. The annual arithmetic is SendGrid: 12 × $19.95 = $239.40. Mailgun: 12 × $35 = $420. The listed subscription difference is $420 - $239.40 = $180.60 per year. This is a comparison of the named plan points; it does not turn an unlisted volume into an estimated overage.

The lower SendGrid subscription does not automatically make it the lower total operating cost. If the SaaS needs Mailgun’s inbound routes, validation and five-day logs, it should price the engineering time and alternative services that SendGrid would require. If the SaaS needs contact management, campaign editing and a scheduled newsletter, it should add SendGrid Marketing Campaigns or a separate campaign product to the Email API line. Treat those needs as architecture choices, not as invisible features of the transactional tier.

At 100,000 monthly emails, SendGrid lists Pro at $89.95 per month and Mailgun lists Scale at $90 per month. The arithmetic is SendGrid: 12 × $89.95 = $1,079.40. Mailgun: 12 × $90 = $1,080. The annual difference is $0.60 before taxes and add-ons. At that point the choice is shaped more by dedicated IP scope, validation, log retention, inbound routing and campaign ownership than by the listed base subscription.

A finance review should keep each line legible: base plan, published included volume, validation, dedicated IPs, campaign contacts, retention exports, regional requirements and support work. Do not combine a campaign contact tier with an Email API send tier and call it one blended price. The people approving the budget need to see which service owns each workload and what changes when message volume or product scope changes.

1. Freeze the definition of a monthly send, including retries and test traffic.
2. Select the exact published 50,000 or 100,000 point on each pricing page.
3. Multiply the listed monthly price by 12 and keep campaign, validation, IP and retention lines separate.
4. Run a representative message and inbound-reply sample before committing to a routing design.
5. Reconcile provider invoices against the internal message ledger after the first full month.

Migration notes: move the message contract, not only the key

A move between SendGrid and Mailgun starts with an inventory. List every sender domain, return path, template, API key, SMTP credential, webhook consumer, inbound route, suppression rule, campaign contact source and service owner. Separate SendGrid Email API from Marketing Campaigns. On Mailgun, separate outbound streams from routes and validation calls. The inventory should name what happens on a hard bounce, a temporary failure, an unsubscribe, a complaint and a malformed inbound message.

Domain work should happen before application cutover. Confirm SPF, DKIM, DMARC, tracking domains, return paths and regional choices. Lower DNS TTL ahead of the change where practical, but do not remove the old records until the new path has delivered a controlled sample. A dedicated IP migration needs its own warm-up schedule. Shared-to-shared moves still need a gradual ramp because recipient expectations and message patterns matter more than the provider brand.

Templates often hide the hardest compatibility work. Export subject, preheader, variables, fallback values, localization, unsubscribe behaviour and attachment rules. Rebuild each template in the destination syntax and render fixtures with long company names, missing optional fields, right-to-left text, invoices, failed payments and security alerts. Test links and tracking domains. Keep a stable internal template identifier so analytics and support can compare the old and new provider without confusing a renamed template for a new message.

Inbound migration needs a separate rehearsal. Send replies to every route, include an attachment and an unexpected sender, and verify that the receiving endpoint rejects malformed or replayed requests. Check route order and loops. If replies create tickets, make the ticket identifier idempotent. Keep the old route available during a short overlap, but do not process the same inbound message twice. Log provider message identifiers and a migration cohort on every test.

Cut over by message class. Start with internal accounts, then invitations, then routine notices, then higher-risk billing and security messages. Compare delivery, bounce, block, complaint, latency, route and webhook outcomes. Keep the old credentials read-only while support closes open incidents. After the new provider is stable, revoke old keys, remove stale DNS assumptions and archive the mapping of old templates, routes and suppression groups.

1. Create a message matrix with event, sender, template, domain, recipient class, suppression rule, route and owner.
2. Verify DNS, authentication, region and retention choices with security and legal.
3. Rebuild templates and run visual, localization, link and attachment tests.
4. Implement webhook and inbound consumers with idempotency, signature checks and replay protection.
5. Ramp one message class at a time and compare provider events with the internal ledger.
6. Close the overlap by revoking credentials and preserving a support-readable migration map.

Which team should pick which?

Pick SendGrid when marketing and product communications are both first-class work. A B2B SaaS may want engineers to send receipts and alerts through Email API while lifecycle or growth staff manage contacts and scheduled campaigns in Marketing Campaigns. SendGrid’s subusers and Event Webhook also suit a larger platform team with several services. The cost is coordination: the organization must define how two products share domains, suppression, consent, reporting and access.

Pick Mailgun when the mail system is primarily an engineering surface. It is compelling for teams that need API and SMTP delivery, inbound routes, validation and logs close to code and infrastructure. A support product that turns replies into tickets, an integration that parses inbound commands, or a sign-up flow that validates addresses can use the same provider family. The cost is that campaign management remains a separate product decision and the team must own receiving security.

Choose based on the operational owner rather than a feature checklist. If a campaign manager is accountable for an audience calendar, SendGrid’s second product may reduce vendor sprawl. If a platform engineer is accountable for webhooks, routes, validation and retention, Mailgun’s vocabulary may fit better. In either case, keep the message ledger, consent source and suppression authority inside the company’s architecture. A provider should report delivery; it should not silently become the only copy of business truth.

A smaller SaaS can start with the lower listed 50,000-email SendGrid tier when it needs only outbound transactional delivery and has no inbound or validation requirement. It can start with Mailgun Foundation when route handling, validation or five days of logs are worth the price difference. A larger SaaS should compare the 100,000-email points, then add the people and systems needed for dedicated IP warm-up, campaign governance, regional review and incident response.