SMTP Port 25 Test

Test if your mail server is reachable on port 25 and check for a valid SMTP banner response.

Evidence ASSESSED

Checked against: Live SMTP conversation on port 25/587 · RFC 5321

RED TEAM 0 findings BLUE TEAM control did not hold

Why Test Port 25?

Port 25 is the standard port used for email transmission between mail servers (MTA to MTA).

Connectivity: If port 25 is blocked or unreachable, your server cannot receive emails from other servers.
Banner Verification: A proper SMTP banner should start with "220" and often includes the server's hostname.
Spam Prevention: Many residential ISPs block port 25 to prevent malware on home computers from sending spam.

Our SMTP Test Tool runs a full diagnostic against your mail server — connectivity, greeting, advertised extensions, STARTTLS availability and relay behaviour — giving you the complete picture of how it appears to other mail servers.

What is SMTP Testing?

SMTP testing exercises a mail server the way another mail server would, and records what happens at each stage.

The sequence matters. A connection opens and the server sends a greeting. The client issues EHLO and the server lists its capabilities. From there the client can attempt STARTTLS to encrypt, and can test whether the server accepts mail for recipients it should not.

Each stage reveals something different. Connectivity tells you the server is reachable at all. The greeting tells you what hostname it claims. The extension list tells you whether encryption is available. The relay test tells you whether the server is dangerously misconfigured. Testing them together gives a picture that no single check provides.

Exercises the server as another mail server would
Tests connectivity, greeting, extensions, encryption and relay behaviour
Each stage reveals a different aspect of the configuration
Shows how the server appears from outside your network
Catches problems that are invisible from the inside

Why SMTP Testing Matters

Mail server problems are silent from the inside. A firewall change blocks inbound connections, a certificate expires and STARTTLS stops working, a configuration edit opens relaying — and none of these produce any local symptom. The server is running, the logs look normal, and mail simply stops arriving or starts being rejected elsewhere.

Testing from outside is the only way to see what other servers see. It is also the only way to catch the problems that matter most: an open relay that will be abused within hours, or a missing STARTTLS that means every message crosses the internet in plaintext.

Mail server problems produce no local symptom
Only an external test shows what other servers see
Catches open relay before it is found and abused
Detects expired certificates breaking STARTTLS
Verifies firewall and security group changes took effect

How This SMTP Test Works

The tool runs through a full SMTP conversation and records each response.

Validates the host input against format and SSRF safety checks
Opens a connection and captures the greeting banner
Issues EHLO and records every advertised extension
Checks whether STARTTLS is offered and works
Attempts a relay transaction to external addresses without sending any message

How to Use the SMTP Test Tool

Enter a mail server hostname you own or are authorised to test
Run the test to execute the full diagnostic
Confirm the connection succeeds and a 220 greeting is returned
Verify STARTTLS is offered
Confirm relaying is refused for external recipients

Understanding Your SMTP Test Results

Each stage of the test reports something different:

Field / Value	Meaning
`Connection`	Whether the port is reachable from outside. A failure here means a firewall or security group is blocking, or the service is not running.
`Greeting`	The 220 response and the hostname the server announces. That hostname should match the reverse DNS of the connecting address.
`EHLO extensions`	The capabilities advertised. STARTTLS should be present, SIZE indicates the message limit, and AUTH is expected on submission ports.
`STARTTLS`	Whether encryption is available and negotiates successfully. A failure here means mail crosses the internet in plaintext.
`Relay test`	Whether the server accepts mail for external recipients from unauthenticated senders. Refusal is correct; acceptance is a critical misconfiguration.
`Response times`	How long each stage took. Slow responses cause sending servers to time out and retry, delaying delivery.

Common Problems & How to Fix Them

Either the service is not running or something is blocking the port.

Check the service is listening, then work outward through the host firewall and any cloud security group. Many cloud providers block port 25 by default in both directions. Test from outside your network, since an internal test takes a different path and will succeed regardless.

Mail is being transmitted in plaintext and can be read by anyone on the network path.

If it is not offered, enable it in the mail server configuration. If it is offered but negotiation fails, the certificate has probably expired or does not match the hostname. Check the certificate and its expiry — this is a common cause of mail suddenly failing for senders that require encryption.

This is critical. The server will be found and abused within hours, and blacklisting follows immediately.

Narrow the permitted network ranges in your configuration and ensure unauthenticated relay to external domains is rejected. After fixing, check blacklist status, since abuse may already have occurred.

Receiving servers compare the announced hostname against the reverse DNS of the connecting address, and treat a mismatch as a spam signal.

Make the announced hostname, the PTR record and the forward A record all agree. The PTR is set by your hosting provider rather than by you, so it usually requires a support ticket.

Slow responses cause sending servers to time out and retry, delaying delivery and eventually causing bounces.

Common causes are a reverse DNS lookup timing out during connection handling, server overload, or deliberate delay from greylisting. Greylisting is intentional; the others are worth investigating.

Best Practices

Test from outside your network, since internal tests take a different path
Run the full test after every mail server or firewall change
Keep STARTTLS enabled with a valid, monitored certificate
Verify relay refusal explicitly rather than assuming the default holds
Match the greeting hostname to reverse DNS and a forward record
Monitor certificate expiry, since it silently breaks STARTTLS
Use submission ports 587 or 465 for authenticated sending

Security Recommendations

Treat an accepted relay as critical and fix it the same day, since abuse follows discovery within hours
Require STARTTLS so mail is not transmitted in plaintext
Never offer AUTH on port 25 for inbound mail, as it invites credential attacks
Consider reducing version detail in the greeting banner, which currently advertises your software to anyone who connects
Rate limit connections to resist enumeration and denial of service
Only test mail servers you own or are explicitly authorised to assess

Frequently Asked Questions

Connectivity, the greeting and announced hostname, the advertised extensions, whether STARTTLS works, and whether the server accepts relay for external recipients. Together these show how the server appears to other mail servers.

Because firewall rules differ by source. An internal test takes a path that is usually permitted, so it will succeed even when external connections are blocked. Only an external test shows what other mail servers actually experience.

The server accepted the connection and is ready. It is the expected first response, and the accompanying text normally names the server and its software version.

Without it, mail crosses the internet in plaintext and can be read by anyone on the network path. It is also required for MTA-STS, and an increasing number of senders refuse to deliver unencrypted.

Your server is an open relay and will be abused as soon as it is discovered, typically within hours. Fix the configuration immediately and check blacklist status, since abuse may have already occurred.

No. The relay check stops after the recipient command and records whether the server accepted or refused. No message data is transmitted and nothing is delivered.

After every mail server, firewall or certificate change, and periodically regardless. Certificate expiry in particular breaks STARTTLS silently, so a scheduled check catches it before senders do.