---
title: IMAP and POP3 monitoring: how to know when a mailbox stops working
description: A mailbox can stop working while the mail server looks perfectly healthy: the password was rotated, the certificate expired on port 993, or the form that should email you every day quietly stopped. IMAP and POP3 monitoring logs in the way a mail client does and tells you which one it is. Here's what to check, what the results look like and how to test it yourself with openssl.
canonical: https://watchfor.io/blog/imap-pop3-monitoring
---

# IMAP and POP3 monitoring: how to know when a mailbox stops working

2026-10-05 · WatchFor Team · Email · email, imap, pop3, ssl

A mailbox can stop working while the mail server looks perfectly healthy: the password was rotated, the certificate expired on port 993, or the form that should email you every day quietly stopped. IMAP and POP3 monitoring logs in the way a mail client does and tells you which one it is. Here's what to check, what the results look like and how to test it yourself with openssl.

**IMAP and POP3 monitoring** means logging in to a real mailbox on a
schedule, the way a mail client does, and alerting when any step fails: the
connection, the TLS handshake, the certificate, the login or opening the
mailbox. It catches the failures a "is port 993 open?" check misses, and,
with one extra rule, the quietest failure of all: mail that simply stops
arriving.

This guide explains what can go wrong with a mailbox, what is worth
measuring, what a real check shows, and how to run the same test by hand.

## Why a mailbox fails while the server looks fine

Most mailbox outages aren't the server going down. They're one of these:

- **The password changed.** Someone rotated it, an admin reset it, or the
  provider forced a change. Every app and shared inbox that logs in with it
  stops getting mail, and nobody notices until a customer asks why there's
  no reply.
- **The certificate expired on the mail ports.** The website renewed
  automatically; the certificate on 993 and 995 didn't. Phones start showing
  "cannot verify server identity" and help desk tools stop syncing.
- **The provider turned off password logins.** Microsoft 365 has switched
  off password (basic) logins for IMAP and POP3, and Gmail only accepts an
  app password. A script that worked for years starts failing overnight.
- **Encryption got weaker after a migration.** A new server offers TLS 1.0,
  or offers a password login before STARTTLS. Mail still flows, but the
  password can now travel in plain text.
- **Mail stopped arriving.** The mailbox is fine, but whatever fills it, a
  contact form, a nightly backup report, invoices from a supplier, stopped
  sending. This is the one that goes unnoticed the longest.

Only the first four break the connection. The fifth needs you to look
*inside* the mailbox, which is why a monitor that logs in is worth more than
a port check.

## IMAP vs POP3 in one paragraph

Both let a client read mail from a server. **IMAP** (port 993 with implicit
TLS, 143 with STARTTLS) keeps mail on the server, with folders and read
status, and is what phones, Outlook and help desk tools use today. **POP3**
(995 / 110) downloads messages and was built for one device per mailbox; it
survives in older ticketing systems, scanners and scripts that collect mail.
If you're not sure which one your tools use, it's IMAP. Monitor whichever
your apps actually log in with, because that's the one that has to keep
working.

## What to measure

| Check | What it tells you | Typical failure |
| --- | --- | --- |
| **Connect** | The server answers on the port from the outside | Firewall change, DNS pointing at the old server |
| **TLS handshake** | Version (1.2 or 1.3), cipher, how long it takes | TLS 1.0/1.1 after a migration, broken chain |
| **Certificate** | Who issued it, which names it covers, days left | Expired on 993/995 while the website renewed |
| **STARTTLS** (ports 143/110) | The upgrade to encryption is still offered | Upgrade disappears, client falls back to plain text |
| **Login** | The username and password are accepted | Rotated password, disabled account, basic auth turned off |
| **Mailbox** | Messages and unread count, opened read-only | Mailbox deleted or permissions changed |
| **Newest message age** | When the last message arrived | Whatever fills the mailbox stopped sending |

Two details matter for a monitor that touches a real mailbox. It should open
the mailbox **read-only** (IMAP `EXAMINE`), so it never marks a message as
read for the person or tool that handles it. And it should read only the
arrival date of the newest message, never the subject, sender or body.

## What a real check shows

Here's a WatchFor IMAP monitor on a real mailbox, checked every five
minutes. Each stage of the session is timed separately, so a slow TLS
handshake looks different from a slow login:

![IMAP monitor for a support mailbox on port 993: mail server grade A+ (TLS 1.3, trusted certificate, login works), the TLS and certificate card, connection stages from DNS lookup through TLS handshake, login, listing folders and selecting the mailbox with each time in milliseconds, the mailbox card (INBOX, 6 folders) and the server's capabilities](/blog/imap-pop3-monitoring-imap.webp)

The page also grades the mail server from **A+** to **F** from the latest
check, with the reasons under the letter: TLS 1.3 over implicit TLS with a
valid certificate is an A+; STARTTLS instead of implicit TLS caps it at A;
a password offered before encryption caps it at C; an expired or untrusted
certificate is an F. A check that never reached the server gets no grade,
so a network problem isn't blamed on the server.

POP3 reports the same connection stages, plus the message count and
mailbox size:

![POP3 monitor for a help desk mailbox on port 995: Dovecot greeting, TLS 1.3, login accepted, capabilities USER, UIDL, TOP and SASL, and the mailbox with its message count and size](/blog/imap-pop3-monitoring-pop3.webp)

## The alerts worth turning on

- **Login failed**: the server refused the login. This is the one that
  catches a rotated password within one check interval instead of when a
  customer complains.
- **Certificate expiry**: fewer than 14 days left on the certificate the
  mail port serves. It's separate from the website's certificate, even on
  the same host name.
- **Plaintext login offered** and **STARTTLS not offered** (ports 143 and
  110): the server would accept a password without encryption, or a client
  on the plain port couldn't encrypt at all.
- **No new mail**: the newest message is older than a threshold, say 24
  hours for a mailbox that receives a nightly report. This is how you find
  out that a form, a backup job or a supplier stopped sending, from the side
  that receives it.

A failure is confirmed before it alerts: a single dropped connection from
one location shows as degraded, and an incident opens only when the next
checks fail too. A mail server having a bad minute shouldn't page anyone.

## Test it yourself with openssl

You can run the same conversation by hand. Connect to IMAP over implicit
TLS:

```bash
openssl s_client -connect imap.example.com:993 -servername imap.example.com -quiet
```

The server greets you with `* OK`. Log in and look at the mailbox without
changing anything (each line starts with a tag of your choice, here `a1`,
`a2`):

```text
a1 LOGIN monitor@example.com your-password
a2 EXAMINE INBOX
a3 LOGOUT
```

`EXAMINE` opens the mailbox read-only (the server confirms with
`[READ-ONLY]`) and returns lines such as `* 42 EXISTS`, the number of
messages. A wrong password answers `a1 NO [AUTHENTICATIONFAILED]`.

For POP3 the commands are `USER`, `PASS`, `STAT` (message count and total
size) and `QUIT`:

```bash
openssl s_client -connect pop.example.com:995 -servername pop.example.com -quiet
```

To see the certificate the mail port serves, and when it expires:

```bash
openssl s_client -connect imap.example.com:993 -servername imap.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -enddate
```

For STARTTLS on the plain port, add `-starttls imap` (or `-starttls pop3`)
and connect to 143 or 110. If the command fails with "STARTTLS not
supported", clients on that port can't encrypt.

Typing your real password into a terminal leaves it in the shell history;
use a dedicated monitoring account, or type the login inside the session as
above rather than on the command line.

## Practical tips

- **Use a dedicated account** with access to one mailbox, not a person's
  login. When that person leaves or changes their password, your monitoring
  shouldn't break.
- **Gmail and Google Workspace** need an app password (which requires
  2-Step Verification). **Microsoft 365** no longer accepts password logins
  for IMAP and POP3, so a login check there fails; a connection-only check
  without a username still grades TLS and the certificate.
- **Pick the right threshold for "no new mail".** A shared support inbox
  gets mail every hour; a backup report arrives once a day. Set the
  threshold a little above the normal gap, not below it.
- **Watch the sending side too.** A mailbox that works says nothing about
  whether your server can send. That's an [SMTP check](/blog/smtp-monitoring-explained),
  and proving the two meet in the middle is an
  [email round trip](/blog/how-to-test-email-delivery).

## How WatchFor monitors IMAP and POP3

The [IMAP](/imap-monitoring) and [POP3](/pop3-monitoring) monitors log in
from our probe locations on your schedule, time every stage, grade the
server and alert on the rules above. The password is stored encrypted for
that one monitor and never shown again, not even to account owners. Setup
details, including provider notes, are in the
[IMAP](/docs/monitors/imap) and [POP3](/docs/monitors/pop3) docs.

---

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