SMTP Relay Monitoring: What to Watch, What to Alert On, and When to Act
Why SMTP Relay Monitoring Gets Neglected Until It's Too Late
SMTP relay monitoring is the operational discipline that separates email infrastructure that runs reliably from infrastructure that fails in ways nobody notices until a customer complains. The relay accepts outbound messages from your application, authenticates them, and delivers them to receiving mail servers. When it fails silently — messages queuing without delivery, delivery rates dropping, bounce rates creeping up — the business impact grows before the first alert fires.
Most organizations have some monitoring in place. But "some monitoring" usually means server-level metrics: CPU, memory, disk. What's often missing is application-level monitoring: the signals that tell you whether messages are actually being delivered, to whom, with what latency, and with what error patterns. Server health and delivery health are not the same thing.
The Signals Worth Monitoring
Delivery Rate
The percentage of accepted messages that are successfully delivered. A healthy relay running to clean lists with good sender reputation should deliver at 98–99%+. Drops in delivery rate are the leading signal for most relay problems — authentication failures, IP blocklisting, and recipient server rejections all show up here first. Track delivery rate by destination domain separately: Gmail, Microsoft, and Yahoo problems look different from each other and require different responses.
Queue Depth and Age
The SMTP queue holds messages waiting to be delivered — either because the destination server is temporarily unavailable, a retry is scheduled after a soft failure, or you're being rate-limited. A queue that grows without shrinking is a sign of a delivery problem. Queue age matters as much as depth: messages queued for hours are a warning sign even if the total count looks low.
Bounce Rate by Type
Hard bounces (permanent delivery failures — invalid address, domain doesn't exist) should be near zero on a well-maintained list. A hard bounce rate above 2% signals a list quality problem that needs immediate attention. Soft bounces (temporary failures — mailbox full, server temporarily unavailable) are normal at low levels, but a spike in soft bounces from a specific provider is often the first sign that provider is rate-limiting or filtering your messages.
Authentication Pass Rate
Every message leaving your relay should pass DKIM signing and SPF alignment checks. Monitor the authentication pass rate on outbound messages. A drop — even a partial one — means some messages are leaving unsigned or with a broken SPF record, which will hurt deliverability across all recipients. Authentication failures are also visible in DMARC aggregate reports if you have a DMARC policy configured. For setup guidance, see MailDog's DNS security documentation.
Connection Errors and TLS Failures
When the relay attempts to connect to a destination server and the connection is refused, times out, or fails TLS negotiation, the message goes back to the queue for retry. Persistent connection errors to a specific destination domain indicate a problem with that domain's mail infrastructure or a network issue between your relay and them. TLS negotiation failures may indicate an outdated cipher suite or certificate issue on either end.
SMTP Response Code Distribution
SMTP response codes carry specific meanings and monitoring their distribution reveals exactly what's happening during delivery:
250— Message accepted successfully421— Service temporarily unavailable; the remote server is busy or rate-limiting your IP450/451— Temporary failure; retry is appropriate and will usually succeed550— Message permanently rejected; often a blocklist hit, policy rejection, or invalid address552/553— Mailbox or message-level issue; may be a size limit or format rejection
A spike in 550 responses from a major provider is a clear indicator of a reputation problem with that specific provider. A sustained stream of 421 responses suggests you're being rate-limited and should reduce connection concurrency to that domain's servers.
Alert Thresholds Worth Setting
Monitoring data is only useful if someone is notified when something goes wrong. These thresholds are reasonable starting points for most sending environments:
- Delivery rate drops below 95% over any 30-minute window
- Queue age exceeds 2 hours for any message
- Hard bounce rate exceeds 2% in any sending batch
- DKIM signing failures appear at all — this should be zero
- Any
550response from Gmail, Yahoo, or Microsoft that isn't a straightforward invalid-address bounce - Queue depth exceeds twice the normal hourly message volume
Err on the side of false positives rather than missed alerts. An alert that fires when nothing is wrong costs a few minutes of investigation. A missed alert that lets a delivery problem run undetected for 6 hours costs substantially more.
Log Retention and Forensic Analysis
SMTP logs are the source of truth for debugging relay problems. Every connection attempt, authentication event, delivery success, and error response should be logged with enough detail to reconstruct what happened. Log retention should cover at least 30 days so that patterns visible in postmaster reporting can be correlated back to specific sending events that caused them.
At minimum, capture: timestamp, message ID, sender address, recipient domain, SMTP response code, delivery latency, and whether TLS was negotiated. Message IDs allow correlation between application logs, relay logs, and delivery event webhook data.
Integrating Relay Monitoring With Delivery Events
SMTP-level monitoring tells you what the relay is doing. Delivery event webhooks tell you what the receiving mailbox provider does with the message afterward: whether it was delivered, deferred, bounced, or — in some cases — placed in the spam folder. Combining relay monitoring with webhook event data gives you end-to-end visibility across the full delivery pipeline.
MailDog's SMTP relay provides built-in delivery event data and real-time logging, so relay-level and delivery-level signals are available in one place without building a separate collection pipeline. The documentation covers webhook configuration for delivery events. For background on how event data maps to what you'll see in relay logs, see MailDog's guide on email webhooks and delivery event tracking. For high-volume senders building custom monitoring pipelines, the team can advise on which signals to prioritize for your sending patterns.
