Monitor a mail server

What you'll know

• Each mail service is up, and it's a mail server that answers. Incoming mail on port 25, your users' mail apps on 587 and 465, and IMAP and POP3 with and without TLS. Every port gets its own check, which waits for the greeting a real mail server sends.
• The certificates aren't about to run out. Gryphon warns 30 days before a certificate on a TLS port expires, and calls it a problem at 7.
• Your domain's MX record still points at your server. Mail goes wherever the MX record says, so a mistake there loses mail even while the server is fine.

A plain port check would say the port is open. These checks also read what answers it. If a load balancer accepts the connection while the mail server behind it is down, or something else has taken the port, the greeting is missing and the check is a problem.

What this can't tell you: whether mail is actually delivered. A server can greet every connection and still bounce messages, sit on a full queue, or be on a blocklist. These checks catch the server, the certificates and the DNS, which is where most mail outages start.

Before you start

• The mail server added as a host in Gryphon, with its public name, such as mail.example.com, under Hostname or IP. Every check below connects to that address.
• No agent. All of these checks run from Gryphon's side, as your users' mail apps and other mail servers reach it.

Steps

1Check incoming mail on port 25

Open the host, go to Manage Services, choose Add service, and pick TCP send/expect. It connects and waits for the greeting a real mail server gives; if you're new to it, how send/expect works explains it from the start.

Name

SMTP

Port

25

TLS

none

Send (optional)

leave empty

Expect

220

Check Interval

Every 3 Minutes

A mail server speaks first. It greets every connection with a line starting 220, such as 220 mail.example.com ESMTP Postfix, so the check only has to listen. Leave Send empty. Postfix's postscreen, and similar spam defences, treat a client that talks before the greeting as a spam bot.

2Add the other ports you run

Add one TCP send/expect check per port, with a Name that says which it is. Leave Send empty on all of them, because every one of these services greets first.

Service	Port	TLS	Expect
Submission	587	none	220
Submission over TLS	465	tls	220
IMAP	143	none	* OK
IMAP over TLS	993	tls	* OK
POP3	110	none	+OK
POP3 over TLS	995	tls	+OK

tls completes a TLS handshake before reading the greeting, and requires a certificate that's trusted and issued for the host's name, as a mail app does. For a server with a self-signed certificate, choose tls-no-verify. Ports 25 and 587 switch to TLS with STARTTLS after the greeting, so they're checked as none. The greeting arrives before the switch.

Choose the TLS setting that matches the port. A TLS port checked as none waits for a greeting that never comes and fails after 10 seconds. A plain port checked as tls fails the handshake.

3Watch the certificates

Add SSL Certificate once for each port that has its own certificate:

Port

993

Verify certificate

true

The certificate check speaks TLS from the first byte, so it reads ports 465, 993 and 995 but not 25 or 587, where TLS starts later. That's rarely a gap, because most mail servers use one certificate for all of them. If yours doesn't, the TLS ports still tell you when each certificate is close to expiring.

4Watch the MX record

Add DNS to the same host:

Nameserver

1.1.1.1 — or your domain's own nameserver

Port

53

Name to look up

example.com

Record type

MX

Protocol

udp

Expected answer (optional)

mail.example.com

Fill in Nameserver. Left empty, it asks the host the check is on, and a mail server usually isn't a nameserver. The check passes when any MX record contains the expected text, ignoring case and the trailing dot, so mail.example.com matches 10 mail.example.com.

Test it

1. Use Check now on each new check. A healthy one says what it found, such as mail.example.com:993 - answered with "* OK" in 41ms.
2. Change one check's Expect to something the server won't say, like XYZ, and check it again. It becomes a problem, and the message quotes what the server did send, which is the fastest way to find the right text for a server you're not sure about. Change it back afterwards.
3. For the real thing, stop the IMAP service on a quiet evening, for example with sudo systemctl stop dovecot. Gryphon rechecks every minute and alerts once three checks in a row agree. Start it again, and the recovery is announced too.

Variations

Microsoft 365 or Google Workspace

When someone else runs the mail servers, there's nothing of yours to connect to. Keep only the DNS check, expecting their MX host, such as mail.protection.outlook.com or google.com. Add a second DNS check with Record type TXT and Expected answer v=spf1, so you know when your SPF record goes missing.

A mail server only your network can reach

For an internal relay, or an IMAP server behind the firewall, use TCP send/expect (agent) on a host with the Gryphon agent. It takes the same fields, plus Host: the server's private address or internal name, as the agent sees it.

fail2ban and connection logs

Each check connects, reads the greeting and hangs up, so your mail log gains a short line every few minutes. If fail2ban is set to ban clients that connect and leave without sending mail, add Gryphon's addresses to its ignore list. They're listed on the check locations page.

From more than one region

On the Pro and Teams plans, TCP send/expect can run from several regions under Check from, so a route problem that only affects one part of the world shows up as one. The certificate and agent checks run from one place.