The reply went from the wrong address
The sending mailbox is decided by the thread, not by the draft. A reply goes from the mailbox that received the message it answers, and a first message goes from the mailbox whose role covers that kind of work — the primary mailbox when nothing narrower applies. An address you did not expect almost always means the mail arrived somewhere you did not expect, or a role has moved since the thread began.
The symptom, and what it actually means#
A customer replies to something and the reply carries an address you would not have chosen — a personal mailbox instead of the shared one, an old address instead of the current one, or the right address with the wrong signature under it. The message itself is fine. What is wrong is the binding between a conversation and a mailbox, and that binding was made when the thread was created, not when the draft was written.
Connect deliberately does not re-choose an address per message. Changing the from-address halfway through a conversation breaks threading in the recipient's client, splits the history, and makes a person who has already replied twice wonder who they are talking to. Stickiness is the correct behaviour; the wrong mailbox is upstream of it.
Causes, most likely first#
| Cause | How to recognise it | Where it is fixed |
|---|---|---|
| The mail arrived at that mailbox | The thread header names the receiving mailbox; forwarding from a shared address into a personal one is the usual reason | At the provider, by changing where the alias delivers |
| The role moved after the thread began | Newer threads use the right mailbox, older ones do not | Nothing to fix — the old thread keeps its binding on purpose |
| No mailbox holds the role you assumed | Every first message leaves from the same address regardless of subject | Assign the role on the Mailboxes screen |
| The workspace has no primary mailbox | First messages fall back to whichever mailbox can send | Repairing a workspace with no primary mailbox |
| One real inbox exists as two rows | Two entries for one address, or a mailbox you connected that the list never shows | A repair on the next boot, not from a screen |
The last row is the one that looks like a fault in the draft and is not. A mailbox row whose workspace stamp is empty matches no scope, so every list omits it silently while by-id actions on it keep working. Reconnecting that identity writes a second row, and a thread can then bind to either. There is no duplicate warning and no error message to search for; the symptom is a mailbox that behaves as though it exists and appears nowhere.
What Connect completed, and what it did not complete#
- Completed. It resolved a mailbox, composed under that mailbox's signature, applied that mailbox's autonomy rule, passed the send through the one send boundary, and recorded the provider's acknowledgement. The message is genuinely sent, is on the thread, and is on the person's timeline.
- Not completed. It did not verify that the mailbox was the one *you* would have picked — the choice is derived, not proposed for approval, so it never appeared in Needs You. It did not re-send from another address, did not change the thread's binding for future replies, and cannot recall a message a provider has accepted.
Putting it right#
Open the thread and read the mailbox named in its header.
Result You learn whether the mail arrived where you thought. If it did not, the address is a delivery question at the provider, not a Connect setting.
If the recipient needs to know, send one short correction naming the address they should use in future.
Result The correction goes from the same mailbox, keeping the thread intact in their client.
Assign or move the role on the Mailboxes screen so the next new conversation starts in the right place.
Result Role changes take effect for threads created afterwards. Existing threads keep the mailbox they were bound to.
If one contact should always be answered from one address, record that as guidance against the contact.
Result The instruction is durable and survives future conversations, rather than being a note on one message.
What an administrator can do, and when to escalate#
An administrator sees all of it on the Mailboxes screen: which mailbox holds which role, which is primary, and each mailbox's health. Read the health verdicts rather than the connection state — a mailbox can authenticate perfectly and still be the wrong one to send from.
A missing mailbox is not repaired from a screen. Stamping the row from a browser request is refused by the database policy, and forcing it would turn an invisible row into a server error. The repair runs as the schema owner during migration on the next boot, which is why the fix arrives with a restart rather than with a button.
Escalate when an address you connected never appears in the list, when one identity shows twice after a restart, or when replies leave from a mailbox that holds no role at all. Quote the thread and the address; do not quote provider error text, which carries message and account identifiers.
Questions#
Can I change which mailbox an existing thread replies from?
No, and that is deliberate. The binding is what keeps the conversation in one place for the recipient. If a conversation genuinely belongs elsewhere, say so in a short message from the current mailbox and let the next thread start in the right one.
The address was right but the signature was wrong. Is that the same problem?
It is the same shape of problem one step further in. A signature belongs to a mailbox, so a wrong signature under a right address means two mailboxes share an address, or the signature on that mailbox is out of date. Check the mailbox the thread names before changing anything.
Does a role change re-route mail that has already arrived?
No. A role decides which mailbox is chosen for new work. Mail already in a thread stays with the mailbox that received it, and that thread's replies continue to leave from there.