Mailgun

What Is Mailgun?

Mailgun is a developer-oriented email service that handles the technical work of sending, receiving, and tracking email at scale through an API and SMTP relay. Founded in 2010 and now part of Sinch, Mailgun is built for transactional and bulk programmatic email, the password resets, receipts, shipping notifications, and large automated campaigns that applications generate, rather than the hand-composed newsletters a marketer writes in a visual editor. It is infrastructure: the plumbing that gets an application's email reliably into the inbox.

This is an important distinction, because it shapes everything about Mailgun, including how (and how easily) you can detect it. A marketing platform like Mailchimp or ConvertKit embeds visible forms and scripts on a public website. Mailgun, by contrast, usually does its work entirely on the back end. A developer integrates Mailgun's API into their server code, and the email goes out from Mailgun's infrastructure without leaving any markup on the website itself. As a result, Mailgun is one of the harder email services to identify purely from a web page, and the reliable signals live in DNS records and email headers rather than in HTML, a point we will be candid about below.

Mailgun is a hosted service, not something you self-host and not a browser extension. You send through it either by calling its RESTful HTTP API or by pointing your application's SMTP settings at Mailgun's relay. In return you get deliverability tooling, analytics, inbound routing, and address validation, the operational layer that makes email-at-scale dependable.

It is worth being clear about the audience and the boundary of the product. Mailgun targets software developers and technical teams who need email to be a programmable, observable part of their application, not marketers who want a drag-and-drop campaign builder. (Sinch does offer a separate, marketing-oriented product, Mailjet, for that audience.) Because Mailgun's value is reliability and control at the infrastructure layer, its features read like an operations checklist, dedicated IPs, authentication, suppression management, webhooks, rather than a creative toolkit. Keeping that framing in mind explains both why Mailgun is so widely embedded in modern web applications and why it tends to be invisible on the public-facing side of those applications.

How Mailgun Works

At the center of Mailgun is its email API. An application makes an authenticated HTTPS request to a Mailgun endpoint, supplying the sender, recipients, subject, and body (plus any attachments, inline images, or recipient-specific variables), and Mailgun accepts the message and takes over delivery. Teams that prefer not to use the HTTP API can instead configure their application's mail library to send through Mailgun's SMTP relay using credentials Mailgun provides; either path leads to the same sending infrastructure.

Mailgun is built for volume and personalization together. Batch sending with recipient variables lets a single API call address thousands of recipients while customizing each message, and the service supports scheduled delivery, message tagging for analytics, and MIME construction for complex emails. This is what makes it suitable for both one-to-one transactional mail and large automated sends.

Deliverability is Mailgun's core promise, and it is delivered through several mechanisms. Senders authenticate their domain with SPF, DKIM, and DMARC DNS records so receiving servers can verify that Mailgun is an authorized sender, which is essential for landing in the inbox rather than the spam folder. Mailgun offers dedicated IP addresses for high-volume senders who want to control their own sending reputation, manages suppression lists (bounces, unsubscribes, and complaints) automatically, and provides reputation monitoring. The analytics layer tracks deliveries, opens, clicks, bounces, and spam complaints.

Mailgun also works in the other direction. Inbound routing lets the service receive email sent to a domain and forward it to an application via webhooks, parsing the message so the application can create a support ticket, process a reply, or trigger a workflow, without the team running its own mail servers. Complementing this, the email validation API checks an address in real time, verifying syntax, confirming the domain exists, assessing mailbox plausibility, and flagging disposable or role-based addresses, which reduces bounces and protects sender reputation before a send ever happens.

The thread running through all of this is that Mailgun operates at the infrastructure layer of an application. Developers wire it in once, then rely on webhooks to receive real-time events, delivered, opened, clicked, bounced, complained, so their application can react programmatically. This event-driven, API-first design is why Mailgun is popular for product email and why its footprint is technical and largely invisible to anyone looking only at a rendered web page.

How to Tell if a Website Uses Mailgun

Detecting Mailgun is fundamentally different from detecting a marketing platform, and it is important to set expectations honestly: because Mailgun is a backend sending service, it usually leaves no markup, script, or form on the public website. There is no embed to find in View Source. Instead, the dependable signals live in DNS and in the headers of emails the site sends. StackOptic analyzes a URL from the server side and inspects DNS where it can, but identifying Mailgun with full confidence often requires seeing an actual email from the domain.

DNS records (the primary signal). When a domain authenticates with Mailgun, it adds recognizable DNS entries. Look for an SPF record (a TXT record) that includes mailgun.org, DKIM TXT records under Mailgun-style selectors (often on a subdomain like mg.example.com), and frequently a tracking CNAME such as email.mg.example.com pointing at mailgun.org. These are the most reliable web-side tells.

MX records for inbound. If a domain uses Mailgun's inbound routing, its MX records (or those of a sending subdomain like mg.example.com) point at mxa.mailgun.org and mxb.mailgun.org. Finding those is strong evidence of Mailgun on the receiving side.

Email headers (the definitive signal). If you can inspect an actual email the site sent, a receipt, a password-reset message, a notification, the full headers usually reveal Mailgun directly: a Received line referencing mailgun.org, an X-Mailgun-* header, a DKIM d= value tied to the sending domain or to mailgun.org, and a Return-Path on a Mailgun-style subdomain. Headers are the clearest confirmation because the act of sending is exactly where Mailgun's fingerprints appear.

What you generally will not find. Do not expect a Mailgun script tag or a form action pointing at Mailgun on the website itself; that is not how a transactional API works. If you see no email-platform markup on a site but the domain's DNS carries Mailgun SPF/DKIM entries, that combination is itself the signal.

Method	What to do	What Mailgun reveals
dig (SPF)	dig TXT example.com	SPF record including mailgun.org
dig (DKIM/CNAME)	dig TXT mg.example.com / dig CNAME email.mg.example.com	Mailgun DKIM selector or tracking CNAME to mailgun.org
dig (MX)	dig MX mg.example.com	Inbound routing via mxa.mailgun.org / mxb.mailgun.org
Email headers	Open a real email, "Show original"/"View source"	Received/X-Mailgun-* headers, DKIM d=, Return-Path
Wappalyzer / BuiltWith	Look up the domain	May report Mailgun from MX/DNS data, not from page HTML

A practical workflow is to run dig TXT example.com and look for mailgun.org in the SPF record, then, if you have a message from the domain, open its raw headers and search for mailgun. For the general approach to backend-and-DNS detection, see how to find out what technology a website uses and how to find out where a website is hosted. Because Mailgun is so often confused with marketing tools, how to find what email marketing platform a website uses is useful for understanding why a transactional sender like Mailgun behaves differently.

The honest summary is this: Mailgun detection is a DNS-and-headers exercise, not a View-Source exercise. A domain can use Mailgun heavily while its website shows zero trace of it. When DNS records carry Mailgun's SPF include and DKIM selectors, that is good evidence; when an actual email header names mailgun.org, that is confirmation. A site can also use multiple senders at once, Mailgun for product email and a separate marketing platform for campaigns, so finding Mailgun in DNS does not preclude finding a marketing tool in the page markup. Treating the two layers separately is the key to reading the stack correctly.

Key Features

• Email-sending API and SMTP relay. Send transactional and bulk email programmatically over HTTPS or by pointing an existing mail library at Mailgun's SMTP relay.
• Batch sending with recipient variables. Address thousands of recipients in one call while personalizing each message; supports scheduling and tagging.
• Deliverability tooling. Domain authentication (SPF, DKIM, DMARC), dedicated IPs, automatic suppression lists, and reputation monitoring.
• Inbound routing. Receive email to a domain and forward parsed messages to an application via webhooks, no mail servers to run.
• Email validation. Real-time address verification for syntax, domain existence, mailbox plausibility, and disposable-address detection.
• Event webhooks and analytics. Real-time delivery, open, click, bounce, and complaint events, plus a dashboard for tracking performance.
• Logs and APIs for operations. Detailed message logs and a full API surface for integrating email into application workflows.

Pros and Cons

Pros

• Purpose-built for reliable, high-volume programmatic email with strong deliverability tooling.
• Flexible integration via both HTTP API and SMTP, fitting almost any application stack.
• Inbound routing and validation extend it well beyond simple sending.
• Event webhooks make email an observable, reactive part of an application.

Cons

• Not a marketing tool: no visual campaign builder, audience segmentation UI, or template designer for non-developers.
• Requires technical setup, DNS configuration and code integration, which is a barrier for non-technical teams.
• Deliverability still depends on the sender maintaining good practices and list hygiene, not just the provider.
• Pricing and IP-warmup considerations add operational overhead for very high volumes.

Mailgun vs Alternatives

Mailgun competes with other transactional email APIs, not with newsletter platforms. The table clarifies the landscape.

Service	Primary use	Interface	Standout strength
Mailgun	Transactional + bulk programmatic email	API + SMTP	Deliverability tooling, inbound routing, validation
SendGrid	Transactional + marketing email	API + SMTP	Scale plus optional marketing campaigns
Amazon SES	High-volume transactional at low cost	API + SMTP	Cost efficiency within the AWS ecosystem
Postmark	Fast transactional email	API + SMTP	Speed and a transactional-only focus
Mailchimp / ConvertKit	Marketing newsletters and automation	Visual UI	Campaign building for non-developers

On compliance, Mailgun gives senders the infrastructure to meet obligations under the GDPR and the CAN-SPAM Act, authentication to prove sender identity, automatic suppression of unsubscribes and complaints, and APIs to honor opt-outs, but as transactional infrastructure it places the duty of lawful sending on the application owner. Transactional messages (a receipt or password reset) are treated differently from marketing messages under these laws, and the sender is responsible for classifying mail correctly, including the right unsubscribe mechanism and physical address where required.

If you find a site uses a marketing platform rather than a transactional API, the detection method differs entirely; compare Mailgun with a creator marketing tool like ConvertKit to see why one shows up in page markup and the other only in DNS and headers.

Use Cases

Mailgun is the default choice when an application needs to send email as part of its normal operation. Software products use it for account verification, password resets, receipts, and notifications, the transactional messages users expect instantly and reliably. Platforms with large user bases use its batch sending and dedicated IPs to push high-volume automated mail without harming deliverability.

It also serves applications that need to receive and process email through inbound routing (support desks, reply-by-email features, parsing pipelines), teams that validate addresses at sign-up to keep lists clean, and any product that wants real-time webhook events to drive downstream logic. For technology research and competitive analysis, detecting Mailgun in a domain's DNS signals a developer-built application with a deliberate email infrastructure choice, useful context when profiling a SaaS company's stack.

Consider a few representative scenarios. A SaaS startup might route every system email, welcome messages, invoices, alerts, through Mailgun's API so engineering can monitor delivery via webhooks and logs. A marketplace might use inbound routing so that buyer and seller replies sent to a masked address are parsed and threaded back into the platform. A growth team might validate every email at registration through Mailgun's API to cut bounces before they ever damage the sending domain's reputation. The common thread is that email is a programmable feature of the product, owned by engineering, not a marketing campaign owned by a marketer.

For sales intelligence and competitive research, finding Mailgun in a company's DNS is a meaningful technographic signal. It indicates an engineering-led organization that has invested in dedicated email infrastructure, which often correlates with a real software product rather than a brochure site. Pairing that insight with other stack signals, the hosting provider, the framework, the front-end CMS, builds a fuller picture of how a company is built. Learn more about turning these signals into qualification in our guide on technographics and using tech-stack data to qualify leads.

Frequently Asked Questions

Can you detect Mailgun just by viewing a website's source code?

Usually not. Mailgun is a backend sending service, so it typically leaves no script, form, or markup on the public website, there is nothing to find in View Source. The reliable signals live in the domain's DNS records (an SPF include for mailgun.org, Mailgun DKIM selectors, MX records pointing at mxa.mailgun.org/mxb.mailgun.org) and, definitively, in the headers of an actual email the site sends.

What DNS records indicate a domain uses Mailgun?

Look for a TXT/SPF record that includes mailgun.org, DKIM TXT records under a Mailgun-style selector (often on a sending subdomain such as mg.example.com), and frequently a tracking CNAME like email.mg.example.com pointing to mailgun.org. For inbound email, MX records on the sending subdomain point at mxa.mailgun.org and mxb.mailgun.org. You can check these with dig TXT example.com and dig MX mg.example.com.

Is Mailgun an email marketing platform?

No. Mailgun is built for transactional and bulk programmatic email sent by applications, password resets, receipts, notifications, and large automated sends, via API or SMTP. It does not offer a visual campaign builder or marketing UI for non-technical users. Sinch offers a separate marketing-focused product (Mailjet) for that purpose. Confusing the two leads to detection mistakes, since marketing tools appear in page markup while Mailgun appears only in DNS and email headers.

How does Mailgun handle GDPR and CAN-SPAM compliance?

Mailgun provides the infrastructure to support compliant sending: domain authentication, automatic suppression of unsubscribes and complaints, and APIs to record and honor opt-outs. However, as transactional infrastructure it places the legal responsibility on the application owner, who must classify messages correctly (transactional versus marketing), include the required unsubscribe mechanism and physical mailing address on marketing mail, and respect recipient consent under the GDPR and the CAN-SPAM Act.

Why is Mailgun harder to detect than a marketing platform?

Because the two work at different layers. A marketing platform embeds a visible sign-up form and a tracking script on the public website, leaving obvious HTML fingerprints. Mailgun runs entirely on the server, an application calls its API and the email is sent from Mailgun's infrastructure, so nothing appears on the rendered page. The act of sending leaves traces in DNS authentication records and in outgoing email headers, which is why detection shifts from View Source to dig and message-header inspection.

Curious which email infrastructure, hosting, and framework a given site uses? Analyze any URL with StackOptic at https://stackoptic.com.