CNAME-Assisted SMTP Attribution Laundering: How two phishing emails exposed legacy university DNS relationships and how the University of Utah case seeded a July 13, 2026 infrastructure expansion spanning 1,449 IP addresses, 42 countries, 161 autonomous systems, and 161 attributed providers.
Author:Vivek UppalReviewer: Tomislav SakicVersion: 1.0Utah-seeded dataset: July 13, 2026Cases: Stanford University and University of UtahResearch status: Published
Research overview
Executive summary
This study documents the methodology of sending phishing emails in which legacy university CNAME relationships caused externally operated SMTP infrastructure to appear under trusted institutional hostnames in receiver-generated email headers. We propose the term DNS Attribution Laundering, and the subtype CNAME-Assisted SMTP Attribution Laundering, for this class of misleading infrastructure attribution. Unlike SubdoMailing, the university domains were not used as authenticated sender identities; unrelated sender-controlled domains passed SPF or DKIM while the university hostnames appeared only as DNS-derived infrastructure context. The evidence establishes DNS Attribution Contamination in both cases, but does not establish that either university operated the sending systems or that the infrastructure operator intentionally sought the university attribution.
Why this is different from SubdoMailing. In SubdoMailing, an affected or hijacked subdomain becomes part of the authenticated sending identity and may pass SPF and DMARC as the victim domain. In the cases documented here, the university hostnames did not authenticate the messages and were not used as envelope or visible sender domains. They appeared in receiver-generated SMTP infrastructure attribution because of external CNAME relationships, while unrelated sender-controlled domains supplied the authenticated identities.
A message, received on February 28, 2026, connected from 50.6.197.216. Google associated that address with wholecellviz.stanford.edu. Another message, received on July 3, 2026, connected from 5.175.188.80, which Google associated with therate.hec.utah.edu. In both cases, the university hostname was a CNAME pointing to an external domain. Those external targets resolved to unusually broad, geographically dispersed address sets that included the IP address directly observed transmitting the phishing message.
The available evidence does not show that Stanford University or the University of Utah operated the sending servers, authorized the messages, or knowingly participated in the activity. Instead, the cases illustrate a narrower and important security problem: a long-lived institutional hostname can remain delegated to an external dependency after the original project or relationship ends. If the external target changes ownership, configuration, or purpose, the trusted hostname may become associated with unrelated, and potentially abusive, infrastructure.
Starting with the University of Utah-related hostname therate.hec.utah.edu and its CNAME target cse-online.net, an iterative expansion through observed A, AAAA, PTR, and seed relationships produced an investigative graph containing 1,449 IP lookup records, 412 domain lookup records, and 3,487 lineage edges. The addresses were attributed across 42 countries, 161 autonomous systems, and 161 provider labels. The expansion reached a maximum recorded depth of 10.
All aggregate statistics, maps, and expanded network visualizations in this study are derived from the Utah-seeded dataset collected on July 13, 2026. The Stanford case was investigated separately and is not included in those aggregate totals unless a figure or statement explicitly says otherwise. The underlying Utah-seeded dataset is assigned Zenodo DOI 10.5281/zenodo.21400689.(To be published soon)
Terminology and intent. The study title names a proposed technique class. Where the available evidence does not establish that an operator deliberately sought the trusted hostname attribution, the neutral term DNS Attribution Contamination describes the observable condition. The stronger “laundering” label should be applied to an individual incident only when intentional exploitation is supported by the totality of the evidence.
Critical interpretation boundary. These totals describe the Utah-seeded expanded research graph collected July 13, 2026, not a list of 1,449 confirmed malicious assets. The graph contains directly observed SMTP sources and a much larger set of associated infrastructure reached through DNS and reverse-DNS relationships. Inclusion in the graph is evidence of a technical relationship worthy of investigation; it is not, by itself, proof of mail-sending activity, malicious control, or intent.
Both universities accepted and acknowledged the evidence provided to them. The problematic DNS associations were remediated: the Stanford CNAME had already been removed before the formal report, while the Utah CNAME was removed after disclosure. Neither institution confirmed nor disputed the researchers’ technical characterization of the historical control chain.
Study results
Key findings and statistics
Aggregate-data provenance. Every statistic in the panel below is derived from the Utah-seeded infrastructure expansion dataset collected July 13, 2026. Stanford case data is not included in these totals.
1,449IP lookup records in the Utah-seeded expansion
412Domain lookup records
3,487Recorded lineage edges
42Countries represented in IP enrichment
161Autonomous systems represented
161Attributed provider labels
13Expanded domains returning more than 50 IPs
54.0%Of observed IPs attributed to the two largest country groups
A distinct attribution mechanism
The cases support a new taxonomy for trusted hostnames appearing in receiver-generated telemetry through stale or repurposed DNS relationships, without being used as the authenticated sender identity.
Two confirmed phishing sources
The core evidence includes two SMTP client addresses directly recorded by Google while transmitting phishing messages: 50.6.197.216 and 5.175.188.80.
Trusted names, external control paths
In both cases, the university hostname was not the authenticated sender. It appeared as infrastructure context because an institution-controlled CNAME pointed to an external domain.
Address-set expansion
The Stanford external target resolved to 50 addresses. The Utah target resolved to 57 addresses, including the confirmed SMTP source.
Snowshoe-style characteristics
The Utah-seeded July 13 graph displayed broad distribution across providers and countries, repeated large address sets, unrelated hosted names, and direct mail capability on confirmed nodes.
Authentication did not implicate the universities
SPF and DKIM authenticated sender-selected domains unrelated to stanford.edu or utah.edu. The university names appeared in DNS-derived infrastructure attribution.
Disclosure led to a safer end state
Both institutions acknowledged the evidence. The continuing DNS associations no longer exist, reducing the risk of future misleading attribution through the same hostnames.
Plain-language explanation
An understandable description of the spam network
The investigation did not begin with a blocklist or a broad internet scan. It began with a receiving mail server’s contemporaneous record of a real SMTP connection.
Received: from sender-presented-name
(dns-associated-hostname [connecting-IP])
by mx.google.com ...
The connecting IP is the server that established the SMTP session with Google. The sender-presented name is commonly supplied during the SMTP HELO or EHLO exchange and may be arbitrary. The parenthesized hostname is DNS-derived context recorded by the receiving system. A reputable hostname in that position can create the appearance that the sending infrastructure belongs to the reputable organization, even when the actual server is externally operated.
Utah-seeded expansion model
therate.hec.utah.eduUniversity of Utah hostname observed in the SMTP trace
→
cse-online.netExternal CNAME target
→
57 addressesInitial target answer set containing the confirmed SMTP source
→
412 domains · 1,449 IP addressesUtah-seeded iterative expansion collected July 13, 2026
Scope boundary. The Stanford case establishes a second CNAME-assisted SMTP attribution event, but its 50 address snapshot was analyzed separately. It is not part of the 1,449-IP Utah-seeded aggregate dataset or the aggregate visualizations linked to DOI 10.5281/zenodo.21400689 (To be published soon).
Core network versus associated graph
Confirmed core
Direct mail evidence
SMTP client IPs observed by Google, relevant email-authentication results, and DNS chains linking the university hostname to the observed source.
Strong association
Direct expansion
Addresses returned by the external CNAME target, repeated infrastructure patterns, and domains or PTR names directly attached to those addresses.
Investigative graph
Secondary expansion
Nodes reached through additional A, AAAA, PTR, shared-hosting, or balloon-domain relationships. These require individual validation before attribution.
The study’s central claim is not that every node in the graph is malicious. It is that confirmed sending infrastructure sits inside a repeatable, unusually broad relationship pattern in which legacy DNS can place a trusted third-party hostname into receiver-generated attribution evidence.
Proposed taxonomy
DNS Attribution Laundering
Dangling DNS, subdomain takeover, snowshoe spam, reverse-DNS attribution, and SubdoMailing describe important parts of the surrounding problem. None of those terms, however, precisely captures the mechanism observed in the cases in this study: attacker-associated infrastructure being represented under a trusted third-party hostname in receiver-generated SMTP telemetry while unrelated sender-controlled domains provide email authentication.
Proposed definition.DNS Attribution Laundering is the intentional use or exploitation of stale, dangling, repurposed, or externally delegated DNS relationships to cause attacker-controlled infrastructure to be represented in receiver-generated logs or security telemetry under a trusted third-party hostname, even though that third party neither operates the infrastructure nor authenticates the activity.
Formal definitions
Email-specific subtype
CNAME-Assisted SMTP Attribution Laundering
A trusted hostname’s CNAME relationship connects that hostname to external infrastructure containing an SMTP-sending IP. The receiving mail system consequently records the trusted hostname in connection with the SMTP session even though the message is authenticated using an unrelated sender-controlled identity.
Intent-neutral condition
DNS Attribution Contamination
The observable condition in which stale, dangling, or repurposed DNS causes a trusted hostname to be associated with unrelated infrastructure. This term does not assume that the infrastructure operator deliberately sought or benefited from the attribution.
Principal term
Formal scope
Intent threshold
Status in this study
DNS Attribution Laundering
Intentional exploitation of stale, dangling, repurposed, or externally delegated DNS relationships so attacker-controlled infrastructure is represented under a trusted third-party hostname in receiver-generated telemetry.
Requires evidence supporting deliberate exploitation or knowing retention of the trusted attribution.
Proposed umbrella technique class; operator intent remains unresolved in both university cases.
CNAME-Assisted SMTP Attribution Laundering
An email-specific subtype in which a trusted hostname’s CNAME chain connects it to an externally operated SMTP source, causing the trusted hostname to appear in receiving mail telemetry while unrelated domains authenticate the message.
The technical event can be observed without proving intent; the “laundering” classification for a specific actor requires evidence of intent.
The CNAME-assisted SMTP attribution pattern is directly observed in both case studies.
DNS Attribution Contamination
The intent-neutral condition in which DNS relationships cause a trusted hostname to become associated with unrelated or abusive external infrastructure.
No malicious intent is required.
Directly supported by the preserved headers and DNS relationships in both university cases.
Why this is not SubdoMailing
SubdoMailing and CNAME-Assisted SMTP Attribution Laundering can share the same underlying exposure - a forgotten or externally delegated DNS relationship - but they use the affected hostname differently. In SubdoMailing, the hijacked subdomain becomes part of the authenticated sending identity. In the cases documented here, the university hostname was not authenticated by SPF or DKIM and did not appear as the envelope or visible sender domain. It appeared in infrastructure-attribution context generated by the receiving mail system.
Dimension
SubdoMailing
CNAME-Assisted SMTP Attribution Laundering
Primary use of the trusted domain
The compromised or hijacked subdomain is used to send mail as the affected organization.
The trusted hostname is surfaced as the apparent network identity of externally operated SMTP infrastructure.
Authenticated identity
SPF and DMARC can pass for the victim domain or hijacked subdomain.
SPF or DKIM authenticates an unrelated sender-controlled domain; the trusted hostname is not authenticated.
Where the trusted name appears
Envelope sender, visible From domain, DKIM identity, or aligned authentication chain.
Receiver-generated Received trace, reverse/forward DNS context, iprev-style telemetry, or related infrastructure logs.
Security effect
Authenticated impersonation of the affected organization.
Misleading infrastructure attribution that can imply organizational ownership or involvement where none is established.
Evidence in this study
Not observed: neither university domain authenticated the messages.
Observed: both university hostnames appeared beside confirmed phishing-source IPs because of external CNAME relationships.
SubdoMailing
Victim subdomain takeover or poisoned dependency ↓ attacker-controlled DNS and mail authorization ↓ SPF / DMARC-aligned email as victim identity
Observed attribution pattern
Trusted institutional hostname ↓ legacy external CNAME attacker-associated SMTP infrastructure ↓ trusted name in receiver trace; unrelated domain authenticates
Potential extensions to the taxonomy
The present study formally documents only the CNAME-assisted SMTP pattern. The same attribution principle could potentially arise through other DNS mechanisms or appear in other telemetry surfaces. The following names are proposed as candidate subtype families for future validation; this study does not claim to have observed or established them.
A stale or repurposed A or AAAA record under a trusted domain points directly to an externally operated SMTP source.
The trusted hostname appears as the network identity of the sending IP without an intervening CNAME.
No
PTR/FCrDNS-Assisted SMTP Attribution Laundering
A PTR record names a trusted hostname and a forward lookup returns the SMTP source IP.
Reverse and forward DNS appear mutually consistent in mail or abuse telemetry.
Not established as a separate mechanism
NS-Delegation-Assisted Service Attribution Laundering
A forgotten subdomain remains delegated to externally controlled authoritative nameservers.
Multiple services can appear beneath the trusted organizational namespace.
No
MX-Assisted Mail-Flow Attribution Laundering
An obsolete MX relationship points to mail infrastructure whose control or purpose has changed.
Mail-routing and receipt telemetry associates the external service with the trusted domain.
No
Wildcard-DNS Attribution Laundering
A wildcard record maps arbitrary names under a trusted domain to external infrastructure.
Many apparently organization-owned hostnames can surface in telemetry without individual records.
No
CNAME-Assisted Web/TLS Attribution Laundering
A stale external CNAME connects a trusted hostname to externally controlled web or TLS infrastructure.
Web logs, certificates, scanners, or threat feeds attribute the service to the trusted organization.
No
Taxonomy boundary. These candidate families are hypotheses for future research. Their inclusion provides an extensible naming framework; it does not establish that each technique exists in operational use.
Novelty statement and scope
To our knowledge, publicly available terminology has not previously isolated and named this specific form of SMTP infrastructure misattribution. We therefore propose the taxonomy above as a research contribution. This is a provisional novelty statement rather than a claim that the underlying behavior has never occurred before. We invite researchers, operators, and affected organizations to identify earlier documented cases or more established terminology.
Application to the university cases. The technical condition - DNS Attribution Contamination - is directly supported by the preserved headers and DNS relationships. Whether the infrastructure operator deliberately engineered or retained those relationships to obtain trusted university attribution remains unresolved. The study therefore characterizes the technique class without asserting proven intent in either university case.
Dataset analysis
Infrastructure statistics
The following figures summarize the completed Utah-seeded infrastructure expansion dataset collected July 13, 2026. The expansion began with therate.hec.utah.edu and cse-online.net. Country, ASN, and provider values are derived from IP-enrichment records and reflect the attribution data available at collection time. Stanford case data is not included in these aggregate figures.
Top 10 countries by observed IP count - Utah-seeded dataset
United States (US)
394 27.2%
Türkiye (TR)
388 26.8%
Germany (DE)
100 6.9%
Romania (RO)
79 5.5%
Ukraine (UA)
79 5.5%
Canada (CA)
76 5.2%
Netherlands (NL)
70 4.8%
United Kingdom (GB)
42 2.9%
France (FR)
30 2.1%
Malaysia (MY)
25 1.7%
Top 10 provider groups by observed IP count - Utah-seeded dataset
HostingDunyam
194 13.4%
AS-COLOCROSSING
146 10.1%
NETINTERNET
143 9.9%
TRANSIP-AS
44 3.0%
MFATIHASAN
43 3.0%
ASN-GIGENET
38 2.6%
OVH
37 2.6%
NETMINDERS
32 2.2%
THCProjects
32 2.2%
LIMESTONENETWORKS
28 1.9%
Top 10 autonomous systems - Utah-seeded dataset
AS212219
194 13.4%
AS36352
146 10.1%
AS51559
143 9.9%
AS20857
44 3.0%
AS215761
43 3.0%
AS32181
38 2.6%
AS16276
37 2.6%
AS51177
32 2.2%
AS7040
32 2.2%
AS24961
28 1.9%
Concentration and dispersion coexist. The United States and Türkiye together accounted for 782 records, or 54.0% of the expanded IP set. At the same time, the complete set was spread across 42 countries and 161 ASNs, making the graph operationally diverse rather than dependent on a single hosting environment.
Address-set “ballooning”
Of the 412 domain lookup records, 13 returned more than 50 addresses, 16 returned more than 40, and 4 returned more than 100 in the captured results. A large answer set is not inherently malicious. CDNs and large services can legitimately return many addresses, but it is an important signal when it appears behind a narrowly scoped, historical research hostname and includes a confirmed phishing source.
Top 15 country groups - detailed table
#
Country
Code
IPs
Share
ASNs
Domains
1
United States
US
394
27.2%
51
171
2
Türkiye
TR
388
26.8%
16
88
3
Germany
DE
100
6.9%
10
55
4
Romania
RO
79
5.5%
14
55
5
Ukraine
UA
79
5.5%
5
17
6
Canada
CA
76
5.2%
7
35
7
Netherlands
NL
70
4.8%
5
50
8
United Kingdom
GB
42
2.9%
14
41
9
France
FR
30
2.1%
4
30
10
Malaysia
MY
25
1.7%
3
31
11
South Korea
KR
24
1.7%
2
22
12
Vietnam
VN
15
1.0%
3
20
13
India
IN
14
1.0%
8
17
14
Lithuania
LT
12
0.8%
4
13
15
Indonesia
ID
9
0.6%
1
9
Top 15 provider groups - detailed table
#
Provider label
IPs
Share
Domains
1
HostingDunyam - HOSTING DUNYAM BILISIM TEKNOLOJILERI TICARET LIMITED SIRKETI, TR
Source: Utah-seeded infrastructure expansion dataset collected July 13, 2026; Zenodo DOI 10.5281/zenodo.21400689. The raw expansion completed with 0 pending lookups and contains 1,449 IP detail records and 412 domain lookup records. A small number of enrichment records contained errors or non-public addresses.
Visual evidence
Geographic and infrastructure maps
Both maps below are derived exclusively from the Utah-seeded infrastructure expansion dataset collected July 13, 2026. They do not include the Stanford case dataset. The underlying records are linked through Zenodo DOI 10.5281/zenodo.21400689.
Global IP distribution - Utah-seeded July 13 datasetIP records by country. Source: Utah-seeded infrastructure expansion dataset collected July 13, 2026. Zenodo DOI 10.5281/zenodo.21400689.
Global ASN distribution - Utah-seeded July 13 datasetASN distribution by country. Source: Utah-seeded infrastructure expansion dataset collected July 13, 2026. Zenodo DOI 10.5281/zenodo.21400689.
Relationship analysis
Network graphs
The two case-lineage diagrams below describe the Stanford and Utah incidents separately. The aggregate lineage composition that follows is derived only from the Utah-seeded infrastructure expansion dataset collected July 13, 2026. A reader should be able to distinguish the original message, connecting IP, university hostname, external CNAME target, initial address set, and secondary expansion.
University of Utah lineage
therate.hec.utah.edu CNAME ↓ cse-online.net 57 A records ↓ 5.175.188.80 SMTP connection ↓ Google
Stanford lineage
wholecellviz.stanford.edu CNAME ↓ wholecellviz.org 50 A records ↓ 50.6.197.216 SMTP connection ↓ Google
Utah-seeded lineage composition
The Utah-seeded graph contains 57 seed relationships, 2,074 A-record relationships, 16 AAAA relationships, and 1,340 PTR relationships. The maximum recorded depth was 10. These counts explain how the University of Utah seed expanded rapidly through repeated forward and reverse DNS relationships. Stanford case data is not included in these aggregate edge counts.
The methodology combines message-level evidence, DNS resolution, infrastructure enrichment, iterative graph expansion, manual review, and responsible disclosure. The Stanford and Utah incidents were investigated as separate cases. The aggregate expansion and visualizations were produced only from the Utah seed and are designed to preserve the distinction between what was observed directly and what was inferred from relationships.
1
Preserve the receiving evidence
Retain complete headers and, where available, the original message. Prioritize headers added by the receiving provider. Record the connecting IP, receiver timestamp, sender-presented HELO/EHLO identity, DNS-associated hostname, envelope sender, SPF result, DKIM result, and message routing.
2
Interpret the SMTP record conservatively
Separate the connecting IP from the sender-presented name and the parenthesized DNS hostname. Do not infer organizational ownership of the server solely from the hostname recorded by the receiver.
3
Reproduce the DNS chain
Resolve the institutional hostname, identify CNAME targets, capture returned A and AAAA sets, and confirm whether the SMTP source appears in the answer set. Preserve query output and collection timestamps.
4
Expand forward and reverse relationships
For each address, collect forward-associated domains and PTR names. For each newly observed domain, collect reverse address results. Record parent-child relationships, relationship types, and depth so that every node retains a lineage back to the seed. Do depth first search till no new nodes are discovered.
5
Enrich infrastructure records
Attach ASN, provider, netblock, and country data to public IP addresses. Summarize distribution by country, provider, and ASN. Retain errors and unknowns rather than silently discarding them.
6
Separate observed mail senders from all other associated nodes
For this study, nodes were divided into two broad categories: IP addresses directly observed sending phishing or spam email, and all other infrastructure reached through the investigation. The second category includes mail-capable systems, DNS rotators, web servers, secondary balloon domains, PTR-associated hosts, and shared-hosting relationships. These additional nodes were retained as investigative associations but were not comprehensively classified by function or maliciousness. Inclusion in the broader graph therefore does not establish that a node sent mail or participated knowingly in abusive activity.
7
Conduct manual validation
Review representative websites, DNS histories, authentication records, and infrastructure patterns. Identify alternative explanations such as shared hosting, stale DNS, compromised systems, or legitimate large-scale services.
8
Disclose to affected institutions
Provide the relevant header evidence and DNS relationship, invite technical context and correction, and avoid claiming compromise or participation without evidence. Record acknowledgment, response, remediation, and unresolved questions.
9
Classify the attribution condition separately from intent
Record whether the evidence establishes only DNS Attribution Contamination or also supports intentional DNS Attribution Laundering. Do not infer operator purpose solely from the technical effect of the DNS relationship.
Utah-seeded dataset snapshot
Dataset
Utah-Seeded DNS Attribution Laundering Infrastructure Expansion Dataset - July 13, 2026
Seed hostname
therate.hec.utah.edu
Seed CNAME target
cse-online.net
Scope
University of Utah-seeded expansion only; Stanford case data is excluded
These cases concern historical DNS associations, not evidence that the universities sent or authorized phishing. Both institutions acknowledged the evidence and the continuing associations were remediated. Neither institution confirmed nor disputed the study’s technical explanation.
Case study 1: Stanford University
wholecellviz.stanford.edu
Potentially obsolete or dangling CNAME
On February 28, 2026, Google received a phishing message from 50.6.197.216. The receiver-added header associated the connecting address with wholecellviz.stanford.edu, while the sender presented zemlak.bremmadoo.com during the SMTP transaction.
Received: from zemlak.bremmadoo.com
(wholecellviz.stanford.edu. [50.6.197.216])
by mx.google.com ...
The Stanford hostname was a CNAME to wholecellviz.org. A March 12, 2026 DNS snapshot showed approximately 50 addresses behind that target, including the confirmed SMTP source. The message passed SPF and DKIM for sender-controlled domains under holsotfit.us.com; those results did not authenticate Stanford.
The available evidence is consistent with a historical research hostname remaining connected to an external target whose ownership, control, configuration, or purpose later changed. The exact transition cannot be reconstructed from the surviving evidence. The complete email headers were retained, but the full message body is not currently available.
Disclosure outcome: Stanford accepted and acknowledged the submitted evidence. The CNAME had already been removed before the formal report. Stanford did not confirm or dispute the researchers’ technical characterization.
Directly observed evidence
Google recorded 50.6.197.216 as the SMTP client.
Google associated the address with wholecellviz.stanford.edu.
The Stanford hostname was a CNAME to wholecellviz.org.
The external target returned approximately 50 addresses, including 50.6.197.216.
SPF and DKIM authenticated sender-selected domains unrelated to Stanford.
Case study 2: University of Utah
therate.hec.utah.edu
Potentially obsolete or dangling CNAME
On July 3, 2026, Google received a phishing message from 5.175.188.80. The receiver-added header associated the address with therate.hec.utah.edu, while the sender presented nicolasprof.com during the SMTP transaction.
Received: from nicolasprof.com
(therate.hec.utah.edu. [5.175.188.80])
by mx.google.com ...
The Utah hostname was a CNAME to cse-online.net. The target returned 57 addresses, including the confirmed SMTP source. The envelope sender passed SPF for a sender-controlled subdomain under peakespeciate.net; that result did not authenticate the university.
The hostname was historically associated with TheRate, a late-1990s scientific application connected to the university’s Henry Eyring Center. This context supports—but does not prove—the interpretation that the DNS relationship outlived the original project or external dependency.
Disclosure outcome: The University of Utah accepted and acknowledged the supporting evidence. The CNAME was removed after disclosure. The university did not confirm or dispute the researchers’ technical characterization or provide a detailed account of its internal findings.
Directly observed evidence
Google recorded 5.175.188.80 as the SMTP client.
Google associated the address with therate.hec.utah.edu.
The Utah hostname was a CNAME to cse-online.net.
The external target returned 57 addresses, including 5.175.188.80.
The sender-controlled envelope domain explicitly authorized the source through SPF.
The CNAME was removed after disclosure.
Engagement history
Responsible-disclosure timeline
The timeline below is constructed from the current case-study records. Dates and institutional wording should be verified against the final correspondence archive before publication.
A phishing message was received from 50.6.197.216. Google associated the connecting IP with wholecellviz.stanford.edu.
A DNS snapshot showed wholecellviz.org resolving to 50 geographically dispersed addresses, including the confirmed source.
A phishing message was received from 5.175.188.80. Google associated the connecting IP with therate.hec.utah.edu.
Lappu AI initiated contact with the University of Utah Campus Help Desk.
Supporting evidence was submitted to the University of Utah.
The Stanford incident was reported and supporting information was exchanged through the university’s helpdesk. By this point, the Stanford CNAME had already been removed.
Communications with University of Utah personnel continued. The Utah CNAME was removed after disclosure;
Disclosure principles used in this study
Describe the technical relationship without implying that a university-operated server transmitted the message.
Provide supporting headers and DNS evidence to the appropriate security personnel.
Invite factual correction, institutional context, and an attributable statement.
Distinguish acknowledgment of evidence from confirmation of the researchers’ interpretation.
Document remediation without claiming causation unless the institution confirms it.
Withhold unnecessary sensitive details that could facilitate ongoing abuse or unfairly implicate unrelated parties.
Stanford University
Remediated
CNAME Deleted
University of Utah
Remediated
CNAME Deleted
Epistemic clarity
Confirmed findings versus reasonable inferences
Confirmed
Direct findings
Two phishing messages were received from the identified IP addresses.
Google recorded the university hostnames in the SMTP Received records.
Each university hostname was a CNAME to the identified external domain.
Each external target returned an address set containing the confirmed SMTP source.
The authenticated sender domains were unrelated to the universities.
The problematic DNS associations no longer exist.
Both universities acknowledged the evidence.
Reasonable inference
Strongly supported
The CNAME records were obsolete or potentially dangling.
The university names appeared because of the DNS relationships, not because the institutions sent the messages.
The external targets had become connected to distributed spam infrastructure.
The broader infrastructure displayed snowshoe-style characteristics.
The original research dependencies were no longer operating in their historical form.
Unresolved
Not established
Who controlled the external domains at the time of the messages.
Whether the domains expired, transferred, were compromised, or were deliberately repurposed.
Whether one actor controlled every related node.
Whether the operator intentionally sought association with university names, which is necessary to apply the “laundering” label conclusively to either case.
How many messages were sent through the infrastructure.
Whether every expanded domain or address was malicious.
Study boundaries
Limitations
The Utah-seeded graph is an investigative expansion, not a conviction list. DNS and hosting relationships can reflect shared infrastructure, historical records, compromise, misconfiguration, or unrelated co-tenancy. Stanford case data is not included in the aggregate graph.
DNS is time-sensitive. Records can rotate quickly. A later query may not reproduce an earlier answer, and historical data sources vary in coverage.
PTR and reverse-IP observations are not ownership proof. They identify names associated with an address but do not establish common control or intent.
The Stanford reconstruction is incomplete. Complete headers are available, but the complete message body is not currently available. The CNAME had already been removed before formal disclosure.
The Utah case is stronger but still does not reveal the operator. The complete message, source IP, DNS chain, SPF authorization, and post-disclosure removal are preserved, but domain-control history remains incomplete.
Infrastructure enrichment can be imperfect. Country, ASN, provider, and netblock attribution can change and may differ across sources.
HTTP content is only one signal. Similar templates, thin content, or advertising pages can support clustering but do not independently prove spam operation.
Message volume is unknown. Only mailbox providers or operators with broader telemetry may be able to estimate how many messages were transmitted by the identified systems.
Institutional acknowledgment is not endorsement. Both universities accepted the evidence and the DNS issues were remediated, but neither confirmed nor disputed the study’s interpretation.
The proposed terminology is provisional. We found no established public term that precisely describes this mechanism, but private intelligence, non-indexed publications, earlier incident reports, or alternative terminology may exist. The study invites prior-art correction.
Defensive guidance
Defensive recommendations
The defensive implications differ depending on which side of the attribution relationship an organization controls. Trusted domain owners must govern and monitor their DNS dependencies. Mail recipients, mailbox providers, and receiving security teams must detect attribution mismatches and avoid treating DNS-derived hostnames as proof of organizational ownership.
GovernanceOwnership, policy, lifecycle, and accountabilityDetectionMonitoring, correlation, and alertingIncident ResponseEvidence handling, attribution, disclosure, and remediation
Audience 1
Trusted domain owners
Universities, enterprises, government agencies, research institutions, and other organizations whose DNS namespaces may contain long-lived external dependencies.
GovernanceMaintain an inventory of external DNS dependencies.
Record the responsible department, project, record type, target domain, service owner, business purpose, creation date, review date, and expected retirement date. The inventory should include CNAMEs as well as delegated subdomains, MX records, and other externally controlled targets.
GovernanceMake DNS cleanup part of project and vendor decommissioning.
A project or external-service relationship should not be considered closed until its DNS records, certificates, hosting accounts, delegated services, and third-party dependencies have been reviewed and removed, transferred, or formally retained.
GovernanceRequire ownership attestation for long-lived academic and experimental namespaces.
Research projects often outlive their original teams, grants, and hosting arrangements. Periodic attestation should confirm that a named owner remains accountable for each externally delegated hostname.
GovernanceProvide a functional vulnerability-disclosure channel.
External researchers need a clear path to security and DNS personnel, an acknowledgment process, and a safe mechanism for submitting headers, DNS evidence, and other potentially sensitive material.
DetectionContinuously verify external target ownership and behavior.
Check whether targets remain registered, resolve as expected, use anticipated providers, and retain an address footprint consistent with the service’s documented purpose.
DetectionAlert on unexplained infrastructure expansion.
A narrowly scoped research or departmental hostname that begins resolving to dozens of addresses across countries, autonomous systems, or providers should trigger review.
DetectionMonitor institutional hostnames in unexpected SMTP contexts.
Where telemetry is available, search received-message datasets, passive DNS, abuse reports, and reverse-DNS observations for organizational hostnames appearing beside unfamiliar SMTP source addresses.
Incident ResponsePreserve evidence before changing or removing the record.
Capture DNS responses, timestamps, historical records, email headers, certificates, web observations, and relationship graphs before remediation so the exposure and any associated activity can be reconstructed.
Incident ResponseDocument the technical condition separately from operator intent.
Record whether the evidence establishes DNS Attribution Contamination, confirmed abusive use, or intentional laundering. Do not infer attacker intent solely from the existence of the DNS relationship.
Audience 2
Mail recipients and receiving mail providers
Mailbox providers, secure email gateways, enterprise mail teams, abuse desks, SOC analysts, and investigators evaluating messages received from externally operated infrastructure.
GovernanceTreat DNS-derived hostnames as infrastructure context, not authenticated identity.
Receiving policies, analyst guidance, and user-facing tools should not imply that the organization named in a PTR, forward-confirmed reverse-DNS result, or Received header necessarily operated or authorized the sending server.
DetectionDetect attribution mismatches.
Alert when a trusted organizational hostname appears in SMTP infrastructure context while SPF, DKIM, the envelope sender, the visible From domain, and the HELO/EHLO identity identify unrelated domains.
DetectionReconstruct the complete DNS relationship before attribution.
Correlate the SMTP source IP, PTR result, forward lookup, CNAME chain, terminal A or AAAA records, and collection timestamp. A trusted hostname should not be treated as ownership evidence without understanding that chain.
DetectionSeparate observed mail senders from the broader associated graph.
Distinguish IP addresses directly observed establishing SMTP sessions from mail-capable systems, DNS rotators, web servers, secondary balloon domains, PTR-associated hosts, and shared-hosting relationships discovered during expansion.
Incident ResponsePreserve receiver-added evidence and time-sensitive DNS state.
Retain complete headers, gateway logs, source IPs, receiver timestamps, authentication results, and contemporaneous DNS responses. Later DNS queries may not reproduce the state present when the message was received.
Incident ResponseAvoid over-attribution and notify the trusted domain owner.
Describe the observed SMTP and DNS relationship without alleging that the named organization operated the sender. Share the minimum evidence needed for the organization to investigate and remediate its DNS exposure.
Incident ResponseUse explicit evidence and confidence labels.
Separate confirmed SMTP sources, directly reproduced DNS relationships, broader investigative associations, reasonable inferences, and unresolved questions.
Incident ResponseSeparate contamination from proven laundering.
Use intent-neutral language during triage. Elevate the classification to DNS Attribution Laundering only when evidence supports deliberate exploitation or knowing retention of the trusted attribution.
Authorship and editorial record
Publication record
This section identifies responsibility for the study, provides the preferred article citation, and establishes how published revisions and corrections will be handled.
Author
Vivek Uppal Lappu AI Research
Vivek Uppal is the sole author of this study.
Reviewer
Tomislav Sakic
Reviewer credit acknowledges review of the study and does not transfer responsibility for the findings or conclusions from the author.
Suggested article citation
Uppal, Vivek. (2026). DNS Attribution Laundering: Legacy CNAMEs and Distributed Spam Infrastructure (Revision 1). Lappu AI Research. https://lappuai.com/research/dns-attribution-laundering/
Revision history
Revision
Publication date
Status
Summary
Revision 1
July 29, 2026
Forthcoming
Initial public release of the study.
Corrections policy
Lappu AI Research welcomes corrections, relevant prior art, and additional context that could improve the accuracy of this study. Correction requests may be sent to vivek@lappuai.com and should identify the passage or data at issue and, where possible, include supporting evidence.
Review: Submissions will be evaluated against the retained message, DNS, infrastructure, correspondence, and dataset evidence. A request from an organization named in the study will be considered carefully but will not be accepted or rejected solely because of its source.
Minor edits: Typographical, formatting, accessibility, and link corrections that do not change the study’s meaning may be applied without creating a new numbered revision.
Material corrections: Changes to evidence, counts, attribution, interpretation, methodology, or conclusions will produce a new numbered revision. The revision history will state what changed, when it changed, and why.
Time-sensitive infrastructure: A later change in DNS, hosting, registration, or network state does not by itself invalidate a documented historical observation. Corrections will distinguish errors in the original record from legitimate changes that occurred after collection.
Preservation: Published revisions will not be silently replaced. Earlier revisions will remain available where practical, and any corrected version will link to or identify the revision it supersedes.
Serious errors or sensitive information: If evidence no longer supports a central finding, the study will carry a prominent correction or withdrawal notice. Information may also be redacted when continued publication would create a disproportionate privacy or security risk; any substantive redaction will be recorded in the revision history.
Reproducibility and citation
Data availability
The dataset underlying the aggregate infrastructure statistics, geographic maps, provider and ASN summaries, and expanded network relationships is the Utah-Seeded DNS Attribution Laundering Infrastructure Expansion Dataset - July 13, 2026.
The dataset is a point-in-time investigative expansion that began with therate.hec.utah.edu and its CNAME target cse-online.net. Collection began at 2026-07-13T17:22:07.240073Z and completed at 2026-07-13T18:04:02.3870726Z. It contains 1,449 IP lookup records, 412 domain lookup records, and 3,487 lineage edges.
Included scope
University of Utah-seeded DNS and reverse-DNS expansion
IP, domain, lineage, country, ASN, and provider records
The source data for aggregate maps and statistical visualizations
A July 13, 2026 point-in-time infrastructure snapshot
Excluded or separate scope
The Stanford case is not included in the aggregate Utah-seeded dataset
The dataset is not a list of confirmed malicious assets
Case-specific IOC bundles are deferred to a companion publication
A reusable behavioral detection analytic is deferred to a companion publication
Suggested dataset citation
Uppal, Vivek. (2026). Utah-Seeded DNS Attribution Laundering Infrastructure Expansion Dataset - July 13, 2026. Lappu AI. Zenodo. https://doi.org/10.5281/zenodo.21400689.
At publication, the Zenodo record should identify the dataset license, version, file manifest, checksums, data dictionary, collection methodology, filtering applied to visualizations, and a statement that relationship inclusion does not establish malicious ownership or intent. Subsequent datasets should be published as linked Zenodo versions rather than silently replacing the cited snapshot.
Research record
References, evidence, and publication notes
Primary evidence retained
Complete headers for phishing messages.
The complete University of Utah-related phishing message.
Receiver-added Google Received headers.
SPF and DKIM authentication results.
DNS query output for the university hostnames and external targets.
The 50-address Stanford snapshot and 57-address Utah snapshot.
The Utah-seeded July 13, 2026 expansion dataset with IP, domain, infrastructure, and lineage records, assigned Zenodo DOI 10.5281/zenodo.21400689.
Reverse-DNS, reverse-IP, web-content, and infrastructure-enrichment observations.
Responsible-disclosure correspondence and remediation observations.
Dataset citation
Uppal, Vivek. (2026). Utah-Seeded DNS Attribution Laundering Infrastructure Expansion Dataset - July 13, 2026. Lappu AI. Zenodo. DOI: 10.5281/zenodo.21400689.
Terminology and standards references
RFC 8601, Message Header Field for Indicating Message Authentication Status: RFC Editor. The specification describes the iprev reverse/forward DNS test and cautions that its value as an authentication mechanism is limited.
Red Sift, The complete guide to SubdoMailing: SubdoMailing overview and examples. This provides a useful comparison because SubdoMailing uses a compromised subdomain as an authenticated sending identity.
Document exact dataset filtering used in visualizations and finalize the Zenodo README, manifest, license, and checksums.
Add the publication date and canonical article URL to the article citation and metadata.
Publication note: This report does not allege that Stanford University or the University of Utah operated the phishing servers, authorized the messages, knowingly participated in the spam network, or intentionally enabled DNS Attribution Laundering. It documents DNS relationships that caused institution-controlled hostnames to become associated with external infrastructure containing confirmed phishing senders and proposes terminology for the broader technique class.
