Connecting Email
The four ways to connect a support inbox — Gmail, Outlook, SMTP/IMAP and Octocom Mail — and the full Octocom Mail setup: DNS records, domain verification and inbox forwarding.
Before the bot can answer email, Octocom needs two things: permission to send as your support address, and a way to receive what customers send to it.
There are four ways to arrange that, all under Settings → Channels → Email → New email address. Three of them connect to a mailbox by signing into it. The fourth, Octocom Mail, doesn't need a mailbox to sign into at all.
Choosing how to connect
| Option | You need | Setup | Receiving |
|---|---|---|---|
| Gmail | A Google Workspace account for the address | One Google login | Pushed to us as mail arrives |
| Outlook | A Microsoft 365 account for the address | One Microsoft login | Pushed to us as mail arrives |
| SMTP/IMAP | Host, port, username and password for both | One form | Polled once a minute |
| Octocom Mail | DNS access for the domain, plus a forward rule | DNS records + forwarding | Forwarded from your real mailbox |
Gmail and Outlook are the quickest by a wide margin — a single OAuth login, no DNS changes, and mail reaches us the moment it lands rather than on a poll. If your support address is on Google Workspace or Microsoft 365, use these and skip the rest of this page.
SMTP/IMAP covers everything else with a real mailbox and a password behind it: Zoho, Fastmail, cPanel, a mail server you run. You give us the same credentials any mail client would use, and sending goes out through your provider's own server, so your existing SPF and DKIM keep working untouched.
Octocom Mail is for an address with no account to sign into, or one you'd rather not send through:
- A distribution list, group or alias with no mailbox and no password of its own.
- A provider with no IMAP, or one whose security policy blocks app passwords.
- Sending limits or deliverability on your own server that you don't want a support queue running through.
It's the only option that asks you to touch DNS, and in exchange the sending side stops depending on your mail provider entirely.
Only Octocom Mail addresses show anything in the Setup column of the email table. Gmail, Outlook and SMTP/IMAP addresses are connected by login or credentials — they either work or they don't, and there's nothing to verify.
How Octocom Mail works
It is not a mailbox. Nothing is stored on our side, there's no webmail to log into, and your existing mail host doesn't change. It's two halves bolted onto an address you already own:
- Sending — we register your domain with our sending infrastructure and you prove ownership through DNS. After that, replies from the bot and from your agents leave as
[email protected], signed with DKIM on your own domain. - Receiving — you forward your real inbox to a private relay address we issue you, ending in
@relay.octocom.ai. Everything landing in your mailbox is copied to us and becomes a conversation.
Mail therefore keeps arriving in your original mailbox as well. Octocom never signs in and never deletes anything there. The two halves also fail independently: stop the forwarding rule and inbound support stops while sending carries on, which is the half-broken state the Setup panel exists to catch.
Connecting an address
You'll need DNS access for the domain and access to the mailbox's forwarding settings. Budget about fifteen minutes, plus however long your DNS takes to propagate — minutes on most providers, occasionally hours.
1. Add the address
New email address → Octocom Mail, type the full address ([email protected]), save. It appears in the table with a Set up sending badge. Open Setup on that row — the remaining three steps all happen in this one panel, which always shows you whichever is outstanding.
2. Publish the DNS records
Press Set up sending. Registering the domain takes up to a minute, after which the panel lists four records to add wherever you manage DNS:
| Type | Purpose |
|---|---|
| TXT | Proves you own the domain |
| TXT | SPF — lets us send on your behalf |
| CNAME | DKIM — signs your outgoing mail |
| CNAME | DKIM2 — the second signing key, rotated alongside |
Three things account for nearly every failed verification:
- Never add a second SPF record. If the host already has a
v=spf1TXT, merge ourinclude:into it. Two SPF records on one host is invalid and breaks SPF for all your mail, not just ours. - The DKIM CNAMEs must be DNS-only. On Cloudflare that's the grey cloud, not orange. A proxied record answers with an IP address instead of a CNAME and can never verify.
- Watch the host. The verification TXT goes on the exact name shown, which may be a subdomain rather than the apex.
3. Verify the domain
Press Verify domain. Each record is checked separately and reported on its own line, because any subset can fail and "it didn't work" tells you nothing. Fix whatever failed and retry just that record — anything already verified stays verified. Where our own DNS lookup can explain a failure, the reason appears underneath it: two SPF records on one host, a proxied CNAME, a token that doesn't match the one we issued.
Once all four pass, the rest is automatic. The badge reads Finishing setup for a few seconds and needs nothing from you.
DNS changes take time to reach us. If a record looks correct in your DNS panel but won't verify, wait a few minutes and retry it rather than re-editing it — a second edit usually just resets the clock.
4. Forward your inbox
Sending now works, but nothing reaches you yet. The panel shows a forwarding address unique to this one address — copy it and create a forwarding rule for [email protected] at your mail provider.
Nearly every provider then sends a confirmation code or link to verify the destination. That confirmation goes to the relay rather than to a mailbox anyone reads, so we catch it and put it in front of you twice: in the Setup panel under Confirmation received, and in your inbox as a conversation that's already handed off, so the bot never answers it. Enter the code (or open the link) back at your provider, then press Mark as done.
The badge flips to Connected once real mail actually arrives at the relay — not when you finish the steps. That's deliberate: arriving mail is the only proof forwarding is genuinely live.
If forwarding was set up before Octocom issued you a relay address — an arrangement from an earlier manual setup — it keeps working. The address is recognised from the first ordinary email that arrives through it.
After it's connected
The Setup column stays on the row as a live status, not just a wizard you finish once:
| Badge | Meaning |
|---|---|
| Set up sending | The domain hasn't been registered yet. |
| Verify domain | DNS records are waiting to be published or verified. |
| Finishing setup | Verified; internal setup is completing. No action needed. |
| Confirm forwarding | Sending works. Nothing has arrived through the relay yet. |
| Connected | Sending and receiving are both working. |
| Sending unavailable | We couldn't check the sending side just now. Forwarding is unaffected. |
More addresses on the same domain — add each one separately (support@, orders@, returns@). The domain only has to be verified once, so for the second and later addresses open Setup, press Verify domain to register the new sender, and go straight to forwarding.
Who owns the domain — it belongs to the organization that connected it. Sibling businesses under the same organization share it freely; a different Octocom account can't claim it. If you're told the domain is already connected elsewhere and you believe it's yours, contact support.
Troubleshooting
Verification passes but no customer email appears. The forwarding rule is missing, unconfirmed, or pointed at the wrong address — the Setup panel will still read Confirm forwarding.
The confirmation never appears in Octocom. Some providers send it to the mailbox owner instead of the destination, so check the original inbox first, spam included. If it's nowhere, contact support — the message may have arrived without enough information to match it to your address.
Email Octocom starts itself goes out from the wrong address. Replies always leave on the address the customer wrote to. Anything with no thread behind it — outbound mail the bot initiates — uses the business's primary address instead. Use Set as Primary on the row you want those to come from.
Everything worked, then outbound stopped. Check the SPF and DKIM records are still present. DNS migrations and registrar transfers routinely drop them.
Related
- Email Rules — route inbound mail by sender, domain or subject before the bot sees it.
- Email Conversation Merging — how replies are threaded into existing conversations.
- Autoresponder — automatic acknowledgements on inbound email.