---
title: Will our new mail server accept mail? How to test it with the SMTP Server Test
description: You're about to point MX at a new mail server, or mail to your server has stopped arriving, and a test from your laptop just times out. To test an SMTP server, connect to it from the outside the way a sending server does and check four things: the greeting banner, STARTTLS, relay refusal and reverse DNS. Here's how with the free SMTP Server Test, and the openssl commands that do the same.
canonical: https://watchfor.io/blog/how-to-test-an-smtp-server
---

# Will our new mail server accept mail? How to test it with the SMTP Server Test

2026-10-04 · WatchFor Team · Guides · guides, email, networking

You're about to point MX at a new mail server, or mail to your server has stopped arriving, and a test from your laptop just times out. To test an SMTP server, connect to it from the outside the way a sending server does and check four things: the greeting banner, STARTTLS, relay refusal and reverse DNS. Here's how with the free SMTP Server Test, and the openssl commands that do the same.

To test an SMTP server, connect to it from outside your network on port 25
(or 587/465 for submission) and check what a sending server would see: a
`220` greeting, `STARTTLS` in the `EHLO` reply, a refusal to relay mail for
domains it doesn't host, and reverse DNS that matches its address. A server
that passes all four will accept mail from the internet; one that fails
loses mail or ends up on blocklists.

The free [SMTP Server Test](/smtp-test) runs that conversation from a
WatchFor location, where port 25 isn't blocked, and reports each check. No
signup.

## What this tool answers

*Would a sending mail server be happy talking to this host?* Reach for it
before you switch MX records to a new server or provider, when inbound mail
stops arriving, after firewall or certificate changes on a mail host, and
whenever you need to prove a server isn't an open relay.

## A real example

### Testing an SMTP server before switching MX to it

Before an MX change, you want proof that the new host answers on port 25,
offers encryption and won't relay spam. Testing from a laptop usually fails
for a reason unrelated to the server: many ISPs and cloud networks block
outgoing port 25. That's exactly what happened from our own connection (see
the command-line section).

To show what a well-configured server looks like, we tested Gmail's own
inbound server. In the [SMTP Server Test](/smtp-test) we entered
`gmail-smtp-in.l.google.com`, kept port **25** and both checks (open relay
and reverse DNS) ticked, and pressed **Test mail server**:

![The SMTP Server Test for gmail-smtp-in.l.google.com on port 25 from Europe / Lithuania: 24 ms connect time, REACHABLE, STARTTLS offered, Relay denied, Reverse DNS matches, Banner uses another name, server banner 220 mx.google.com ESMTP ... gsmtp, and timings DNS 98 ms, connect 24 ms, banner 0 ms, EHLO 34 ms](/blog/how-to-test-an-smtp-server-result.webp)

From Vilnius the server answered in **24 ms** and passed every check that
matters:

- **STARTTLS offered.** The `EHLO` reply advertises `STARTTLS`, so senders
  can encrypt the session.
- **Relay denied.** Asked to accept mail for an outside domain without
  authentication, it refused.
- **Reverse DNS matches.** The address has a PTR record whose name resolves
  back to the same address (forward-confirmed reverse DNS).
- **Banner uses another name.** The greeting reads
  `220 mx.google.com ESMTP ... gsmtp`, not the host name we typed. That's
  normal behind a load balancer, as here.

**The answer:** this is what a ready server looks like. If your new host
shows the same four results, switching MX to it is safe from the receiving
side. If it shows **UNREACHABLE**, fix the firewall or the listener before
touching DNS, or inbound mail will queue at senders and eventually bounce.

## How to read the results

| What you see | What it means |
| --- | --- |
| **Connect time** | How long the TCP connection took from the test location. Distance sets most of it. |
| **REACHABLE / UNREACHABLE** | Whether the server accepted the connection and greeted. Unreachable comes with the error: refused (nothing listens), timed out (a firewall drops it), or a DNS failure. |
| **STARTTLS offered / No STARTTLS** | Whether `EHLO` lists `STARTTLS`. Without it, mail to this host travels unencrypted, and Gmail marks such messages as not encrypted. On port 465 it reads **Encrypted (implicit TLS)**. |
| **Relay denied / Open relay** | Whether it accepted a recipient at a domain it doesn't host, without logging in. Open relay is critical: spammers find these fast, and blocklists follow. |
| **Reverse DNS matches / mismatch** | Whether the IP's PTR name resolves back to the same IP. A mismatch or missing PTR gets mail *from* this server greylisted or rejected by many receivers. |
| **Banner names this host / uses another name** | Whether the `220` greeting contains the host you typed. Informational; shared clusters often greet with a common name. |
| **Server banner** | The raw greeting line, useful for identifying the software or provider. |
| **DNS / connect / banner / EHLO** | Timings for each step. A slow banner (seconds) can mean slow reverse lookups on the server side, or a deliberate greeting delay against spammers. |

## More ways to use it

- **Submission ports for apps.** Testing port **587** (STARTTLS) or **465**
  (implicit TLS) on your provider's SMTP host tells you whether an app's
  "can't connect to mail server" is a network block or bad credentials.
- **After renewing a mail server certificate.** Confirm STARTTLS is still
  offered, then look at the new certificate with the `openssl` command
  below.
- **Proving you're not an open relay.** When a blocklist cites an open
  relay, run the test on the listed server after fixing it, and keep the
  result for the delisting request.
- **Choosing which host to test.** The tool tests the name you type; it
  doesn't follow MX records. Look the MX up first with the
  [MX Lookup](/mx-lookup), then test the lowest-priority-number host (the
  [MX guide](/blog/how-to-check-mx-records) explains priorities).

## Tips and gotchas

- **Port 25 is blocked on most home and many cloud connections.** A timeout
  from your laptop proves nothing about the server. Test from outside, as
  here, or from a server whose provider allows port 25.
- **Reverse DNS is set by whoever owns the IP.** Your hosting or cloud
  provider sets the PTR, not your DNS host. Point it at the server's
  name, and give that name an A record back to the IP.
- **The relay test doesn't send mail.** It stops at the recipient step and
  only checks whether the server would accept it.
- **A ready server isn't the whole story.** Senders also need your MX
  records pointing at it, and your own outbound mail needs SPF, DKIM and
  DMARC; the [email authentication guide](/blog/how-to-check-email-authentication)
  covers that side.

## Check it from the command line too

From a network that allows port 25, `openssl` holds the same conversation and
shows the certificate after `STARTTLS`:

```bash
openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -brief
```

From our own connection that command just hung: the ISP blocks port 25, as
`nc` shows:

```bash
nc -vz -w 5 gmail-smtp-in.l.google.com 25
```

```text
nc: connect to gmail-smtp-in.l.google.com (142.251.127.26) port 25 (tcp) timed out: Operation now in progress
```

Port 587 isn't blocked, so a submission server can be tested from almost
anywhere:

```bash
openssl s_client -starttls smtp -connect smtp.gmail.com:587 -brief </dev/null 2>&1 | grep -E "Protocol|Peer certificate"
```

```text
Protocol version: TLSv1.3
Peer certificate: CN=smtp.gmail.com
```

Forward-confirmed reverse DNS by hand: the PTR of the address, then the
address of that name:

```bash
dig +short gmail-smtp-in.l.google.com A
dig +short -x 142.250.147.27
dig +short rd-in-f27.1e100.net A
```

```text
142.250.147.27
rd-in-f27.1e100.net.
142.250.147.27
```

The name points back to the same address, so the check passes. Google
rotates addresses, so you may get a different one.

## Keep watching it

A mail server that stops answering doesn't announce it; senders queue and
retry, and you find out days later from bounces. An
[SMTP monitor](/smtp-monitoring) connects on a schedule and runs the same
checks: **Probe Status** fires when it stops accepting connections and
**Open Relay Detected** opens a critical incident on the first sighting.
**TLS Required** and **FCrDNS / PTR Failed** can be switched on for the
other two checks.

## FAQ

**How do I test if my SMTP server is working?**
Connect to it from outside your network on port 25 and check for a `220`
greeting, `STARTTLS` in the `EHLO` reply and a refusal to relay for outside
domains. An online SMTP test does this from a server where port 25 is open.

**Why can't I connect to port 25?**
Most residential ISPs and many cloud providers block outgoing port 25 to
stop spam from infected machines. Use port 587 for sending from apps, and
test inbound port 25 from outside.

**What is an open relay and why is it dangerous?**
A server that accepts mail for any destination from anyone, without
authentication. Spammers use it to send through you, your IP lands on
blocklists, and your legitimate mail stops being delivered. See
[how blocklists work](/blog/email-blacklists-rbl).

---

Canonical page: https://watchfor.io/blog/how-to-test-an-smtp-server · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt