How to Set Up SMTP Uptime Monitoring

What is an SMTP Check?

An SMTP check connects to your mail server from Xitoring's global probing nodes and verifies that the SMTP service is accepting connections and returning a valid banner. SMTP handles outbound email — when SMTP is down, your application stops sending password resets, receipts, and notifications.

For diagnosing SMTP issues at the OS level (logs, packet inspection, swaks), see How to check SMTP Health on Linux.

Use SMTP checks for:

Outbound mail relays your application uses to send email
Inbound MX servers that receive mail for your domain
Submission endpoints used by your team's email clients
Third-party SMTP providers your service depends on (SendGrid, Mailgun, Postmark, etc.)

What Gets Monitored

Connection success — TCP handshake on the SMTP port
Greeting — server returns a valid SMTP banner (e.g., 220 mail.example.com ESMTP)
TLS handshake for SMTPS (465) and STARTTLS-on-587
Response time — time to greeting from each probing node
Geographic availability — reachable from each region

Prerequisites

A reachable mail server hostname or IP
The SMTP port to monitor:
- 25 — server-to-server SMTP (often blocked by cloud providers outbound)
- 587 — submission with STARTTLS (recommended for clients)
- 465 — SMTPS (implicit TLS)
Firewall rules allowing TCP from Xitoring's probing IP ranges
A valid TLS certificate when monitoring SMTPS

How to Set Up an SMTP Check

Step 1: Create the Check

Log in to your Xitoring Dashboard
Go to Uptime → Add Check
Select SMTP as the check type

Step 2: Configure the Connection

Enter the hostname (e.g., mail.example.com)
Set the port — 25, 587, or 465
Enable SSL/TLS if monitoring port 465
Optionally set an expected banner substring (e.g., 220, ESMTP)
Set the check interval (30 seconds to 15 minutes)
Set the timeout (default: 30 seconds)

Step 3: Choose Probing Nodes

Select at least 3 probing nodes. For inbound MX monitoring, spread nodes across the regions where senders live.

Step 4: Assign Notifications

Under Triggers, attach a notification role.

Step 5: Save and Verify

Save the check. The first probe runs immediately.

Setting Up Triggers

Common alerting rules:

Connection refused or timed out — SMTP daemon down or port blocked upstream
Banner mismatch — wrong server responding (DNS, NAT, or routing issue)
TLS handshake failure — expired certificate on 465 or broken STARTTLS on 587
Slow response — server overloaded or queue backed up

Tips

Monitor each port you actually use — 25 for inbound MX, 587 for client submission, 465 if you still expose SMTPS
Cloud providers (AWS, GCP) block outbound 25 by default — if your probe nodes can't connect to your inbound MX on 25, that's the cloud egress filter, not your server
Pair with SSL certificate monitoring on the mail hostname so you catch expiring certs before mail clients break
An SMTP banner check verifies the daemon is up — not that mail is being delivered. For full delivery monitoring, run a round-trip test from a real account on a separate cadence
Watch banner contents if you operate behind a CDN or load balancer — a banner from the wrong backend means traffic is going to the wrong place