---
title: Email deliverability monitoring: every check was green and the mail still wasn't arriving
description: SMTP up, mailbox fine, SPF published, and the password resets landed in spam all weekend. Email deliverability monitoring sends real mail to find out.
canonical: https://watchfor.io/blog/email-deliverability-monitoring
---

# Email deliverability monitoring: every check was green and the mail still wasn't arriving

2026-10-20 · WatchFor Team · Email · email, deliverability, smtp, incidents

SMTP up, mailbox fine, SPF published, and the password resets landed in spam all weekend. Email deliverability monitoring sends real mail to find out.

On Friday at 17:40 someone in marketing added a newsletter service to the
company's SPF record. It's a one-line change, the kind you make at the end of
a week. The newsletter went out fine.

On Monday the support queue had forty tickets that all said roughly the same
thing: *I never got the password reset email.* A few said they found it in
spam. Most found nothing at all.

Over the weekend, the monitoring looked like this:

- **The SMTP check was green.** The mail server answered on port 587,
  negotiated TLS, accepted the login and replied `250 OK` to every message.
- **The mailbox check was green.** IMAP logins worked, the certificate was
  valid.
- **The DNS check was green.** The SPF record existed and resolved.

Every one of those checks was correct, and none of them measured the thing
the customers cared about: did the email arrive in their inbox?

This post is about that gap, the failures that live in it, and the one kind
of check that closes it.

## `250 OK` is a receipt, not a delivery

When your SMTP server says `250 OK`, it means one thing: *I have taken
responsibility for this message.* What happens next is out of sight. The
message waits in a queue, hops through one or more relays, and reaches a
receiving server that decides, using SPF, DKIM, DMARC, its spam filter and
its own reputation data, whether it goes to the Inbox, to Spam or nowhere.

An [SMTP monitor](/blog/smtp-monitoring-explained) watches the first step.
An [IMAP or POP3 monitor](/blog/imap-pop3-monitoring) watches the last one,
the mailbox. Both are useful, because when something breaks they tell you
*which* side broke. But mail can fail between them while both stay green.

The only check that sees the whole path is the obvious one: send a real
message and look for it. That's an **email round trip**, and doing it on a
schedule is what email deliverability monitoring means in practice. (How the
test itself works, step by step, is in
[How to test email delivery end to end](/blog/how-to-test-email-delivery).
This post is about what it catches.)

## Five ways mail stops arriving while everything looks fine

### 1. The SPF include that pushed you over ten lookups

SPF allows at most **ten DNS lookups** while a receiver evaluates your record
(RFC 7208). Every `include:` for a mail service costs at least one, and the
services' own records include more. Add one more service and you can cross
the limit without the record looking any different: it's still there, it
still resolves. The receiver stops at lookup eleven and returns a
`permerror`, which DMARC treats as a failure.

That's the Friday story above. Depending on your DMARC policy, the mail goes
to spam or is rejected outright.

- **The green checks say:** the record exists.
- **A round trip says:** SPF did not pass, DMARC did not pass, and the test
  message landed in Spam. Those are the **SPF Failed**, **DMARC Failed** and
  **Landed in Spam** alerts.

You can count your lookups any time with the
[SPF checker](/blog/how-to-check-an-spf-record). The round trip tells you
when it starts to matter.

### 2. A DKIM key rotation that only half happened

Rotating a DKIM key has two halves: publish the new key under a new selector,
switch signing to it, and only then remove the old one. Do them in the wrong
order, or let one half fail quietly in a provider's dashboard, and your mail
is signed with a key the receiver can't find. The signature fails, and with
it, often, DMARC.

- **The green checks say:** the server is up, the DKIM record you looked at
  exists.
- **A round trip says:** the receiving server could not verify the
  signature. That's **DKIM Failed**, usually followed by **Landed in Spam**.

### 3. A queue that stopped draining

Sometimes the message is accepted and then simply waits. The next hop is
rate-limiting you, a relay is deferring mail, or the receiving side is
greylisting new senders and asking them to try again later. Nothing errors.
Mail arrives eventually, minutes or hours late, which for a login code is the
same as not arriving.

- **The green checks say:** `250 OK`, every time.
- **A round trip says:** delivery time is climbing. Turn on **Slow
  Delivery** to hear about it while it's a slowdown; a message that misses the
  delivery timeout altogether counts as not delivered and opens a **Message
  Not Delivered** incident.

### 4. Mail that vanishes

The quietest failure of all: the message is accepted, and it never shows up
anywhere. Not in the Inbox, not in Spam. A provider dropped it, a filter rule
quarantined it out of sight, a forwarding chain broke.

- **The green checks say:** everything is fine, because from every single
  vantage point, it is.
- **A round trip says:** the message was sent and did not arrive in the Inbox
  or the spam folder within the timeout. **Message Not Delivered**, critical,
  on by default.

### 5. A relay hop that dropped encryption

A smarthost gets reconfigured, a backup relay takes over, and one hop on the
path now hands your mail over in plain text. Delivery works. Nobody notices,
because nothing is broken; it's just no longer private.

- **The green checks say:** your server negotiates TLS, so it must be fine.
- **A round trip says:** the delivered message's `Received` headers show a
  hop without TLS. That's the **Unencrypted Relay Hop** alert.

## What it looks like

Here is one round trip in WatchFor: the path the message took, how long each
stage took, and what the receiving server thought of it.

![An email round-trip monitor in WatchFor: the delivery path with each relay hop and whether it was encrypted, the round-trip stages from mailbox login through SMTP TLS, login and send to the delivery wait and deleting the test message, plus the SPF, DKIM and DMARC verdicts and the spam and antivirus results](/blog/email-deliverability-monitoring-delivery.webp)

And here are the alerts. **Message Not Delivered** and **Landed in Spam** are
on from the start; the rest are one switch each.

![The Alerting tab of an email round-trip monitor: Message Not Delivered and Landed in Spam turned on, Slow Delivery, SPF Failed, DKIM Failed, DMARC Failed and Unencrypted Relay Hop available to turn on](/blog/email-deliverability-monitoring-alerts.webp)

| Failure | What the round trip shows | Alert |
| --- | --- | --- |
| SPF over the lookup limit | SPF and DMARC fail, message in Spam | SPF Failed, DMARC Failed, Landed in Spam |
| Broken DKIM rotation | Signature can't be verified | DKIM Failed, Landed in Spam |
| Queue not draining, greylisting | Delivery time climbs, then times out | Slow Delivery, Message Not Delivered |
| Message dropped or quarantined | Not in Inbox or Spam | Message Not Delivered |
| Relay without TLS | A `Received` hop without encryption | Unencrypted Relay Hop |

Because every check sends a real message, the delivery alerts open an
incident only after **two** failing checks in a row, and two good checks
close it. One slow message
doesn't page anyone.

## Setting one up

1. **Create a dedicated test mailbox** if you can: one nobody reads, with no
   personal filters, so the results reflect your mail setup and nothing else.
2. **Point the monitor at the server you actually send through**, with the
   same login your app uses. If your password resets go out through a
   provider, test through that provider.
3. **Use IMAP for the receiving side** if you want the spam-folder check;
   POP3 can only see the Inbox.
4. **Pick an interval.** Every check sends a real message, so the shortest is
   five minutes; ten is a sensible start.

Gmail needs an app password for both sides. Microsoft 365 has turned off
password logins for IMAP and POP3, so it can't be the receiving mailbox
today. The [docs](/docs/monitors/email-round-trip) cover every setting.

## What a round trip doesn't tell you

It's honest to say what this check can't do:

- **It's one mailbox's view.** It tells you how *your test mailbox's* server
  treated the message. Gmail, Outlook and a small company's filter may each
  decide differently. It's a canary, not a survey of every inbox on earth.
- **Verdicts need headers.** SPF, DKIM, DMARC and the spam score come from
  headers the receiving server writes. If it writes none, those values are
  missing and the rules on them stay quiet.
- **It doesn't replace the layer checks.** When the round trip fails, the
  [SMTP](/blog/smtp-monitoring-explained) and
  [mailbox](/blog/imap-pop3-monitoring) monitors, and a look at your records
  with the [email policy checker](/email-policy-checker), tell you where to
  start.

## The other Friday

Run the weekend again with a round trip every ten minutes. At 17:52, twelve
minutes after the SPF change, the second failing check opens an incident:
*SPF Failed, Landed in Spam.* Someone looks at the record, sees eleven
lookups, swaps one include for the service's IP range, and the next two
checks come back from the Inbox. The incident closes before anyone has left
for the weekend. Monday's queue is empty.

That's the whole idea: don't wait for customers to tell you the mail isn't
arriving. Send some yourself, and check.

[Set up an email round-trip monitor](/email-round-trip-monitoring), or read
[why emails go to spam](/blog/why-emails-go-to-spam) if you're already there.

---

Canonical page: https://watchfor.io/blog/email-deliverability-monitoring · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt