Subdomain Takeovers and Your DMARC Policy: When Dangling CNAMEs Become Email Spoofing Vectors

In April 2026, we discovered a coordinated subdomain takeover campaign affecting 34 US universities, including MIT, Harvard, Stanford, UC Berkeley, Columbia, UChicago, Johns Hopkins, and others. The attack pattern was straightforward: universities had created CNAME records pointing subdomains to external services (GitHub Pages, WP Engine, various cloud hosting), the external accounts were abandoned, and the DNS records stayed live. Attackers registered the orphaned external accounts, took control of what the universities' subdomains served, and used the trusted .edu domains to host SEO-optimized explicit spam that Google indexed.

Renée Burton, VP of Threat Intelligence at Infoblox, confirmed in our LinkedIn comments that the campaign matched the pattern of Hazy Hawk — a threat actor Infoblox had been tracking since the same group hijacked CDC subdomains using the identical technique. "It's amazing how long the dangle can last. Years. And then they just pick it up, drop it. Rinse repeat."

The SEO spam was the visible damage. The under-reported risk, which is what this post is about, is that a subdomain takeover can also be used to bypass DMARC at p=reject on the parent domain. If your subdomains can be hijacked, your DMARC policy is weaker than you think it is — even when it's correctly enforced.

How Subdomain Takeover Works

The technique relies on the gap between DNS records and the external services they reference. A typical scenario:

1. A department at the university creates a subdomain, project.example.edu, pointing to a GitHub Pages site at <department>.github.io.
2. The project ends. The GitHub Pages site is deleted.
3. The CNAME record project.example.edu → <department>.github.io stays in DNS, because nobody removed it.
4. An attacker registers the GitHub username <department> (or claims the GitHub Pages name), points it to whatever content they want, and now anyone visiting project.example.edu sees the attacker's content.

The same pattern works across dozens of platforms — Heroku, Azure, AWS S3 buckets, Fastly, Netlify, WP Engine, Shopify, Tumblr, and many others. Wherever a DNS record can point to an externally-managed name that can be re-claimed after abandonment, the takeover is possible.

For SEO spam, the takeover is the entire attack — serve the content, get indexed under the trusted parent domain, monetize through affiliate networks. The damage is reputational and remediation is straightforward: remove the dangling CNAME, request URL removal from Google Search Console for cached pages, audit DNS for other orphaned records.

For email spoofing, the takeover is the entry point to a different attack.

The Email Spoofing Angle

DMARC alignment uses the visible From: domain to determine which DMARC record applies. If the From: domain is project.example.edu, the receiver looks up _dmarc.project.example.edu first. If that subdomain doesn't have its own DMARC record, the receiver falls back to the organizational domain (example.edu) — but only after applying the sp= tag from the parent DMARC record, which governs subdomain policy specifically.

This creates several attack paths once a subdomain is taken over:

Path 1: The subdomain has no DMARC record and the parent's sp= is permissive. If the parent DMARC is set to p=reject; sp=none (a configuration we encounter regularly in audits), then the subdomain effectively has no enforcement. The attacker who controls the subdomain via takeover can also publish SPF and DKIM records on it (because they control the DNS at the subdomain level via the cloud platform that's now serving content there), authenticate mail under the subdomain, and send phishing that visibly comes from project.example.edu with valid authentication and no DMARC enforcement.

Path 2: The parent's DMARC includes the subdomain in alignment, but the subdomain's SPF/DKIM are misconfigured or absent. If the receiver evaluates DMARC with relaxed alignment (adkim=r, aspf=r), authentication on the subdomain can be sufficient to pass DMARC for the From: domain. An attacker with control of the subdomain's DNS can publish whatever SPF/DKIM records they need to make mail authenticate.

Path 3: The takeover platform itself provides legitimate email infrastructure. Some cloud platforms — including a few that frequently host takeovers — offer email sending as part of their service. An attacker who claims an abandoned account on such a platform can use the platform's own DKIM signing to send mail under the hijacked subdomain. The mail authenticates correctly because the platform is doing the signing under a domain the platform thinks the attacker legitimately controls.

The result, across all three paths: a phishing email visibly from project.example.edu that passes DMARC, lands in inbox at Gmail and Outlook, and bears every signal of legitimacy. Recipients see what looks like a message from a trusted institution, sent from a subdomain that genuinely belongs to the institution, with valid authentication. The institution's p=reject policy on the apex did not protect them, because the attack happened at the subdomain layer.

The Inherited Trust Problem

The reason this is dangerous beyond ordinary phishing is that subdomains inherit the trust signals of the parent domain. A spoofed message from mit-research.example.com carries no inherited trust. A spoofed message from research.mit.edu does — recipients are far more likely to read, respond, and act on mail that appears to come from an .edu they've heard of.

Mailbox provider machine learning models, which weight sender reputation heavily, also inherit reputation across subdomains. A phishing campaign launched from a hijacked .edu subdomain can take advantage of the parent domain's accumulated good reputation to skate past spam filters that would catch identical content from a freshly-registered look-alike domain.

For high-value brand impersonation targets, this is the structural advantage of subdomain takeover over typosquatting: the attacker isn't impersonating you, they're literally sending from your domain. The visible signal to the recipient is correct — the mail did, in some sense, come from your infrastructure. Just not from a part of your infrastructure that anyone is actively governing.

How to Detect Vulnerable Subdomains

The detection pattern is to enumerate every CNAME in your zone and verify the target. For each CNAME, the target should either:

1. Resolve to active infrastructure under your direct control, or
2. Resolve to a registered, claimed external service that you actively pay for.

If the CNAME target does not resolve, or resolves to a generic error page indicating the external account has been deleted or never existed, the subdomain is vulnerable. The attacker just has to register or claim the right name on the external platform to take control.

Practical detection tools include:

• dig or dnsx for enumerating CNAMEs across the zone
• subjack, subzy, or nuclei with subdomain takeover templates for automated detection across common takeover-prone platforms
• DNSPolaris, Detectify, or other commercial DNS-monitoring services for ongoing detection at scale

For organizations with hundreds or thousands of subdomains, the audit is a scripted job that should run periodically — not a one-time inventory. Subdomains accumulate. Cloud accounts get abandoned. New takeover-prone services come into use. The threat surface evolves continuously.

The Remediation

For an individual vulnerable subdomain, the fix is to remove the dangling CNAME. The fix is fast — the discipline is making sure DNS cleanup is part of the decommissioning process for every project, vendor, or service that gets retired.

For an organization-wide hardening posture, the discipline is:

1. Maintain a DNS inventory. Every subdomain, the target of every record, the business purpose of each. New subdomains require a documented owner and a decommissioning trigger.

2. Audit CNAMEs periodically. Automated detection runs on a schedule. Findings are routed to the team that owns the affected subdomain for either removal or re-claim.

3. Tighten DMARC subdomain policy. Set sp=reject on the apex DMARC record, so subdomains without their own DMARC records inherit strict enforcement. This doesn't prevent takeover, but it limits the email-spoofing damage if a takeover occurs.

4. Publish SPF and DMARC at the subdomain where appropriate. A subdomain that's actively used for email should have its own SPF record (not inheriting the apex's) and either its own DMARC or explicit reliance on the apex's sp= policy. The explicit configuration leaves less room for ambiguity if the subdomain is later abandoned.

5. Implement a decommissioning checklist. When a project ends, a vendor is changed, or a service is sunsetted, the checklist includes DNS cleanup. The CNAME that pointed to the old service is removed before the external account is deleted, not after.

6. Monitor for unauthorized DNS changes. If a subdomain CNAME is modified by someone other than the documented owner, the change should generate an alert. DNS-aware monitoring platforms (URIports has a DNS-change detector; Cloudflare has audit logs) make this straightforward.

The Decentralization Trap

The Hazy Hawk university campaign is, in part, a story about decentralized DNS governance. Universities are highly decentralized institutions — individual departments, labs, research groups, and student organizations frequently have the ability to request subdomains independently. When the people who originally requested those subdomains leave, the records are orphaned without a designated successor.

The same dynamic applies, at smaller scale, to any organization with distributed engineering or distributed marketing. Each team that gets the authority to create subdomains becomes a potential source of dangling CNAMEs once the team's projects end. The fix at the architectural level is governance — a single team that owns DNS, with explicit gates on subdomain creation and required decommissioning records — but most organizations don't have this until after their first incident.

If your organization hasn't centralized DNS governance, you almost certainly have orphaned subdomains. The question is whether you find them before an attacker does.

What This Means for Your DMARC Posture

The general principle: DMARC at p=reject on the apex domain is a strong control against the most common spoofing attacks, but it's not the same as protecting every part of your DNS surface. The subdomain takeover vector specifically gives attackers a way to send authenticated, DMARC-passing mail under your domain — and the only defense at the email layer is sp=reject and per-subdomain DMARC on actively-used subdomains.

The deeper defense is DNS hygiene. Every dangling CNAME is a potential takeover. Every takeover is a potential email-spoofing vector. The work of finding and removing dangling records is unglamorous but it's the actual security posture for organizations with any non-trivial subdomain footprint.

We've published a more detailed writeup of the Hazy Hawk university campaign separately — including the full list of affected institutions, the Department of Defense Education Activity (DoDEA) extension flagged by community researcher Henk G., and the disclosure timeline. The general lesson is broader than the universities: every organization with abandoned DNS records is one motivated attacker away from being the next case study.

---

Written by the team at SH Consulting. If you want a DNS audit to find dangling CNAMEs, abandoned subdomains, and subdomain takeover risk across your domains, book a call.