Email

Email is usually the first channel a business has and the last one anybody manages. A shared mailbox gives you no idea who replied, what is still outstanding, or how long people waited. Connecting it to Tola turns it into a queue with the same statuses, assignment and reporting as every other channel.

Ways to connect

Forwarding an existing address

This is the fastest path and the one to use unless you have a reason not to.

1. Go to Channels → Add channel → Email.
2. Name the channel — this is what agents will see in the sidebar, so Support rather than support@….
3. Tola shows you a forwarding address. Copy it.
4. In your mail provider, set up forwarding from your real address to that one. In Gmail this is under Settings → Forwarding and POP/IMAP; in Microsoft 365 it is a mail flow rule.
5. Confirm any verification email your provider sends — it will arrive in Tola's inbox.
6. Send a test message to your real address and check it lands.

Connecting Gmail or Microsoft

If you would rather Tola read the mailbox directly — so that mail sent from Tola also appears in the mailbox's Sent folder — connect it over OAuth instead.

1. Go to Channels → Add channel → Email and choose Gmail or Microsoft.
2. Sign in with the mailbox account and grant access.
3. Choose which agents get access to the channel.

You will be asked to re-authorise occasionally when the provider expires the grant. Tola flags this on the channel rather than silently stopping.

Connecting your own mail server

For self-hosted mail or a provider without a direct integration, Tola can connect using standard mail server settings. Your IT team will need to supply the incoming and outgoing server addresses, the port numbers, and a mailbox username and password — the same details used to set up a desktop mail client.

Ask them for an app-specific password rather than the account's main password where the provider offers one.

How threading works

When a customer emails you, Tola creates a conversation. When they reply to your reply, it needs to attach to the same thread rather than open a new one — otherwise a five-message exchange becomes five conversations.

Tola handles that with message headers and a per-conversation reply address. Conversation continuity is what keeps it working; leave it on unless you have a specific reason not to.

A resolved conversation that receives a new reply reopens rather than starting fresh, so the agent picking it up sees the whole history.

Sending as your own domain

By default, replies leave from Tola's sending infrastructure with your name on them. Two settings make it look like your own mail:

Custom reply-to email sets the address customers see and reply to.

Custom reply domain sends from your domain outright. This works through a few DNS records — SPF and DKIM — so that receiving servers trust Tola to send on your behalf. Without them, your mail lands in spam. Set this up before a launch, not after complaints start.

Signatures and templates

Each agent sets their own signature under their profile; it is appended to outgoing email automatically. Account-level branded email templates control the wrapper — logo, colours, footer — so every reply looks like it came from your company rather than from a generic help desk.

Troubleshooting

Mail arrives as a new conversation every time. Threading is broken — usually conversation continuity is off, or a forwarding rule is rewriting headers.

Replies go to spam. SPF/DKIM are missing or wrong for your custom reply domain. Check with a mail tester before assuming it is content.

Nothing arrives. Check the forwarding rule is active and confirmed. Providers silently disable forwarding when the verification email is never acknowledged.

Auto-replies create conversations. Out-of-office bounces from other systems can open threads. Use a workflow to auto-resolve conversations whose subject matches your usual noise.