Open Relays Are Dead. Long Live Open Relays.

Most security pros will tell you the open mail relay went extinct with dial-up modems and Usenet. They were a plague of the late '90s, servers that blindly forwarded email from anyone to anyone, eventually blacklisted into oblivion. The consensus is that we fixed this. The consensus is wrong.

Just last week, I triaged a BEC attempt that slipped past multiple layers of security. The CEO impersonation was flawless, the payload was a link to a credential harvesting site on a newly registered domain, but the email itself was strange. It passed no authentication checks—SPF, DKIM, DMARC all failed—yet it flew right into the user's inbox. The sending IP belonged to a legitimate, small cloud provider with a perfectly clean reputation.

The server wasn't part of a botnet. It was a single, forgotten Linux box, a ghost in the machine. It was an open relay, a technique everyone thought was dead, repurposed for modern, high-stakes attacks. They've just changed their camouflage.

The New Relay Isn't Your Grandfather's Exchange Server

The classic open relay was an on-premise Microsoft Exchange 5.5 or Sendmail server, misconfigured by an overworked admin who didn't understand the `Allow relaying` checkbox. Today's relays are far more ephemeral and harder to pin down. They are cloud instances, containers, and even IoT devices.

Born in the Cloud, Abused by Attackers

Imagine a developer at a startup. She needs a way for her application to send transactional emails—password resets, welcome messages. She spins up a cheap EC2 instance, runs `apt-get install postfix`, and follows a five-year-old Stack Overflow post to get it working. That post might contain a line like `mynetworks = 0.0.0.0/0`, effectively telling Postfix, "Accept and forward mail from anyone." She tests it, it works, and she moves on. The server sits there, forgotten, a pristine SMTP server waiting to be abused.

For an attacker, this is gold. It launders their reputation. Sending a phish from a known-bad residential IP address is a fast track to the spam folder. But sending that same phish through this accidental relay in a reputable provider's IP space? The initial IP reputation checks pass. The mail has a much higher chance of landing in an inbox, giving the attacker a shot at fooling a user. The relay acts as a form of reputation arbitrage.

Hunting Relay Hops in Email Headers

You can't find these relays without reading the raw source of an email. The headers are the server-to-server conversation transcript, and the `Received:` headers are the most important part of that story. They trace the an email's journey from sender to receiver. The trick is knowing how to read them: from the bottom up.

Deconstructing the `Received:` Header Chain

Each Mail Transfer Agent (MTA) that handles a message prepends a new `Received:` header to the top. So the first hop is at the bottom of the list, and the final delivery into the mailbox is at the very top. A typical header looks complex, but it follows a simple pattern defined in RFC 5321.

Received: from mail-relay.somecloud.com (mail-relay.somecloud.com [198.51.100.25])
by mx.google.com with ESMTP id some-id-here
for <recipient@example.com>
(version=TLS1_3 cipher=...);
Tue, 14 May 2026 14:20:01 -0700 (PDT)

The key fields are `from` (the server that connected) and `by` (the server that received the connection). In a normal flow, the `from` server is the upstream MTA. But in a relay scenario, you'll see something jarring.

Spotting the Anomalies

An open relay reveals itself when an MTA accepts a connection from one client but then tells the *next* server it received the mail from a completely different, unrelated source. Look for a `Received:` header created by a trusted server (like your own mail gateway or Microsoft/Google) that documents receiving mail from an IP you don't recognize. Then look at the `Received:` header directly below it. If that header shows that the mystery IP received the mail from somewhere else entirely—like a residential IP address (`adsl-1-2-3-4.someisp.net`)—you've found your relay. The middle server (`mail-relay.somecloud.com` in our example hunt) accepted the mail from the residential IP and forwarded it, hiding the true origin from its next hop.

This is almost always accompanied by a failed SPF check in the `Authentication-Results` header. The check will show a `permerror` or `fail` because the open relay's IP (198.51.100.25) is not listed in the SPF policy for the domain in the `MAIL FROM` command. DKIM (RFC 6376) might still pass if the relay didn't modify the email body, but DMARC (RFC 7489) alignment will almost certainly fail because the authenticated domain (the relay's domain) doesn't match the one in the visible `From:` header. This combination of failed authentication and a suspicious hop is the smoking gun.

The Accidental Relay Farm

The threat isn't a shadowy cabal of relay operators. It's death by a thousand cuts from widespread, unintentional misconfiguration across cloud and IoT landscapes.

Cloud Compute: A Double-Edged Sword

The ease of deploying compute on platforms like AWS, Google Cloud, and DigitalOcean is a major driver of this problem. A developer can get a server with a public IP in minutes. Need to send email notifications? A quick search leads to tutorials for Postfix or Exim. The goal is to make the application work, not to harden an MTA according to decades of email security best practices. Authentication, relay restrictions—these are afterthoughts.

The result is thousands of servers, each a potential relay. They aren't part of a botnet; their owners are legitimate customers. This makes shutting them down a delicate process for providers, who must distinguish between a compromised machine and a simply misconfigured one.

When Your Smart Fridge Sends Phish

It gets weirder. Many embedded systems—network-attached storage (NAS), DVRs, routers, even 'smart' appliances—include a basic SMTP client to send status alerts. When these devices are exposed to the public internet with default credentials, they can be configured by an attacker to act as a relay. The owner of the device will never know.

These IoT relays are particularly dangerous. They are rarely updated, almost never monitored, and their owners are typically consumers who have no idea what SMTP is. Tracking down and disabling these is a nightmare, as the 'owner' is often just a residential ISP customer.

From Detection to Takedown

When you find an open mail relay, your job isn't done. Simply blocking the IP address on your firewall is a temporary fix that does nothing for the rest of the internet. The goal is to get the relay shut down at the source. This is about ecosystem hygiene.

Who Owns the Abused Server?

Your first step is reconnaissance. Run a `whois` query on the relay's IP address. This won't give you the name of the developer who configured Postfix, but it will give you the owner of the network block, which is usually a large hosting provider or ISP.

Look for an `abuse-c` handle or an `abuse@` email address in the `whois` output. This is your point of contact. For major cloud providers like AWS or Azure, they have dedicated web forms for reporting abuse, which are generally more effective than email.

Crafting an Effective Abuse Report

When you file your report, be precise and professional. The person reading it is likely a overworked analyst who needs actionable data, not a novel.

Subject: Open Mail Relay Activity from IP 198.51.100.25

To whom it may concern,

The server at IP address 198.51.100.25 is operating as an open mail relay. On Tue, 14 May 2026 at 14:20:01 UTC, it forwarded an unauthenticated message from an external source to our mail infrastructure. The relevant `Received` header shows your server accepting the connection and relaying it. We request that you investigate this host and disable the open relay configuration.

Full headers are attached for your review. — Example Abuse Report

Always attach the full email, with all headers, as a `.eml` or `.txt` file. This is your primary evidence. Don't paste headers into the body of the email unless they're a short, illustrative snippet. Clarity and evidence make it easy for the provider to validate your claim and take action, which is what you want.

The takeaway

Open relays never really went away; they just blended into the background noise of the modern internet. Their function has shifted from high-volume spam cannons to targeted tools for bypassing reputation-based security controls in attacks like business email compromise. They represent a seam in our defenses, exploiting the trust we place in legitimate infrastructure.

The ability to dissect a raw email header is no longer an esoteric skill for grizzled postmasters. It's a fundamental requirement for any security analyst. It's the only way to find the ground truth and reconstruct an attack chain. While tools like MailSleuth.AI can surface these anomalies automatically, knowing how to manually verify the hops and understand the underlying mechanics is what separates a good analyst from a great one.