Freshdesk Email Not Working: Causes & Fixes
When Freshdesk email breaks, it rarely announces itself — customers just go quiet, or the same person keeps opening what looks like a brand-new ticket. The symptoms cluster into three buckets: emails that never become tickets at all, a mailbox that has silently stopped syncing, and replies that fork into new tickets instead of threading onto the original. Each has a different root cause and a different fix, and chasing the wrong one wastes a morning. This guide works through them in the order you should actually check — most common and cheapest to rule out first — with the exact Freshdesk menu paths and the settings that quietly cause each failure. None of it requires a support ticket to Freshworks; almost every case comes down to a forwarding rule, an authentication token, or a threading marker.
First, confirm the mailbox is actually verified
Before you debug anything downstream, rule out the simplest cause: the support email isn't in a working state. Go to Admin → Channels → Email and look at your support email list. Each mailbox shows a Status — you want Verified. A mailbox that's still Pending (Freshworks-server route, waiting on a forwarding rule) or Disconnected (custom mailbox that lost its connection) will not convert mail into tickets, and no amount of threading configuration fixes that.
If the status is anything but Verified, jump straight to the section that matches your setup — forwarding (Freshworks server) or reauthorization (custom mailbox). If it is Verified and mail still isn't arriving, work down the list below.
Cause 1: Emails aren't creating tickets
This is the loudest failure — mail is being sent to your support address, and nothing appears in Freshdesk. Per Freshworks' why aren't emails converted to tickets documentation, work through these in order:
- Check the forwarding rule (Freshworks-server route). If you use the default Freshworks mailbox, your real address (
[email protected]) must forward mail to the Freshdesk forward-to address — the long one that looks like[email protected]. If that rule was never created, or a mail-provider change dropped it, no ticket is created. Re-add the forwarding rule in Google Workspace / Microsoft 365 and re-verify. - Send two test emails. From an outside address, email (a) the long forward-to address directly and (b) your real support address. If the forward-to address creates a ticket but the support address doesn't, the problem is your forwarding rule, not Freshdesk.
- Check the spam and trash folders inside Freshdesk. Open the ticket list view and check the account's Spam and Trash folders — legitimate mail sometimes lands there and looks "missing."
- Watch for email-loop suppression. Freshdesk deliberately will not convert a message where the From and To are the same address, or where Reply-To equals To, to stop the help desk mailing itself in a loop. Automated no-reply or self-addressed mail gets silently dropped for this reason.
- Confirm IMAP is enabled on the underlying mailbox (custom-server route). If IMAP is off on the mail provider, Freshdesk can't read incoming mail at all — check with your IT/email team.
Freshworks' what to do if none of your emails are getting converted article covers the same checklist and recommends sending sample email headers to Freshworks support only after the above are ruled out.
Cause 2: The mailbox stopped syncing (custom mailbox disconnected)
If tickets were flowing and abruptly stopped, you almost certainly have a disconnected custom mailbox. When Freshdesk detects a connection failure, it retries the mailbox roughly 8 times over about 12 minutes; if every retry fails, it marks the mailbox disconnected and stops pulling mail until you manually reauthorize it. The good news, per the reauthorization of custom mailbox docs: any mail that arrived during the outage is automatically resent once reauthorization succeeds — so you don't lose the tickets, they just show up late.
The two most common triggers:
- Microsoft Office 365 — Basic Auth deprecated. Microsoft has retired Basic Authentication on Exchange Online in favour of OAuth. If your mailbox was set up on the old method, you'll see a reauthorization required banner and must reconnect over OAuth. Confirm Authenticated SMTP and IMAP are enabled on the tenant — O365 disables SMTP auth by default.
- Gmail / other — password changed or expired. If the mailbox uses a password that was rotated, the connection drops. Re-entering credentials restores it.
If the mailbox reconnects but keeps dropping, the troubleshoot custom email server docs point to two settings: confirm the ports (IMAP 993, SMTP 465) and have your IT team allowlist Freshdesk's IP ranges on the mail server so it stops rejecting the connection. If you're standing up a fresh Gmail or Office 365 connection from scratch, our walkthrough on connecting Office 365 or Gmail to Freshdesk covers the OAuth flow step by step.
Cause 3: Replies create new tickets instead of threading
The subtlest failure: everything "works," but a customer's reply spawns a fresh ticket instead of appending to the original conversation. Freshdesk decides threading with two checks — a marker check and a sender check — and the message has to pass both, per the email threading documentation.
The marker check. Freshdesk threads a reply by finding the ticket ID in the subject in the format [#{{ticket.id}}], or by matching the original message's Message-ID in the In-Reply-To / References headers. Common ways this breaks:
- Plaintext replies strip the marker. If a customer's client sends in plaintext and the subject was edited, the ticket identifier can be lost.
- The subject line changed. If you've enabled the create a new ticket when the subject changes option in Advanced Settings, a reply with an altered subject will fork into a new ticket by design. To keep everything on one thread, disable that option.
- A missing ticket-ID prefix. If your outgoing templates don't carry the
[#{{ticket.id}}]marker, replies have nothing to match against.
The sender check. The reply must come back to the same support address it left from. If your help desk has multiple support emails and an agent replied from a different product's From address, the customer's reply lands on the wrong mailbox and opens a new ticket. Freshworks' threading logic article documents this precedence in full.
Most threading problems resolve by confirming the ticket-ID prefix is present in your templates and turning off the "new ticket on subject change" toggle under Admin → Channels → Email → Advanced Settings.
Quick-reference: symptom → likely cause → fix
| Symptom | Most likely cause | First fix |
|---|---|---|
| No tickets at all from an address | Forwarding rule missing / mailbox not Verified | Re-add forwarding rule; test the long forward-to address |
| Was working, then stopped | Custom mailbox disconnected | Reauthorize (O365 → OAuth; Gmail → re-enter credentials) |
| Some self-addressed mail dropped | Loop suppression (From = To / Reply-To = To) | Expected behaviour — send from a distinct address |
| Replies open new tickets | Threading marker or sender check failed | Keep [#ticket.id] prefix; disable "new ticket on subject change" |
| Mail arrives but lands in spam | DKIM/SPF not configured | Configure DKIM/SPF (see below) |
What native Freshdesk email does well — and where it stops
Credit where it's due: Freshdesk's email engine is robust. The retry-and-resend behaviour on a dropped mailbox means you rarely lose mail outright, the threading logic is well-documented and predictable once configured, and the loop suppression genuinely prevents ugly mail storms. For most of these failures, the fix is a five-minute settings change — not a rebuild. This is solid infrastructure.
There are honest edges, though. Threading is rule-based, so unusual clients, stripped subjects, or aggressive forwarding will occasionally still fork a conversation no matter how carefully you configure it. DKIM is domain-gated — you can't authenticate outbound mail on a freshdesk.com subdomain, so deliverability suffers until you move to a custom domain; if replies keep hitting spam, start with our guide on Freshdesk emails going to spam and the fuller SPF, DKIM, and custom mailbox setup walkthrough. And a disconnected mailbox is silent — nothing alerts the customer that their message is sitting in a resend queue.
The deeper limit is that every fix above keeps the pipe healthy — getting mail into a ticket and a reply back out — but does nothing about the reading and the answering in between. A perfectly synced, perfectly threaded inbox still lands every message on a human. That's the seam where an AI layer fits, and it's worth being clear-eyed about the build-versus-buy tradeoff before adding one. The category of AI agents for customer service exists to do the reasoning-heavy part the pipe can't. Macha is one such layer: it runs on top of the Freshdesk you already use as a native connector — it does not replace your help desk, your mailboxes, or your DKIM setup. You connect Macha to Freshdesk with your subdomain and API key, and it reads the same email-to-ticket conversations your forwarding rules create — drafting a grounded first reply, triaging by intent, and looking up order or account status through a custom tool that turns a REST API into something the agent can call. (Macha's connector is for Freshdesk specifically — not Freshchat, Freshservice, or Freshcaller. Credits are consumed per AI action, not per resolution — see the pricing breakdown.) If you want to see how that's wired, how to automate Freshdesk with AI walks through it. And if email is still misbehaving, our full guide on how to configure email in Freshdesk covers the setup end to end.
FAQ
Why are my Freshdesk emails not creating tickets? Most often the forwarding rule from your real support address to Freshdesk's forward-to address is missing or broken. Test by emailing the long forward-to address directly — if that creates a ticket but your support address doesn't, fix the forwarding rule. Also check the account's Spam/Trash folders, confirm IMAP is enabled, and note that Freshdesk deliberately won't convert mail where the From and To addresses are identical.
My mailbox was working and suddenly stopped. Why? Your custom mailbox likely disconnected. Freshdesk retries a failed connection about 8 times over 12 minutes, then marks it disconnected until you reauthorize. For Office 365 you'll usually need to migrate from Basic Auth to OAuth; for Gmail, re-enter credentials if the password changed. Mail received during the outage is resent automatically after reauthorization.
Why do customer replies open new tickets instead of threading? The reply failed one of Freshdesk's two threading checks — the ticket-ID marker ([#{{ticket.id}}] in the subject, or matching In-Reply-To/References headers) or the sender/address check. Keep the ticket-ID prefix in your outgoing templates, disable the "create new ticket when subject changes" option, and reply from the same support address the ticket originated on.
What ports do I use for a custom Freshdesk mail server? Use IMAP port 993 for incoming and SMTP port 465 for outgoing, with IMAP and Authenticated SMTP enabled on the mailbox. If the connection keeps dropping after reconnecting, ask IT to allowlist Freshdesk's IP ranges on your mail server.
Can I add AI to Freshdesk email without replacing Freshdesk? Yes. An AI agent layer like Macha connects to Freshdesk as a native connector and works on the same email-to-ticket conversations your mailboxes create — drafting grounded replies and triaging by intent — while Freshdesk stays the system of record for how mail is received, sent, and authenticated.
Once your email pipeline is healthy, the next win is letting it answer itself. Start a free trial of Macha and connect it to your Freshdesk in minutes.
Add AI agents to your Freshdesk
Macha resolves tickets end to end on Freshdesk — no migration, no code.
Shopify
Stripe
Slack
Notion
Google Workspace
Confluence

