SMTP Monitoring

SMTP monitoring connects to your mail server, reads the greeting banner, negotiates EHLO to discover advertised capabilities, and — when STARTTLS is enabled — upgrades the connection and inspects the peer TLS certificate. This makes it suitable for monitoring submission servers, MX relays, and any SMTP endpoint where you care about both reachability and secure-transport health.

Configuration

Required Parameters

Host — Hostname or IP address of the SMTP server. Example: mail.example.com.

Optional Parameters

Port — TCP port to connect to. Default: 25. Common values:

• 25 — MTA-to-MTA relay (default)
• 587 — Mail submission with STARTTLS
• 465 — Implicit TLS (not supported — use port 587 with STARTTLS instead)

EHLO hostname — Hostname the prober announces in the EHLO command. Leave blank to use the probe's own hostname. Useful when your server enforces hostname validation on incoming EHLO.

Upgrade with STARTTLS — When enabled, the prober attempts a STARTTLS upgrade after EHLO if the server advertises the capability. The connection starts plain; the upgrade is performed in-band. Default: off.

Validate certificate during STARTTLS — When STARTTLS is in use, verify the server's TLS certificate (chain, hostname, expiry). Disable only for internal servers with self-signed certificates. Default: on.

Timeout (seconds) — Maximum time allowed for the full check (connect, banner, EHLO, optional STARTTLS). Default: 10.

Check Interval — Monitoring frequency in seconds. Default: 180 s (3 min). Minimum depends on your plan (Free: 300 s, Pro: 60 s, Team: 30 s, Enterprise: 10 s).

How It Works

Each check runs the following sequence:

1. TCP connect — Opens a plain TCP connection to host:port.
2. Read banner — Waits for the server's greeting line. The reply code (typically 220) and banner text are recorded.
3. EHLO — Sends EHLO <hostname> and parses the response. The first line identifies the server's greeting hostname; subsequent lines are the advertised ESMTP extension keywords (e.g., SIZE, STARTTLS, AUTH, 8BITMIME).
4. STARTTLS upgrade — If "Upgrade with STARTTLS" is enabled and the server advertised STARTTLS, the prober issues STARTTLS and completes the TLS handshake. The TLS protocol version and peer certificate are then extracted and included in the result.
5. QUIT — Gracefully closes the session.

Connection time through to receiving the banner is recorded as response_time_ms. Only TCP-level failures (refused, timeout, unreachable) mark the check as unreachable. A non-2xx banner code keeps the check reachable but triggers the default banner-code assertions.

Assertions / Response Validation

UptimeHunt evaluates assertions against the SMTP response envelope. Without any custom assertions the default checks are:

• Banner code is in the 200–299 range (severity: down if not met).

You can add custom assertions in the Expectations tab of the service detail page.

smtp_banner_code — Banner code equals

Checks that the initial greeting reply code equals an exact integer value.

Example: assert 220 to require the standard SMTP-ready greeting.

smtp_banner — Banner contains

Checks that the banner text string contains a substring. Useful for asserting that a specific hostname or software name appears in the greeting.

Example: assert mail.example.com to verify the correct server is responding.

smtp_capability — Advertises capability

Checks that the ESMTP capability list returned by EHLO contains a given keyword. Capability keywords are normalised to uppercase (e.g., STARTTLS, AUTH, SIZE).

Example: assert AUTH to verify the server advertises authentication support.

smtp_starttls — STARTTLS offered

Checks whether the server advertised STARTTLS as an ESMTP extension. This assertion evaluates the capability advertisement, independent of whether the prober actually upgraded the connection.

Example: assert true so the service goes degraded if STARTTLS disappears from the advertisement.

smtp_cert_expiry_days — Certificate valid for at least N days

Checks that the TLS certificate obtained during STARTTLS will not expire within N days. This assertion only produces a result when the prober performed a STARTTLS upgrade and obtained a certificate; it is silently skipped on plain-text checks.

Example: assert 30 to go degraded when the mail TLS certificate has fewer than 30 days remaining — giving you time to renew before clients start seeing TLS errors.

Examples

Port 25 availability check

Monitor an MX relay for basic SMTP reachability. No STARTTLS — just verify the server responds with a valid greeting.

Name:     MX Relay – mx1.example.com
Host:     mx1.example.com
Port:     25
STARTTLS: off
Interval: 3 minutes

Add assertion: smtp_banner_code equals 220 (severity: down) to require the standard ready-greeting code.

Submission server on port 587 with STARTTLS

Monitor a user-facing submission server and assert that STARTTLS is offered and the certificate is not about to expire.

Name:               SMTP Submission – mail.example.com
Host:               mail.example.com
Port:               587
STARTTLS:           on
Validate cert:      on
Timeout:            10 s
Interval:           3 minutes

Recommended assertions:

• smtp_starttls equals true (severity: down) — submission servers must offer STARTTLS.
• smtp_cert_expiry_days ≥ 30 (severity: degraded) — alert 30 days before the cert expires.
• smtp_capability contains AUTH (severity: degraded) — verify authentication is advertised.

Internal mail relay with self-signed certificate

For an internal relay that uses a self-signed certificate, disable certificate validation so the STARTTLS upgrade still succeeds and you can still assert on the cert expiry.

Name:             Internal Relay
Host:             smtp.internal.corp
Port:             587
STARTTLS:         on
Validate cert:    off
Interval:         5 minutes

Troubleshooting

Connection refused / timeout

The probe could not open a TCP connection to the host and port. Verify the server is running, the correct port is set, and that firewall rules permit inbound connections from the probe locations shown in the check details.

Banner code outside 200–299

The server responded but returned an error code. The check is marked reachable but the default assertions fail. Check the banner text in the check detail view for the server's reason.

STARTTLS upgrade failed

The prober successfully connected and read the banner but the TLS handshake failed. Common causes: certificate hostname mismatch (check that host matches the cert's Common Name or SAN), expired certificate, or a TLS version mismatch. Enable "Validate cert: off" temporarily to isolate whether the issue is certificate-trust vs. connectivity.

smtp_cert_expiry_days not evaluated

This assertion requires "Upgrade with STARTTLS" to be enabled. If the server does not advertise STARTTLS (check has_starttls in the check detail), the upgrade is skipped and no certificate is collected.

Related Documentation

• Service Details
• Services Management
• Creating Your First Service
• HTTP Monitoring