# Mailgun inbound routes: MX records and email verification

How domains that route inbound mail through Mailgun look in DNS, why Mailgun routes accept every recipient, and which verdicts to expect for addresses on them.

Updated: 2026-09-03

Mailgun is a sending service for applications, but it also receives mail: a domain whose MX records point at Mailgun delivers every incoming message to Mailgun's inbound routes, which store it, forward it or post it to a webhook. Such domains are usually application domains (a support system, a reply-tracking subdomain, a notifications domain), not places where people read mail in an inbox. Spaw reports them as `mx_provider: "mailgun"`.

## How Mailgun shows up in DNS

Domains receiving through Mailgun publish two MX records, `mxa.mailgun.org` and `mxb.mailgun.org`, at priority 10. Mailgun's own product domain, mailgun.com, is on Microsoft 365; it is mailgun.net, a Mailgun-operated domain, that shows the pattern in practice. Spaw matches the `.mailgun.org` suffix. Mailgun is an inbound-routing service rather than a mailbox host: the MX target accepts mail on behalf of whatever the customer's routes do with it.

## How Mailgun answers a verification handshake

Inbound routes accept every recipient by design. Mailgun does not know which addresses "exist" because routes are pattern-based (`match_recipient(".*@support.example.com")` is the canonical example), so the SMTP handshake says yes to any username and the customer's route logic decides afterwards. To a verifier, every Mailgun-receiving domain is a catch-all, and no probe can prove that a specific mailbox exists.

## What that means for your verdicts

Every syntactically valid address on a Mailgun-receiving domain answers `risky` with `reason: catch_all` and `mailbox_exists: null`. Spaw remembers the catch-all per domain for seven days, so subsequent lookups on the same domain do not spend a probe, and returns `mailbox_confidence` for each address. Mailgun is not on the established-provider list, so the estimate is driven by the domain's own DMARC and SPF, its registration age, the shape of the username and your own delivery outcomes; a name-shaped username on a young domain with no DMARC will score low, and that is the right answer for most application domains.

Consider what the address is for before you add it to a list. A reply-tracking address such as `reply+abc123@mail.example.com` is a machine endpoint, and sending marketing mail to it is pointless even though it will be accepted. `is_gibberish: true` on such addresses is a useful hint.

## SPF and DMARC at Mailgun

Mailgun's domain verification guide has customers add `include:mailgun.org` to their SPF record (`v=spf1 include:mailgun.org ~all` when Mailgun is the only sender) and publish the DKIM TXT record shown in the Mailgun dashboard, usually on a dedicated sending subdomain so the root domain's own MX and reputation stay untouched. Mailgun explicitly advises against putting its MX records on a root domain that already receives mail elsewhere. Spaw reports `has_spf` and `dmarc_policy` for whichever domain you look up, including subdomains.

## Practical notes for sending to Mailgun-receiving domains

Mail sent to a Mailgun inbound route reaches software, not a person, unless the customer forwards it to a mailbox. If you see these domains on a customer list, they usually came from automated signups, reply addresses harvested from email threads, or test data. Treat the `risky` catch-all verdict at face value and keep them out of human-facing campaigns; the feedback endpoint can confirm the few that do reach a person.

For a live look at any Mailgun-receiving domain, run it through the free MX lookup and the SPF and DMARC checker.

Reference: https://spaw.co/email-providers/mailgun