Monitoring FTP, SMTP, IMAP, and POP3: Keep Legacy Services Alive

Not everything runs on HTTP. FTP servers handle file transfers for enterprise workflows. SMTP relays route critical transactional emails. IMAP and POP3 servers let employees access their mailboxes. These protocols have been running since the 1970s and 1980s, and they are not going anywhere — they are deeply embedded in business processes, partner integrations, and infrastructure that would cost millions to replace. They are also the services that teams forget to monitor, because modern monitoring tools assume everything is a web endpoint.

The core problem is that legacy protocol failures are invisible to HTTP monitoring. When your SMTP relay goes down at 2 AM, your HTTP monitors stay green while customers silently stop receiving password reset emails and order confirmations. When your FTP server fails, automated file transfers stop flowing, and nobody notices until a downstream system complains about missing data hours later. The web application continues to function. The dashboard looks healthy. But critical business processes have stopped.

SMTP Monitoring

Your transactional emails — password resets, order confirmations, shipping notifications, invoices, two-factor authentication codes — all depend on your SMTP server or relay. When SMTP goes down, the impact is immediate but often goes undetected for hours because the sending application typically queues emails and does not report delivery failures back to the user.

What Monitorion Checks

Monitorion's SMTP monitor connects to your mail server, performs a proper SMTP handshake, and verifies:

• Connection acceptance — the server accepts connections on your configured port (25 for relay, 465 for SMTPS, 587 for submission)
• SMTP banner — the server returns its identity banner, confirming the SMTP service is running, not just the port being open
• STARTTLS support — if configured, verifies that the server offers TLS encryption and the handshake completes successfully
• Authentication — optionally authenticates with test credentials to confirm the auth backend (LDAP, database, local accounts) is operational
• Response latency — measures the time from connection to banner, catching performance degradation before it causes timeouts in sending applications

Setting Up SMTP Monitoring

Go to Monitors → New Monitor → SMTP. Enter your mail server hostname and port. For most configurations:

• Port 587 (submission) — the standard port for applications that send email via authenticated SMTP. Use this to monitor your outbound mail relay.
• Port 465 (SMTPS) — implicit TLS connection. Some legacy configurations still use this.
• Port 25 (relay) — used for server-to-server mail relay. Monitor this if you run an MX server that accepts inbound email.

If your SMTP server requires authentication, provide test credentials. A server that accepts TCP connections but rejects logins is effectively down for your application — testing authentication catches this critical failure mode.

Alert Channel Strategy for Mail Servers

Here is the irony of SMTP monitoring: if your email server is down, email alerts about it being down will not arrive. Always configure a non-email alert channel for SMTP monitors — Slack, SMS, Discord, PagerDuty, or a webhook. This is the single most important alert routing decision you will make.

IMAP and POP3 Monitoring

If your organization runs a self-hosted mail server — Dovecot, Microsoft Exchange, Zimbra, hMailServer — then IMAP and POP3 are how your employees access their email. When these services fail, every email client in the company stops syncing. Most modern setups use IMAP (which syncs across devices), but if you have legacy POP3 clients — older point-of-sale systems, embedded devices, or specific business applications — monitor POP3 as well.

Setting Up Mail Access Monitoring

Go to Monitors → New Monitor → IMAP (or POP3). Configure:

• Hostname — your mail server address (e.g., mail.yourcompany.com)
• Port — 993 for IMAP over SSL, 143 for plain IMAP with STARTTLS, 995 for POP3 over SSL, 110 for plain POP3
• Credentials (optional but recommended) — test username and password to verify full authentication, not just TCP connectivity

The monitor connects, verifies the protocol handshake (the server's greeting banner and capability advertisement), and optionally authenticates. This confirms the entire mail access stack is working — the TCP listener, the TLS layer, the protocol handler, and the authentication backend.

FTP Monitoring

FTP is everywhere in enterprise, even in 2026. Automated file drops from payment processors. Nightly backup transfers to offsite storage. Partner data exchanges in healthcare and finance. When the FTP server goes down, these automated workflows stop silently — there are no users clicking buttons and seeing error messages. The failure only surfaces when downstream systems complain about missing data, sometimes hours or days later.

Setting Up FTP Monitoring

Monitorion's FTP monitor connects to your server, verifies the FTP banner, performs a login (anonymous or authenticated), and optionally confirms that FTPS (FTP over TLS) is available. Go to Monitors → New Monitor → FTP and enter:

• Hostname — your FTP server address
• Port — 21 for standard FTP, 990 for implicit FTPS
• Credentials — use a dedicated monitoring account with minimal permissions (read-only access to a test directory is sufficient)

If your FTP server supports FTPS, enable the TLS option to verify encrypted connections. Many compliance requirements (PCI-DSS, HIPAA) mandate encrypted file transfers — monitoring the TLS handshake ensures you stay compliant.

Monitoring Strategy for Legacy Services

Legacy protocols need a different monitoring approach than HTTP endpoints. Here are the key principles:

• Check interval: 1-5 minutes. These services are critical infrastructure, and failures should be caught fast. A 5-minute interval means maximum 5 minutes of undetected downtime. For mail servers that handle transactional email, consider 1-minute intervals.
• Always test authentication. A server that accepts TCP connections but rejects logins is effectively down for your applications. Port-only monitoring misses this critical failure mode. Always provide test credentials.
• Use non-email alerts for mail servers. Sending an email alert about your email server being down is a circular dependency. Use Slack, SMS, PagerDuty, or webhooks for SMTP, IMAP, and POP3 monitors.
• Add port monitoring as a diagnostic layer. Create a port monitor alongside each protocol-specific monitor. If both fail, it is a network or firewall issue. If only the protocol monitor fails, the application layer has a problem.
• Rely on automatic retries. FTP servers are typically centralized, so multi-region consensus is unnecessary. Monitorion automatically retries failed checks on a different worker, filtering out transient network issues.
• Create a dedicated test account. Never use production credentials for monitoring. Create a read-only account with minimal permissions — this limits the blast radius if credentials are exposed and prevents accidental data modification.

Common Failure Scenarios to Watch For

• TLS certificate expiry on the mail server. The mail server's certificate expires. Encrypted connections fail while plaintext connections still work — the server appears "up" but is broken for production use. Pair protocol monitoring with SSL certificate monitoring on the same hostname.
• Authentication backend failure. The LDAP server or database storing credentials goes down. The server accepts connections but every login fails. Only monitors that test authentication catch this.
• Firewall rule change. A network change blocks the port for specific source IPs. Internal users connect fine, but external partners cannot reach the server. Multi-region monitoring catches this immediately.

All protocol monitors — FTP, SMTP, IMAP, and POP3 — are available on Pro plans. Start monitoring your full infrastructure stack — HTTP endpoints and legacy protocols alike. Your business depends on more than just the web.