Do I still need the SPF include if I've set up DKIM?

Freshdesk makes DKIM the mandatory domain-verification step and notes that configuring it also handles the SPF check, so a verified DKIM setup is enough to be compliant — DKIM signs with d=yourdomain.com and carries DMARC alignment on its own. Adding include:email.freshdesk.com is still worthwhile as belt-and-suspenders authorization (some receivers weight SPF), but if you're near the 10-lookup limit, verified DKIM alone is sufficient — or use your 1-lookup regional include instead of the full one.

Why does include:email.freshdesk.com use so many DNS lookups?

Because it isn't flat. Live DNS shows it expands to include:sendgrid.net plus four regional includes (fdspfus/euc/ind/aus.freshemail.io), and sendgrid.net itself nests ab.sendgrid.net — 7 lookups in total. Freshdesk routes some mail via SendGrid and keeps separate US/EU/India/Australia IP pools. If that pushes your SPF over 10 lookups, switch to just your account's regional include, which is a flat ip4-only record costing a single lookup.

Which regional include should I use?

Match your Freshdesk account's data center: fdspfus.freshemail.io (US), fdspfeuc.freshemail.io (EU), fdspfind.freshemail.io (India), fdspfaus.freshemail.io (Australia). Your data center is tied to where your account was provisioned. If you're unsure, or you've migrated pods, keep the full include:email.freshdesk.com — it covers every region at the cost of more lookups.

I use a custom mailbox / send Freshdesk replies through Google Workspace. Do I add Freshdesk's records?

No. When outbound goes through your own SMTP server or a connected Google/Microsoft mailbox, Freshdesk isn't the sender — your provider is. Authenticate at that provider (its SPF include and DKIM) and skip Freshdesk's SPF/DKIM records entirely. Freshdesk's records only apply when Freshdesk itself sends your replies.

Does the default yourcompany.freshdesk.com address need SPF and DKIM?

No. That mailbox is already authenticated by Freshdesk on the freshdesk.com domain. You only add these records when you reply from a support email on your own domain, like support@yourdomain.com.

My DKIM won't verify — what's wrong?

Almost always one of five things: the records were added as TXT instead of CNAME; a Cloudflare orange-cloud proxy is on; the host got doubled (fwdkim1.yourdomain.com.yourdomain.com); there's a stray leading/trailing space; or you didn't add all of the CNAMEs Freshdesk generated (typically 4). Fix those, wait for propagation (up to 24–48 hours), and click Verify again.

Will Freshdesk's records conflict with my Google Workspace or Microsoft 365 mail?

No — DKIM uses Freshdesk's own selectors and CNAMEs, so it won't touch your existing DKIM. The only rules: keep a single SPF TXT record on the domain (merge, don't duplicate), and mind the lookup budget — Freshdesk's full 7-lookup include plus Google or Microsoft can push you past the 10-lookup ceiling, so use your 1-lookup regional Freshdesk include (fdspfus/euc/ind/aus.freshemail.io) rather than the full one when you're stacking senders.

SPF setup guide

SPF, DKIM & DMARC for Freshdesk.

Freshdesk lets you reply to customers from your own address (support@yourdomain.com) instead of the default yourcompany.freshdesk.com mailbox — but the moment you do, Freshdesk is sending mail as your domain, and you have to prove it's authorized. Authentication is two moves: a DKIM step inside Freshdesk (Admin → Channels → Email → Advanced Settings → Configure DKIM) that generates CNAME records signed as your domain, and an SPF include you can merge into your root record at your DNS host. Freshdesk publishes no DMARC value, so you add that policy record yourself. Get DKIM verified (with DMARC alongside) and your ticket replies land in the inbox with no "via freshdesk.com" tag; skip it and Gmail, Yahoo, and Microsoft increasingly route them to spam.

SPF include

Your DNSAdd the CNAME / TXT records

FreshdeskSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate Freshdesk?

Helpdesk mail is the worst mail to have land in spam: password-reset confirmations, ticket replies, SLA notifications — the messages customers are actively waiting for. Yet a Freshdesk support email on your domain is exactly the kind of "third party sending as you" that Gmail and Yahoo's February 2024 sender rules (and Microsoft's 2025 enforcement) are designed to filter. Until you authenticate, Freshdesk sends your replies over its shared infrastructure with no cryptographic tie to your domain: recipients may see a "via" note, DMARC can't pass, and your ticket mail inherits the reputation of every other unauthenticated Freshdesk tenant. Freshdesk itself now makes DKIM domain verification a mandatory check for domain-based support emails precisely because of these rules — its docs note that verifying DKIM also covers the SPF check that DMARC relies on. Setting up DKIM (plus SPF and DMARC) ties the mail to your organizational domain, removes the "via" tag, lets DMARC pass on ticket replies, and builds sending reputation under your own name — not the shared pool.

The SPF reality for Freshdesk

Freshdesk is a genuine "include" provider — unlike CNAME-only ESPs, it documents a real shared mechanism, include:email.freshdesk.com, that you can add to the single SPF TXT record on your sending domain. But it is not Freshdesk's primary setup step, and the include is unusually heavy. Verified against live DNS, email.freshdesk.com publishes v=spf1 include:sendgrid.net include:fdspfus.freshemail.io include:fdspfeuc.freshemail.io include:fdspfind.freshemail.io include:fdspfaus.freshemail.io ~all — Freshdesk routes some mail through SendGrid and maintains four regional IP pools (US, EU, India, Australia). Counting those includes plus the nested include:ab.sendgrid.net inside sendgrid.net, a single include:email.freshdesk.com consumes 7 of your 10 allowed SPF DNS lookups (RFC 7208). That becomes a real problem the day you also stack Google Workspace or Microsoft 365 on the same domain — you hit PermError and SPF stops evaluating for everyone. Freshdesk's own fix: it publishes per-data-center includes — fdspfus.freshemail.io, fdspfeuc.freshemail.io, fdspfind.freshemail.io, fdspfaus.freshemail.io — each a flat ip4-only record that costs a single lookup. Using just your account's regional include drops the cost from 7 lookups to 1. The honesty point: whether SPF actually aligns for DMARC depends on the envelope sender Freshdesk stamps, so treat DKIM — which signs with d=yourdomain.com — as the mechanism that carries your DMARC pass. Freshdesk itself makes DKIM the mandatory domain-verification step and notes that configuring DKIM also handles the SPF check, so it never asks you to add its SPF include separately. Add the include (regional if you're near the limit) for belt-and-suspenders authorization, but let DKIM do the alignment work, and always keep exactly one v=spf1 record on the domain by merging, never publishing a second.

Step by step

In Freshdesk

1
Add a support email on your own domain
Sign in as an admin and go to Admin (gear icon) → Channels → Email. Click New support email and set the reply address to something on your domain, e.g. support@yourdomain.com. Only domain-based support emails need authentication — the built-in yourcompany.freshdesk.com address is already authenticated by Freshdesk and needs nothing.
2
Open DKIM configuration
Still under Admin → Channels → Email, open Advanced settings and click Configure DKIM. Freshdesk generates a set of CNAME records (typically 4) unique to your domain, each pointing into *.domainkey.freshemail.io. Leave this screen open — you'll copy the exact host and value into DNS.

In your DNS

3
Publish the DKIM CNAMEs
At your DNS host, add each record Freshdesk shows as a CNAME (not TXT). Copy the Host and Value verbatim, character for character. Enter only the subdomain label in the host field (e.g. fwdkim1) — not the full fwdkim1.yourdomain.com — so your registrar doesn't append your domain twice. Ensure there are no leading or trailing spaces.
4
Add or merge the SPF include (optional)
DKIM alone verifies your domain, but you can add include:email.freshdesk.com to your SPF TXT record for extra authorization — e.g. v=spf1 include:email.freshdesk.com ~all. If you already send from Google, Microsoft 365, or another provider, merge this mechanism into that one line rather than publishing a second SPF record. Near the 10-lookup limit? Use your data-center-specific include instead (e.g. include:fdspfeuc.freshemail.io) to spend 1 lookup rather than 7.
5
Turn off the Cloudflare proxy on the CNAMEs
If your DNS is behind Cloudflare, set each Freshdesk DKIM CNAME to "DNS only" (grey cloud). An orange-cloud proxied CNAME won't resolve through to freshemail.io and DKIM verification will fail.

In Freshdesk

6
Verify DKIM
Return to the Configure DKIM screen in Freshdesk and click Verify. Freshdesk checks that all the CNAMEs resolve and marks the domain verified. DNS propagation is usually minutes but can take up to 24–48 hours; re-check if it doesn't pass immediately.

In your DNS

7
Publish a DMARC policy record
Freshdesk gives you no DMARC value, so create one yourself. Add a TXT record at _dmarc.yourdomain.com beginning with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only — it won't affect delivery while you confirm Freshdesk mail passes DKIM aligned to your domain. Keep just one _dmarc record for the whole domain.

Verify

8
Send a real ticket reply and check the headers
From Freshdesk, reply to a test ticket addressed to a Gmail account you control. Open the message, choose ⋮ → Show original, and confirm DKIM: PASS with d=yourdomain.com and DMARC: PASS. SPF will show Freshdesk's (or SendGrid's) sending IPs. Don't rely on Freshdesk's "Verified" badge alone — confirm on an actual message.

Records to add

Freshdesk generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
CNAME	fwdkim1	spfmx1.domainkey.freshemail.ioDKIM signing record — ILLUSTRATIVE and the primary setup step. Freshdesk generates the exact host and target (usually 4 CNAMEs) per domain on the Configure DKIM screen; copy them verbatim. Add as CNAME, not TXT.
CNAME	fwdkim2	spfmx2.domainkey.freshemail.ioSecond illustrative DKIM CNAME. Add every record Freshdesk lists (typically 4) — all point into *.domainkey.freshemail.io and sign as your domain. Some of the 4 hosts include a _domainkey label; use whatever Freshdesk shows.
TXT	@	v=spf1 include:email.freshdesk.com ~allOptional root SPF — authorizes Freshdesk's sending IPs. Merge into your ONE existing SPF line; never publish a second SPF record. This shared include costs 7 DNS lookups (see the regional alternative below). DKIM, not this include, is what aligns for DMARC.
TXT	@	v=spf1 include:fdspfeuc.freshemail.io ~allRegion-specific alternative (EU shown) — a flat ip4-only record that costs just 1 lookup instead of 7. Pick fdspfus / fdspfeuc / fdspfind / fdspfaus to match your account's data center. Use this OR the line above, not both.
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYour DMARC policy — Freshdesk provides no value, so you create this. One per domain; start at p=none and tighten later.

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Freshdesk's setup costs against that budget.

SPF 10-lookup budget7 used · 3 free

Freshdesk adds 7 of your 10 lookups; ip4: and ip6: mechanisms are free.

DKIM

DKIM is Freshdesk's mandatory domain-verification step and the mechanism that actually carries your DMARC pass — and it's CNAME-delegated. On the Configure DKIM screen (Admin → Channels → Email → Advanced Settings → Configure DKIM) Freshdesk generates a set of CNAME records — typically four — unique to your domain, each pointing into *.domainkey.freshemail.io (an illustrative pair looks like fwdkim1 → spfmx1.domainkey.freshemail.io and fwdkim2 → spfmx2.domainkey.freshemail.io, but your exact hosts and targets are account-specific — copy them verbatim). Because these are CNAMEs delegated to Freshdesk rather than TXT keys you paste, Freshdesk holds the private keys and can rotate them without you ever editing DNS again. Critically, this DKIM signs your outgoing ticket mail with d=yourdomain.com, so it aligns with your From address and satisfies DMARC on its own — which is why Freshdesk treats DKIM as the mandatory verification step and its docs note that configuring DKIM also covers the SPF check, without asking you to add its SPF include separately. Add all of the CNAMEs exactly as shown (as CNAME, not TXT), with no leading or trailing spaces, grey-cloud/DNS-only if you're on Cloudflare, and enter only the subdomain label so your registrar doesn't double the domain. Then click Verify in Freshdesk.

DMARC

DMARC is a separate policy record on your domain, and Freshdesk deliberately hands you no value for it — you create it yourself. Publish a TXT record at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only, so it won't affect delivery while you confirm that Freshdesk ticket mail is passing DKIM aligned to your domain. Watch the aggregate (rua) reports for a week or two — Freshdesk should show up as a source with DKIM aligned and passing — then tighten the policy to p=quarantine and eventually p=reject. Keep exactly one _dmarc record for the whole organizational domain no matter how many senders you use (Freshdesk, Google Workspace, Microsoft 365, etc.); don't add a separate DMARC record for Freshdesk. If your support email is on a subdomain like support@help.yourdomain.com, DMARC on the organizational domain still covers it, but the SPF and DKIM records must sit on that subdomain.

Check it actually worked

Don't trust Freshdesk's "Verified" badge alone — confirm on a real message. From Freshdesk, reply to a test ticket sent to a Gmail address you control, open the reply, and choose ⋮ → Show original: you want DKIM: PASS with d=yourdomain.com and DMARC: PASS. SPF will list Freshdesk's or SendGrid's sending IPs (it authorizes but may not align — DKIM is what carries alignment). Want a full report? Send a Freshdesk test to check-auth@verifier.port25.com for an emailed breakdown. You can also run your domain through Qualisend's domain health check to confirm every CNAME and the SPF/DMARC records resolve — and watch the SPF lookup count, since include:email.freshdesk.com alone spends 7 of your 10. Once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer to confirm Freshdesk appears as an aligned, passing source.

Domain health check DMARC report analyzer

Common gotchas

Coverage
DKIM is the real step, not SPF: Freshdesk makes DKIM domain verification the mandatory check for domain-based support emails, and DKIM (d=yourdomain.com) is what aligns for DMARC. The SPF include is optional belt-and-suspenders — don't skip DKIM thinking an SPF line covers you.
Breaks auth
The include is a lookup hog: include:email.freshdesk.com nests SendGrid (plus its own ab.sendgrid.net) and all four regional pools — 7 of your 10 SPF DNS lookups from one line. Stack it with Google Workspace or Microsoft 365 and you can trip PermError, which makes SPF stop evaluating for the whole domain. If you add it at all, use your data-center include (fdspfus / fdspfeuc / fdspfind / fdspfaus.freshemail.io) — each is 1 lookup.
DNS setup
Custom mailbox changes everything: if you configure a custom mailbox / your own outbound SMTP (or a Google/Microsoft "send-as"), Freshdesk relays through YOUR server, not its own. In that case Freshdesk's SPF include and DKIM CNAMEs don't apply — you authenticate at that outbound provider instead (e.g. include:_spf.google.com and Google's DKIM).
DNS setup
Host-field doubling: many registrars (GoDaddy especially) auto-append your domain, so entering fwdkim1.yourdomain.com becomes fwdkim1.yourdomain.com.yourdomain.com and verification fails. Enter only the label (fwdkim1) if the panel adds the domain for you.
DNS setup
They're CNAMEs, not TXT: Freshdesk's DKIM records must be created as CNAME records pointing into freshemail.io. Pasting them as TXT is a common cause of "DKIM not verified." Also strip any leading or trailing spaces — Freshdesk explicitly warns a stray space breaks validation.
DNS setup
Cloudflare proxy breaks resolution: set every Freshdesk DKIM CNAME to "DNS only" (grey cloud). An orange-cloud proxied CNAME won't resolve to freshemail.io and Verify fails.
Breaks auth
One SPF record only: if you add the include and already have a v=spf1 line, merge include:email.freshdesk.com into it. Two separate SPF TXT records is itself a PermError, and Freshdesk mail is often added alongside an existing mailbox provider.
DNS setup
No DMARC value from Freshdesk: it never appears on the DKIM screen. You must publish _dmarc yourself — skipping it means DKIM/SPF pass but you get no reporting and, under Gmail/Yahoo rules, no policy.
DNS setup
The default freshdesk.com mailbox needs nothing: only domain-based support emails require these records. And a support email on a subdomain needs its SPF and DKIM published on that subdomain, not the root.

Build your SPF record

Freshdesk doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.

Sending sources

Search for each platform you send email through and tick it.

Search for your email platform above, or .

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record0/10 DNS lookups

v=spf1 ~all

No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list