SMTP Open Relay Tester

Verify if an email server is improperly configured to allow unauthorized users (spammers) to send mail through it, masking their true origin.

Our Open Relay Test checks whether your mail server will accept and forward mail from unauthenticated senders to arbitrary external recipients. An open relay is abused within hours of being discovered and gets the address blacklisted almost immediately.

What is an Open Relay?

An open relay is a mail server that accepts mail from anyone and forwards it to anyone. It will take a message from an unauthenticated sender on the internet and deliver it to a recipient in a completely unrelated domain.

A correctly configured server relays under only two conditions: the sender is authenticated, or the recipient is in a domain the server is responsible for. Anything else is refused. Mail from a stranger to another stranger has no legitimate reason to pass through your server.

Open relays were the internet default decades ago, before spam made that untenable. Modern mail software refuses relaying out of the box, so an open relay today is almost always the result of a misconfiguration — an overly broad network range in the permitted list is the classic case.

Accepts mail from anyone and forwards it to anyone
Correct servers relay only for authenticated senders or local recipients
Modern mail software refuses relaying by default
Almost always the result of an overly broad configuration
Discovered and abused within hours of appearing

Why Open Relays Matter

The internet is scanned continuously for open relays, and one is found and abused very quickly — typically within hours. Spammers then use your server to send their mail, with your address and your reputation attached.

The consequences arrive fast. The address is blacklisted, your own legitimate mail stops being delivered, your hosting provider may suspend the service for abuse, and your bandwidth and server capacity are consumed by someone else campaign. Recovery requires fixing the configuration and then working through delisting across multiple blocklists.

Found and abused within hours through continuous internet scanning
Your address and reputation are attached to the spam sent
Blacklisting follows almost immediately
Hosting providers frequently suspend service for the abuse
Recovery requires delisting across multiple lists

How This Open Relay Test Works

The tool attempts a relay transaction using external addresses for both sender and recipient.

Validates the host input against format and SSRF safety checks
Connects to the mail server and reads the greeting
Issues MAIL FROM with an external sender address
Issues RCPT TO with an external recipient address
Records whether the server accepted or refused, without sending any message

How to Use the Open Relay Test

Enter a mail server hostname you own or are authorised to test
Run the test to attempt a relay transaction
Confirm the server refuses relaying for external recipients
A refusal with 550 or 554 is the correct result
If relaying is accepted, fix the configuration immediately

Understanding Your Open Relay Test Results

The response to the relay attempt is what matters:

Field / Value	Meaning
`Relay denied`	The correct result. The server refused to accept mail for an external recipient from an unauthenticated sender, typically with a 550 or 554 response.
`Relay accepted`	A critical misconfiguration. The server will forward mail from anyone to anyone, and it will be abused as soon as it is discovered.
`550 relay access denied`	The standard refusal. The server correctly identified that it is not responsible for the recipient domain and the sender is not authenticated.
`554 rejected`	Another correct refusal, often used when the server rejects earlier in the transaction based on policy.
`Authentication required`	The server offers relaying but only to authenticated senders. Correct behaviour, and the expected response on submission ports.
`Accepted then dropped`	Some servers accept during the transaction and discard afterwards. This is not an open relay, but it generates backscatter and is poor practice.

Common Problems & How to Fix Them

This is critical and needs fixing immediately, before the server is discovered.

In Postfix, check mynetworks — an overly broad range such as an entire /8 is the classic cause — and ensure smtpd_recipient_restrictions includes reject_unauth_destination. In Exim, review the relay_from_hosts and relay_to_domains configuration. In Microsoft Exchange, check the receive connector permission groups, particularly whether anonymous users have been granted relay permission.

After fixing, check blacklist status for the address, since abuse may already have occurred.

A permitted range broader than intended means anyone in that range can relay. On shared or cloud infrastructure this can include other customers.

Narrow mynetworks or the equivalent to the specific addresses that genuinely need to relay. Prefer authentication over address-based trust wherever possible, since authentication survives infrastructure changes and address ranges do not.

The restriction is now blocking your own applications or users.

Use authenticated submission on port 587 rather than address-based relay permission. Applications and mail clients should authenticate rather than being trusted by source address, which is both more secure and more robust.

Accepting during the SMTP transaction and discarding afterwards is not an open relay, but it means the sender receives no error while the mail disappears. It also generates backscatter when the server bounces to forged senders.

Reject during the SMTP transaction instead, so the sending server receives a proper refusal it can act on.

The relay was found and used before you closed it.

Fix the configuration first, then check every major blocklist and work through their delisting processes. Review outbound logs to understand the volume sent, since some lists ask about it. Expect the reputation impact to outlast the delisting.

Best Practices

Require authentication for relaying rather than trusting source addresses
Keep permitted network ranges as narrow as possible
Use submission ports 587 or 465 for authenticated sending
Reject during the SMTP transaction rather than accepting and discarding
Test for open relay after every mail server configuration change
Monitor outbound volume for anomalies indicating abuse
Check blacklist status regularly as an early warning

Security Recommendations

Treat an open relay as a critical finding requiring immediate remediation, since discovery and abuse follow within hours
Check blacklist status immediately after closing a relay, as abuse may already have occurred
Prefer authentication over address-based trust, which fails when infrastructure changes
Apply rate limiting on authenticated submission so a compromised account cannot send unlimited volume
Monitor outbound mail volume, since a sudden increase is the clearest sign of abuse
Only test mail servers you own or are explicitly authorised to test

Frequently Asked Questions

A mail server that accepts mail from unauthenticated senders and forwards it to arbitrary external recipients. A correctly configured server relays only for authenticated senders or for recipients in domains it is responsible for.

Typically within hours. The internet is scanned continuously for them, and one that appears is found and used almost immediately, with your address and reputation attached to whatever is sent.

In Postfix, narrow mynetworks and ensure reject_unauth_destination is present in smtpd_recipient_restrictions. In Exim, review relay_from_hosts and relay_to_domains. In Exchange, check receive connector permissions for anonymous relay grants.

Almost always a configuration error rather than a default. The classic cause is a permitted network range set far broader than intended, such as an entire /8 where a single /24 was meant.

Through authenticated submission on port 587. Users and applications authenticate rather than being trusted by source address, which is both more secure and more robust when infrastructure changes.

Check blacklist status on every major list immediately, since abuse has likely already occurred. Review outbound logs to understand the volume sent, then work through the delisting processes.

Only with authorisation. The test initiates an SMTP transaction against a third-party system, which without permission may constitute unauthorised access. Test only servers you own or are explicitly authorised to assess.