Documentation
Complete guide to setting up website monitoring with PingZen. API documentation, code examples, and best practices.
PingZen has three separate monitor types for mail: SMTP for the server that accepts outgoing mail, IMAP and POP3 for the servers your users read mail from. Each one connects, completes the opening handshake of its protocol, sends one harmless command, and hangs up. None of them logs in, and none of them sends or fetches a message.
What It Is For
The submission server your application sends through
Your app sends password resets, receipts and notifications through an SMTP server on port 587. When that server stops answering, nothing in the app breaks visibly — the mail just silently stops. An SMTP monitor checks the greeting, the EHLO exchange and the STARTTLS upgrade on the same schedule as everything else you watch.
The mailbox server your users log into
IMAP on 993 and POP3 on 995 are what every phone and desktop client talks to. Users notice an outage here within minutes and report it as "mail is broken", usually without saying which half. A monitor on each port tells you which one it is before the first ticket arrives.
A mail server you just moved, upgraded or re-secured
Mail servers break quietly after a migration: TLS starts on the wrong port, a renewed certificate is not picked up, STARTTLS disappears from the capability list. These monitors exercise the TLS path on every check, from outside, so a configuration that only works from the office does not look healthy.
Certificate expiry on IMAPS, without a second monitor
An IMAP monitor on port 993 reads the certificate the server presents and stores its dates, issuer and SAN list, exactly like an TLS/SSL monitor would. It can send a "Certificate Expiring" alert on its own. This is true only of IMAP on 993 — the SMTP and POP3 monitors record no certificate at all.
What It Is Not For
These monitors prove the server is up and speaking its protocol. They do not prove anything about mail itself:
| You want to know | Use instead |
|---|---|
| Is my mail actually being delivered, and does it land in the inbox instead of spam? | Nothing in PingZen answers this — see the note below |
| Is the IP I send from listed on a spam blacklist? | DNSBL monitor |
| When does the certificate on my SMTP or POP3 server expire? Neither monitor records certificate dates | TLS/SSL certificate monitor, pointed at the implicit-TLS port — 465 for SMTP, 995 for POP3 |
| Is the webmail interface working? Roundcube can be down while IMAP behind it is perfectly healthy | HTTP / HTTPS monitor |
| Do my MX records still resolve, and do they still point where I think? | DNS monitor, with the record type set to MX |
| Can this account still log in with this password? | Nothing in PingZen — no email monitor authenticates |
| Is port 25 reachable from outside at all, on a server that answers nothing else? | TCP monitor |
On deliverability, be clear-eyed. PingZen never sends a message, never receives one and never reads a mailbox. A green SMTP monitor means the submission server accepted a connection and completed a handshake. It says nothing about whether your mail leaves the queue, survives the recipient’s filters or arrives at all. Deliverability is a different problem with different tools, and no uptime monitor — this one included — measures it.
What an SMTP Check Does
- Connects to the host and port, in plaintext. Port 587 unless the address names another.
- Reads the server’s greeting banner.
- Sends EHLO and reads back the capability list.
- If STARTTLS is enabled and the server advertises it, upgrades the connection to TLS and sends EHLO again over the encrypted channel.
- Sends QUIT and closes.
Three details are worth knowing.
The connection always starts in plaintext. The monitor has no implicit-TLS mode, so it cannot talk to an SMTPS port that expects a TLS handshake as the first thing on the wire. Point an SMTP monitor at 587 or 25, and watch port 465 with an TLS/SSL monitor instead.
A missing STARTTLS does not fail the check. The upgrade happens only when the server offers it. If your server stops advertising STARTTLS after a configuration change, the monitor keeps connecting in plaintext and stays green. The check records whether STARTTLS was offered, but that flag is not stored or shown anywhere today, so do not rely on the monitor to notice the day encryption disappears.
A broken certificate does fail the check. Certificate verification is on by default, so if the STARTTLS upgrade presents an expired, self-signed or wrong-name certificate, the handshake fails and the check goes down. So an SMTP monitor catches a dead certificate — on the day it dies. It has no way to warn you in advance, because it never records the expiry date.
What an IMAP Check Does
- Connects to the host and port. With SSL on, that is implicit TLS on port 993; with SSL off, plain IMAP on 143.
- Waits for the server’s greeting and collects the CAPABILITY tokens the greeting carries.
- Sends NOOP and requires an
OKanswer. - On port 993, reads the TLS certificate and cipher off the connection.
- Sends LOGOUT and closes.
The IMAP monitor never does a STARTTLS upgrade. Plain IMAP on port 143 stays plain for the whole check, even if the server advertises STARTTLS in its capability list. If you want the connection encrypted — and you want the certificate facts — use port 993 with SSL on, which is the default.
The capability list is shown on the monitor page, grouped into protocol, push, auth and TLS features. Some older servers do not put capabilities in the greeting; then the list is simply empty, and that is not a failure. NOOP is what actually proves the server is alive.
What a POP3 Check Does
- Connects to the host and port. With SSL on, that is implicit TLS on port 995; with SSL off, plain POP3 on 110.
- Reads the
+OKwelcome line. - Sends NOOP.
- Sends QUIT and closes.
On port 995 the certificate is always verified, and there is no setting to turn that off. An expired or wrong-name certificate therefore fails the check outright. As with SMTP, that is detection on the day of expiry, not a warning before it: the POP3 monitor records no certificate fields.
The welcome line is read and truncated by the check, but it is not stored or displayed anywhere — it is not a way to watch the server’s version string.
The Certificate: Which Monitor Sees It
This is the part that surprises people, so it is worth stating twice.
| Monitor | What it knows about the certificate |
|---|---|
| IMAP on 993, SSL on | Expiry date, issue date, issuer, subject, SAN list, TLS version, cipher suite and key size. Shown in the same certificate card as an TLS/SSL monitor, and able to alert on expiry |
| IMAP on 143, SSL off | Nothing — there is no TLS on the connection |
| SMTP | Only whether the handshake succeeded. No dates, no issuer, no expiry alert |
| POP3 | Only whether the handshake succeeded. No dates, no issuer, no expiry alert |
On an IMAPS monitor the expiry alert works exactly as it does on an TLS/SSL monitor. When the certificate has fewer days left than the monitor’s critical threshold — 7 by default, and capped at one sixth of the certificate’s own lifetime so a short-lived certificate is not permanently critical — the monitor sends a “Certificate Expiring” alert, at most once every 24 hours. It opens no incident and costs no uptime — the monitor stays green while it warns you. Attach an alert with the Certificate Expiring trigger to receive it.
The warning and critical day counts are not editable in the monitor form for an IMAP monitor. They default to 14 and 7, and changing them means using the REST API or the MCP tools.
Credentials Are Not Used
No email monitor logs in. There is no username, no password and no authenticated command in any of the three checks — by design, because a monitor that authenticates every minute is a monitor that eventually locks out an account.
The form used to show Username, Password and Use TLS boxes for SMTP, IMAP and POP3 and send them to a backend that had no such fields and discarded them without a word. Those boxes are gone — an email monitor asks only for the address and the protocol’s own TLS setting.
The settings that do exist — STARTTLS and certificate verification for SMTP, SSL on or off for IMAP and POP3 — are in the form, and also available through the REST API and the MCP tools. Their defaults are the secure ones, so a monitor created without touching them uses STARTTLS with verification on SMTP and implicit TLS on IMAP and POP3.
Status Logic
None of the three monitors has a degraded state, and none of them has a response-time threshold. Every check ends up, down or timed out.
| Result | Status |
|---|---|
| SMTP: connected, EHLO answered, and the STARTTLS upgrade succeeded or was not attempted | UP |
| SMTP: the connection failed, the server dropped the session, it answered with an error code, or the TLS upgrade failed | DOWN |
IMAP: the greeting arrived and NOOP answered OK | UP |
IMAP: NOOP answered anything other than OK, the server aborted the session, the connection was refused, or the network failed | DOWN |
| POP3: the welcome line arrived, NOOP passed and the session closed cleanly | UP |
| POP3: a protocol error, a TLS error, a name that did not resolve, a refused connection, or a socket that timed out inside the session | DOWN |
| Any of the three: the whole check ran out of time | TIMEOUT |
Down and timeout both count as downtime and both open an incident — after the confirmation threshold, three consecutive failing checks by default, so one slow handshake does not page anyone. The “Certificate Expiring” alert on an IMAPS monitor is not downtime and opens nothing.
A note on how the failure message reads: SMTP and IMAP report a timeout as a timeout, while POP3 has two kinds. A socket that times out during the session is recorded as a down check whose message says it timed out; only the outer limit on the whole check produces the TIMEOUT status. Both count as downtime, so this changes the wording on the monitor page, not the arithmetic.
Configuration
Address
Host, optionally with a port: mail.example.com:587. A scheme is accepted and stripped — smtp:// for SMTP, imaps:// or imap:// for IMAP, pop3s:// or pop3:// for POP3. IPv6 goes in brackets. With no port in the address, the check uses 587 for SMTP, 993 for IMAP (143 with SSL off) and 995 for POP3 (110 with SSL off). There is no separate port field in the form for these three: the port lives in the address.
Check interval
60 seconds by default, the same as most protocols. A mail server that is hit once a minute by a monitor notices nothing; the check is one connection with no authentication attempt behind it.
Timeout
Five seconds by default. It bounds each step of the conversation, and a slightly larger outer limit bounds the check as a whole. Greylisting mail servers can be slow to greet a new address, so raise it if a healthy server keeps timing out on the banner.
Use STARTTLS (SMTP)
On by default. The monitor upgrades the connection when the server advertises STARTTLS. Turning it off keeps the whole check in plaintext, which is only useful for an internal relay that has no TLS at all.
Verify TLS certificate (SMTP)
On by default: the certificate presented during the STARTTLS upgrade must be valid and match the hostname. Turn it off for a server with a self-signed certificate — and understand that you have then told the monitor to accept any certificate at all.
Use SSL (IMAP and POP3)
On by default, meaning implicit TLS on 993 and 995. Turning it off switches the default port to 143 or 110 and drops encryption entirely — there is no STARTTLS fallback. On IMAP it also removes the certificate facts, since there is no certificate to read.
Key Features
- Three monitor types covering the sending and receiving halves of a mail system, with nothing installed on the server
- A real protocol handshake on every check — greeting, EHLO or CAPABILITY, NOOP — not just an open port
- STARTTLS negotiated and verified on SMTP, implicit TLS on IMAP and POP3
- Full certificate detail and expiry alerting on IMAPS, in the same card and with the same thresholds as an TLS/SSL monitor
- IMAP capability tokens from the last check, grouped and explained on the monitor page
- Runs from PingZen regions or from your own private probe, which also supports all three protocols
Common Questions
What protocols can I monitor?
PingZen supports 23 protocols: HTTP/HTTPS, WebSocket (WS/WSS), TCP, UDP, ICMP Ping, gRPC, DNS, WHOIS, TLS/SSL certificates, Email (SMTP/IMAP/POP3), FTP/FTPS, DNSBL, PageSpeed, SOCKS5, MTProxy, API Check, and Transaction. You can monitor websites, APIs, servers, databases, and any network service.
How fast can I get alerts?
Telegram alerts are delivered within 1-2 seconds of detection. Slack and Discord notifications arrive almost instantly. You can configure multiple alert channels for redundancy.
Can I organize monitors by project?
Yes! PingZen supports workspaces, which let you organize monitors by project, environment, or team. Each workspace can have its own alert configurations and team members.
Is there an API for automation?
Absolutely. PingZen provides a full REST API with OpenAPI documentation. You can create, update, and delete monitors programmatically.
How do status pages work?
Status pages are public, branded pages showing your services' uptime. You can display real-time status and allow customers to subscribe for updates.
What happens if I reach my monitor limit?
We'll notify you when approaching your limit. You can pause some monitors or contact us for increased capacity. We never stop monitoring without warning, ensuring your critical services stay protected.
Ready to stop missing downtime?
Join thousands of teams who trust PingZen. Setup takes 30 seconds.