Freshdesk Emails Going to Spam: How to Fix
When your agents reply from Freshdesk and those replies quietly land in the customer's junk folder, it almost never means Freshdesk is broken — it means the receiving mail server can't prove the message really came from your domain. Modern inbox providers judge every outbound email against three authentication checks — SPF, DKIM, and DMARC — and Freshdesk sends on your behalf from its own infrastructure, so unless you tell the internet that's allowed, your mail looks like a spoof. This guide walks through the real fix in the order that matters: authenticate your domain with DKIM and SPF, add DMARC, confirm you're sending from a verified custom domain, and then handle the smaller monitoring and threading details. It cites Freshworks' own documentation, stays honest about what's plan- and domain-gated, and ends by mapping where native email genuinely stops.
Why Freshdesk mail lands in spam (the one-sentence cause)
The root cause is authentication, not content. Because Freshdesk relays your replies through email.freshdesk.com, a receiving server sees mail claiming to be from [email protected] but arriving from a Freshworks IP. If your DNS doesn't publish a record authorising that, SPF fails; if the message isn't cryptographically signed, DKIM fails; and if you've published a DMARC policy, a DKIM misconfiguration is usually what tips the whole message into the spam folder. The fix is to publish the right DNS records so all three checks pass.
Step 1: Configure DKIM (the primary fix)
DKIM is the single highest-leverage change, so do it first. It signs every outbound message with a private key held by Freshdesk and a matching public key published in your DNS — receiving servers verify the signature and trust the mail. Per Freshworks' email domain verification using DKIM records documentation, the flow is:
- Go to Admin → Channels → Email → Advanced Settings → Configure DKIM (you need admin access).
- Freshdesk generates 4 CNAME records unique to your domain — this is "a one-time configuration step per domain name."
- Publish all four CNAME records at your DNS host (GoDaddy, Cloudflare, Route 53, etc.).
- Return to Freshdesk and verify. A green check mark means the DNS verified successfully; a red cross mark means it's still unverified.
Give DNS time to propagate — Freshworks notes it can take "from a few minutes to several hours, and in some cases, up to 48 hours," and you'll get an email once verification completes. Two mistakes cause most failures: signing with Freshdesk's own DKIM keys instead of the ones generated for your domain, and leaving the proxy toggle ON for those CNAME records at providers like Cloudflare — proxying rewrites the record and verification never lands. Turn the proxy (the orange cloud) off for the DKIM CNAMEs.
Step 2: Add or confirm your SPF record
SPF tells receiving servers which infrastructure is allowed to send on your behalf. Helpfully, configuring DKIM in Freshdesk also nudges SPF into place, but you should confirm the record exists on your domain. The value to include for Freshdesk is:
v=spf1 include:email.freshdesk.com ~all
A domain can only have one SPF record, so if you already send mail through Google Workspace or Microsoft 365, don't add a second v=spf1 line — merge the include:email.freshdesk.com mechanism into your existing record. One caveat worth flagging: SPF has a hard limit of 10 DNS lookups, and stacking several include: mechanisms (Freshdesk plus Google plus a marketing tool) can blow past it and cause SPF to fail permanently. If you're near the limit, an SPF-flattening service or careful consolidation is the fix.
Step 3: Publish (or reconcile) DMARC
DMARC ties SPF and DKIM together and tells receivers what to do when a message fails both. A basic monitoring policy looks like this:
v=DMARC1; p=none; rua=mailto:[email protected]
Start with p=none to collect reports without affecting delivery, then tighten to p=quarantine or p=reject once you confirm Freshdesk mail passes. The important rule from the deliverability guides: a domain can hold only one DMARC record, so if you already publish one, don't create a duplicate — reconcile the single record instead. In practice, most "Freshdesk mail going to spam" cases that survive DKIM setup are a DMARC record that's failing because DKIM alignment was misconfigured, which loops you straight back to Step 1.
Step 4: Send from a verified custom domain
Here's the honest gate that trips up trial and small accounts: DKIM requires a verified custom support-email domain. If your outbound replies still go out from [email protected], there is no custom domain for Freshdesk to sign, the Configure DKIM page shows an empty state, and you inherit whatever reputation the shared subdomain carries. The fix is to add a support email on your own domain ([email protected]) first, then authenticate that domain. Setting the mailbox up correctly in the first place is covered in how to configure email in Freshdesk, and the full authentication walkthrough lives in Freshdesk SPF, DKIM, and custom mailbox setup.
Step 5: Monitor and archive outbound mail
Once authentication passes, you'll want visibility into what's actually being sent — both to spot deliverability regressions and to keep a compliance copy of agent replies. Freshdesk's Advanced email settings include an automatic Bcc option that silently copies a monitoring or archive inbox on all ticket communications, so you can audit outbound mail without sitting in every ticket.
To be clear about what this dialog does and doesn't do: the automatic Bcc is an archiving and monitoring control, not a deliverability fix. It won't stop mail from being flagged as spam — that's the DKIM/SPF/DMARC work above. What it does give you is a running copy of every outbound reply, which is exactly what you want when you're diagnosing why certain messages bounce or land in junk. Pair it with a DMARC rua report address (Step 3) and you have both an internal archive and an external signal on how receivers are treating your mail.
Native Freshdesk deliverability: what it does well, and where it stops
Credit where it's due: Freshdesk's built-in authentication is genuinely good. It generates the DKIM records for you, folds in SPF, gives you a clear verified/unverified indicator, and documents the whole flow well. For most teams on a custom domain, publishing four CNAMEs and one SPF line is the entire fix, and mail sits in the inbox where it belongs. None of what follows is a knock on that.
But the honest edges are real. DKIM is domain-gated — you cannot authenticate mail on a freshdesk.com subdomain, so any team that hasn't moved to a custom domain ships weaker deliverability with no in-product remedy. Freshdesk also doesn't manage your DNS, so SPF-lookup-limit problems, proxied CNAMEs, and duplicate DMARC records all live in a system Freshdesk can't see or fix for you — verification simply stays red until you sort it at the registrar. And once mail is delivering, authentication does nothing about the actual work waiting in the inbox: reading each message, understanding intent, and writing the answer.
That last gap is where an AI layer fits — and it's worth weighing the build-versus-buy tradeoff before adding one. The category of AI agents for customer service exists to do the reasoning-heavy part authentication can't touch. 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 works the same email-to-ticket conversations your authenticated mailbox already creates: 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.) For how that automation is wired end to end, how to automate Freshdesk with AI walks through it.
The clean division of labour: keep Freshdesk as the system of record for how mail is sent and trusted — DKIM, SPF, DMARC, the custom domain — and layer an agent on top for the part authentication can't do, which is answering what finally lands in the inbox. If you want the wider mental model of how Freshdesk email works underneath all this, Freshdesk email explained covers the full flow.
FAQ
Why are my Freshdesk emails going to spam? Almost always because of failed email authentication. Freshdesk sends on your behalf from email.freshdesk.com, so unless your domain publishes DKIM signatures, an SPF record authorising Freshdesk, and a consistent DMARC policy, receiving servers treat the mail as unverified and route it to junk.
How do I set up DKIM in Freshdesk? Go to Admin → Channels → Email → Advanced Settings → Configure DKIM. Freshdesk generates four CNAME records; publish all four at your DNS host, disable any proxy on those records, then verify. A green check mark confirms success; propagation can take up to 48 hours.
What SPF record do I add for Freshdesk? Include v=spf1 include:email.freshdesk.com ~all — but a domain can only have one SPF record, so merge the Freshdesk include into your existing record rather than adding a second line, and watch the 10-lookup limit.
Do I need a custom domain to fix deliverability? Yes. DKIM requires a verified custom support-email domain — you can't authenticate mail on a yourcompany.freshdesk.com subdomain. Add a support email on your own domain first, then configure DKIM, SPF, and DMARC for it.
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 the same email-to-ticket conversations your authenticated mailbox creates — drafting grounded replies and triaging by intent — while Freshdesk stays the system of record for how mail is sent and authenticated.
Ready to turn a clean-sending Freshdesk inbox into one that answers itself? Start a free trial of Macha and connect it to your Freshdesk in minutes.
Add AI agents to your Freshdesk
Macha reads the ticket, drafts the reply and takes the action, inside the Freshdesk you already run.
Shopify
Stripe
Slack
Notion
Google Workspace
Confluence

