Connecting Email

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

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.

---

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.

---

Which address a message is matched to

Forwarding hides a detail that matters as soon as you have more than one support address: the message we receive was addressed to your mailbox, not to us. We have to work out which of your configured addresses it belongs to, and the answer decides which address the reply goes out from.

What the message has to look like

Two headers do the work:

A plain forwarding rule preserves both, which is all we need. What breaks it is a rule that rewrites the sender, because then every conversation looks like it came from your own domain: forward-as-attachment, "resend as", and some mailing-list style rewrites all do this. If you have a choice of mechanism, pick the one your provider calls forwarding or redirect rather than one that re-sends the message as itself.

How we pick the address

In order, stopping at the first hit:

1. To, matched exactly against the addresses you've configured.
2. Cc, then Bcc, the same way — this catches customers who put your support address in copy.
3. The relay address the forward delivered to, read from the Delivered-To and X-Forwarded-* headers your provider adds. Each relay address belongs to exactly one configured address, so this always resolves.

Step 3 is the one doing the work in most real setups, and it's why a funnel works.

Aliases, groups and funnels

You do not have to configure every alias your customers write to. If help@, trade@ and returns@ all funnel into support@, and support@ is the address you connected, everything arrives and becomes a conversation — step 3 matches on the relay address regardless of what the To header says.

What you get in exchange is a single identity:

That is usually what people want from a funnel, but it is a decision, so make it deliberately:

• Keep the funnel if one support identity is fine. Simplest to run: one address to connect, one forwarding rule, one sender to verify.
• Connect each address separately if trade@ has to keep answering as trade@. Add each one under New email address, and give each its own forwarding rule. The domain is verified once and shared, so the extra work per address is small.

You can mix the two: connect the addresses whose identity matters, and let the rest funnel.

---

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:

Three things account for nearly every failed verification:

• Never add a second SPF record. If the host already has a v=spf1 TXT, merge our include: 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.

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.

---

After it's connected

The Setup column stays on the row as a live status, not just a wizard you finish once:

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. Do this for the addresses that need to answer under their own name; anything funnelling into an address you've already connected needs nothing, as matching explains.

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 goes out from the wrong address. Replies leave on the configured address the conversation was matched to, which is not necessarily the address the customer typed — see Which address a message is matched 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 Signatures — automatically add a shared signature to emails sent by agents or the bot.
• 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.