# Connected email

Mailbox sign-in is separate from signing in to Ralti.

Open Email → Add account and choose Microsoft 365/Outlook, Gmail/Google Workspace, or IMAP/SMTP. Administrators may need to configure the provider registration first. An unavailable provider explains its setup state. Select one mailbox or all connected mailboxes after the initial synchronization.

## Connect and verify

- Authorize the intended provider account, or enter its approved server settings and app password when required.
- For password-based connections, the wizard checks authentication and discovers folders before saving. Verification does not send a test message.
- Wait for initial synchronization or use the visible retry. Large mailboxes may need several passes.
- Inspect a synthetic message and verify sending with a test recipient before relying on a newly configured mailbox.

## Use email on iPhone and iPad

Open Email from Home or Explore on a phone, or use the sidebar on a wider iPad. Choose the mailbox and folder, open a conversation, then use Conversations to return to the list. Draft and reply controls stay in the shared email workspace. Sending still requires the same confirmation and provider permissions as on desktop.

Connecting Google or Microsoft in the installed iOS app explicitly opens the system authentication browser. Return to Ralti after consent, and keep the same Ralti account active in the app and browser. Canceling a connection does not authorize mailbox access.

## Keep ownership explicit

Mailbox history stays private until its owner explicitly shares a linked conversation. Connecting mail does not copy it into shared sheets or enable AI sorting. Ralti categories are separate from Gmail labels and server folders. Optional incoming AI sorting and AI-designed categories have their own controls. Linking a conversation should be an intentional sharing decision.

## Send with a clear result

Drafts, replies, record links, categories, bulk actions, and the outgoing queue use a common interface, but each account exposes its actual provider capabilities. Sending needs explicit confirmation or an authorized notification job. An ambiguous provider response becomes an unknown state and is not automatically resent; inspect that state before retrying. Provider acceptance is not proof of recipient delivery.

> **Current boundaries** Mail is displayed as plain text. Received attachments are identified, but attachment downloads and outgoing attachments are not implemented. Gmail delegated/shared accounts and sending aliases are not implemented. Microsoft shared mailboxes require explicit authorization.

IMAP/SMTP requires TLS and publicly reachable servers; local mail bridges are unsupported. Folder actions depend on server capabilities, including MOVE. Sync uses bounded polling, not Gmail push or IMAP IDLE. Connection and management use the shared website and installed iOS app. The earlier Android interface does not include this email center.