September 12, 2026
Why “Claimable” Doesn’t Always Mean “Exploitable”: A Subdomain Takeover That Wasn’t
A dangling CNAME, a claimable Mailgun domain, and a rejection that taught me more than an acceptance would have.
By 0x_specter
1 min read
Why "Claimable" Doesn't Always Mean "Exploitable": A Subdomain Takeover That Wasn't
Subdomain takeover checklists all say some version of the same thing: find a CNAME pointing to a service, confirm the target isn't claimed, register it, done. I found one that ticked every box on that checklist — and it still didn't work. Here's why, and what it changed about how I test these now.
The finding
A subdomain, email.newsletter.company.com, had a CNAME pointing to eu.mailgun.org. Querying it directly returned a 404 served from Mailgun's own infrastructure — the standard signal that a domain is dangling and unclaimed. I created a free Mailgun account, went to add the domain, and it was accepted without resistance. Every step of the classic takeover checklist checked out clean.
The rejection
The program closed it as Informative, and — unusually for a bounty response — gave a specific, verifiable technical reason: Mailgun changed its domain verification process back in 2016, requiring DKIM DNS verification (a TXT record) before a claimed domain can actually be used to send mail. Since email.newsletter.company.com is itself a CNAME record, you can't add a separate TXT record at that same name — DNS doesn't allow it. So while the domain was claimable inside Mailgun's dashboard, it was never actually usable for sending, because the verification step that would let you send mail from it has no valid place to attach.
The gap in the checklist
This is the part worth sitting with: "claimable" and "exploitable" got treated as the same thing, and they aren't. The standard takeover test proves registration succeeds. It doesn't prove the attack you actually care about — sending mail, serving content, whatever the impact claim depends on — is still possible after registration. Mailgun closed this exact gap for the email-sending scenario years ago, and it's easy to miss because the takeover still "succeeds" up to the point of registration; it just quietly stops mattering after that.
What I do differently now
Before reporting a takeover on a CNAME target, I check whether the service has a secondary verification step gating the actual impact (DKIM/TXT for mail-sending services, ownership-file verification for some hosting providers, etc.) — and specifically whether the DNS record type of the subdomain itself would even allow that verification to be added. If it's a CNAME and the service needs a TXT record at that same name to unlock real functionality, the "takeover" may be cosmetic.
Takeaway
A rejected report with a real technical explanation is worth more than a vague duplicate close — this one handed me a checklist gap I'd have otherwise kept repeating. If you're testing subdomain takeovers, "can I claim it" is step one. "Can I actually use it for the impact I'm claiming" is the step most checklists skip, and providers have been quietly patching that gap for the services that matter most.