A send that failed
A failed send is one the provider refused, or one a check refused before the provider saw it. Nothing was delivered. The reason is recorded against the thread and escalated into Needs You, and whether another attempt makes sense depends entirely on which of four classes the failure belongs to.
What you see#
The thread shows the message as failed with a plain-language reason, and an item appears in Needs You. The reason is written for a person: the provider's own error text is not printed to the screen, because it routinely contains addresses, message identifiers and internal hostnames that have no business on a page somebody might screenshot.
What you do not see is a silently emptied queue. A failure that removes work without saying so is the behaviour this design is most careful about, on every channel.
The four classes#
| Class | Typical cause | Another attempt? |
|---|---|---|
| Refused before the provider | The recipient is suppressed, unsubscribed or on do-not-contact | No. Fix the record, or accept the refusal — the Connect Assistant cannot clear a do-not-contact entry |
| Authentication | The mailbox's credentials expired, were revoked, or the account changed | Not until the mailbox is reconnected. Every send from it fails the same way meanwhile |
| Rejected message | Size, an attachment the provider will not carry, an address that is not valid | Only after changing the message. Repeating it unchanged repeats the failure |
| Transient | The provider was unavailable or applying a limit of its own | Yes, later. This is the only class where waiting is the fix |
Reading the class first saves the usual wasted half hour. An authentication failure looks exactly like a transient one from inside a single thread — a message that did not go — and behaves completely differently: it will not clear on its own, and it is failing every other message in that mailbox at the same time.
What Connect completed, and what it did not#
- Completed
- The message was written, checked and recorded. The thread, the decision and the reason all exist. If it was a follow-up, the commitment stays open rather than being closed as done.
- Completed
- All the inbound work on that thread — the customer's message was still read, canonicalised, triaged and available. A send failure does not roll back reading.
- Not completed
- Nothing left the mailbox. No partial delivery, no half-sent message, and nothing for the recipient to have seen.
- Not completed
- The allowance was not consumed by a send that did not happen.
Clearing it#
- Read the class, not the thread. Open the mailboxes screen. If other messages from the same mailbox are failing, it is the connection rather than this reply.
- For authentication, reconnect the mailbox — described on Connecting Gmail and its Microsoft and IMAP equivalents. Everything queued behind it clears afterwards.
- For a rejected message, change the message. Usually the attachment. Editing and sending again is a new send with its own evidence.
- For a compliance refusal, respect it. The entry exists because somebody asked for it, or because an earlier message bounced. The suppression list explains which entries may be cleared and by whom.
- For a transient failure, try later. If it recurs across mailboxes and providers, it is not the provider.
Escalate to an administrator when the mailbox needs reconnecting, when a compliance entry looks wrong, or when failures span more than one provider — that last pattern points at the workspace's configuration rather than at any mail service.
Questions#
Was the customer told anything?
No. A failed send never reaches a provider, so there is no message, no notice to them and nothing in their inbox. From their side the only symptom is silence, which is why the Needs You item matters.
Does a failure count against the daily allowance?
A send that did not happen does not consume it. A refusal caused by the allowance itself is a different thing — the work is held rather than failed, and the read cursor deliberately does not advance. The daily email allowance covers it.
Why does the screen not show the provider's exact error?
Because those strings carry identifiers — addresses, message ids, internal hostnames — and a support ticket is exactly where they end up being pasted. The class and the plain reason are what a person needs in order to act.