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 [email protected] 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.