Monitoring an email server means watching three distinct layers – the SMTP delivery pipeline, IMAP/POP3 client access, and the message queue that sits between them – and email server monitoring fails most often when teams only check one of these and assume the rest is fine. A mail server can accept connections perfectly while its queue silently backs up for hours, and nobody notices until a customer calls asking why their invoice never arrived.
Why email monitoring gets overlooked
Email is one of those services that “just works” until it doesn’t, so it rarely gets the same monitoring attention as web servers or databases. Teams set up a basic port check on 25 or 587, see it return green, and move on.
The problem is that a listening port tells you almost nothing about actual mail flow. SMTP can accept a connection, complete a TLS handshake, and still fail to relay a single message if the queue is stuck, DNS resolution for the destination MX is broken, or a downstream spam filter is greylisting everything. Port monitoring alone catches maybe a third of the failure modes that actually take down mail delivery.
SMTP monitoring – what actually needs checking
SMTP health has layers that go well beyond “can I connect.”
Connection and banner checks confirm the daemon is up and responding with the expected greeting. This is the baseline every setup should have, similar to basic port monitoring for any TCP service.
Authentication testing verifies that a real send attempt with valid credentials succeeds, not just that the port answers. This catches cases where TLS certificate expiry or a misconfigured auth backend blocks legitimate senders while the port stays open.
Relay and delivery testing is the step most setups skip. Sending a synthetic test message end-to-end and confirming it lands in a mailbox within an expected window (say, under two minutes) catches queue backups, DNS/MX resolution failures, and downstream filtering issues that a simple connect test never will.
TLS certificate expiry deserves its own check, separate from delivery testing, since a cert quietly expiring on a Friday night is a classic weekend-ruining incident.
IMAP and POP3 – the access side
SMTP can be perfectly healthy while nobody can actually read their mail. IMAP and POP3 need their own checks:
– Connection and login test with a dedicated monitoring mailbox – not a real user’s account
– Folder listing response time – slow LIST or SELECT responses often precede a full IMAP daemon stall
– Session count and concurrent connection limits, since IMAP servers commonly cap simultaneous connections per backend process and quietly reject new ones once the cap is hit
– Search and fetch latency for larger mailboxes, since IMAP performance degrades non-linearly as mailbox size grows on some backends
A common mistake here is monitoring IMAP with a generic port check and calling it done. IMAP daemons can accept TCP connections and hang on the actual protocol handshake, especially under memory pressure or when the mailbox backend (Maildir on a slow disk, for example) is struggling.
Queue health – the part everyone underestimates
The mail queue is where problems accumulate silently. A queue of a few hundred messages during a legitimate bulk send is normal; the same number sitting there for six hours because of a stuck greylisting response or a downstream server refusing connections is an outage in progress.
Metrics worth tracking:
– Queue depth over time – not just a snapshot, but the trend. A queue that grows steadily for 30 minutes is a leading indicator, not a lagging one
– Oldest message age in queue – this is often more useful than raw count, since a queue of 50 messages that are all 4 hours old is worse than a queue of 2,000 messages that clear within 10 minutes
– Deferred vs. active message ratio – a spike in deferred mail usually points to a specific destination domain rejecting or throttling, not a general server problem
– Bounce rate trend – a sudden jump often signals a blocklisting event, which needs a different response than a queue backup
A practical example: a mid-sized company running Postfix noticed nightly report emails arriving late. The port check was green the entire time. It turned out the queue was accumulating during business hours because one client domain’s mail server had started greylisting, and Postfix’s retry interval meant messages sat for 45+ minutes before redelivery attempts succeeded. Nothing was “down,” but queue age monitoring would have flagged the pattern within the first hour instead of after a week of complaints.
Setting thresholds that mean something
Generic thresholds like “alert if queue > 100” break down fast because normal queue size varies wildly by mail volume and time of day. Establish a baseline first – what does queue depth look like on a normal Tuesday afternoon vs. a normal Sunday night – before setting alert levels. This is the same baseline-first approach that applies to CPU, memory, or any other metric prone to natural variance.
For queue age specifically, alert on rate of change as well as absolute value. A queue that’s growing 20 messages per minute is more urgent than a static queue of 500 that’s been slowly clearing all along.
Common misconception: uptime monitoring is enough
The biggest myth around email monitoring is that if the mail server shows as “up” in an uptime tool, delivery is working. Uptime monitoring confirms a port responds – it says nothing about whether messages are actually being accepted, queued sanely, relayed, and delivered within a reasonable time.
This distinction matters enough that it’s worth treating email as a case where external and internal monitoring need to work together: external checks confirm the service is reachable, while internal metrics on queue depth, deferred mail, and daemon resource usage show whether it’s actually functioning correctly.
Putting it together with agent-based monitoring
Because queue depth, process health, and disk usage for mail spools are all local metrics, an agent running directly on the mail server gives far more accurate data than external checks alone. CPU spikes during large attachment processing, disk filling up under /var/spool/mail, or a spam filter process consuming all available memory are all things an external SMTP probe simply can’t see. Combining synthetic send/receive tests from outside with local agent metrics for queue and resource monitoring covers both angles without redundant tooling.
Frequently asked questions
How often should synthetic email delivery tests run?
Every 5 to 15 minutes is typical for production mail servers. Faster intervals rarely add value since SMTP retry logic already introduces delays measured in minutes, and testing too frequently can itself trigger rate limiting on strict receiving servers.
What’s a reasonable queue age threshold before alerting?
There’s no universal number, but many teams start alerting when the oldest message in the active queue exceeds 30 minutes, since that usually indicates a delivery problem rather than normal processing delay. Adjust based on your own baseline data.
Can queue monitoring predict blocklisting before it fully happens?
Not directly, but a sharp rise in deferred messages to a specific destination combined with an uptick in 4xx temporary rejection codes is often an early sign of a receiving server tightening its filters – worth investigating before it escalates to a full block.
Email delivery problems rarely announce themselves with a service outage; they show up as a slow accumulation of delayed or bounced messages that nobody notices until someone complains. Watching SMTP delivery, IMAP access, and queue trends together – rather than relying on a single port check – is what actually catches these issues while they’re still small.