The reply would not send

What the symptom looks like#

• The reply is on the thread with a failure against it rather than a sent state.
• An entry appears in Needs You, because a message that did not go is a problem for a person.
• Other mailboxes in the same workspace may be sending normally — failures are per mailbox, and often per recipient.
• The customer has received nothing. A failed send is not a delayed send.

This is not the same as a send whose result is unknown. Where the provider neither accepted nor refused — a dropped connection, a timeout after the message may already have been accepted — the state is *uncertain* and is shown as uncertain rather than guessed. That case has its own page: the send result is uncertain.

Three categories, three responses#

One check separates them in a few seconds: try a different recipient from the same mailbox, and the same recipient from a different mailbox. If the mailbox is the constant, it is a credential or a sender problem; if the recipient is the constant, it is an address problem.

The recovery, stage by stage#

1. Trigger — outbound.py hands the message to the provider and the provider refuses it.
2. External event — the refusal comes from the sending provider or from the receiving server, and both are outside Connect.
3. Authentication and workspace resolution — the failure belongs to one mailbox in one workspace, which is what makes 'is it only this mailbox?' a valid first question.
4. Ingest — the refusal is recorded against the message rather than raised and forgotten.
5. Canonical record — the reply survives as a record on the thread; nothing is deleted because a send failed.
6. Classification — recipient, provider, or credential. The response differs for each.
7. Knowledge, memory and rules — unchanged. A failed send teaches nothing by itself, and a repeated failure to one address is a suppression decision rather than a memory.
8. Autonomy and approval — a re-send is a fresh outbound action and passes the same gates, including suppression and the allowance.
9. Action — a person decides to send again, edit and send, or stop.
10. Result — sent with provider evidence, or refused again with the reason recorded.
11. Relationship, timeline and memory — the attempt and its outcome are on the person's timeline, so a colleague can see the reply was tried.
12. Audit, usage and Needs You — the failure is a recorded decision, and the queued entry drains once the message goes or is abandoned.

What Connect did complete#

• The reply was written, and it still exists — text, recipients and thread intact.
• The compliance checks ran before the attempt, so a failure here is not a suppressed recipient in disguise.
• The failure is recorded against the message and surfaced in Needs You rather than being logged and forgotten.
• Nothing was double-sent. A refusal is a definite answer, which is exactly what makes it safer than an uncertain one.

What Connect did not complete#

• The recipient has nothing. No partial delivery exists in email — a refused message did not arrive.
• No write-back happened for that reply, so read state and labels at Gmail do not reflect an answer that never went.
• No follow-up was created from a reply that failed to send; if the message contained a commitment, the commitment is not yet a record.
• Connect did not retry on its own. Automatic re-sending of a refused message is deliberately not a behaviour here.

What you can do, and when to escalate#

1. Read which recipient failed before touching the message.

   Result A single bad address in a multi-recipient reply is fixed by correcting that address, not by re-sending to everyone.

2. Send a test to a colleague from the same mailbox.

   Result You learn in seconds whether the mailbox or the recipient is the problem.

3. For a permanent rejection, stop and record it rather than retrying.

   Result The address is wrong or dead; repeated attempts to a dead address are what damages a sending domain.

4. For a temporary refusal, wait and send once more.

   Result If it succeeds, the provider's evidence is recorded against the message as normal.

An administrator can check whether the sending domain's authentication is in order at the mail host, whether the mailbox has hit a provider-side sending limit, and whether other mailboxes in the workspace are affected. Escalate when sends from a mailbox fail while its credential authenticates and reading works — describe the category, the recipients affected and the timing rather than pasting a provider error that contains identifiers.

Questions#

Related#

• A send that failed
• Proof that a message was sent
• The send result is uncertain
• Sending email
• The recipient is suppressed
• Deliverability
• The mailbox disconnected