# Email

> Turn a support mailbox into a contact-center channel. Mail is collected by the platform, threaded, and routed to agents by the same skills that route calls.

Point the platform at the address your customers already write to. New mail is
collected from the mailbox, matched to the conversation it belongs to, and
offered to an agent through **the same skill-based routing your calls use** —
the same queues, the same agents, the same wrap-up codes and the same reports.

There is no separate e-mail queue to design and no second set of routing rules
to keep in step with the first. A mail thread is a conversation like any other:
it runs your visual flow, an AI agent can triage or answer it, and it lands on a
human agent's desktop when it needs one.

## When to use it

  - **A shared support address** — `support@`, `billing@`, `orders@` — mail that several people answer today
    out of one inbox, where nobody can tell who has picked up what.
  - **Mail alongside calls and chat** — The same agents already take calls. Routing mail through their skills means
    one set of queues, one occupancy picture, one report.
  - **AI triage before a human** — Let a flow read the mail, answer the routine ones, and queue only what needs
    a person — the same flow builder your IVR uses.
  - **Keeping your existing mailbox** — Nothing moves. Your mail stays where it is, on Microsoft 365, Google
    Workspace, or your own server; the platform reads it.

## How a message becomes a conversation

  1. **The mailbox is checked**
The platform connects to the mailbox on the interval you set and collects
    anything new. Nothing is forwarded and no MX record changes — mail keeps
    arriving exactly where it does today.
  2. **The message is threaded**
A reply is matched to the conversation it belongs to, following the
    threading information the sender's mail client supplies. A customer who
    replies a week later continues the same thread rather than opening a new one.
  3. **Your flow runs**
A new thread starts the routing program set on the mailbox. It can answer,
    ask for details, or queue straight to a skill — the same steps a call flow
    uses.
  4. **An agent answers**
The thread appears in the agent's **Email** screen. They reply in place; the
    answer is sent from the mailbox and lands inside the customer's existing
    thread.

> **NOTE:**
> A mailbox with no routing program still **collects and stores** mail — it simply
> never offers it to an agent. If a newly added mailbox looks silent, this is the
> first thing to check.

## Connecting a mailbox

How you sign in depends on who hosts the mailbox.

| Where the mailbox lives | Sign-in | Notes |
| --- | --- | --- |
| Microsoft 365 / Exchange Online | **OAuth** | Microsoft removed password sign-in for mail access. A password will not work, whatever it is set to. |
| Google Workspace / Gmail | **OAuth** | Same: password sign-in is no longer accepted. |
| Exchange Server (on premises) | Password | IMAP must be enabled on the server; many administrators turn it off by default. |
| Dovecot, Zimbra, cPanel, other | Password | The common case for a self-hosted or shared-hosting mailbox. |

> **WARNING:**
> If a Microsoft 365 or Google mailbox reports that it cannot sign in even though
> the password is correct, the password is not the problem — those providers no
> longer accept one for mail. Switch the mailbox to OAuth.

For an OAuth mailbox you register an application with the provider and supply
its identifier plus an access token that allows **both reading the mailbox and
sending as it**. A token that only allows reading will collect mail and then
fail on the first reply.

### Encryption and ports

Two settings, and the usual values:

- **Incoming** — encrypted on port 993, or upgrade-to-encrypted on port 143.
- **Outgoing** — upgrade-to-encrypted on port 587, or encrypted on port 465.

Choosing no encryption sends the sign-in details in the clear, so it is only
appropriate inside a network you control end to end.

> **NOTE:**
> Collecting mail and sending replies use **different servers** on most providers.
> A mailbox that receives correctly but fails on every reply almost always has the
> outgoing server wrong.

## Read and unread

The **mailbox is the source of truth**, not the console.

That matters because the same mailbox is usually still open in Outlook or Gmail
alongside the console. So:

- Marking a message read in the agent's Email screen marks it read **in the
  mailbox** too.
- Someone reading or un-reading a message in their own mail client is picked up
  on the next check and reflected in the console.

The two cannot drift apart, which is what makes it safe to keep using your
normal mail client during a migration.

## Unwanted mail

Not everything that arrives in a mailbox was written by a person. Every message
is checked against the machine markers its sender's own infrastructure set, and
anything that is not from a person is **kept and shown, but never sent to an
agent**:

| Set aside as | Decided by |
| --- | --- |
| Auto-reply | `Auto-Submitted:` (RFC 3834), or a vendor out-of-office marker |
| Delivery failure | an empty return path, a `MAILER-DAEMON` sender, or a delivery-status report |
| Mailing list | `List-Id` / `List-Unsubscribe`, or `Precedence: bulk` |
| Suspected spam | the provider's own `X-Spam-*` verdict, or a sender that failed its domain's published policy |

This is not a content filter and it makes no judgement about what a message
says. It reads the headers and nothing else, so it cannot mistake a blunt
customer for a spammer.

> **WARNING:**
> **Auto-replies are the important one.** Your routing program can answer mail. If
> it answered an out-of-office, the far side's responder would answer that, and
> the exchange would never end — a loop that gets your mailbox rate-limited or
> blocked by your provider. Setting auto-replies aside is what prevents it.

Nothing is deleted. Set-aside mail appears under **Filtered** in the agent's
Email screen, labelled with which kind it was, so a message held wrongly is
still readable. And a thread stops being filtered the moment a person writes
into it — a customer who replies properly to a thread that began with an
out-of-office reaches an agent normally.

> **NOTE:**
> Your provider's own junk filter still runs first and files spam into a separate
> folder. Because the platform reads the folder you choose — `INBOX` by default —
> most unwanted mail never reaches it at all. The checks above are what catch the
> rest.

## Replies

Agents type the reply and nothing else. The subject line and the threading
information are filled in for you, so the answer appears inside the customer's
original thread instead of starting a new one, and the reply is sent from the
mailbox the thread arrived in.

A reply that the mail server refuses is not lost: it stays in the thread marked
as undelivered, with the reason, so the agent can correct it and try again.

## What it does not do

  - **Attachments** — Attachments are not collected. An agent sees the message text; open the mail
    in a normal client when the attachment matters.
  - **Formatting** — A formatted message is converted to readable text. Layout, images and tables
    are not shown, and the message is labelled so the agent knows.
  - **Outbound campaigns** — This is a conversation channel, not a bulk sender. It answers mail that
    arrives; it does not run mailing lists.
  - **Moving your mail** — Your mailbox stays yours. The platform reads it and replies through it; it
    is not a migration.

## Next

  - **[Set up a mailbox](/modalities/email/console)** — The Mailboxes screen, field by field.
  - **[Skills and routing](/modalities/voice/transport-telephony/pbx-acd)** — How skills, queues and flows work — e-mail uses the same ones.