SMTP monitors

Prove a mail server is actually serving — not just that the port is open — and watch the certificate on a submission or MX host that a normal HTTPS check would never see. Catch a dead relay or a quietly-expiring mail cert before delivery breaks.

An smtp monitor connects to a mail host, reads its 220 banner, sends EHLO, and — when smtp_starttls is on (the default) — requires the server to advertise and complete STARTTLS. To watch the mail server's TLS certificate expiry instead, use an ssl monitor with ssl_starttls: true pointed at port 587 or 25. Both run on the normal probe schedule and reuse request_timeout_seconds.

What is an SMTP monitor?

A TCP check on port 25 or 587 tells you a socket opened — nothing more. A mail server can accept the connection and still be wedged: no greeting, a broken EHLO, or STARTTLS silently dropped so mail falls back to plaintext. An smtp monitor speaks enough of the protocol to prove the server is genuinely up:

smtp_host — the mail host to connect to, e.g. mx.example.com.
smtp_port — the port to connect on. Defaults to 587 (submission); use 25 for MX.
smtp_starttls — when true (the default), the server must advertise and complete STARTTLS or the probe fails.
smtp_expect_banner — optional substring the 220 greeting must contain (max 255). Leave blank to accept any 220.
smtp_banner — the greeting line captured on the most recent probe; read-only.

Create — submission host

curl -X POST https://api.nightlamp.app/apps/$APP_ID/monitors \ -H "Authorization: Bearer $NIGHTLAMP_API_KEY" \ -H "Content-Type: application/json" \ -d '{"name":"Submission host","check_type":"smtp", "smtp_host":"mx.example.com","smtp_port":587, "smtp_starttls":true}'

What the probe proves beyond a port check

The probe walks the opening of an SMTP conversation and fails at the first thing that doesn't hold:

Banner — the server must return a 220 greeting within the timeout. A connection that opens but never greets is a wedged server a TCP check would call healthy.
EHLO — the server must accept EHLO and respond, proving it speaks ESMTP rather than just holding a socket open.
STARTTLS — with smtp_starttls on, the EHLO response must advertise STARTTLS and the upgrade must complete. This catches a relay that has quietly stopped offering TLS so mail downgrades to plaintext.

Use smtp_expect_banner when you want to be sure the right host is answering — pin your MTA name or hostname so a misrouted port or a substituted server fails instead of passing on a generic 220:

Pin the banner

# Pin the greeting — fail if a wrong server answers the port. The check # passes only when the 220 banner CONTAINS this substring. { "smtp_host": "mx.example.com", "smtp_port": 587, "smtp_starttls": true, "smtp_expect_banner": "mx.example.com ESMTP" }

For an inbound MX host the probe is identical — just point it at port 25, where STARTTLS is still expected:

MX on port 25

# MX host on port 25 — same probe, STARTTLS still required. { "smtp_host": "mx.example.com", "smtp_port": 25, "smtp_starttls": true }

Port 465 is implicit TLS (no STARTTLS handshake). For 465, use an ssl monitor without ssl_starttls, or a plain tcp check.

Watching a mail certificate's expiry

A normal ssl monitor does an implicit TLS handshake — great for 443, useless for a mail host that starts in plaintext and only upgrades with STARTTLS. So the submission and MX certs that your deliverability quietly depends on never get watched.

Set ssl_starttls: true and the SSL check fetches the leaf cert over STARTTLS instead, then watches its expiry, key strength, and warning window exactly as it would for a 443 cert. STARTTLS lives on 587 and 25, not 443, so point ssl_port at the mail port — in the UI, enabling the toggle defaults the port to 587 for you:

Create — submission cert expiry

curl -X POST https://api.nightlamp.app/apps/$APP_ID/monitors \ -H "Authorization: Bearer $NIGHTLAMP_API_KEY" \ -H "Content-Type: application/json" \ -d '{"name":"Submission cert expiry","check_type":"ssl", "ssl_host":"mx.example.com","ssl_port":587, "ssl_starttls":true,"ssl_warn_days":14}'

This is a separate concern from the smtp check: use smtp to prove the server answers, and ssl with ssl_starttls to prove its certificate isn't about to expire. Many mail hosts warrant both.

When does Nightlamp open an incident?

An smtp probe fails — and an incident opens through the normal alert pipeline — when the host doesn't return a 220 banner, rejects EHLO, fails to complete STARTTLS while it's required, doesn't contain the expected banner substring, or times out. When the next probe completes the handshake cleanly, the incident resolves automatically. Create the monitor like any other — pick SMTP server as the type — and its check-type is fixed after creation, while the host, port, STARTTLS requirement, expected banner, and interval stay editable.