You set p=reject on your main domain months ago. SPF is clean, DKIM signs everything, and your DMARC reports look quiet. As far as you’re concerned, nobody can send mail as your brand.
Then a customer forwards you a phishing email. It came from promo.yourbrand.com. It passed SPF. It passed DKIM. It passed DMARC. And you have no idea who sent it, because that subdomain has been dead for three years.
This is the gap almost nobody checks. Your organisational domain can be locked down perfectly and still leave an open door, because a subdomain you forgot about is pointing at infrastructure an attacker now controls. The technique has a name, SubdoMailing, and it has been running at scale since 2022.
The subdomain you stopped thinking about is still in DNS
Every organisation accumulates subdomains. A marketing campaign needs landing.yourbrand.com. A vendor sets up support.yourbrand.com and points it at their SaaS. Someone spins up blog.yourbrand.com on a hosting platform for a product launch. The campaign ends, the contract lapses, the launch is over. The service gets cancelled.
What almost never happens is the DNS cleanup. The CNAME record stays. It still points to the third-party service that no longer exists. That is a dangling DNS record, and it is the raw material for a takeover.
Here is the chain. Your DNS has a CNAME like this:
promo.yourbrand.com. CNAME yourbrand.marketingvendor.io.
The marketing vendor shuts down. The contract for yourbrand.marketingvendor.io lapses and the name becomes available to register. An attacker scanning for exactly this pattern finds your dangling CNAME, registers yourbrand.marketingvendor.io themselves, and now controls whatever promo.yourbrand.com resolves to. From that moment, promo.yourbrand.com is theirs. They can stand up a phishing page on it, or worse, they can send email from it.
Why these emails pass authentication
This is the part that catches people out. The whole point of DMARC is to stop unauthorised mail claiming to be from your domain. So how does mail from a hijacked subdomain sail through?
Two ways, and both abuse trust you set up yourself.
The first is the SPF include. SPF records chain to other domains using the include: mechanism, which pulls in the allowed senders defined by a third party. A record might look like this:
v=spf1 include:_spf.yourbrand.com include:mail.oldvendor.net -all
If oldvendor.net expires and an attacker registers it, they now control the SPF record that your domain imports. They point it at their own mail servers. Your SPF record, unchanged, now authorises the attacker to send on your behalf. The mail passes SPF cleanly, because as far as the receiving server is concerned, you told it to trust that source.
The second is the dangling CNAME itself. Once an attacker owns the resource promo.yourbrand.com points to, they can configure mail and DNS for that hostname. Mail sent from promo.yourbrand.com is genuinely sent from a subdomain of your organisational domain. SPF passes. If they can get DKIM signing in place, that passes too. And because the From header is a real subdomain of your domain, DMARC alignment succeeds.
That last point is what makes this dangerous. The mail is not spoofed in the technical sense. It is authenticated. Your security stack waves it through, your customers see your brand in the sender, and the DMARC report shows a pass. Guardio Labs, who first documented the campaign at scale, found attackers running roughly five million emails a day through more than 8,000 hijacked domains, all passing the authentication checks the victim domains had configured.
This is not theoretical, and it is not slowing down
The original SubdoMailing campaign hijacked subdomains belonging to MSN, VMware, McAfee, The Economist, and Marvel, among others. Big brands with mature security teams, all sending phishing because of forgotten DNS entries.
It is still happening. In April 2026, researchers confirmed a coordinated subdomain takeover campaign hitting MIT, Harvard, Stanford, UC Berkeley, Columbia, Johns Hopkins, and more than 25 other universities, attributed to a threat actor tracked as Hazy Hawk, the same group previously seen hijacking CDC subdomains. The hijacked .edu subdomains were serving spam that Google was actively indexing under trusted university names.
There is a regional edge to this too. CloudSEK documented phishing campaigns targeting major UAE organisations including ADNOC, SNOC, and ENOC, using domains built on naming schemes close to the real ones. Around 90% of the malicious domains in that campaign were hosted in North America, deliberately, because takedown requests to providers in that region take longer to process. Slow takedowns mean a hijacked or lookalike domain stays live longer, and a live domain sends more mail.
The UAE Cyber Security Council put out an advisory in April 2026 stating that more than 75% of cyberattacks now begin with phishing. Authenticated phishing from your own subdomains is about the most effective version of that there is.
Closing the door
The fix splits into two jobs: subdomains you don’t use, and subdomains you do.
For subdomains you never send mail from, publish an explicit reject policy. DMARC has a dedicated tag for this. On your organisational domain’s _dmarc record, the sp tag sets the policy for every subdomain that does not have its own record:
v=DMARC1; p=reject; sp=reject; rua=mailto:reports@yourbrand.com
A common and dangerous mistake is to assume the main domain’s p=reject automatically protects subdomains in every case. It covers subdomains that inherit, but if a subdomain publishes its own DMARC record, that record wins and overrides the parent entirely. A hijacked subdomain can publish its own p=none. So sp=reject on the parent is the floor, not the ceiling, and you still need to know what records exist below it.
If you genuinely don’t use subdomains for email, there’s no reason to wait. You can hold the main domain at p=none while you’re still watching traffic and publish sp=reject immediately, locking subdomains shut before you’ve finished the rollout on the parent.
For the harder job, the dangling records, no policy tag helps. You have to find them and remove them. That means auditing your DNS for CNAMEs pointing at services you no longer use, and walking every include: in your SPF chain to confirm each referenced domain is still registered and still yours. Then you build a habit: whenever a project ends, a vendor contract lapses, or a service gets cancelled, DNS cleanup is part of decommissioning, not an afterthought.
Doing this without checking by hand every quarter
The audit is straightforward once. The problem is that DNS keeps changing, vendors keep coming and going, and a manual review is a snapshot that’s stale the moment someone adds a new CNAME. Researchers who warned over a thousand organisations about exposed subdomains found that 98% of them did nothing. Not because the fix is hard, but because nobody was watching the right place.
This is where continuous monitoring earns its place. DMARCS has a SubdoMailing Guard and a Subdomain Monitor built for exactly this: tracking your subdomains and their DNS dependencies, and flagging dangling records and takeover exposure before an attacker finds them first. Alongside that, the Forensic Analysis view turns your RUF failure reports into readable detail, so when an unfamiliar subdomain shows up sending mail, you see it and can attribute it rather than scrolling through raw XML hoping to spot the anomaly. Because DMARCS was built in the UAE, that reporting data stays in the jurisdiction you choose, which matters if you’re answering to PDPL or sector rules on where authentication data can live.
Start by running your domain through the free DMARC Analyzer. It will show you your current policy and whether your subdomains are actually covered or just look like they are. If you find dangling records or want continuous monitoring across every subdomain you own, start a trial and we’ll walk the cleanup with you.
