InboxRatio
Check your domain

Glossary term

Open relay: the mail server that forwards for anyone

What an open relay is

An open relay (or open mail relay) is a mail transfer agent configured to accept and forward email from any sender to any recipient, with no authentication and no restriction to its own users or domains. Anyone on the internet can connect to it over SMTP, submit a message claiming any origin, and have the relay deliver it onward under the relay's own IP address and good name — for as long as that name stays good.

Relaying itself is legitimate and defined behavior: RFC 5321 describes how a server may accept mail addressed elsewhere and pass it along the route. The failure is the missing decision. A properly run relay carries mail for parties it knows — its own users, authenticated clients, specific downstream domains. An open relay carries mail for whoever shows up, which in practice means it carries spam within hours of being discovered, because scanning for open relays is among the oldest automated abuse behaviors on the internet.

In the 1990s open relays were common, partly by default configuration and partly by an early-internet ethos of forwarding mail cooperatively. Mass spamming ended that era: modern MTA software ships closed by default, and the anti-abuse ecosystem treats an open relay as an incident, not a preference.

How an open relay differs from a legitimate relay

Every mail path involves relaying; the difference is authorization at each hop.

An authorized relay knows why it is carrying each message. An ESP's MTAs relay for authenticated customers; a corporate smarthost relays for machines inside its network; a backup MX relays inbound mail for domains it has agreed to serve. Each acceptance is grounded in a relationship the server can verify — credentials, network origin, or a configured domain list.

An open relay has no such grounding: RCPT TO succeeds for foreign destinations from unauthenticated, unknown sources. The message then leaves the relay carrying the relay's IP as its origin, so every receiver-side judgment (blocklists, IP reputation, rate decisions) attaches to the relay operator, not to the spammer who used it.

A related but distinct hazard is the open proxy or compromised host used to send mail; the effect on the abused party is similar, but the fix is different (patching and access control rather than MTA relay rules). And a server that accepts mail then bounces it to forged senders creates backscatter — a cousin failure with its own entry.

How an open relay happens and how it is found

The misconfiguration. Typical routes: relay restrictions loosened during troubleshooting and never restored; an internal-network trust range that accidentally includes public addresses; an application server whose bundled MTA defaults were never reviewed; or SMTP authentication that silently accepts any credentials. The server's operators usually learn about it from the outside.

The discovery. Abuse actors scan address space for port 25 continuously and probe with relay tests — attempts to send from a foreign address to a foreign address. Anti-abuse organizations run the same tests defensively. The window between becoming open and being exploited is best measured in hours.

The listing. Blocklist operators treat verified open relays as a listing basis. Spamhaus documents policy-based listings for insecure and abusable infrastructure, and open relays are the founding example of the class; historically, dedicated relay blocklists existed for nothing else. Once listed, the relay's IP starts collecting 5.7.1 rejections at receivers that consult those lists — visible in SMTP reply codes naming the list, and verifiable with the blacklist checker.

The industry position. M3AAWG, the messaging anti-abuse working group, has long recommended that operators manage port 25 traffic and close relay paths as a baseline anti-abuse control; ISPs blocking outbound port 25 for consumer connections is one downstream effect of that consensus. Running a relay open is not a gray area anywhere in current practice.

Open relays and your deliverability

Most senders will never operate one, but the topic touches deliverability from three directions.

If it is your server, it is your outage. An exploited relay burns the IP's reputation within days: blocklist entries, throttles, then outright refusals for your legitimate mail traveling the same path. Cleanup means closing the relay, draining the abuse, then working delisting processes per list, each with its own evidence requirements. Sender reputation rebuilds on the timescale of weeks, not the afternoon the config took.

Legacy blocklist entries outlive the incident. IPs with an open-relay history circulate in old lists and reputation datasets. When acquiring address space or standing up infrastructure on a dedicated IP, part of due diligence is checking what the address did in a previous life.

The rule shapes the modern rules. Requirements you meet daily (authenticated submission, SPF authorizing specific senders, receivers scoring the connecting IP) are in part the ecosystem's long response to the open-relay era. The design assumption everywhere is that relaying is accountable, which is why anonymous paths score so badly.

Limitations and failure modes

Testing from the inside. From within your own network, relaying is supposed to work, so an internal test proves nothing. Relay testing must originate from an outside address attempting foreign-to-foreign delivery; only that reproduces what scanners see.

Closing the front door, leaving the side door. Common partial fixes: relay closed on port 25 but open on 587 with broken authentication; a webmail or application endpoint that accepts arbitrary recipients; a misconfigured backup MX accepting mail for domains it does not serve then forwarding onward. An open relay is a behavior, not a port.

Assuming default equals safe forever. Defaults are closed today, but configuration drifts: migrations, copied configs from old wikis, "temporary" exceptions. Periodic external relay testing belongs in the same hygiene rotation as certificate expiry checks.

Confusing relay abuse with compromised credentials. If spam leaves your server via an authenticated account, the relay is doing its job for a stolen identity — a password and access-control incident, not a relay-rule incident. The blocklist consequences look identical; the remediation differs entirely.

Delisting before fixing. Blocklist operators generally re-test and re-list rapidly if the underlying openness persists. Sequence matters: verify closure from outside, drain queued abuse, then request delisting with the fix documented.

Forgetting the accept-then-bounce trap. A closed relay can still misbehave by accepting mail for invalid users and bouncing to forged senders, generating backscatter that earns its own class of listings. Reject at SMTP time; the open-relay fix and the backscatter fix are the same instinct applied at two stages.

Related terms

mail transfer agent, SMTP, backscatter, IP reputation, SMTP reply codes, sender reputation, SPF record, dedicated IP.

Frequently asked questions

What exactly makes a relay "open"? It forwards mail from unauthenticated, unknown sources to destinations it has no responsibility for. Neither the sender nor the recipient needs any relationship with the server — that absence of authorization is the whole definition.

Are open relays still a real problem? Far rarer than in the 1990s, but scanning for them never stopped, and misconfigurations still create them — especially on application servers with bundled MTAs. The consequences arrive as fast as ever.

How do I check whether my server is an open relay? From a network outside your own, attempt to send a message through the server from a foreign address to a foreign address; a properly closed relay refuses at RCPT TO. Then check your IPs against public blocklists with the blacklist checker.

Will an open relay get my IP blocklisted? Reliably, once discovered and exploited — which is a matter of hours to days. Policy-based lists target the openness itself; trap-fed lists catch the spam that flows through it. Both attach to your IP, not the spammer.

How do I recover after an open-relay incident? Close the relay and verify from outside, flush abusive queue contents, then pursue each list's delisting process with the fix documented. Expect reputation recovery at major receivers to lag the delistings.

Is relaying ever legitimate? Constantly — it is how mail works. Smarthosts, ESP infrastructure, backup MX hosts and forwarding services all relay. The requirement is that each hop knows who it is carrying mail for, via authentication, network origin or configured agreements.

If you operate anything that speaks SMTP (including that forgotten application server with a bundled mailer), schedule an external relay test today and run your IPs through the blacklist checker. Finding the problem yourself costs minutes; letting a scanner find it first costs weeks.

Sources