Connect your mailbox

Which path is yours#

Attaching it#

1. Open #/mailboxes and start adding a mailbox.

   Result You are asked which kind of account it is, which decides the path you take next.

2. For Gmail or Microsoft, complete the provider's own consent screen. For IMAP/SMTP, enter the server details for both directions — reading and sending are separate settings and can be separate hosts.

   Result The mailbox appears in the list. Connection is only the first claim; health is the one that matters.

3. Give the mailbox a role and a signature.

   Result The role is what distinguishes a sales address from a support one, and it is used when Connect decides which mailbox a reply belongs to. That choice is not editable from a held draft later, so it is worth getting right now.

4. Set the mailbox's own autonomy if it should differ from the channel's.

   Result You have created an endpoint-scoped rule, which beats the channel rule for this mailbox only.

5. Wait for the first sync, then open #/inbox.

   Result Conversations appear with senders resolved to people, not raw addresses — that resolution is what later lets a call and an email from the same person share one record.

Proving it worked#

'Connected' means the credentials were accepted. It does not mean mail is flowing, which is why the Mailboxes screen reports health separately. Two things are worth confirming before you trust the connection:

• Recent messages, not just old ones. A sync that fetched history but has stopped following new mail looks healthy in the conversation list and is not.
• A message you can account for. Send yourself something from another address and find it — that closes the loop between the provider and the canonical conversation record.

Mail deliberately exists twice inside Connect: the provider adapter stores what it fetched in the provider's own shape, and a bridge copies it into the canonical threads and messages the engine and the screens read. The engine never reads the provider tables. That is why adding a second provider later changes nothing about how anything downstream behaves.

When it does not work#

Consent completes, no mail arrives

The account consented but the required scopes were not all granted. Re-running consent is the fix; partial scopes fail quietly rather than loudly.

IMAP reads, SMTP refuses

Reading and sending are configured separately and frequently have different hosts, ports and rules. A mailbox in this state will draft and never send.

Mail stops after a while

The fetch cursor is the usual cause. How a mail cursor loses messages explains the failure and how it is prevented.

Everything works, nothing is sent

Check autonomy before checking the mailbox. draft_only and ask_before_send both produce a written reply that stays put.

Sending stops mid-day

A plan's daily allowance can be spent. The approval is still recorded and the send waits rather than being lost.

An administrator who needs to see what a mailbox is doing has the decision log on #/autonomy-audit, which records refusals as well as actions — a refusal is a decision, and a mailbox that is quiet for a good reason looks identical to a broken one until you can see that reason written down.

Questions#

Related#

• Your first hour
• Email in Connect
• Add a second mailbox
• Why 'connected' is not enough to prove mailbox health
• How a mail cursor loses messages, and how to stop it
• Decide what Connect may do