During a penetration test last week, our consultant Subhash Paudel found a subdomain on a client's domain that pointed at Mailgun and led nowhere. The DNS records were still sitting there, neat and verified looking. The Mailgun side was empty. That gap, the space between what your DNS claims and what actually exists behind it, is enough to hand a piece of an organisation's email to whoever finds it first.
This is a write up of what the issue is, why it still turns up in 2026 even though Mailgun tightened things years ago, how common the underlying problem really is, and what you should do about it.
The client ran a dedicated subdomain for email, something along the lines of ds-email.[redacted].vic.edu.au. It carried a textbook Mailgun setup:
v=spf1 include:mailgun.org ~allmxa.mailgun.org and mxb.mailgun.orgAll of it had been marked verified at some point in its life.
The tell was simple. The records pointed at Mailgun, but when we sent requests to the subdomain, nothing came back. No active resource sat behind it. The DNS was saying "this belongs to Mailgun", and Mailgun, in effect, was saying "I have no idea what this domain is." When those two disagree, you have a dangling record. Dangling records are how subdomains get taken over.
Mailgun lets a customer add a sending or receiving domain and then prove ownership through DNS. The catch is what counts as proof. The MX records for receiving mail (mxa and mxb.mailgun.org) and the SPF include are the same values for every Mailgun customer on the planet. They are not unique to one account. So if those records are already present in a victim's DNS, and the domain is not actively claimed by anyone, an attacker can add the same subdomain to their own Mailgun account and find that the records they need to prove ownership are already there waiting for them.
The only record that is genuinely unique and randomly generated per account is DKIM. Hold that thought, because it is the single detail that separates an embarrassment from a catastrophe.
Once an attacker controls the receiving side of the domain, they can create routes inside the Mailgun portal and start collecting any mail addressed to that subdomain. That is the scenario Subhash flagged. An attacker quietly arranges, through the portal, to receive mail meant for the target.
I want to be precise here, because there is a lot of breathless writing on subdomain takeover that skips the nuance and ends up overstating the impact.
Back in 2021, a researcher reported almost exactly this class of issue against an ExpressVPN subdomain that happened to run through a third-party recruitment platform on Mailgun. Mailgun responded by stopping unverified subdomains from sending to arbitrary addresses, and by requiring a properly verified domain before DKIM authority could be inherited. In mid 2022 they went further, requiring DNS verification across MX, TXT and CNAME even when a domain is only used to receive mail. After that change, naive attempts to relay mail through a hijacked domain tend to fail with a relaying denied error.
So, the absolute worst case, sending fully spoofed and DKIM signed mail as the victim, is genuinely hard now, because DKIM is account-specific and randomly generated. The case that still bites is the receiving side. If the dangling records let an attacker claim the domain at all, they can read inbound mail addressed to it. And whether a given subdomain is claimable comes down to which records were left behind and how Mailgun validates them on the day you test. That platform dependence is the reason this keeps surfacing in real engagements instead of being a closed chapter from 2022.
In plain terms, do not assume that the vendor fixed this years ago means your environment is clean. The finding last week says otherwise.
A lot of people hear subdomain takeover and picture a defaced web page. The email version is quieter and usually worse, because email is the master key to almost everything else.
If an attacker can receive mail sent to a domain you control, consider what flows through it. Password reset links. Multi-factor codes and magic links. Invoices and payment redirection opportunities. Vendor onboarding and verification messages. Delivery and bounce reports that leak internal addresses and system detail. Any of those can be turned into an account takeover or a fraud, and none of it requires the attacker to send a single spoofed message.
For this client, the stakes were sharper still. A vic.edu.au domain means a school, which means student and parent records, safeguarding sensitive communications, and a community that trusts mail from that domain implicitly. Education is a sector that runs lean on security resourcing and heavy on third-party platforms for newsletters, permission forms and parent messaging. That combination is exactly where forgotten email subdomains accumulate.
Common enough that it has its own tooling and its own threat actors.
Dangling DNS, the broad category this falls under, is being found at scale. SentinelOne flagged more than 1,250 subdomain takeover risks tied to dangling DNS across its clients in 2024 alone. One Silent Push customer reportedly surfaced over 2,000 exploitable DNS records that needed immediate remediation. Infoblox tracked a threat actor it named Hazy Hawk in early 2025 that was hijacking dangling DNS records belonging to organisations including the CDC, Deloitte, PwC and Ernst and Young. These are not obscure shops with no security team. They are large, well-resourced organisations that simply lost track of an old record.
The Mailgun-specific flavour has been documented repeatedly in bug bounty and VAPT writeups across 2024 and 2025, and there is a maintained tool, mx-takeover, built specifically to hunt misconfigured MX records pointing at Mailgun. The fact that the tooling exists and stays maintained tells you the problem has not gone away.
The pattern is almost always the same. An organisation starts using a service, sets up the DNS, later stops using the service or migrates away, and forgets to remove the records. The gap between deprovisioning a service and an attacker claiming it can be hours, not months.
There are three jobs here. Find it, fix it, and stop it from coming back.
Find it. Inventory every DNS record that delegates to a third party, not just CNAMEs, but MX and TXT as well. For any subdomain you suspect, a couple of quick lookups tell you a lot.
dig ds-email.example.vic.edu.au CNAME
dig ds-email.example.vic.edu.au MX
host ds-email.example.vic.edu.au
If the records point to a provider like Mailgun, but nothing live resolves behind the subdomain, treat it as a candidate for takeover and verify it properly on an authorised engagement. Tools such as subzy and mx-takeover help at scale, and EdOverflow's can-i-take-over-xyz reference is worth keeping handy to check provider-specific behaviour.
Fix it. If you are no longer using the service, remove the records. That is the actual remediation, and it is usually a five minute change that nobody owns, which is why it never happens. If you are still using the service, make sure the domain is claimed and verified in your active account, with current DKIM in place, so there is no orphaned configuration for someone else to grab. Restrict subdomains to spoof the parent domain by switching to “Reject” (sp=reject). While you are there, search Certificate Transparency logs (crt.sh) for any certificates issued against the subdomain that you did not request.
Stop it coming back. This is really a process problem dressed up as a technical one. DNS cleanup belongs in your offboarding runbook for any SaaS or platform you retire, the same way you would revoke API keys or disable accounts. Maintain an inventory of which subdomains are delegated to which providers and who owns each one. For anything beyond a handful of domains, periodic manual review will not keep up, so fold DNS hygiene into continuous external attack surface monitoring.
The vulnerability here is not really Mailgun. It is the record nobody remembered to delete. Email infrastructure tends to be set up once, in a hurry, by whoever was migrating a newsletter or a notification system, and then it is left alone for years. The DNS keeps advertising a relationship with a provider long after the relationship ended, and that advertisement is an open invitation.
If your organisation has ever used Mailgun, or SendGrid, or any hosted email platform on a dedicated subdomain, go and check what is still pointing at it. The finding that prompted this post took minutes to spot once someone bothered to look.
Finding by Subhash Paudel, Spartans Security. If you would like us to check your own external footprint for dangling email and DNS records, that is the kind of thing our penetration testing and attack surface work covers.
