Email authentication for Freshdesk: SPF, DKIM and DMARC

13 May 2026 · 14 min read

Freshdesk is a support desk that sends on your behalf from your own support address, for example support@yourdomain.com, every time an agent replies to a ticket or an automation fires a notification. To your customers it looks like your company sent the email. To Gmail, Yahoo and Microsoft it looks like a third party (Freshdesk) sending mail that claims to be from your domain, and unless you authenticate it correctly, it either lands in spam or, once you enforce DMARC, gets rejected outright.

This guide is specific to Freshdesk. It covers the exact SPF include Freshdesk uses, the two DKIM CNAME selectors you publish, what Freshdesk does and does not let you control about the Return-Path, and the order of operations that takes your domain to DMARC enforcement without breaking a single ticket reply. If you want the underlying theory rather than the Freshdesk mechanics, what is DMARC and DMARC alignment explained are the background reading. Everything below assumes you already send from your own domain, not the default yourcompany.freshdesk.com address.

How Freshdesk sends your support email

When a ticket reply leaves Freshdesk, three pieces of identity travel with it, and DMARC cares about how they relate to each other.

• The From header shows your support mailbox, for example support@yourdomain.com. This is the domain DMARC evaluates against. Everything hinges on whether SPF or DKIM can be made to match it.
• The Return-Path (the envelope MAIL FROM address that SPF actually checks) is set by Freshdesk to its own outbound mail domain. Freshdesk relays through Freshworks mail infrastructure, so the bounce address lives on a Freshdesk/Freshworks-controlled domain, not yours.
• The DKIM signature, before you configure anything, is applied by Freshdesk using a Freshdesk-owned signing domain. It is a valid signature, but the d= value is not your domain.

DMARC does not pass just because SPF passes or a DKIM signature verifies. It passes when at least one of them both passes and aligns, meaning the authenticated domain matches the domain in the visible From header. With nothing configured for Freshdesk:

• SPF passes for Freshdesk's envelope domain, because that domain is listed in Freshdesk's own SPF record. But the envelope domain is not yourdomain.com, so SPF is not aligned, and DMARC ignores the pass.
• DKIM verifies against Freshdesk's signing domain, which again is not yourdomain.com, so DKIM is also not aligned.

The result is that out of the box, Freshdesk mail can fail DMARC even though it is perfectly legitimate. The fix has two halves: add Freshdesk to your SPF record (helps deliverability, may or may not align depending on your setup), and publish Freshdesk's DKIM CNAMEs so signatures carry d=yourdomain.com. DKIM is the mechanism you can rely on to align, so treat it as mandatory rather than optional.

The mental model to keep: SPF is hygiene, DKIM is alignment. For Freshdesk, getting both fdkim1 and fdkim2 CNAMEs live and verified is what actually carries your DMARC pass to p=reject.

Step 1: add Freshdesk to your SPF record

Freshdesk publishes an SPF include for its outbound mail. The mechanism you add to your record is:

include:_spfd.freshemail.com

You merge this into your existing v=spf1 record. You must never publish a second SPF record. A domain is allowed exactly one v=spf1 TXT record, and publishing two produces a permanent error (PermError) that breaks SPF for every sender on the domain, not just Freshdesk. If you already send through Google Workspace and Freshdesk, a single combined record looks like this:

v=spf1 include:_spf.google.com include:_spfd.freshemail.com -all

Two things to watch closely.

• The 10 DNS-lookup limit. SPF allows a maximum of ten DNS lookups across the entire record, counting everything pulled in by nested includes. Freshdesk's include expands to further lookups, and once you stack Google, Freshdesk, a marketing platform and an invoicing tool, you can tip over ten and trigger PermError, which silently breaks SPF for all of them. If you are near the edge, flattening is the answer. See how SPF flattening works and the 10-lookup limit explained, or let our hosted SPF product keep a flattened, auto-updating record under the limit.
• Your all qualifier. Use -all (hard fail) once you are confident every legitimate sender is listed. While you are still discovering senders, ~all (soft fail) is the safer interim setting.

Before and after editing, confirm the record parses and stays under ten lookups with the SPF checker. It expands the record and shows you the live lookup count so you can see exactly whether the Freshdesk include pushed you over.

A note on SPF alignment with Freshdesk specifically: because the Return-Path sits on a Freshdesk/Freshworks domain by default, SPF passes but does not align to your From domain. That is normal. We cover the Return-Path question and what you can change in the next section, but do not expect SPF alone to carry your DMARC pass for Freshdesk. DKIM is the dependable path.

Step 2: publish Freshdesk's DKIM CNAME records

This is the part that makes DMARC work. Freshdesk uses two DKIM selectors and rotates the underlying keys, so you publish two CNAME records pointing back to Freshdesk. Because they are CNAMEs, Freshdesk manages the actual public keys behind them, and any key rotation happens on their side without you touching DNS again.

In Freshdesk you start the process under Admin then Email then your support mailbox settings, where Freshdesk shows you the DKIM records to add for your domain. The selectors Freshdesk uses are fdkim1 and fdkim2. Replace yourdomain.com with your real support domain and create:

fdkim1._domainkey.yourdomain.com.  CNAME  fdkim1.yourdomain.com.dkim.fdkim.net.
fdkim2._domainkey.yourdomain.com.  CNAME  fdkim2.yourdomain.com.dkim.fdkim.net.

Freshdesk generates the exact right-hand target for your account inside the admin panel, so always copy the destination it shows you rather than typing it from memory; the host portion is keyed to your domain. The left-hand side will always be fdkim1._domainkey and fdkim2._domainkey under your domain. A few specifics that trip people up:

• They are CNAME records, not TXT. A very common mistake is to paste the target into a TXT record. CNAME is correct. If your DNS host shows the value with a trailing dot, keep it; if it does not, do not add one. Match your provider's convention.
• Do not proxy them. If your DNS sits behind a CDN or proxy with a per-record proxy toggle (for example an orange-cloud switch), DKIM CNAMEs must be DNS-only. A proxied DKIM CNAME will not resolve to the key, and DKIM will fail.
• The hostname must be exact. fdkim1._domainkey and fdkim2._domainkey, no typos, no extra label, no swapping the numbers.
• Subdomains. If your support address lives on a subdomain, say support@help.yourdomain.com, the selectors must be published under that subdomain (fdkim1._domainkey.help.yourdomain.com). The selector hostname always tracks the From domain Freshdesk signs for. For more on how selectors work, see DKIM selectors explained.

Publish both. Freshdesk alternates between the two selectors when it rotates keys, so if only one is live, signing fails intermittently the moment it switches to the missing one. For background on why providers rotate, see DKIM key rotation.

After publishing, verify both CNAMEs resolve before you tell Freshdesk to activate them. The DKIM checker lets you query a selector directly: check fdkim1 and fdkim2 against your domain and confirm each returns a valid key through the CNAME chain. DNS propagation can take anywhere from a few minutes to a day depending on your TTL, so do not rush.

Step 3: activate DKIM in Freshdesk (last, not first)

The single most important sequencing rule: publish the CNAMEs, confirm they resolve, then click Activate in Freshdesk. If you tell Freshdesk to enable DKIM before the records are live and propagated, it may sign with a key recipients cannot verify yet, which causes delivery failures on your support mail.

Once both CNAMEs resolve cleanly:

1. In Freshdesk, open Admin then Channels then Email.
2. Find your support mailbox (your custom support@yourdomain.com address) and open its settings.
3. In the DKIM/domain authentication section, click Verify or Activate so Freshdesk checks the published CNAMEs and turns on signing for your domain.

From then on, outbound Freshdesk mail carries a DKIM signature with d=yourdomain.com and an fdkim1 or fdkim2 selector. Because the signing domain now matches your From domain, DKIM aligns, and that is what makes Freshdesk traffic pass DMARC.

Send a test ticket reply to an address you control at a major mailbox provider, open the raw message, and inspect the Authentication-Results header. You want to see something like:

dkim=pass header.d=yourdomain.com header.s=fdkim1
dmarc=pass (p=NONE) header.from=yourdomain.com

If header.d shows a Freshdesk or Freshworks domain instead of yours, the custom-domain DKIM did not take effect, usually because the CNAMEs were not resolving when you clicked Activate. Re-check DNS with the DKIM checker and verify again in Freshdesk.

What about the Return-Path and a custom from address?

This is where Freshdesk teams often go down a rabbit hole, so it is worth being precise.

Freshdesk's From header is fully yours: you set up the support mailbox as support@yourdomain.com and that is what recipients see and reply to. There is no argument about the visible identity.

The Return-Path (envelope sender) is the part Freshdesk controls. By default Freshdesk uses its own outbound mail domain as the envelope, which means SPF passes for that envelope but does not align to your From domain. Unlike a marketing ESP that hands you a custom return-path subdomain to CNAME, Freshdesk's standard mailbox flow keeps the bounce processing on its side. So:

• Do not bank on SPF alignment for Freshdesk under the standard configuration. Treat any SPF pass you see in reports as deliverability help, not as your DMARC pass.
• DKIM alignment is the reliable mechanism and it is fully under your control via the two CNAMEs. This is why we treat DKIM as mandatory here rather than optional.

DMARC passes if either SPF or DKIM aligns. Because DKIM aligns cleanly once fdkim1/fdkim2 are live and active, you do not need SPF to align. That is the whole game. If you also run an inbound forwarding setup (forwarding support@yourdomain.com into Freshdesk), note that forwarding is an inbound concern and does not change the outbound authentication picture described here. For why DKIM survives forwarding hops where SPF does not, see forwarding and DMARC.

Step 4: read your DMARC reports and inventory every sender

Before you tighten your policy, you need proof that Freshdesk is aligning and that you have not forgotten another sender on the same domain. Your From domain is almost certainly used by more than Freshdesk: a marketing platform, your own mail server, an invoicing tool, a CRM, a newsletter system. DMARC enforcement blocks anything that is not aligned, so you inventory everything first.

DMARC aggregate reports (RUA) are how you build that inventory. Start your DMARC record at monitoring only:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; fo=1; adkim=r; aspf=r

A few notes specific to the Freshdesk situation:

• p=none collects data without affecting delivery. Stay here until Freshdesk and every other sender shows aligned passes.
• adkim=r (relaxed DKIM alignment) is the default and is correct for Freshdesk. The signing domain and the From domain match at the organisational level, so relaxed alignment passes. Do not use adkim=s (strict) unless every single sender signs with the exact same domain, which is rare once a help desk is in the mix.
• fo=1 requests a failure report whenever any mechanism fails, which helps you see the Freshdesk SPF-misalignment noise and confirm DKIM is the one carrying the pass.

If you do not yet have a DMARC record, generate one with the DMARC generator and confirm what is published with the DMARC checker. For what these tags mean, DMARC RUA and RUF reports is the reference.

Aggregate reports arrive as XML and are painful to read by hand. Drop them into the DMARC report analyzer to see, per source, whether SPF and DKIM passed and aligned. For Freshdesk you are looking for rows where the source is Freshworks/Freshdesk infrastructure showing DKIM aligned: pass. Expect those same rows to show SPF aligned: fail, which is completely fine, because DMARC only needs one aligned pass. If you are new to reading these, reports versus the inbox explains what the numbers mean.

For ongoing visibility rather than a one-off check, our monitoring ingests your aggregate reports continuously and alerts you when a source like Freshdesk stops aligning, for example after a key-rotation hiccup or a DNS edit. That is the difference between finding out from a dashboard and finding out from an angry customer whose reply bounced.

Step 5: move to quarantine, then reject

Only when your reports show Freshdesk and every other legitimate sender aligned over a representative window (a week or two that covers your normal ticket volume) should you tighten the policy. Rushing this is how teams break their own support email.

Step up gradually. First, quarantine a fraction of failing mail:

v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@yourdomain.com; fo=1

The pct=25 tag applies quarantine to a quarter of failing mail, so any sender you overlooked gets a soft landing in spam rather than a hard block while you watch. After a few clean days, raise to pct=100, then once that is clean, go to full enforcement:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; fo=1

At p=reject, unauthenticated mail using your domain is refused outright. Because Freshdesk is aligned via DKIM, your support email sails through, while anyone spoofing your domain does not. For the staged playbook in full, see reach p=reject without breaking email, and for the policy ladder itself, none, quarantine and reject explained.

If your support address lives on a subdomain, remember the subdomain policy (sp=) and any dedicated subdomain DMARC record govern it. The subdomain policy tag and subdomain DMARC records cover the details so a subdomain does not slip enforcement.

Common Freshdesk pitfalls

• Only one selector published. Both fdkim1 and fdkim2 must resolve. Freshdesk rotates between them, so a single live selector means intermittent DKIM failures when it switches. Verify both with the DKIM checker.
• Activating in Freshdesk before DNS propagated. The classic outage. Confirm both CNAMEs resolve first, then click Verify/Activate in the mailbox settings.
• CNAMEs turned into TXT or proxied. They must be CNAME, must be DNS-only, and must point at the exact target Freshdesk generated for your account.
• Copying another tenant's target. The CNAME destination is keyed to your domain. Always copy the value Freshdesk shows in your own admin panel; do not reuse one from a blog or another domain.
• Assuming SPF will carry alignment. Under the standard Freshdesk mailbox, the Return-Path is on a Freshdesk domain, so SPF passes but does not align. Rely on DKIM for the DMARC pass.
• Still sending from yourcompany.freshdesk.com. DKIM signing for your domain only applies to a support address on your own domain. Set up the custom support mailbox first, then authenticate it.
• Forgetting other senders. Freshdesk aligning is necessary but not sufficient. Inventory every sender via reports before you enforce, or you will block your own marketing or billing email when you reach p=reject. The classic failure mode is a service that was never aligned showing up at reject.
• A second SPF record. Merge the Freshdesk include into your one v=spf1 record. Two records is PermError for the whole domain.

The practical takeaway

Freshdesk is a DKIM-first sender. SPF should still list include:_spfd.freshemail.com for deliverability, but because the Return-Path sits on a Freshdesk domain by default, SPF passes without aligning, so your entire DMARC pass for support email rests on publishing both fdkim1 and fdkim2 CNAME records, confirming they resolve, and only then activating DKIM in your Freshdesk mailbox settings. Once header.d shows your domain and your reports show Freshdesk DKIM aligned, you can move from p=none through p=quarantine to p=reject without losing a single ticket reply.

Start by checking what is live today with the SPF checker, the DKIM checker and the DMARC checker, then watch your aggregate reports in the DMARC report analyzer. If you would rather not babysit selectors, propagation and the staged rollout yourself, our done-for-you DMARC service configures Freshdesk alignment, keeps your SPF record flattened and under the lookup limit, and takes your domain to enforcement safely with continuous monitoring so you hear about a broken signature before your customers do.