SMTP Relay Explained: How It Works, Open Relay Risks & Setup

What Relay Actually Means in an Email's Journey

Very few emails travel directly from a sender's mail client straight to the recipient's mailbox in a single hop — almost every message passes through at least one, and often several, intermediate servers along the way, and each of those intermediate hops is performing relay: accepting a message it isn't the final destination for, and forwarding it onward toward the next step in its journey. A typical path might look like: your mail client submits a message to your provider's submission server (authenticated, on port 587 or 465), that provider's outbound infrastructure then relays the message to the recipient's mail server (on port 25, having looked up their MX records), and that recipient's server performs final delivery into the actual mailbox. The middle step in that chain — provider to recipient — is relay in its purest, most legitimate form, and it's this exact mechanism that, left unrestricted, became one of the most exploited weaknesses of early internet mail infrastructure.

The Historical Open Relay Disaster, Briefly

Through the 1990s and into the early 2000s, it was extremely common for mail servers — many run by small organizations, universities, and even early ISPs — to accept and relay mail from absolutely anyone, for any destination, with no authentication or restriction whatsoever. This wasn't originally a security oversight so much as a reflection of the internet's early, more trusting culture; the assumption that a connecting server was acting in good faith simply hadn't been seriously challenged yet at the scale it eventually would be. As spam became commercially lucrative, spammers rapidly realized that open relays let them send enormous volumes of unsolicited mail that appeared to originate from someone else's server and reputation entirely, hiding their own identity and sending infrastructure while borrowing the (initially clean) reputation of the exploited relay. Within a relatively short period, essentially every unrestricted, discoverable open relay on the internet was actively being abused, sometimes within hours of being detected by automated scanning tools built specifically to find them. This drove the mail server software industry to fundamentally rethink default configurations — restricting relay by default became the new standard, and remains the standard today specifically because of how catastrophically the earlier, more permissive default played out in practice.

How Modern Servers Prevent Open Relay Abuse

A properly configured modern mail server typically layers several of these mechanisms together rather than relying on just one, since each addresses a slightly different threat scenario — authentication alone, for instance, doesn't prevent abuse from a genuinely compromised but valid account, which is exactly what rate limiting is designed to catch, and no single layer on its own has historically proven sufficient against a determined or automated abuser working at scale.

Legitimate Relay Configurations

Relay itself isn't inherently a security problem — it's an essential, everyday function of how email works at all — the problem is specifically unrestricted, unauthenticated relay open to anyone. Legitimate relay configurations are extremely common and take a few standard forms. A "smart host" configuration routes an organization's outbound mail through a designated relay server — often a specialized provider — rather than each individual application or server attempting direct delivery itself, centralizing deliverability management, reputation, and policy enforcement in one place. An internal relay might exist within a larger organization, where individual departments or applications send through a central internal mail hub before that hub relays outward to the broader internet using its own carefully managed reputation and authentication. Third-party transactional email providers essentially function as a specialized, professionally managed relay service, accepting authenticated mail from an application and handling the complexities of deliverability, reputation and compliance on the sender's behalf.

Third-Party Relay Providers vs Self-Hosted Relay

How Automated Scanners Find Open Relays Today

It's worth understanding the actual mechanics of how an open relay gets discovered and abused, since the speed involved is genuinely surprising to anyone who assumes an obscure, low-traffic server is somehow safer by virtue of being unnoticed. Automated scanning tools — some run by security researchers cataloging vulnerable infrastructure, many more run directly by spam operations — continuously and systematically probe wide swaths of IP address space specifically looking for exactly the behavior an open relay exhibits: a server on port 25 that accepts a RCPT TO command for a domain it doesn't host, without requiring authentication first. These scans aren't targeted at specific, well-known organizations; they're broad, indiscriminate sweeps that will eventually reach any publicly reachable mail server regardless of how small or obscure the organization behind it is. Once discovered, an open relay is typically added to automated abuse tooling within hours, sometimes minutes, and begins receiving relay requests from spam-sending infrastructure looking to exploit exactly this kind of unrestricted server. This is precisely why "it's a small server nobody would bother targeting" is a dangerous assumption — the targeting isn't manual or selective, it's automated and comprehensive, and obscurity offers essentially no real protection against it, a lesson that has been relearned the hard way by countless small organizations who assumed their low profile was itself a form of security.

The Downstream Consequences of Being Discovered as an Open Relay

Beyond the immediate abuse itself, being discovered and exploited as an open relay carries a cascade of downstream consequences that can significantly outlast the initial incident. Major reputation and blocklist services — used by the vast majority of receiving mail servers worldwide to filter incoming mail — actively track and list IP addresses observed sending spam, including relay abuse traffic passing through a compromised open relay. Once an IP address lands on one or more of these blocklists, legitimate mail sent from that same server (including entirely unrelated, genuinely legitimate mail from the organization that owns it) can be rejected or heavily filtered by receiving servers checking those same blocklists, sometimes for a period of days or weeks even after the underlying open relay vulnerability has been fixed, since blocklist removal typically requires an explicit delisting request and review process rather than an automatic, instant reversal once the immediate cause is corrected. Organizations that have experienced this firsthand often describe the reputation recovery process as considerably more painful and time-consuming than the technical fix for the open relay misconfiguration itself, which reinforces why prevention — correct configuration from the start, and periodic testing thereafter — is so much more valuable than remediation after the fact.

Distinguishing True Open Relay From Adjacent Misconfigurations

That last row is worth specific attention, since it represents one of the more common real-world variants of accidental open relay exposure — not a complete absence of restriction, but a restriction so loosely scoped that it fails to meaningfully restrict anything in practice, which is functionally equivalent to no restriction at all from an abuse perspective.

Mail Server Software Defaults and What Changed

Postfix's own origin story is a useful illustration of how seriously the industry took this lesson: it was explicitly designed, in part, as a security-conscious alternative to Sendmail's historically more permissive and complex configuration model, with secure, restrictive defaults baked in as a core design principle from the outset rather than bolted on afterward.

Relay Configuration in Cloud and Managed Hosting Environments

Organizations using managed or cloud-hosted mail infrastructure — rather than administering raw mail server software themselves — still need to understand relay concepts, even though the underlying configuration is largely handled by the provider, because misconfigurations at the application or account level can still create relay-adjacent problems. A common example: an application configured with overly broad sending permissions on a shared relay account might inadvertently allow sending on behalf of domains it shouldn't be authorized for, which isn't a classic open relay in the traditional server-configuration sense, but produces a similar practical risk — unauthorized use of sending infrastructure and reputation. Reviewing exactly which domains and sending patterns a given relay account or API key is authorized for, and scoping those permissions as narrowly as the actual use case requires, is the cloud-era equivalent of the traditional open relay restriction checklist, even though the underlying mechanism looks quite different from directly configuring a self-hosted server's relay rules.

Legal and Reputational Dimensions of Relay Abuse

Beyond the purely technical consequences already covered, organizations whose infrastructure is discovered relaying spam — even unknowingly, due to a configuration oversight rather than any intentional wrongdoing — can face genuine reputational and, in some jurisdictions or contractual contexts, legal exposure. Hosting providers frequently include acceptable use policies that explicitly prohibit operating an open relay, and discovering one on a customer's infrastructure can result in service suspension pending remediation, sometimes with little advance notice given the urgency abuse situations typically carry. Organizations operating under specific regulatory or compliance frameworks (particularly those involving customer data or communications) may also need to document and report security incidents involving unauthorized use of their mail infrastructure, adding an administrative burden well beyond the purely technical fix. None of this is meant to be alarmist — properly configured relay restriction, verified periodically, avoids essentially all of this exposure — but it's useful context for understanding why relay security receives the level of attention and default-restrictive design philosophy it does across the mail server software industry.

Configuring Relay Restrictions: A Practical Checklist

That last row matters more than it might initially seem — a relay configuration that defaults to permissive behavior for any case not explicitly handled is a latent open relay waiting for an edge case or oversight to trigger it, while a configuration that defaults to restrictive behavior fails safely even when something wasn't explicitly anticipated during setup.

How to Test Whether Your Server Is Accidentally an Open Relay

Testing relay restriction directly is the only reliable way to confirm a configuration is actually working as intended, rather than trusting documentation or assumed defaults. From a connection that should not be authorized — an external network, without providing credentials — attempt to send a test message through your server addressed to a domain your server doesn't host. A properly restricted server should refuse this attempt, typically with a "relay access denied" or similar error, at the RCPT TO stage of the SMTP conversation. If the server instead accepts the message and appears willing to forward it, that's a serious, immediate configuration problem requiring urgent correction, since it means the server is currently exploitable exactly as historical open relays were. Numerous free, public open relay testing services exist specifically for this purpose, and running a periodic check — not just once at initial setup — is good practice given how a subsequent configuration change could inadvertently reopen a restriction that was previously correctly locked down.

DKIM and Relay: A Configuration Detail Worth Getting Right

When mail passes through a third-party relay provider, a subtle but important question arises: whose DKIM key signs the outgoing message — yours, or the relay provider's? Some relay configurations sign with the provider's own DKIM key by default, which can still pass DMARC evaluation if the domain's DMARC record is configured with relaxed alignment and the provider is a properly authorized sender, but it means the cryptographic proof of authenticity is tied to the provider's infrastructure and reputation rather than your own domain's directly. Many organizations prefer configuring their relay provider to sign with their own domain's DKIM key specifically, giving them full, direct control over their domain's authentication posture rather than depending on a third party's signing practices remaining correctly configured indefinitely. Check your specific relay provider's documentation for how DKIM signing is handled and whether custom domain signing is supported and recommended for your use case, since this single configuration choice has meaningful downstream implications for DMARC alignment reporting and how confidently a receiving server can attribute a message's authenticity directly to your organization rather than to an intermediary.

How Relay Rate Limiting Actually Gets Implemented

Beyond a simple authenticated-or-not binary decision, mature relay infrastructure typically implements rate limiting as a genuinely important secondary layer of protection, addressing a scenario authentication alone can't solve: a legitimate, correctly authenticated account that's been compromised, or an application with a bug causing it to send far more mail than intended. Rate limiting can be applied at several different granularities simultaneously — per-account limits (a given set of credentials can send no more than X messages per hour), per-IP limits (a given source IP can initiate no more than Y connections or messages in a window), and per-recipient-domain limits (protecting against a single sender overwhelming one specific destination, which can itself trigger reputation problems with that destination). A well-configured relay service typically applies graduated responses as limits are approached or exceeded — temporary throttling before an outright block, alerting administrators of unusual volume before automatically suspending an account, and clear, actionable error messages (typically 4xx temporary failures) rather than silent message dropping, so a legitimate sender hitting a limit understands what happened and can address it rather than simply losing mail with no indication why.

Relay Authentication Models Beyond Simple Username and Password

While SMTP AUTH with a username and password remains the most common relay authentication model, especially for smaller-scale or self-hosted setups, several alternative or complementary models are worth understanding for more sophisticated relay configurations. IP-based trust, already covered, works well for stable, known infrastructure but doesn't scale well to dynamic or cloud-hosted sending sources where the IP address might change. API-key-based authentication — common among transactional email providers — functions similarly to a password but is typically designed to be more easily scoped, rotated, and revoked independently per application or integration, without needing to change a shared account password that might affect multiple integrations simultaneously. Mutual TLS (client certificate authentication) represents a more rigorous model where the connecting client presents a cryptographic certificate as proof of identity, rather than a shared secret like a password, offering stronger guarantees against credential theft since the private key never needs to be transmitted at all, though it requires more sophisticated certificate management infrastructure than simpler password or API-key models and is correspondingly less common outside of larger, security-mature organizations that already have the supporting certificate lifecycle tooling in place for other purposes.

Monitoring Relay Traffic for Early Abuse Detection

Beyond preventing unauthorized relay in the first place, mature relay operations typically implement ongoing monitoring specifically designed to catch abuse of legitimately authorized access — the scenario where credentials are valid but being misused, whether through compromise or a misconfigured integration sending far more than intended. Useful signals to monitor include sudden, unexplained volume spikes from a specific account relative to its historical baseline, an unusual spread of recipient domains inconsistent with an account's typical sending pattern (a transactional account that normally sends to a narrow set of customer domains suddenly sending broadly across many unrelated domains, for instance), and a rise in bounce or complaint rates associated with a specific account's traffic, which often indicates either a data quality problem or, in more concerning cases, genuinely unauthorized use. None of these signals alone definitively proves abuse, but a combination of several appearing simultaneously for a given account is a strong indicator worth immediate investigation rather than waiting for an external report (like a blocklisting) to force the issue.

Relay Considerations for Multi-Tenant and SaaS Platforms

Software-as-a-service platforms that send mail on behalf of their own customers — a CRM platform sending customer emails, a marketing automation tool sending campaigns, an e-commerce platform sending order confirmations — face a distinct and genuinely harder relay challenge than a typical single-organization setup: they need to relay mail on behalf of many different customers, potentially claiming many different sending domains, while preventing any individual customer from abusing that shared infrastructure in a way that damages the platform's overall sending reputation for every other customer sharing it. This typically requires per-customer rate limiting and monitoring (as covered above, but applied per-tenant rather than per-organization), domain verification processes confirming each customer genuinely controls whatever sending domain they claim before mail is relayed on their behalf, and often IP pool segmentation, where different reputation tiers or customer categories send from different dedicated IP ranges specifically to contain the reputation impact if any single tenant's mail practices cause problems, rather than letting one bad actor's behavior affect the platform's entire shared sending reputation at once.

Expert Tips for Safe Relay Configuration

Real-World Use Cases

Final Word: Relay Is Infrastructure, Treat It Like Infrastructure

The recurring theme throughout this guide is that relay — despite being an invisible, largely automatic part of how every email travels — is genuine infrastructure carrying real security and reputation stakes, not a configuration detail that can be set once during initial setup and safely forgotten about afterward. The organizations that avoid open relay incidents and reputation damage aren't the ones that got lucky; they're the ones that treated relay restriction as an ongoing operational responsibility — tested periodically, monitored for abuse of legitimate access, and reviewed whenever the surrounding infrastructure changes, whether that's a new mail server deployment, a cloud migration, or a new SaaS integration granted sending permissions. Given how quickly automated abuse tooling finds and exploits any genuine gap, and how disproportionately painful the reputation recovery process is compared to the relatively simple preventive checks covered throughout this guide, relay security is one of the clearer cases in email infrastructure where a modest, consistent ongoing investment in verification pays for itself many times over compared to the alternative.

Real-Time Blackhole Lists and Their Role in the Open Relay Story

No discussion of open relay history is complete without covering the tooling that emerged specifically to combat it, since this tooling remains foundational to how spam filtering works even today, long after open relay abuse itself became far less common. Real-time Blackhole Lists (RBLs), sometimes called DNS-based Blocklists (DNSBLs), emerged directly in response to the open relay epidemic — community-maintained, continuously updated lists of IP addresses observed sending spam, including relay-abused open relays, queryable in real time by any receiving mail server as part of its own spam filtering decision. A receiving server checking an incoming connection's source IP against one or more RBLs could reject or heavily filter mail from any IP appearing on the list, creating a strong, tangible incentive for organizations to fix an open relay quickly once discovered and listed, since the alternative was watching all of their legitimate mail get rejected by a growing share of the internet. This mechanism — external, community-driven reputation tracking with real, immediate consequences for listed IPs — proved so effective that it became a permanent fixture of email infrastructure rather than a temporary response to a specific historical problem, and modern email reputation and blocklist services descend directly from this same basic model, even as the specific threats they're tracking have evolved considerably since the original open relay era.

Related Reading

For the specific error codes you'll encounter when relay is correctly restricted, see SMTP Connection Errors. For the authentication mechanisms that gate legitimate relay access, read SMTP Authentication. For which port relay traffic typically uses, see SMTP Ports Explained. For the encryption layer protecting relay credentials in transit, read SMTP TLS vs SSL. For a broader troubleshooting framework if your relay configuration isn't behaving as expected, see SMTP Troubleshooting. To test your own relay server's connectivity and behavior directly, use the SMTP Tester.