While analyzing spam messages as part of our email-security research, we discovered something unexpected: infrastructure sending unwanted email was being associated by a receiving mail system with a trusted University of Utah hostname.

The University of Utah was not sending the email, its domain was not authenticating the messages, and there was no evidence that the university had authorized or knowingly participated in the activity. Instead, a legacy DNS relationship was causing a trusted .edu hostname to become associated with unrelated external infrastructure that included an IP address we directly observed sending spam.

The university was not aware that this condition existed. We investigated the relationship, established the technical cause, disclosed our findings to the university, and the problematic DNS record was subsequently removed.

This case illustrates an important part of modern email security: protecting an organization's email requires looking beyond the messages it intentionally sends. We also need to understand how its domains and infrastructure appear in the broader email ecosystem.

The problem was visible from outside, not inside

Our investigation began as part of a broader effort analyzing spam messages and the infrastructure behind them. We were examining message headers, authentication results, sending systems, domains and infrastructure relationships to understand how unwanted email was being delivered.

During that work, one piece of infrastructure evidence stood out. Google's receiving mail infrastructure had recorded an SMTP connection containing this attribution:

Received: from nicolasprof.com
    (therate.hec.utah.edu. [5.175.188.80])
    by mx.google.com ...

The header contained three important pieces of information:

  • The connecting IP address was 5.175.188.80.
  • The SMTP system identified itself as nicolasprof.com.
  • Google associated that address with therate.hec.utah.edu.

That last hostname belonged within the University of Utah's trusted .edu namespace.

For an email-security investigation, that association immediately mattered. Receiving systems use hostnames, IP addresses, SMTP identities, SPF, DKIM, DMARC and other signals to build a picture of where a message came from and whether it should be trusted. The important question was not whether the University of Utah was sending spam. There was no evidence that it was.

The question was:

Why was infrastructure sending spam being associated with a University of Utah hostname?

Following the attribution chain

We investigated therate.hec.utah.edu and found that it did not resolve directly to infrastructure operated by the University of Utah.

Instead, it was a CNAME:

therate.hec.utah.edu
        |
        | CNAME
        v
cse-online.net

We then examined cse-online.net.

It resolved to 57 IPv4 addresses.

One of those addresses was:

5.175.188.80

That was the same IP address we had directly observed connecting to Google's mail infrastructure.

The relationship therefore looked like this:

therate.hec.utah.edu
        |
        | CNAME
        v
cse-online.net
        |
        | 57 A records
        v
5.175.188.80
        |
        | observed SMTP source
        v
Google

At that point, this was more than an unusual DNS configuration. It had become an email-security attribution problem. A hostname belonging to a trusted institution was being associated with infrastructure involved in sending unwanted email.

The University of Utah was not the sender

This distinction is central to the case.

There is no evidence that the University of Utah sent, authenticated, authorized or knowingly participated in the spam activity we observed. The University of Utah domain was not the authenticated sender, was not the envelope sender, was not the visible From domain, and was not providing DKIM authentication for the messages.

Instead, the .edu hostname appeared as infrastructure context associated with the connecting SMTP IP. The actual sender authentication pointed elsewhere.

The situation was therefore not:

University of Utah
        |
        v
sending spam

It was:

University-controlled hostname
        |
        v
external DNS dependency
        |
        v
unrelated infrastructure
        |
        v
IP observed sending spam

That distinction matters in email security because receiving systems see more than the visible From address. They also evaluate infrastructure signals that influence reputation, attribution and investigation. A trusted organization's hostname appearing in that context can create ambiguity even when the organization had nothing to do with sending the message.

A legacy dependency created a modern email-security problem

The hostname itself had a long history.

therate.hec.utah.edu appears to have been associated with TheRate, short for Theoretical Rates, a scientific application used to calculate thermal rate constants for gas-phase chemical reactions. The project was associated with the University of Utah's Henry Eyring Center and dates to the late 1990s. This historical context matters because the hostname had been created in a very different Internet environment, long before today's email authentication systems, reputation services and automated threat intelligence. At some point, the hostname came to point through a CNAME to cse-online.net. We cannot establish exactly when that CNAME was created, why it was created, how the external dependency evolved over time, or when the relationship became problematic.

What we can establish is the condition we observed:

A hostname within the University of Utah's trusted namespace was delegating resolution to external infrastructure that included a system directly observed sending spam.

That was enough to create an email-security concern.

Why the organization did not know it had a problem

This type of issue can be difficult for an organization to detect internally because many of the usual warning signs are absent. There was no compromised mailbox generating an alert. There was no obvious failure in the university's SPF, DKIM or DMARC configuration associated with these messages. There was no internal mail server that simply needed to be cleaned. From the perspective of DNS itself, the record continued to function.

The problem became visible only when we correlated activity occurring outside the organization:

    spam traffic
        |
        v
receiving-server telemetry
        |
        v
unexpected trusted hostname
        |
        v
infrastructure investigation
        |
        v
legacy external dependency

This is one reason external email-security visibility matters. Organizations generally know the systems they intentionally use to send email. They may have far less visibility into old hostnames, historical third-party dependencies and external infrastructure relationships that continue to influence how their infrastructure appears to receiving mail systems.

The University of Utah case was visible to us because we were examining the email ecosystem from the receiving side.

Email security is fundamentally an attribution problem

Modern email security depends heavily on answering a deceptively simple question:

Who actually sent this message?

SPF helps associate an envelope sender with authorized infrastructure. DKIM cryptographically associates a message with a signing domain. DMARC connects authenticated identities to the visible From domain. Receiving systems also examine IP addresses, SMTP identities, reverse DNS, reputation and other signals. Together, these mechanisms try to distinguish legitimate mail from impersonation, spoofing and abuse.

The Utah case demonstrates another dimension of that attribution problem. Even when the core authentication mechanisms do not implicate an organization, legacy infrastructure relationships can introduce the organization's trusted hostname into the attribution chain. That does not make the organization responsible for the email. But it creates ambiguity where security systems ideally need clarity.

Discovering the problem was the difficult part

Once we established the relationship, the remediation itself was straightforward.

Getting there required connecting information that normally lives in separate places:

  • spam messages and SMTP headers;
  • sending IP addresses and hostnames;
  • DNS relationships;
  • external infrastructure;
  • and email authentication evidence.

No individual data point told the whole story.

This is characteristic of much of the email-security work we perform today. The challenge is often not fixing a DNS record or updating an authentication policy. The challenge is discovering that a condition exists in the first place, determining whether it matters, and gathering enough evidence for corrective action.

From discovery to remediation

Once we had sufficient evidence, we contacted the University of Utah and provided our findings.

We showed the relationship between:

  • therate.hec.utah.edu;
  • the external CNAME target cse-online.net;
  • the 57-address infrastructure set;
  • and 5.175.188.80, the IP address directly observed sending spam to Google's mail infrastructure.

The university investigated the issue, and the CNAME was subsequently removed.

Before remediation, the relationship looked like this:

therate.hec.utah.edu
        |
        | CNAME
        v
cse-online.net
        |
        v
external infrastructure

After the record was removed, the University of Utah hostname no longer delegated resolution to cse-online.net. The unintended association was eliminated. The investigation required substantial analysis. The technical fix itself was comparatively simple. That contrast is important.

Many security problems are difficult not because remediation is technically complex, but because someone first has to discover the condition, understand why it matters and identify the organization affected by it.

The investigation led to a broader infrastructure study

Once we understood the relationship behind the Utah hostname, we continued investigating the infrastructure connected to cse-online.net. The 57-address response provided additional pivots through forward DNS, reverse DNS, hosting relationships, ASN information, infrastructure providers and other related domains. That work eventually produced the broader DNS Attribution Laundering research dataset.

The Utah-seeded point-in-time dataset collected on July 13, 2026 contains:

  • 1,449 IP lookup records
  • 412 domain lookup records
  • 3,487 lineage relationships
  • infrastructure spanning 42 countries
  • and 161 autonomous systems

Those numbers do not mean that 1,449 IP addresses were confirmed spam senders. The dataset represents an investigative infrastructure graph. Some addresses have direct mail observations, while others are connected through DNS, hosting, reverse DNS or related infrastructure evidence. We deliberately distinguish between observed email activity and infrastructure relationships discovered during investigation.

The broader lesson for email security

The lesson from this case is not simply to remove old DNS records. The larger lesson is that an organization's email-security posture includes more than the email systems it knowingly operates. Organizations need to understand how their domains and infrastructure appear to the rest of the email ecosystem. That includes traditional controls such as SPF, DKIM, DMARC, sender authorization, domain alignment and spoofing protection. It also means identifying unexpected relationships that can cause a trusted organizational infrastructure to appear in connection with systems the organization does not control.

A strong email-security program therefore needs to ask more than:

Are our legitimate emails authenticated correctly?

It should also ask:

Where else is our identity showing up, and could infrastructure outside our control cause recipients or security systems to associate activity with us that we did not originate?

Those are fundamentally email-security questions. DNS happens to be one of the places where the answers can hide.

From an unknown problem to a resolved one

The University of Utah case began with something the institution could not readily see from inside its environment: its trusted hostname was appearing in connection with unrelated email-sending infrastructure.

Our investigation turned that external signal into an explainable technical chain:

   spam activity
        ↓
receiving-system evidence
        ↓
unexpected University hostname
        ↓
legacy CNAME
        ↓
external infrastructure
        ↓
observed SMTP source

We identified the condition, established what it meant and, equally importantly, what it did not mean. We contacted the affected institution, and the problematic relationship was removed. That is the outcome we want from email-security research: not simply documenting an unusual technical phenomenon, but discovering a security problem an organization may not yet know it has and helping turn that discovery into remediation.

Organizations cannot remediate risks they do not know exist. Finding those risks is often the first and most important step toward making email more secure.

Complete research study:
DNS Attribution Laundering: CNAME-Assisted SMTP Attribution Laundering

Research dataset:
DNS Attribution Laundering — July 13, 2026 point-in-time dataset
DOI: 10.5281/zenodo.21400689