By the Onsites AI team · Last updated · 5-minute read
Email is the channel every team already has, which makes it the one with the most setup choices and the least patience for reading about them. There are exactly three ways to connect a mailbox to your desk — forwarding, your own domain, and IMAP import — and the honest answer is that most teams should start with the first and end with the second, the third being for history. This guide compares them the way you will actually experience them: setup time, how replies look to customers, failure modes, and what switching between them costs later.
The fastest path: keep your existing address (support@, info@, or a fresh alias), set it to forward everything to the desk, and every message becomes a conversation in the shared queue. Setup is a single rule on your mailbox — five minutes, no DNS, no verification, zero risk to your existing email because the original mailbox keeps receiving as always. This is the option to pick in week one, on a free workspace, when the desk's entire value is still being tested.
Its limits are also real. Replies typically go out from an alias rather than the original address, which some customers notice as a mismatch; sender-reputation lives with a forwarding chain you do not fully control; and deliverability debugging — when something lands in spam — has one more link in it than necessary. None of these matters while the team is two people evaluating a free tool. All of them matter by the time the desk is the company's official support address.
Connecting your domain means the desk receives mail at your real addresses and sends replies as you — same domain, same identity, no forwarding link. Setup adds one step: a DNS record you add at your domain's admin panel to verify ownership, minutes to paste and up to a day to propagate in the worst case. From then on, the desk and your domain share one identity: customers write to support@yourcompany.com and are answered from the same address, and deliverability is built on your own domain's reputation rather than a forwarding chain.
This is the setup the cloud setup guide recommends for teams, for practical reasons that stack: replies look native; the address the customer sees is the address you own; future channels (the widget, messaging) unify under one brand identity; and the day you want history moved anywhere — another setup, or a self-hosted deployment — the data is already yours in clean form. The cost is one-time and small: the DNS record and a moment of care with your provider's panel.
The third option exists for the mailbox you already have — years of conversations in Gmail, Outlook or wherever your team's shared mailbox evolved. IMAP import connects to that mailbox directly and brings the history in: existing threads arrive as conversations, so the desk's first day already contains the context that would otherwise live only in people's memories. It is the bridge for migrating from a per-seat help desk or from a plain shared mailbox — the "email-first cutover" that migration guides recommend, because email is the one channel where every tool has an out.
Run it as a one-time job: import until the mailbox is quiet, keep the original archive untouched for a season, then decide the old mailbox's future. Text conversation is tiny — years of it fit well inside free-tier storage — so the import's cost is the one-time job, not storage.
Pick forwarding if any of these hold: this is week one, the desk is being evaluated, or the existing mailbox's continuity matters more than reply identity. It is reversible by a click and never wrong for long. Pick your own domain if the desk is becoming official — a team answering customers as the company, an address you intend to keep, deliverability you intend to own. It is the setup every guide on this site assumes by default. Pick IMAP import when history exists elsewhere and losing it would hurt — whether that history lives in a mailbox, an old desk, or an export from a previous tool; it is a bridge, and bridges are crossed once.
A sequence that fits most teams: forward for the first week, import history when the desk becomes official, then verify your own domain — three small steps, none urgent, none conflicting, each reversible for a season after it is done.
Forwarding's classic failure is the silent one: the forward rule exists on one person's personal account, that person changes jobs, and the alias quietly routes to nothing. Tie forwards to a role address owned by the company, never a personal mailbox, and note them in the runbook — the shared inbox guide's ownership habit applies to the plumbing as much as to the replies.
Own-domain failures are DNS-shaped and boring: a typo in the verification record (the desk tells you instantly), propagation delay measured in minutes to hours, and the rare provider panel that requires a specific record format — all one-line fixes with instructions on screen. The deeper habit is keeping the DNS records listed somewhere the next admin will find them; domains outlive administrators.
IMAP failures are almost always scope: importing an enormous mailbox with a decade of noise takes time and imports attachments you never wanted. Import the recent window that matters, leave the deep archive in its original place, and let the desk's exports (the data-ownership guide's ritual) handle the long tail — history is for reference, not for relitigating 2019 one thread at a time.
The customer-visible difference between these options is the From line and, occasionally, deliverability. With forwarding, replies usually leave as an alias the customer has not written to before, and the first reply asks a small act of trust. With your own domain, replies arrive from the address the customer wrote to, with the thread underneath — indistinguishable from mail sent by any well-run team, because reputation, identity and history all match. That is the real argument for graduating from forwarding: not features, but the removal of small moments of doubt in every reply, on a desk whose free tier already gave you everything else.
Whichever option you start with, the email channel lives in Settings → Channels, is included in the free plan with three seats, and carries no per-message meter. The switching costs between the three options are minutes, not projects — which is the strongest reason not to spend more than five minutes deciding today.
What is the simplest way to connect email to a help desk?
Forwarding: point your existing address at the desk and every forwarded message becomes a conversation. It is live in minutes, needs no DNS work, and is the right choice for the first week on a free workspace.
Why should a team move past forwarding to its own domain?
Replies then leave from the address customers wrote to, sent as you, with deliverability built on your own domain's reputation rather than a forwarding chain. Setup adds one DNS verification record; it is the recommended long-term setup for teams.
What does IMAP import do?
It connects directly to an existing mailbox and brings conversation history into the desk — the standard bridge when migrating from a per-seat tool or a plain shared inbox, so the desk's first day already contains prior context. Text conversations are tiny; the cost of import is the one-time job, not storage.
Can these email setups be switched later?
Yes — forward first, import history when the desk becomes official, then verify your own domain; the three steps are independent, reversible for a season, and switching costs are minutes rather than projects.
Does connecting email cost anything on the free plan?
No. All three email options — forwarding, own domain, IMAP import — are included in the free workspace with three seats and 100 MB storage. There is no per-message meter; paid meters on the desk begin with seats beyond the third or purchased storage and AI credits.