A dead inbound mailbox no longer hides

A mailbox that has stopped receiving mail now reports as failing. It used to keep reporting healthy, which meant replies stopped being detected and nothing said so.

What changed

Sending and receiving are separate. A mailbox can send perfectly while its inbound connection is broken, and the two failures look nothing alike from the outside.

Connector status only reflected sending. A mailbox that could send was healthy, whatever was happening on the receiving side. So a broken inbound connection showed a green mailbox, and the only symptom was replies not appearing.

That symptom is easy to misread. A quiet week looks like a quiet week. Nobody's first thought is that the mailbox has stopped listening.

Inbound now has its own health, based on when the mailbox last successfully connected to receive. When that goes stale, the connector reports failing and names the inbound side as the cause.

Why it matters

A missed reply is the most expensive failure in outreach. Everything before it, the research, the writing, the sending, exists to produce a reply. Losing the reply after it arrives wastes all of it.

It also damages the conversation with the person who replied. From their side they answered and heard nothing back. By the time the connection is fixed and the backlog arrives, the message you send is days late with no explanation.

Follow up sequences make it worse. A campaign that has not seen a reply carries on with its next scheduled message, so someone who wrote back receives a follow up that ignores what they said.

How to use it

Nothing to switch on. Inbound health is checked continuously and appears on the connector alongside sending status.

A failing inbound connection appears in the connectors list with the reason. The usual causes are an expired password, a revoked app password, or a provider that has changed its access requirements.

Reconnect the mailbox and receiving resumes. Anything that arrived while the connection was down is fetched when it comes back, so nothing is permanently lost.

What a failure looks like

Most inbound failures are authentication. App passwords expire, get revoked, or stop working after a security change on the provider's side. The connector will say the mailbox could not authenticate.

Some are provider policy. Providers periodically tighten what they allow, and a connection that worked for a year stops without warning.

A few are connection problems that clear on their own. Those do not raise a failure, because the health check tolerates a gap before deciding something is actually wrong.

Checking a mailbox is genuinely alive

Send a message to the mailbox from an address outside the product. If it appears in the product within a few minutes, receiving works.

Do this after any change to the mailbox's password or security settings, and after any provider notification about access policy. Those are the two events that break inbound most often.

For a mailbox that matters, the check is worth doing occasionally even when everything looks fine. It takes a minute and it is the only test that proves the whole path works.

While a mailbox is down

Sending continues if the sending side is still working. This is deliberate. Stopping sending because receiving broke would turn one problem into two.

Follow ups continue too, which is the uncomfortable part. If someone replied while the connection was down, they may receive a follow up that ignores their reply. This is why the failure being visible matters more than it might sound.

When the connection returns, the backlog is fetched and replies are matched to their campaigns, so the record ends up correct even though the timing was not.

Why sending and receiving fail separately

They are different connections doing different things, often over different protocols and sometimes with different credentials. Sending pushes a message out through one route. Receiving connects in to a mailbox and reads what has arrived through another.

A provider can restrict one without touching the other, and routinely does. Security tightening tends to land on the reading side first, because reading a mailbox is the more sensitive permission. So the common failure is exactly the confusing one: a mailbox that sends perfectly and hears nothing.

Treating them as one status was the underlying mistake, and it made the more damaging failure the invisible one.

What happens to replies that arrived while it was down

They are not lost. Mail that arrived at the mailbox while the connection was broken is still sitting in the mailbox, and it is fetched when the connection comes back.

What is lost is time. A reply that sat unseen for two days is answered two days late, and the follow up that went out in the meantime has already told the person you were not paying attention.

Matching still works correctly on recovery. Replies are attached to the right campaign and the right lead, and the campaign stops following up with anyone who wrote back, so the record ends up right even though the timing did not.

Worth checking after a provider notice

Providers send occasional emails about changes to application access, and those emails are the single best predictor of an inbound connection about to break. They are also easy to skim past, because they read like every other policy notice.

When one arrives, test the mailbox. It takes a minute and it catches the failure before it costs a reply rather than after.

Using a separate mailbox for replies

Some teams send from one address and receive at another, usually because a shared inbox is where the team actually works. That arrangement is fine, and the health check follows the connection that is actually reading mail rather than the one on the envelope.

What it cannot do is tell you a reply went somewhere else entirely. If a prospect replies to a personal address rather than the one in the campaign, no health check will find it, because nothing is broken. That one is a routing decision rather than a fault.

Availability

Live now for all mailboxes on all plans. Inbound health appears in the connectors list next to sending status.