Freshdesk & Freshsales deliverability: test before the SLA breaks

Freshdesk and Freshsales both sit in the same awkward spot for deliverability. They are not marketing tools, so nobody thinks to run them through a placement test. But they handle messages that are more time-sensitive than a newsletter: ticket replies, quote follow-ups, demo confirmations, password reset handshakes, renewal notices. When those messages land in the Spam tab, the SLA clock keeps ticking and the customer assumes you ghosted.

How mail flows in and out of Freshworks

The Freshworks stack treats email as two separate pipes: inbound to create or update tickets, and outbound to reply. The inbound side is an MX record that points at Freshdesk's ingestion servers. The outbound side is the part that breaks deliverability.

• Inbound: you point an MX (or forward) fromsupport@yourdomain.com to the Freshdesk-assigned address such as yourbrand@yourbrand.freshdesk.com.
• Outbound (default): replies leave through Freshdesk's own mail servers with the From header rewritten to look like your domain. This is where SPF and DKIM either line up or don't.
• Outbound (custom mailbox): you can connect a custom SMTP or OAuth mailbox (Google Workspace, Microsoft 365) so replies leave through your own infrastructure. More control, more moving parts.

Freshsales (the CRM) follows the same pattern for sales sequences and one-to-one outreach. The difference is that Freshsales is much more likely to hit Gmail's bulk thresholds because sequences fire at pace.

The DKIM and SPF setup nobody actually finishes

During onboarding Freshworks shows you a DNS setup screen with DKIM CNAMEs. Three patterns are extremely common:

1. The admin adds the DKIM CNAMEs, verifies green in the UI, and moves on. Nobody checks SPF.
2. The SPF record already has a different sender (Google Workspace, Mailchimp, HubSpot) and nobody merges ininclude:_spf.freshemail.net — so the Freshdesk send fails SPF silently.
3. DMARC is at p=none and everyone assumes that means "everything is fine". It means "we have no opinion" — which is not the same as inbox placement.

A minimal sane DNS state looks like this (yours will differ by which Freshworks region you are on):

; SPF — one record, merged includes
yourdomain.com.  TXT  "v=spf1 include:_spf.google.com include:_spf.freshemail.net ~all"

; DKIM — per Freshworks onboarding screen
freshdesk1._domainkey.yourdomain.com.  CNAME  freshdesk1._domainkey.freshemail.net.
freshdesk2._domainkey.yourdomain.com.  CNAME  freshdesk2._domainkey.freshemail.net.

; DMARC — start at none, move to quarantine after 2 weeks clean
_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

When to use a custom outgoing mailbox

Freshdesk lets you plug in your own SMTP or OAuth mailbox instead of sending through Freshworks infrastructure. This is worth doing if:

• Your domain has established reputation on Google Workspace or Microsoft 365 and you'd rather ride that reputation than build a new one on Freshworks shared IPs.
• You have strict compliance requirements around which servers touch customer data.
• You are seeing systematic Gmail Promotions placement on transactional replies and need alignment with your primary sending identity.

The trade-off: you now own warm-up, rate limits, and bounce handling. Freshworks will happily pump through a Google Workspace mailbox faster than the 2,000/day per-user cap, and when you hit the cap your agents see cryptic send errors instead of a clean error in the UI.

Seed-test a real ticket reply

This is the part most teams skip. It takes three minutes and costs nothing.

1. Create a dummy ticket in Freshdesk by emailingsupport@yourdomain.com from a throwaway address (the From address becomes the "customer").
2. Reply to that ticket from Freshdesk using the exact template your agents use — signature, images, tracking link.
3. Instead of using a single throwaway address as the "customer", use a seed mailbox list covering Gmail, Outlook / Microsoft 365, Yahoo, Mail.ru, GMX, ProtonMail, and iCloud. That is what a placement test gives you.
4. Check how many land in Inbox vs Promotions vs Spam, and read the raw headers for SPF / DKIM / DMARC verdicts.
5. Do the same thing once for a Freshsales sequence email — those are typically closer to cold outreach and will behave differently from transactional replies.

What the results usually say

From our own testing of Freshdesk-sent replies across ~50 customer domains, three patterns show up:

• SPF pass, DKIM fail: you added DKIM records but pointed them at the wrong region (US-vs-EU Freshworks pods). Fix by pulling the CNAMEs from the account's actual region.
• Inbox on everything except Gmail Promotions: the template has too much marketing CSS, an image-to-text ratio tilted toward banners, and one-click unsubscribe. Gmail reads it as marketing. Strip the template down for replies.
• Outlook Junk only: missing PTR / rDNS on a custom SMTP, or the tracking domain is on an IP with a poor Microsoft SNDS reputation. Swap the tracking subdomain or drop click tracking for support replies entirely.

10-minute checklist before you close this tab

1. Both DKIM CNAMEs present and resolving.
2. SPF record merged — one record only — with Freshworks include added.
3. DMARC published (start at p=none, read reports for 2 weeks, then tighten).
4. Tracking domain is a subdomain of your own domain, not a Freshworks shared one.
5. Signature has a plain-text unsubscribe / preferences link only on marketing contexts, not on transactional ticket replies.
6. One seed test run against a real ticket reply, from a real agent account, before you ship a new template.

FAQ