Dangling DNS records are usually discussed as a subdomain takeover problem.
The pattern is familiar: an organization creates a CNAME that points a subdomain to an external service. The project ends and the external resource disappears, but the DNS record remains. If an attacker can claim the abandoned resource, they may be able to serve content from what appears to be a trusted organizational subdomain.
Our investigation into DNS Attribution Laundering suggests that the consequences can extend beyond web content—and even beyond conventional email spoofing.
A stale DNS relationship can also affect how receiving email systems attribute the infrastructure that transmitted a malicious message.
That gives us a useful progression:
- Web content abuse
- Email authentication abuse
- Email infrastructure attribution abuse
The first two are increasingly well documented. The third is the behavior we documented in our DNS Attribution Laundering research.
Web content abuse: the established dangling-CNAME problem
Consider a common lifecycle:
project.university.edu → CNAME → external service
A university department, laboratory, research project, or student organization creates a site using an outside hosting provider. Years later, the project ends. The external account disappears, but the CNAME remains.
If the abandoned external resource can be recreated or claimed, an attacker may inherit the DNS relationship and serve content under the trusted university hostname. This is the classic subdomain takeover problem.
Infoblox documented this pattern at scale in its research into the threat actor it calls Hazy Hawk. The actor identified dangling CNAMEs associated with abandoned cloud resources and used them to hijack subdomains belonging to universities, government agencies, healthcare organizations, and major corporations.
The attacker does not need to compromise the organization's DNS account. The organization has already created the trust relationship. The attacker finds one that has outlived the infrastructure it was meant to describe.
Universities illustrate the lifecycle problem
Universities are particularly susceptible to this weakness. Departments create projects. Research groups use external services. Faculty and students move on. Cloud accounts disappear. Sites are retired. DNS records can survive all of those transitions.
Stanford discussed the issue years before our research. Its 2022 IT Community program included a session titled “NetDB hygiene and subdomain takeovers”.
The underlying weakness is not new. What has become increasingly clear is how many different ways attackers can exploit it.
University subdomain takeover at scale
On April 7, 2026, security researcher Alex Shakhov published findings from a campaign targeting U.S. university subdomains. Attackers were locating orphaned CNAMEs, claiming the abandoned resources, and serving spam under trusted .edu hostnames.
An expanded investigation published April 15 identified 34 affected universities, including Stanford University and the University of Utah.
The primary abuse Shakhov documented was web-based:
Dangling DNS → external resource takeover → trusted web content abuse
But he also pointed toward another consequence: depending on SPF, DKIM, and DMARC configuration, a hijacked subdomain could potentially be exploited for email spoofing.
Email authentication abuse
Email authentication depends heavily on DNS. SPF defines authorized sending infrastructure. DKIM publishes cryptographic keys. DMARC evaluates whether SPF or DKIM authenticates an identity aligned with the visible sender.
If an attacker gains sufficient control over a domain or subdomain through an abandoned DNS relationship, email becomes another possible avenue of abuse.
On March 9, 2026, the Certified Senders Alliance published guidance describing dangling DNS as an email-security and brand-reputation risk. It explained that attackers who gain control of abandoned infrastructure may be able to configure SPF and DKIM for the affected domain.
Stanford's own email-authentication guidance reflects a related concern about third-party infrastructure. Stanford states that it does not add external vendors to its primary SPF record because doing so could allow other customers of that service to send messages authenticated by Stanford's domain.
The security model here is:
DNS relationship → email authorization → authenticated malicious email
This is also where techniques such as SubdoMailing fit. The affected domain becomes part of the authenticated identity of the email.
Our investigation encountered something different.
Email infrastructure attribution abuse
On February 28, 2026, before the university takeover research described above was published, we received a phishing email containing an unusual Google-generated Received header.
The connecting SMTP address was 50.6.197.216, but Google represented the connection as:
wholecellviz.stanford.edu [50.6.197.216]
That raised an obvious question: Why was an external phishing server being associated with a Stanford University hostname?
We began investigating the DNS relationship behind the header. wholecellviz.stanford.edu was a CNAME pointing to wholecellviz.org.
On March 12, 2026, we preserved a DNS snapshot of that relationship. The external CNAME target resolved to approximately 50 geographically dispersed IP addresses. One was the exact SMTP source Google had recorded transmitting the phishing message: 50.6.197.216.
The Stanford hostname therefore had an observed DNS path to infrastructure that included the phishing source. But Stanford did not authenticate the email. Stanford was not the visible sender. Stanford did not authorize the sending IP through SPF or provide the DKIM signature. Its hostname appeared only in receiver-generated infrastructure telemetry.
That is fundamentally different from conventional subdomain takeover and email authentication abuse. The trusted domain was not being used as the authenticated identity of the message. Instead, the DNS relationship caused malicious SMTP infrastructure to be represented under a trusted institutional hostname by the receiving system.
We later documented the same general mechanism in another university case and proposed a term for the technique class: DNS Attribution Laundering, with the email-specific subtype CNAME-Assisted SMTP Attribution Laundering.
Our complete study is published as DNS Attribution Laundering: Legacy CNAMEs and Distributed Spam Infrastructure.
Three consequences of the same underlying weakness
1. Web content abuse
Trusted hostname → abandoned external resource → attacker-controlled content
The attacker claims infrastructure behind a dangling CNAME and serves content using the trusted organization's hostname.
2. Email authentication abuse
Trusted subdomain → attacker control → SPF/DKIM authority → authenticated email
The attacker gains enough control to use the affected domain as part of an authenticated sending identity.
3. Email infrastructure attribution abuse
Trusted hostname → external DNS relationship → malicious SMTP source → receiver attribution
The affected organization's domain does not authenticate the message. Instead, the DNS relationship causes externally operated infrastructure to appear under the trusted hostname in receiver-generated SMTP telemetry.
This is the behavior at the center of DNS Attribution Laundering.
A period of independent convergence
The chronology shows how several investigations approached the same DNS lifecycle weakness from different directions:
- 2022: Stanford's IT Community discusses NetDB hygiene and subdomain takeovers.
- February 28, 2026: Lappu AI receives the Stanford-related phishing message from
50.6.197.216. Google's receiver-generated header associates the address withwholecellviz.stanford.edu. - March 9: The Certified Senders Alliance highlights dangling DNS as an email-security problem.
- March 12: We preserve the Stanford DNS relationship and observe the phishing source among approximately 50 addresses behind the external target.
- April 7–15: Alex Shakhov independently documents university subdomain takeover at scale. His expanded research includes Stanford University and the University of Utah, the same institutions that later appear in our DNS Attribution Laundering research.
- May 29: The Stanford Daily reports on compromised Stanford web properties being used for black-hat SEO and scams.
- June 16: Stanford announces its Minimum Web Standards. Its DNS guidance calls for regular audits and prompt decommissioning of obsolete records, including CNAMEs, and requires DNS entries to be removed when a web property is retired.
- July 15: Lappu AI formally reports the historical Stanford association and supporting evidence to the university. By then, the CNAME identified in our investigation had already been removed.
The mechanisms were different, but they shared a root condition: institutional DNS relationships persisted after the infrastructure relationships behind them had changed.
Independent validation, not a causal claim
The available evidence does not support drawing a causal connection between these publications, investigations, or remediation efforts. That makes the convergence more useful, not less.
Stanford had been thinking about subdomain-takeover hygiene for years. Infoblox independently documented active exploitation of dangling CNAMEs. Shakhov independently found widespread university subdomain takeover. The Certified Senders Alliance independently emphasized the email-authentication consequences. Stanford's current standards explicitly call for obsolete CNAMEs to be removed.
Our investigation approached the same infrastructure weakness from another direction: the evidence left behind by a phishing email.
What we observed was a legitimate DNS path between a Stanford hostname and infrastructure that included the phishing source. We inferred that this relationship explained the trusted hostname in Google's receiver-generated telemetry. We did not observe Stanford sending or authenticating the message, and we found no evidence that Stanford authorized or knowingly participated in the activity.
Some historical details remain unknown: why the CNAME was originally created, how the external target's infrastructure changed over time, and precisely when the relationship became problematic. The CNAME was removed before our July report, so we do not claim our disclosure caused that remediation.
DNS can outlive the infrastructure it was meant to describe
DNS records often have extraordinarily long operational lives. The project that created a CNAME may disappear. The researcher may leave. The external service may be retired. Unless someone deliberately removes the record, DNS can continue answering the same way.
That matters because modern security systems use DNS for far more than locating websites. DNS participates in email authentication, contributes infrastructure context, influences security telemetry, and helps systems decide which names belong with which machines.
A DNS record that is no longer organizationally meaningful can remain technically meaningful to the rest of the Internet.
That is the broader lesson of DNS Attribution Laundering. Dangling DNS is not simply a question of:
Can somebody take over this forgotten website?
It is also worth asking:
What other security decisions are still being made because this DNS relationship exists?
For email security, the answer can include authentication. Our research shows that it can also include infrastructure attribution itself.
