How to Set Up SPF, DKIM & a Custom Mailbox in Freshdesk

SPF and DKIM in one minute

SPF (Sender Policy Framework) is a single DNS record that lists which mail servers are allowed to send email for your domain. When Freshdesk sends a reply from [email protected], the receiving server looks up your SPF record and checks whether Freshdesk's servers are on the approved list. DKIM (DomainKeys Identified Mail) goes a step further: it attaches a cryptographic signature to every outgoing message, and the receiving server validates that signature against a public key you've published in DNS. SPF answers "is this sender allowed?"; DKIM answers "was this message actually sent by them and untampered?".

You want both. Together they're what modern mailbox providers use to decide whether your support mail is trustworthy, and they're the foundation a DMARC policy sits on top of later. Missing authentication is the single most common reason a Freshdesk instance ends up in spam folders, so it's worth getting right before you touch anything fancier.

Step 1: Publish your SPF record

SPF is the quicker of the two, and it's the same for every Freshdesk account. Per Freshworks' Create an SPF record documentation, the value to publish is:

v=spf1 include:email.freshdesk.com ~all

1. Log in to your DNS provider (the registrar or host that controls your domain — Cloudflare, GoDaddy, Route 53, and so on).
2. Look for an existing SPF record. It's a TXT record on your root domain whose value starts with v=spf1. You can only have one SPF record per domain — a second one breaks both.
3. If you have no SPF record yet, add a TXT record on your domain with the value above.
4. If you already have one (for Google Workspace, Microsoft 365, a marketing tool, etc.), merge Freshdesk's include into it rather than adding a new record. For example: v=spf1 include:_spf.google.com include:email.freshdesk.com ~all.
5. Save, and allow time for DNS to propagate.

One useful detail from the same doc: SPF checks count against a hard limit of DNS lookups, so if your record is getting crowded you can swap the generic include for a data-centre-specific one to reduce lookups — fdspfus.freshemail.io (US), fdspfeuc.freshemail.io (EU), fdspfind.freshemail.io (India), or fdspfaus.freshemail.io (Australia), matching wherever your Freshdesk account is hosted. And note Freshworks' own caveat: SPF configuration isn't required if you already have DKIM set up — though publishing both is the belt-and-braces approach most teams should take.

Step 2: Set up DKIM (this is where the domain gating bites)

DKIM is where deliverability really lives, and it's also where the setup gets conditional. In Freshdesk, DKIM is configured under Admin → Channels → Email → Advanced Settings → Configure DKIM, as documented in Freshworks' Email domain verification using DKIM records guide.

Here's the important catch, and the reason the screenshot below looks the way it does: DKIM applies to a support email on a custom domain that you own ([email protected]), not to the default @yourcompany.freshdesk.com address you get out of the box. If you haven't created a support email on a verified custom domain yet, Freshdesk has nothing to sign — so the DKIM Settings page shows an empty state prompting you to create one first. Adding a custom support-email domain is itself a feature that depends on your plan tier, so this is the first place a lower-tier account can hit a wall.

Once you do have a custom support domain, the flow is:

1. Open Admin → Channels → Email → Advanced Settings → Configure DKIM and expand your domain.
2. Freshdesk generates four CNAME records unique to your account. Copy each one exactly — the host/name on the left and the target it points to on the right.
3. Add all four CNAME records at your DNS provider, matching Freshdesk's values precisely (a single wrong character means the check fails).
4. Return to the same DKIM page and click Verify.
5. Freshdesk checks your DNS and shows a green check next to each record it can validate, or a red cross where the record isn't found yet.

DNS changes aren't instant. Freshworks notes propagation can take anywhere from a few minutes to several hours, and in some cases up to 48 hours — so if Verify shows red crosses immediately after you publish the records, wait and try again rather than assuming you got the values wrong. You'll get an email confirmation once verification completes. One reassuring point: DKIM is documented as available across all Freshdesk plan tiers (Free, Growth, Pro, Enterprise) — the gate isn't DKIM itself, it's whether you have a custom support-email domain for it to sign.

Step 3: When you're using a custom mailbox

A custom mailbox (also called a custom email server or connected mailbox) is when you route Freshdesk through your own mail infrastructure — connecting an existing Google Workspace or Microsoft 365 mailbox so mail is sent from your servers rather than Freshdesk's. This changes the authentication picture.

Because the mail leaves your infrastructure, Freshdesk's DKIM signing isn't the thing doing the work — your own mail provider's authentication is. Freshworks is explicit that DKIM verification is not specifically required for a custom email server in Freshdesk, but they still recommend configuring DKIM for your own DNS at your end. In practice: set up SPF and DKIM for your mailbox with your mail provider (Google Workspace and Microsoft 365 both publish their own steps), make sure your SPF record authorises that sending infrastructure, and treat Freshdesk's DKIM page as an optional extra rather than the primary control.

The decision comes down to who sends the mail:

The honest limits — where native email authentication stops

Freshdesk's built-in SPF and DKIM tooling is genuinely solid: the SPF value is a copy-paste, the DKIM page generates account-specific records and verifies them for you with clear green-check/red-cross feedback, and the whole thing is available without paying extra for DKIM itself. For most teams it's all you need to escape the spam folder.

But be clear-eyed about the edges. The custom-domain requirement is the real gate — DKIM only signs mail from a support address on a verified custom domain, and adding that domain depends on your plan. If you're on a low tier using the default @yourcompany.freshdesk.com address, you can't sign your outbound mail through Freshdesk, and the DKIM page will keep showing that empty state. Freshdesk also doesn't provide a DMARC value — the policy layer that tells receivers what to do when SPF/DKIM fail — so you author that record yourself with a DMARC generator. And once your DNS is clean, deliverability stops being the bottleneck: authentication decides whether your reply is delivered, not how good or how fast the reply is. If you want the fuller tour of the surrounding options, Freshdesk email explained covers them.

That second problem — the quality and speed of the reply itself — is where an AI agent layer fits, sitting cleanly on top of the deliverability you've just fixed. The broad category of AI agents for customer service exists to do the reading and writing that DNS records can't. Macha is one such layer: it connects to the Freshdesk you already use as a native connector — it does not replace your help desk, your mailbox, or your DNS setup. You connect it with your subdomain and API key, and it reads and writes the same tickets, drafting or posting grounded replies and looking up order or account status through a custom tool that turns a REST API into something the agent can call — the fuller version is in how to automate Freshdesk with AI. (Macha's connector is for Freshdesk specifically — not Freshchat, Freshservice, or Freshcaller. And credits are consumed per AI action, not per resolution — the pricing page breaks that down.)

The clean division of labour: let SPF and DKIM guarantee the message arrives, and layer an agent on top so the message that arrives is actually a fast, correct answer.

FAQ

What SPF record does Freshdesk need? Publish a single TXT record on your domain with the value v=spf1 include:email.freshdesk.com ~all. If you already have an SPF record for Google Workspace, Microsoft 365 or another tool, merge Freshdesk's include into that existing record rather than creating a second one — a domain can only have one valid SPF record.

Why does the DKIM page say I haven't created a custom domain? Because DKIM in Freshdesk signs mail sent from a support email on a verified custom domain you own ([email protected]), not the default @yourcompany.freshdesk.com address. Until you've added a custom support-email domain, there's nothing for Freshdesk to sign, so the DKIM Settings page shows an empty state prompting you to create one first. Adding that domain depends on your plan tier.

How long do DKIM records take to verify? DNS propagation can take anywhere from a few minutes to several hours, and in some cases up to 48 hours. If Freshdesk shows red crosses right after you publish the four CNAME records, wait and click Verify again before assuming the values are wrong.

Do I still need DKIM if I use a custom mailbox? Freshdesk says DKIM verification isn't strictly required for a custom email server, because your own mail provider handles the signing — but Freshworks still recommends configuring SPF and DKIM at your provider's end (Google Workspace or Microsoft 365) so your outbound mail is authenticated from your own infrastructure.

Does fixing SPF and DKIM improve my reply quality? No — authentication only controls whether your mail reaches the inbox instead of spam. To improve the speed and quality of the reply itself, you'd layer an AI agent like Macha on top of Freshdesk, which drafts or sends grounded replies while Freshdesk and your DNS stay exactly as they are.

Once your mail is landing in the inbox, the next win is making the reply itself faster and better. Start a free trial of Macha and connect it to your Freshdesk in minutes.