SMTP Relay Monitoring: What to Track, What to Alert On, and When to Act

Most organizations spend time configuring their SMTP relay and then assume it's running fine unless something breaks loudly. That assumption is expensive. The problems that matter most — deliverability degradation, IP reputation damage, authentication failures, queue buildup — are usually quiet at first. They show up as small anomalies in metrics that nobody is watching, and by the time they cause visible disruption, they've been running for days.

Active SMTP relay monitoring isn't optional if you care about reliable email delivery. Here's what to track and why each metric matters.

Delivery Rate

Your overall delivery rate — the percentage of outbound messages that are successfully accepted by the receiving server — is the headline metric. But it's not very useful on its own. A delivery rate of 97% looks fine until you realize that the missing 3% is all going to one ISP, and that ISP is Microsoft.

Break your delivery rate down by destination domain or ISP. Track it for Gmail, Microsoft (Outlook, Hotmail, Live), Yahoo, and your other significant destination domains separately. A drop in delivery rate for a specific ISP is a much more actionable signal than a blended number, and it points you toward the right remediation — whether that's a blocklist issue, an authentication problem, or a reputation signal specific to that provider.

Bounce Categories

Not all bounces mean the same thing, and monitoring them as a single number misses most of the signal they carry.

Hard Bounces

A hard bounce means the email address doesn't exist or the receiving server permanently rejected the message. High hard bounce rates signal a list hygiene problem — you're sending to addresses that have never existed, have been deactivated, or are typos. Hard bounces should trigger immediate suppression of the address and, if rates are elevated, an audit of your list acquisition and validation processes.

Most receiving servers start throttling or blocking senders whose hard bounce rates exceed 2–5%. Monitor this daily and alert when the rate climbs.

Soft Bounces

Soft bounces are temporary — full mailboxes, server unavailability, rate limiting. Some soft bounces are expected and normal; your relay should retry them on a schedule. What you're watching for is a pattern: if soft bounces to a specific ISP are climbing, it may indicate that ISP is rate limiting or throttling you as a prelude to blocking. This is an early warning you can act on.

Bounce Codes

SMTP response codes tell you exactly what happened. 421 is a temporary rejection — try again later. 450 and 451 are temporary failures. 550 is a permanent rejection, often accompanied by a message telling you why. 552 and 554 are policy rejections — your message violated a filter rule at the destination.

Log bounce codes with their full response text. When you see a spike in 550 errors from Microsoft with a message referencing a blocklist or spam policy, that tells you exactly what happened and exactly where to look.

Queue Depth and Age

Your SMTP queue depth tells you how many messages are waiting to be delivered. Some queue depth is normal — messages are queued briefly while connections are established and delivery attempted. What you're watching for is sustained queue growth.

If queue depth is increasing over time rather than clearing, something is wrong: a receiving server is throttling you, your relay is overwhelmed, or messages are getting stuck due to a configuration issue. Alert on queue depth that exceeds a baseline threshold and has been growing for more than a few minutes.

Queue age matters separately. A message that's been sitting in the queue for 4 hours is a different problem from one that's been there for 4 minutes. Most relay configurations set a maximum queue lifetime before bouncing undeliverable messages — know what yours is and monitor for messages approaching that limit.

Authentication Failure Rate

Monitor for DKIM signing failures, SPF alignment failures, and DMARC policy rejections. These should be close to zero under normal operation. A spike in DKIM failures often indicates a configuration change went wrong — a new signing key wasn't propagated, or a third-party sending service was added without being authorized in your SPF record.

Authentication failures are particularly dangerous because many of them fail silently on the sending side. The message appears to go out, but the receiving server filters it based on failed authentication. You won't see this as a bounce — you'll see it as a drop in engagement or a complaint from a recipient who expected your email and didn't receive it.

MailDog's DNS security tools can help you audit your authentication configuration and spot misalignments before they cause delivery failures.

Connection and TLS Errors

Track the rate of failed SMTP connection attempts and TLS negotiation failures. Connection failures can indicate network issues, firewall rules blocking outbound connections, or receiving servers rejecting connections from your IP before any message exchange happens.

TLS failures are worth watching separately, especially if you're enforcing TLS for outbound connections. Some older or misconfigured receiving servers don't support TLS properly. A policy that requires TLS and encounters a server that can't negotiate it will result in bounces that look like connectivity failures — logging the TLS handshake outcome makes these diagnosable.

IP Reputation Signals

Check your sending IPs against major blocklists regularly — not just when something breaks. Blocklist monitoring services can check dozens of lists automatically and alert you the moment your IP appears on one. The sooner you know, the sooner you can begin the delisting process and investigate what triggered the listing.

Postmaster tools from Gmail and Microsoft provide reputation data directly from those providers. Google Postmaster Tools shows your domain reputation, IP reputation, spam rate, and authentication results as seen by Gmail. Microsoft's SNDS (Smart Network Data Services) provides similar data for their systems. Both are free to use and essential if Gmail and Microsoft are significant destinations for your email.

Sending Volume Anomalies

Alert on unexpected spikes in outbound volume. A sudden jump in email volume from your relay — especially if it's not correlated with a campaign you scheduled — can indicate a compromised sending account or a misconfigured application sending far more mail than intended. Catching these quickly limits the reputation damage and stops you from sending email you didn't mean to send.

Set a baseline for your normal sending patterns and alert when volume deviates significantly in either direction. Unexpected drops in volume can also indicate a problem — authentication failures, queue issues, or an application that stopped sending event-triggered email.

Building Your Alerting Setup

The goal isn't to watch dashboards all day. It's to set thresholds that trigger alerts automatically so you only need to act when something actually needs attention. Practical alert thresholds for most setups:

• Hard bounce rate > 2% — investigate list quality and address validation
• Delivery rate to any major ISP drops more than 5% — check blocklists and authentication
• Queue depth grows beyond 2× baseline for 15+ minutes — check for throttling or configuration issues
• Any new blocklist listing — immediate investigation and delisting process
• DKIM failure rate > 0.5% — check signing configuration across all sending sources
• Volume spike > 3× normal — check for compromised accounts or misconfigured applications

For teams using MailDog's SMTP relay, delivery event data is accessible via the API and dashboard, giving you the raw material to build these monitoring workflows. If you want to discuss monitoring approaches for your specific sending volume and patterns, reach out — the right monitoring setup depends on your infrastructure and what you're sending.

Logs Are Your Foundation

All of this monitoring depends on having accessible, complete logs. SMTP logs should capture the timestamp, sender address, recipient address, destination server, SMTP response code and text, delivery status, and queue time for every delivery attempt. Without that data, you're reconstructing incidents from memory instead of evidence.

Retain logs long enough to be useful for incident investigation — 30 days is a minimum, 90 days is better for spotting patterns. Index them so you can search efficiently. A delivery problem that happened last Tuesday needs to be diagnosable today, not just when it's actively occurring. For more on maintaining reliable email operations, explore the rest of the MailDog blog.