Squid Support

Documentation

Email channel

Email is where most support still happens. Once your domain is connected, mail sent to your support address becomes a ticket in the inbox, and replies go back out from your own domain rather than ours.

How inbound email becomes a ticket

Mail addressed to your support address reaches Squid Support, and we match it to a brand and a customer. If the sender already has a conversation history, the message is threaded onto it; otherwise a new ticket is created and a customer record is made from the sender's address. Attachments come across with the message.

From there it behaves like any other conversation — see The inbox — and if the AI agent is enabled for that brand it will read the message and draft or send a reply according to your settings.

Connecting your support address

Email is configured per brand, so each storefront can have its own address and its own sending domain. You choose the local part — the piece before the @. It defaults to support, but help, contact or anything else works.

Squid Support uses two separate hostnames under your domain, which is worth knowing before you touch DNS:

  • A sending subdomain (em by default) that carries the DKIM records proving mail from you is genuinely yours.
  • An inbound subdomain (helpdesk by default) that carries the MX record receiving your mail.

They are deliberately kept apart because a single hostname cannot hold both a CNAME and an MX record. This split is why the setup asks for records on two different hostnames rather than one.

Verifying your domain

Adding a domain moves it through three states — pending while you add records, verifying while we check them, and verified once everything resolves. Three kinds of record are involved:

  • TXT — a one-off ownership challenge proving you control the domain.
  • CNAME — DKIM authentication on the sending subdomain, so mailbox providers trust mail we send on your behalf.
  • MX — on the inbound subdomain, so mail can be received.

The dashboard shows the exact hostnames and values to add for your specific domain. Copy them from there rather than from any guide, including this one — they are generated per domain and differ between brands.

DNS changes take time to propagate. If verification does not succeed immediately, wait and re-check before changing anything; the most common cause of a stuck domain is a record that was added correctly and simply has not propagated yet. The second most common is a DNS provider that silently appends your domain to the host field, producing something like em.example.com.example.com.

Forwarding instead of full migration

You do not have to move your whole mailbox. A common setup is to keep your existing public address and forward it into Squid Support. There is a forwarding test that sends a message to your public support address carrying a token — if forwarding is configured correctly, that message arrives at the inbound subdomain, the token is matched, and forwarding is confirmed.

One gotcha with Google Workspace: Gmail skips forwarding rules for some self-addressed mail, and a forwarding rule may need to be confirmed from a link Google emails you before it becomes active. If the test does not confirm, check for that pending confirmation first.

Mail that cannot be routed

Sometimes mail arrives that we cannot confidently attach to a brand — a message sent to an address on a domain that is not fully verified, for example. Rather than dropping it silently, it is captured with its sender, subject, recipients and body so nothing is lost, and so you can see what arrived and why it did not route.

If you see unrouted mail piling up, it almost always means a domain or address is not verified yet, or mail is being forwarded to an address that Squid Support does not know about.

Sending replies

Replies are sent from your brand's own support address on your verified domain, so customers see your name in their inbox and can reply straight back into the same thread. Outbound mail is signed with the DKIM records set up during verification, which is what keeps it out of spam folders.

Sending before a domain is verified is the single most common cause of deliverability problems. Finish verification first.

Bounces and delivery failures

Not every message gets through — addresses go dead, mailboxes fill up, and receiving servers occasionally reject mail. When a send fails, the conversation is flagged so it does not look answered when it is not.

The Failed Emails view in the inbox sidebar collects these. It is worth checking regularly: a customer whose reply bounced has, from their point of view, been ignored. Bounce events are recorded so repeated failures to the same address are visible rather than silently retried forever.

A sensible order to do this in

  1. Add your domain and choose the local part for the address.
  2. Add the TXT, CNAME and MX records the dashboard gives you.
  3. Wait for verification to complete.
  4. If you are forwarding from an existing address, set up the forwarding rule and run the forwarding test.
  5. Send a real message from an outside account and confirm it appears in the inbox.
  6. Reply from Squid Support and confirm it arrives, from your address, in the same thread.

That last step matters more than it looks — it proves both directions work before you point real customers at the address. If something in this sequence fails, see Troubleshooting or email hello@squidsupport.ai with the domain you are setting up.