---
title: SMTP monitoring: is your mail server still accepting and sending mail?
description: Your shop's order confirmations, password resets and invoices all leave through one SMTP login. When that login breaks, nothing errors on your website: the emails just don't go out. SMTP monitoring checks both halves of a mail server, the inbound side on port 25 and the sending login on 587 or 465. Here's what each one tells you, which port is which, and how to test it with openssl.
canonical: https://watchfor.io/blog/smtp-monitoring-explained
---

# SMTP monitoring: is your mail server still accepting and sending mail?

2026-10-05 · WatchFor Team · Email · email, smtp, deliverability, networking

Your shop's order confirmations, password resets and invoices all leave through one SMTP login. When that login breaks, nothing errors on your website: the emails just don't go out. SMTP monitoring checks both halves of a mail server, the inbound side on port 25 and the sending login on 587 or 465. Here's what each one tells you, which port is which, and how to test it with openssl.

**SMTP monitoring** checks the mail server that sends and receives your
email, on a schedule, from outside your network. It answers two different
questions, and it's worth knowing which one you're asking:

1. **Will the internet deliver mail to us?** That's the inbound side: other
   mail servers connect to yours on port 25.
2. **Can our apps and people still send?** That's the submission side: your
   website, shop, CRM and mail clients log in on port 587 or 465 and hand
   over messages.

A server can be fine on one side and broken on the other. This guide covers
both, with real examples and the commands to check by hand.

## What breaks, and how it looks from the outside

| What happened | What users notice | What a check sees |
| --- | --- | --- |
| Firewall or DNS change after a migration | Inbound mail bounces or delays | Port 25 doesn't answer, or answers from the old host |
| The sending password was rotated | Order and reset emails stop; the site shows no error | `535 Authentication failed` on 587 |
| Certificate expired on 587/465 | Mail clients refuse to send, apps log TLS errors | Certificate days left: 0, handshake fails |
| STARTTLS disappeared after an update | Mail still flows, passwords travel in plain text | `STARTTLS` missing from the `EHLO` reply |
| The server became an open relay | Your IP lands on blocklists within hours | The server accepts mail for a domain it doesn't host |
| Reverse DNS doesn't match | Big providers reject or spam-folder your mail | PTR record missing or pointing elsewhere |
| The provider switched off password logins | Scripts and old apps can't send | Login refused even with the right password |

The second row is the expensive one. A broken sending login doesn't show up
anywhere a customer can see it, until they wait for a password reset that
never comes.

## Port 25, 587 or 465?

People mix these up constantly, so here's the short version:

- **25** is server-to-server mail. Other mail servers deliver to yours here.
  It's not meant for logins, and most cloud providers and home ISPs block it
  outbound, which is why "telnet to port 25" from a laptop often just times
  out without telling you anything about the server.
- **587** is submission with **STARTTLS**: the client connects in plain
  text, asks to upgrade, and only logs in after the connection is encrypted.
  This is the default for apps and mail clients.
- **465** is submission with **implicit TLS** (SMTPS): encrypted from the
  first byte, nothing in plain text. Equally good; some providers prefer it.

So: check port 25 to know whether you can *receive*, and 587 or 465 with a
real login to know whether you can *send*.

## The inbound check (port 25)

An inbound check connects the way a sending server does and looks at what it
would see:

- the `220` **greeting** and how fast it arrives,
- the `EHLO` reply, and whether **STARTTLS** is offered,
- whether the server **refuses to relay** mail for domains it doesn't host
  (an open relay gets you blocklisted fast),
- **reverse DNS**: the server's IP should resolve back to a name that
  resolves to the same IP. Many receivers penalise mail from servers
  without it.

You can run this one without signing up, from a location where port 25
isn't blocked, with the free [SMTP Server Test](/smtp-test); the guide
[How to test an SMTP server](/blog/how-to-test-an-smtp-server) walks
through a real run.

## The sending check: log in like your app does

The submission check is the one most setups are missing. It connects on 587
(or 465), completes TLS, reads the certificate, lists the login methods the
server offers, and **logs in** with the same kind of account your app uses.
Then it says goodbye. No message is sent.

Here's what that looks like on a real server, checked every five minutes:

![SMTP login monitor on port 587: mail server grade A (STARTTLS rather than implicit TLS), TLS 1.3 with a trusted certificate and its expiry, the submission login card showing the offered methods PLAIN and LOGIN, the login accepted and the time of each stage from DNS lookup to login](/blog/smtp-monitoring-explained-auth.webp)

What each part tells you:

- **TLS version and certificate.** TLS 1.3 with a certificate valid for the
  host name is what you want. Days left feed a certificate expiry alert at
  14 days, separate from your website's certificate.
- **Login methods.** `PLAIN` and `LOGIN` after STARTTLS is normal. If a
  server offers them *before* the upgrade, a misconfigured client can send
  the password unencrypted.
- **Login accepted.** The core of it. A refused login is a critical alert:
  it means every app using that account has stopped sending.
- **Stage timings.** A slow login (hundreds of milliseconds instead of
  tens) often points at an overloaded authentication backend before it
  fails outright.

One safety rule worth insisting on in any tool you use: the password should
only be sent after TLS is up. If a 587 server stops offering STARTTLS, the
check should fail without sending the password at all.

## Test it yourself with openssl

The inbound conversation on port 25 (from a network that allows it):

```bash
openssl s_client -connect mail.example.com:25 -starttls smtp -servername mail.example.com
```

`openssl` sends `EHLO` and `STARTTLS` for you. Once it's connected, type
`EHLO test.example` to see what the server offers after encryption, then
`QUIT`.

The submission side on 587:

```bash
openssl s_client -connect mail.example.com:587 -starttls smtp -servername mail.example.com -quiet
```

Then log in with `AUTH PLAIN`, which takes the username and password
base64-encoded with a zero byte before each:

```bash
printf '\0monitor@example.com\0your-password' | base64
```

```text
EHLO test.example
AUTH PLAIN AG1vbml0b3JAZXhhbXBsZS5jb20AeW91ci1wYXNzd29yZA==
QUIT
```

`235 Authentication successful` means the login works; `535` means it
doesn't. For port 465, drop `-starttls smtp` and connect straight to `:465`.

Base64 isn't encryption: anyone who sees that line has the password. Only
type it inside an encrypted session like the one above, and prefer a
dedicated sending account for tests.

## Practical tips

- **Monitor the login your apps really use.** If the shop sends through
  `orders@`, check `orders@`, not an admin account with different rules.
- **Gmail and Google Workspace** need an app password for SMTP.
  **Microsoft 365** is retiring password logins for SMTP AUTH; if your apps
  still use one, that's a migration to plan before it fails.
- **Don't monitor submission on port 25.** It isn't meant for logins, cloud
  networks block it, and a check there tells you little about whether your
  apps can send.
- **A working login isn't the same as delivered mail.** The server can
  accept the message and still lose it, delay it or drop it in spam. To
  prove mail arrives, send a real one and look for it:
  [how to test email delivery end to end](/blog/how-to-test-email-delivery).

## How WatchFor monitors SMTP

The [SMTP monitor](/smtp-monitoring) checks the inbound side (banner,
STARTTLS, open relay, reverse DNS) and, with **Authenticate** turned on,
logs in on 587 or 465 the way your apps do. The password is stored
encrypted for that monitor and never shown again. Failures are confirmed
before they alert, and the alert names the stage that broke. Details are in
the [SMTP docs](/docs/monitors/email#smtp).

---

Canonical page: https://watchfor.io/blog/smtp-monitoring-explained · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt