How to connect Mailgun to Stripe, HubSpot, and Salesforce

Mailgun has a clean API, a fair price, and a real deliverability team behind it. Most teams still get less than half the value out of it.

The pattern is always the same. A developer drops the SMTP credentials into the product, password resets and receipts start flowing, and the integration work stops there. The CRM never learns who bounced. Stripe events never fire emails. Replies vanish into a shared inbox. The validation API is paid for but never called.

The integrations that turn Mailgun from a relay into a revenue system are not complicated. They are just rarely built, because nobody owns email at the stack level. This is what mid-market teams should be wiring up, and the plays we run when we do it for them.

The Integration Gaps Most Mailgun Customers Have

If your Mailgun account looks like this, you are leaving the platform on the table:

• One default sending domain, no sub-accounts for marketing versus transactional traffic.
• Stripe is connected to the product but not to email. Failed payments, trial expiries, and churn events get logged but never trigger a send.
• Bounce, complaint, and unsubscribe events never make it back to HubSpot or Salesforce. The CRM keeps mailing dead contacts.
• Replies to outbound, support@, and billing@ disappear into a Gmail label. No routing, no parsing, no CRM logging.
• Validate is on the bill but never invoked before a campaign. Bounce rates climb past 3% and deliverability quietly degrades.

Automation Plays We Build with Mailgun

These are the four integration plays we run most often when we take over a Mailgun setup. Each one connects Mailgun to a system that already lives in the stack, so the team gets compounding value without buying anything new.

1. Stripe to Mailgun lifecycle

Trigger: any Stripe webhook event that matters for revenue. invoice.payment_failed, customer.subscription.trial_will_end, customer.subscription.deleted, charge.refunded.

Workflow: an n8n flow or serverless worker receives the Stripe webhook, looks up the customer in Supabase or the CRM, picks the right template, and calls Mailgun's send API with the right sub-account and from-address. Dunning gets three touches over seven days. Trial expiry gets a heads-up at day minus three and a final at day minus one. Cancellations get a win-back at day fourteen.

Outcome: dunning recoveries typically land between 8 and 18 percent of failed-payment ARR, and trial-to-paid conversion lifts in the 5 to 12 percent range. Indicative, not promised. The exact lift depends on baseline and ICP.

2. HubSpot and Salesforce bounce sync

Trigger: Mailgun event webhooks for bounced, failed, complained, and unsubscribed events.

Workflow: every event hits a webhook endpoint that writes the result to a Supabase audit table, updates a custom property on the contact record in HubSpot or Salesforce (email_status, last_bounce_reason, suppression_source), and drops the contact into the right suppression list. Hard bounces stop all sequences immediately. Soft bounces get a three-strike rule.

Outcome: the CRM stops emailing dead contacts. Deliverability rises across both transactional and marketing traffic, and the sender reputation recovers within one to two send cycles.

3. Inbound parsing for replies and shared mailboxes

Trigger: a reply lands at a Mailgun-routed address. support@, billing@, or the reply-to of an outbound sequence.

Workflow: Mailgun's routing posts the parsed message as JSON to a webhook. A lightweight classifier (rules first, LLM for the hard ones) tags the message as positive reply, OOO, unsubscribe request, or support ticket. Positive replies get logged on the contact in HubSpot or Salesforce and Slacked to the AE. OOO messages pause the sequence. Support tickets get created in the helpdesk. Nothing manual.

Outcome: reply handling time drops from hours to minutes. The AE never misses a hot reply because it was buried in a shared inbox.

4. Pre-send validation gate

Trigger: any bulk send from MailerLite, HubSpot, or an in-house campaign tool. Anything over a few hundred recipients.

Workflow: the list goes through Mailgun's Validate API before it hits the send queue. Invalid, role-based, and disposable addresses are dropped or flagged for review. The cleaned list goes back to the sending tool, and a daily report logs how many addresses got pulled and why.

Outcome: bounce rates typically settle below 1 percent. Gmail, Outlook, and Yahoo placement improve because the sender reputation is no longer being dragged down by junk addresses.

How Mailgun Should Integrate With Your Stack

A well-wired Mailgun account is not a standalone tool. It is the email layer that every other system writes to and reads from. The connections that matter:

• Stripe: revenue events drive lifecycle sends. Failed payments, trial states, refunds, and cancellations all become email triggers, not just billing log lines.
• HubSpot or Salesforce: Mailgun events write back to contact properties so the CRM always knows who is mailable. Sequences and workflows respect that signal.
• Slack: positive replies, bounce spikes, blocklist alerts, and Stripe-triggered dunning failures all post to the right channel. Email becomes observable.
• Supabase or your data warehouse: every Mailgun event lands in a typed table. The team can join sends against product usage, NPS, and revenue without scraping the Mailgun UI.
• n8n or your automation layer: the orchestration sits in one place. Webhooks in, conditional logic, Mailgun API calls out. No glue code scattered across three repos.
• Your helpdesk (Zendesk, Intercom, HelpScout): inbound parsing creates tickets directly. Shared mailboxes stop being a separate workflow.

What ROI Actually Looks Like

Email ROI is hard to attribute cleanly, so the right way to think about it is in ranges. These numbers are indicative, drawn from the kinds of mid-market builds we run. Not promised.

• Dunning automation: recovers 8 to 18 percent of failed-payment ARR within ninety days of go-live.
• List validation: bounce rates fall from 3 to 6 percent down to under 1 percent. Inbox placement on Gmail and Outlook usually lifts 5 to 15 points.
• Reply routing: SDR and AE response time on hot replies drops from a few hours to under fifteen minutes. Reply-to-meeting conversion typically improves 10 to 25 percent.
• Sub-account separation: zero cross-contamination incidents between marketing and transactional sending. The number is binary. You either lose password reset deliverability one week or you do not.

Where Teams Go Wrong

Even teams that take Mailgun seriously trip on the same things.

• One sending domain for everything. Marketing newsletters, product receipts, and outbound sequences sharing one reputation. The day a campaign gets reported as spam, password reset deliverability tanks too.
• Dedicated IPs without warmup. Buying a dedicated IP on Scale and blasting 50,000 emails on day one is the fastest way to land on a blocklist. Mailgun has a warmup path. Use it.
• Bounce events ignored. The webhook is configured, the events fire, and nothing reads them. The CRM never updates. Sender reputation slowly bleeds out.
• Validation paid for, never used. The credits roll over month after month. The bulk lists go out raw and the bounce rate is the first thing nobody talks about in the QBR.
• No ownership. Email sits between RevOps, engineering, and marketing. Each team assumes the other is watching. The result is a Mailgun account that ages without ever improving.

Sending Domains, Sub-Accounts, and Why They Matter

Before any of the plays above work, the sending architecture has to be right. The single biggest mistake is using one domain and one IP pool for everything. Mailgun makes it easy to split traffic, and once you have, the rest of the integration work gets cleaner.

We typically run three sending streams. The first is transactional product email from a subdomain like mail.product.com, on a dedicated IP pool with the tightest reputation. The second is lifecycle and marketing from a separate subdomain such as news.product.com, on its own pool. The third is cold outbound, which never touches the primary domain at all and lives on a third subdomain bought specifically for it. Each stream gets its own sub-account in Mailgun, so logs, suppression lists, and analytics stay isolated.

The benefit shows up the first time something goes wrong. A marketing send that lands in a spam trap does not pull password resets down with it. A cold outbound experiment that gets reported never touches the brand-critical domain. The team can move faster on marketing and outbound because the blast radius is contained.

Migrating to Mailgun Without Burning Your Reputation

If you are switching to Mailgun from SendGrid, Postmark, or Amazon SES, the move is not a same-day cutover. The new IPs have no reputation, and the receiving mailbox providers will throttle them until they do.

The pattern we run is a two-week parallel send. Week one routes 10 percent of transactional traffic through the new Mailgun IPs, 90 percent through the legacy provider. The split is by hashed user ID so individual users see one provider consistently. Week two moves to 50 percent. End of week two we cut over fully. Bounce, complaint, and delivery metrics are watched daily on both legs. If the new pool degrades, the split shifts back.

For marketing traffic, the warmup is slower. Mailgun has a managed warmup schedule on Scale and Enterprise, and we let it run for the full thirty days before increasing volume aggressively. The cost of going slower is small. The cost of getting blocklisted out of the gate is two months of recovery work.

Templates: Inline or in Mailgun

One question every team asks: should templates live in code or in Mailgun's template builder? The answer depends on who owns the copy.

If marketing owns the copy and the engineers do not want to ship a release for every wording change, templates go in Mailgun. The API call passes a template name and variables, the rendering happens server-side, and the marketing team edits the template directly. The trade-off is that template versioning lives outside Git, which means version control discipline has to move into Mailgun's UI.

If engineering owns the copy and the team uses React Email, MJML, or Maizzle, templates stay in the repo. Mailgun receives the rendered HTML on each send. Versioning, previews, and reviews all run through pull requests. This is our default for transactional email because the changes are infrequent and the audit trail matters.

Where Moonira Comes In

We treat Mailgun as one piece of a working email system, not a vendor to install. We audit the current setup, map every send and event back to a system of record, separate the traffic types, wire the integrations into Stripe, the CRM, the warehouse, and Slack, and put the validation and warmup workflows on autopilot.

If your team is sending tens of thousands of emails a month and the only thing connected is the SMTP credential, the gap between what Mailgun costs and what it should be returning is the build we do.