Open Mail Relays: Security Risks and How to Test Your Server
An open mail relay is an SMTP server configured to accept and forward email from any sender to any recipient, regardless of whether either party is local. In the early days of the internet this was normal. Today, it is one of the most dangerous misconfigurations a mail server can have. This guide explains how open relays work, why they are a critical security risk, and how to detect and fix them.
What Is an Open Mail Relay?
An open mail relay (also called an open relay or third-party relay) is an SMTP server that allows anyone on the internet to send email through it, without requiring authentication or verifying that the sender or recipient belongs to a local domain. When a server is an open relay, any external party can connect to port 25 and instruct it to deliver messages to arbitrary destinations.
In the 1980s and 1990s, open relays were the default configuration. Email was a small, trusted network and relaying was a convenience feature. As the internet grew and spam became a massive problem, open relays became the primary vehicle for delivering unsolicited bulk email. By the early 2000s, running an open relay was universally considered a serious misconfiguration.
Why Open Relays Are Dangerous
Operating an open relay, even unknowingly, exposes your organization to several severe consequences:
Spam Amplification
Spammers actively scan the internet for open relays. Once they find one, they use it to send millions of spam messages. Your server becomes the delivery engine, meaning the spam appears to originate from your IP address and domain. This can happen within hours of a misconfiguration being deployed. Spammers use automated tools that can push hundreds of thousands of messages through a single relay in a day.
IP and Domain Blacklisting
Once your server is used to relay spam, it will quickly be added to DNS-based blacklists (DNSBLs) such as Spamhaus, Barracuda, and SORBS. Being blacklisted means that legitimate email from your domain will be rejected or sent to spam folders by virtually every major email provider. Delisting can take days to weeks and requires proving that the relay has been closed. Use our Blacklist Checker to see if your server is already listed.
Resource Exhaustion
Relaying spam consumes server resources: CPU, memory, bandwidth, and disk I/O. A server handling millions of spam messages will slow down dramatically, potentially causing outages for legitimate services. Queue backlogs can fill disk partitions, and the constant connection churn can exhaust available file descriptors and socket connections.
Legal and Compliance Risks
In many jurisdictions, being an open relay that facilitates spam can create legal liability. The CAN-SPAM Act, GDPR, and various national anti-spam laws hold infrastructure operators partially responsible when their systems are used to distribute unsolicited email. Your ISP or hosting provider may also terminate your service for violating acceptable use policies.
Reputation Damage
Beyond blacklisting, an open relay incident damages your organization's reputation. Partners, customers, and vendors who receive spam from your domain will question your technical competence. Rebuilding sender reputation after an open relay incident can take months, even after the technical issue is resolved.
How to Test for Open Relays
Testing for open relay status should be part of every mail server audit. There are several approaches:
Automated Testing Tools
The fastest way to check is with our Open Relay Test tool. It connects to your mail server and attempts multiple relay scenarios, testing different combinations of sender and recipient addresses to determine if the server will accept and forward messages it should reject. The test covers 19 different relay patterns including direct relay, source routing, and percent hack attempts.
Manual Telnet Testing
You can also test manually by connecting to your server via telnet or netcat. Connect to port 25 and attempt to send a message where both the sender and recipient are external addresses:
telnet mail.example.com 25
HELO test.com
MAIL FROM:<test@external.com>
RCPT TO:<test@another-external.com>
DATA
Subject: Open relay test
This is a test.
.
QUITIf the server accepts the RCPT TO command with a 250 response for an external recipient when the sender is also external and unauthenticated, your server is an open relay. A properly configured server will respond with a 550 or 554 rejection. You can verify your server's SMTP banner configuration with the SMTP Banner Checker.
How to Fix an Open Relay
Closing an open relay requires configuring your SMTP server to restrict relaying. The exact steps depend on your mail server software:
Postfix
In Postfix, the key directive is smtpd_relay_restrictions (or smtpd_recipient_restrictions in older versions). A secure configuration looks like:
smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destinationThe reject_unauth_destination directive ensures the server only relays mail for local domains or authenticated users. Without this, Postfix will relay for anyone.
Microsoft Exchange
In Exchange, relay permissions are controlled through Receive Connectors. Ensure that your internet-facing receive connector does not have "Anonymous Relay" enabled. Check the permission groups on each connector and remove ms-Exch-SMTP-Accept-Any-Recipient from anonymous sessions.
Sendmail
In Sendmail, relay control is managed through the access database and the FEATURE(`access_db`) macro. Ensure that the FEATURE(`promiscuous_relay`) macro is not enabled, as this explicitly allows open relaying. Use the access file to explicitly list which domains and networks are permitted to relay.
Real-World Consequences of Open Relays
The impact of running an open relay is not theoretical. In 2023, a mid-sized company discovered their newly deployed mail server had been an open relay for just 48 hours. In that time, over 2 million spam messages were relayed through their IP. Their primary IP was added to 14 blacklists, and it took 3 weeks to fully delist and restore normal email delivery.
Universities and government agencies are frequent targets because they often run complex mail infrastructure with multiple servers and legacy configurations. A single overlooked server can compromise the reputation of the entire organization's IP range.
Preventing Future Open Relay Issues
Closing the relay is only the first step. To prevent recurrence:
- Test regularly. Schedule periodic open relay tests as part of your security audit process. Configuration changes, software updates, and server migrations can inadvertently reintroduce relay vulnerabilities.
- Monitor outbound mail volume. Set up alerts for unusual spikes in outbound email. A sudden increase in queue size or outbound connections is often the first sign of relay abuse.
- Require SMTP authentication. All outbound relay should require SMTP AUTH with valid credentials. Never rely solely on IP-based restrictions for relay authorization.
- Implement rate limiting. Even for authenticated users, rate limits prevent a compromised account from being used to send bulk spam.
- Use firewall rules. Restrict port 25 inbound access to only the IP ranges that need to deliver mail to your server. Use port 587 (submission) for authenticated outbound relay.
- Deploy SPF, DKIM, and DMARC. These authentication protocols do not prevent open relay abuse directly, but they help receiving servers identify and reject spoofed messages. Check your setup with our SPF Checker and DMARC Checker.