SMTP/IMAP round-trip monitoring — prove email actually arrives

The cardinal sin: monitoring port 25/587 only

The default monitoring shape for an email pipeline is a TCP probe on port 25, 465, or 587. The port answers, the SYN/ACK comes back, the monitor flips Up. That probe is useful — see our TCP port monitoring guide — but it is answering a much narrower question than "does email work". Specifically, it is silent about every one of the failure modes that actually breaks transactional email in production:

• Queue accepts, downstream MTA rejects. Your relay replies 250 Ok: queued as ABC123, then ten seconds later silently fails because the next-hop MX returned 550 5.7.1 message rejected. The submission side reports success. The mail never lands.
• SPF fails at the recipient. Your SPF record stopped including a vendor's IP range when you migrated relays. Gmail's SPF check returns fail, the message lands in spam, the TCP probe is green.
• DKIM signature invalid. Someone rotated the DKIM key on the relay but the new public key isn't in DNS yet. Every signed message fails verification downstream. Submission keeps working. Delivery rots.
• DMARC quarantine. Your policy is p=quarantine and an alignment failure on the From: domain sends every probe message into spam. The recipient inbox sees nothing.
• Greylisting. The receiving MTA delays first-time senders for 5 minutes. Your password-reset email arrives after the user has already given up. Nothing in your stack is "down" — everything is working as configured.
• Auth works, rate-limit hit. The relay authenticates, then refuses the message with 451 4.7.0 ... Daily user sending limit exceeded. A TCP probe never issues MAIL FROM and never sees the rate-limit response.
• App Password revoked. An admin rotated the Workspace App Password six weeks ago. Submission has been failing for six weeks. The port is still open.

None of those are TCP-layer problems. None of them show up on a TCP probe. The class of probe you need has to actually speak SMTP, actually submit a message, and ideally actually verify that someone, somewhere, received it.

What "round-trip" actually means

Round-trip email monitoring is a black-box test of the entire pipeline. The probe acts as both sender and recipient — or, at minimum, as one of the two — and measures whether a message put in at one end actually comes out at the other within a bounded time.

The shape is:

1. Submit. Connect to the SMTP submission relay over TLS, authenticate, run the full SMTP transaction (EHLO, MAIL FROM, RCPT TO, DATA, body with a unique marker, terminating dot, await 250, QUIT). Capture the latency of each phase.
2. Poll. Connect to a destination mailbox over IMAP, SELECT the target folder, run UID SEARCH for the marker, and re-poll on a short interval until the message appears or a hard wait budget expires.
3. Measure. Total round-trip latency is submit-start to message-found. Compare against a baseline (typically 5-30s for cloud-to-cloud, longer for self-hosted or cross-region).
4. Inspect. Optionally fetch the headers of the retrieved message and parse Authentication-Results to know whether SPF, DKIM, and DMARC actually passed at the recipient.

That is the difference between "the email server is up" and "email actually arrives". The first answers a question nobody cares about; the second is the question your product makes promises about.

The three probe modes

Not every pipeline can run the full round-trip. The probe needs to fit the side of the pipeline you actually control. Three modes cover the practical cases.

Mode A — Submit-only (SMTP only)

The probe connects to your SMTP relay, runs the full submission transaction, and quits. No IMAP poll. This is submission proof, not delivery proof. Use it when the recipient side isn't yours — you're sending to real customer inboxes through SendGrid, SES, Mailgun, or Postmark — and what you need to assert is "my outbound path is healthy".

A real Mode A transcript looks like this (client lines marked C:, server lines marked S:):

S: 220 smtp.sendgrid.net ESMTP service ready
C: EHLO probe.statuspulse.ai
S: 250-smtp.sendgrid.net Hello probe.statuspulse.ai
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN
S: 250-SIZE 31457280
S: 250 8BITMIME
C: STARTTLS
S: 220 Ready to start TLS
   [TLS handshake]
C: EHLO probe.statuspulse.ai
S: 250-smtp.sendgrid.net Hello probe.statuspulse.ai
S: 250 AUTH PLAIN LOGIN
C: AUTH PLAIN AGFwaWtleQBTRy54...
S: 235 Authentication successful
C: MAIL FROM:<noreply@example.com>
S: 250 Sender address accepted
C: RCPT TO:<probe-inbox@example.com>
S: 250 Recipient address accepted
C: DATA
S: 354 Continue
C: Subject: StatusPulse-Probe-7c4a8e2f
C: From: noreply@example.com
C: ...
C: .
S: 250 Ok: queued as 9F2A1B
C: QUIT
S: 221 Bye

Mode A catches: relay unreachable, TLS handshake broken, credentials revoked, MAIL FROM rejected for an unverified identity (SES is strict), RCPT TO rejected, rate-limit reached. Everything before the message leaves your relay.

Mode B — IMAP-poll-only (retrieval only)

The inverse. The probe doesn't submit; it polls an inbox and asserts somebody else's messages keep arriving. Useful when you don't own the sender — verifying a third-party SaaS keeps sending notifications to a mailbox you own, or that an inbound contact-form pipeline is delivering into your support inbox. Less common than A or C; the assertion is "a message matching subject X arrived within T minutes", and the probe goes Down when the inbox falls silent.

Mode C — Round-trip + auth

The full picture. The probe submits via SMTP, polls via IMAP until the unique-marker message arrives, then parses the Authentication-Results header to verify SPF, DKIM, and DMARC passed at the recipient. This is the mode that catches deliverability rot — the slow-burn failures that don't outright break delivery but degrade reputation until Gmail starts spam-foldering everything.

Use Mode C when:

• You own the sender domain and care about deliverability.
• You can spin up a mailbox at an independent provider (Gmail/Workspace, Microsoft 365, FastMail) — somewhere with no incentive to be lenient about your auth posture.
• You've ever had a DKIM rotation break delivery, or want to make sure you never do.

The marker pattern

One detail makes or breaks the IMAP-poll side of the probe: how do you know which message is yours? The mailbox you're polling has other messages in it — older probe runs, real mail if the mailbox isn't dedicated, system notifications. Searching by subject "StatusPulse Probe" matches every run that ever happened.

The fix is a per-run unique token, embedded in both the subject and the body, generated fresh for every probe execution. Something like StatusPulse-Probe-7c4a8e2f — short, URL-safe, with enough entropy that two concurrent probe runs can't collide. On the retrieval side the probe runs:

A001 SELECT INBOX
* 1247 EXISTS
A001 OK [READ-WRITE] SELECT completed
A002 UID SEARCH SUBJECT "StatusPulse-Probe-7c4a8e2f"
* SEARCH 1248
A002 OK SEARCH completed
A003 UID FETCH 1248 (BODY[HEADER])

UID SEARCH is server-side and O(1) regardless of mailbox size. The probe knows it found this run's message — not last hour's, not yesterday's. Markers in subject and body matter because some receiving systems strip or normalise subject lines for spam scoring; matching against either field makes the probe robust to that.

One consequence: the probe mailbox accumulates messages. The probe doesn't auto-delete them — that would create a moving target for debugging when something goes wrong. Set up a server-side filter on the probe mailbox to auto-archive or auto-delete probe messages older than 7 days. Gmail filters on a substring of the marker prefix and a "delete after N days" rule cover this in two clicks.

SPF / DKIM / DMARC alignment

Once the probe has retrieved its own message back from the destination mailbox, the most valuable artifact in that message is the Authentication-Results header — written by the receiving MTA, telling you what its verifier thought of your authentication. A real one from Gmail looks like:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s2026 header.b=Hk2pQ9aF;
       spf=pass (google.com: domain of noreply@example.com designates
            167.89.115.34 as permitted sender) smtp.mailfrom=noreply@example.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Three verdicts, three independent failure surfaces.

• SPF — does the sending IP appear in the v=spf1 TXT record at the envelope-from domain? Multi-relay setups (SendGrid as primary, SES as failover) softfail when a message goes via a path you forgot to add. The fix is in DNS; see our DNS monitoring guide for catching MX/SPF/DKIM TXT drift directly.
• DKIM — does the signature on the message verify against the public key published at <selector>._domainkey.<domain>? The single most common cause of unexpected dkim=fail is rotation drift: the relay starts signing with a new selector before the DNS publishes the matching key, or the relay keeps signing with an old selector after the DNS was cleaned up.
• DMARC — does the message align? DMARC requires that either SPF or DKIM passes and that the passing domain matches the From: header domain (strict or relaxed alignment). A message can have spf=pass and dkim=pass and still get dmarc=fail because the passing identifier is at a sibling subdomain.

"Partial alignment" is the trap. spf=pass dkim=fail dmarc=pass is valid — DMARC needed only one of the two to align, and SPF did. But you've lost half your defence-in-depth. The probe should report the individual verdicts, not a single rolled-up pass/fail.

Common failure modes

A round-trip probe surfaces failures the TCP probe can't see. The ones that actually show up in production:

• App Password revoked. Gmail and Workspace App Passwords get revoked whenever the account password changes, 2FA is reconfigured, or an admin runs a security review. The probe reports 535 5.7.8 Username and Password not accepted. Mode A catches it immediately.
• OAuth2 token revoked. Microsoft 365 modern auth and Gmail XOAUTH2 tokens can be revoked by an admin or an IdP policy change. Same symptom as an expired App Password.
• Greylisting causing 5-minute delays. Postfix with postgrey, FastMail, and some self-hosted Exchange delay first-time senders for 30s to 5min. The first run from a new path spikes; subsequent runs are fast. Don't treat a single slow run as Down.
• Recipient inbox full. Workspace and 365 enforce per-mailbox quotas; a shared probe mailbox at 100% bounces new mail with 552 5.2.2 Mailbox full. Mode A succeeds, Mode B times out.
• Vendor IP on an RBL. Your relay's outbound IP gets listed on Spamhaus or Barracuda, the receiving MTA silently drops messages, no NDR comes back. Mode B catches it; Mode A doesn't.
• "Authenticated SMTP" disabled on the user. Microsoft 365 has been progressively disabling SMTP AUTH on new tenants. The AUTH rejection looks like bad credentials but is a policy switch upstream.

Setting realistic thresholds

Round-trip latency varies by topology. Cloud-to-cloud (SendGrid → Gmail, SES → Workspace) typically completes in 3-15s. Self-hosted Postfix → Gmail can take 20-60s on a cold connection. Greylisting can push the first run of the day to 5 minutes. If your environment is consistently slower, baseline for two weeks and set thresholds at p95 plus a margin.

• End-to-end < 60 s = Healthy. Cloud pipelines and most well-tuned self-hosted setups comfortably make this. A spike past 60s is informational, not actionable yet.
• 60-300 s = Degraded (greylist suspicion). This is the window where greylisting, anti-spam delay queues, and transient backpressure on the receiving MTA live. Flag it, don't page on it. If it stays Degraded for several runs in a row, that's the signal to investigate.
• > 300 s = Down. If the round-trip is taking more than 5 minutes, something is wrong that user expectations can't tolerate. Most password-reset and magic-link flows assume sub-minute delivery; multi-minute latency is functionally an outage.

Per-phase thresholds matter too, because they tell you where in the pipeline the slowness lives:

• SMTP connect < 2 s — DNS + TCP + TLS handshake to the relay. Slow connects usually mean DNS issues or a relay under load.
• SMTP auth < 1 s — credential verification. Slow auth often means the relay is rate-limiting or back-pressure on the auth service.
• SMTP submit < 3 s — the DATA phase plus the relay's accept.
• Retrieval < 3 s — the IMAP poll cycle itself, independent of how long the message took to arrive.

If you run both, set different intervals. A 1-minute Mode A plus a 15-minute Mode C is a healthy split — fast detection of submission failures, periodic confirmation that delivery still works. Going below 5 minutes on Mode B/C risks probes overlapping themselves under greylist-style latency.

Wrap-up

SMTP monitoring that stops at port 587 tells you the doorman is at his post; it says nothing about whether anyone got past him. The probe shape that actually answers "does email work" submits a real message, polls a real inbox, finds its own message by a unique marker, and reads the Authentication-Results header to verify SPF, DKIM, and DMARC. Three modes cover the practical cases: submit-only for outbound senders, IMAP-poll-only for inbound, and round-trip with auth for the full picture.

The discipline is in the details — a per-run unique marker, a dedicated probe mailbox, per-phase latency budgets, and thresholds set at the realistic p95. Once wired, silent deliverability failures (DKIM rotation drift, RBL listings, DMARC alignment regressions, App Password revocations) surface as alerts the morning after, not as support tickets three weeks later. For per-field reference and vendor-specific recipes (Gmail, Microsoft 365, SES, Postfix), see the Email probe documentation.