For Freshdesk’s default sending server, authenticate each support-email domain using the four CNAME records generated in your account, then run Freshdesk’s verification. A separate SPF change is not required when DKIM is already configured. Finish by checking a real support reply at an external mailbox, not just the green verification indicator. Freshdesk DKIM instructions and Freshdesk SPF guidance
This guide covers Freshdesk-managed outbound support mail. A connected Gmail, Microsoft 365, or custom SMTP mailbox uses a different sending route. Freshservice and Freshmarketer are separate products, not interchangeable DNS configurations.
This is a documentary setup guide. No customer account, DNS zone, or delivered message was tested.
Identify the transport before changing DNS
Make a short inventory before opening the DNS editor. For each support address, write down the visible From domain, selected outgoing server, business owner, and one representative message type. Include brand-specific domains and subdomains instead of assuming that the primary support address represents every reply.
Freshdesk’s default-server DKIM workflow requires an administrator. Its published applicability includes Freshdesk Free, Growth, Pro, and Enterprise, as well as listed Omni plans; older Omni experiences can differ. Custom-server authentication belongs at that sending service. Freshdesk configuration scope
If a mailbox connection is failing, distinguish that from a DNS-authentication failure. Expired authorization, invalid SMTP configuration, and provider sending restrictions can prevent a message from leaving at all. Publishing more DNS records cannot repair those problems. Freshdesk custom-server troubleshooting
For a connected Microsoft or Google mailbox, authenticate at that mailbox provider, then test the Freshdesk-originated message through that actual route. Do not switch transports as an incidental DNS fix.
Understand what SPF, DKIM, and DMARC prove
SPF evaluates SMTP MAIL FROM, normally reflected in the delivered Return-Path, or HELO in applicable cases such as a null reverse-path, not automatically the address displayed to the customer. A passing SPF result for a provider-owned domain does not automatically authenticate your visible From domain. Keep a single SPF TXT policy at each owner name and account for the ten DNS-lookup-term limit, including nested lookups. SPF specification
DKIM verifies a signature using the public key associated with its signing domain and selector. The message’s d= and s= values identify that lookup. A DNS record alone does not prove that an outbound message actually received the intended signature. Never publish a private signing key. DKIM specification
DMARC needs either passing, aligned SPF or passing, aligned DKIM. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. Authentication is not an inbox-placement guarantee. Current DMARC specification
The practical implication is simple: record the identities seen by the receiver. Do not treat “SPF passed” or “domain verified” as sufficient evidence without knowing which domain passed.
Prepare the DNS change
Use the DNS provider that serves the domain’s authoritative nameservers. It may differ from the registrar where the domain was purchased. Arrange access for an authorized DNS editor and keep the Freshdesk administrator available for the final verification.
Export or record the existing zone entries. Capture the current SPF and DMARC policies, any records already occupying the proposed CNAME names, and their TTLs. Set a small change scope: adding the generated authentication records should not alter website addresses, inbound MX routing, or unrelated verification tokens.
A CNAME cannot coexist with conflicting ordinary records at the same owner. Do not add TXT, A, AAAA, MX or a second target at an existing CNAME owner. Identical requirements across Freshdesk accounts need no duplicate; differing targets cannot be combined into one CNAME. If another service already uses the name, preserve it and resolve the conflict with Freshdesk Support rather than replacing it. DNS owner-name conflicts
Check the editor’s naming convention. In an example.com zone, a fully qualified owner such as SELECTOR._domainkey.example.com may need the relative host SELECTOR._domainkey. The uppercase word is a placeholder. The intended public name must appear once, not as SELECTOR._domainkey.example.com.example.com.
For a signing domain support.example.com, the full placeholder owner SELECTOR._domainkey.support.example.com is entered as SELECTOR._domainkey.support in the parent example.com zone, or SELECTOR._domainkey in a separately delegated support.example.com zone. If _domainkey.support.example.com itself is delegated, its authoritative administrator enters SELECTOR there. For an apex signing domain with delegated _domainkey.example.com, the relative selector is likewise SELECTOR. Do not remove valid NS delegations to make the parent dashboard appear authoritative. These are naming examples, not Freshdesk-issued selectors. DNS zones and aliases
Before opening Configure DKIM, confirm that the intended custom support address is already configured under Admin > Email so the correct domain appears. Freshdesk creates the domain entry when the email address is added. Support-address prerequisite
Publish the Freshdesk-generated records
- Sign in as an administrator and open Admin > Channels > Email > Advanced Settings > Configure DKIM.
- Select the relevant domain and copy all four generated CNAME owner/target pairs.
- Publish those exact pairs as CNAME records in the authoritative zone.
- Return to the domain’s DKIM settings and select Verify.
Use the complete generated set. Multiple addresses on the same domain share that domain setup; a second domain needs its own configuration. For an occupied record name, contact Freshdesk Support rather than inventing another selector. Official DKIM setup and verification
Keep an implementation worksheet with four rows: supplied owner, supplied target, public answer, and verification result. This catches the common case where three records were entered correctly and the fourth was overlooked. A target is a hostname, not a web URL: do not add https://, quotes, or spaces. Freshdesk’s screenshot shows four rows, including a non-selector alias as well as _domainkey owners. Preserve each generated owner rather than forcing every row into a selector pattern. Screenshot domains and account numbers are examples, never your values.
Keep each issued alias visible as a literal CNAME, not an HTTP-proxied or flattened address answer. On Cloudflare, use DNS only and turn the record’s Flatten control off when available. Relevant whole-zone CNAME flattening for all CNAME records must also be off: it overrides per-record behavior. Coordinate affected services before changing that shared setting. Cloudflare flattens apex CNAMEs by default and same-zone targets regardless of the setting; do not relocate Freshdesk owners to the apex or invent a switch. If mandatory behavior prevents the required literal answer, stop and agree a supported configuration with the DNS administrator and Freshdesk. Preserve valid delegations and unrelated records. Check authoritative CNAME answers after saving. Cloudflare verification controls and flattening scope and exceptions
Decide whether a separate SPF change is needed
Freshdesk explicitly says additional SPF configuration is unnecessary if DKIM is already set up. Where a separate SPF authorization is genuinely required, its documented mechanism is include:email.freshdesk.com. Do not create a second SPF record or replace the existing policy with a Freshdesk-only example. Freshdesk SPF instructions
For an approved change, insert the mechanism into the existing policy before its terminal all mechanism, preserving other authorized senders and the established qualifier. If the existing policy uses redirect=, review that flow with its owner instead of appending an all: redirect is ignored whenever an all mechanism is present. Preserve legitimate authorizations and policy intent. Then validate syntax and the full lookup budget. SPF all/redirect precedence A policy ending in -all should not silently become ~all because a tutorial uses that example.
Freshdesk also lists data-center-specific alternatives: fdspfus.freshemail.io for US, fdspfeuc.freshemail.io for EU, fdspfind.freshemail.io for IND, and fdspfaus.freshemail.io for AU. Confirm the account’s actual data center before considering a narrower include; geography of the support agent is not sufficient evidence. Data-center SPF options
Do not remove older SPF authorizations as an incidental cleanup. Establish whether another active sender still needs them and schedule that work separately.
Preserve the existing DMARC boundary
Look up the visible From domain’s policy before adding anything. For a sender at support.example.com, query _dmarc.support.example.com; also investigate applicable parent-policy inheritance. An empty child lookup does not mean there is no effective policy.
If a policy exists, preserve its enforcement, alignment settings, reporting destinations, and delegated administration. Do not publish a second DMARC policy or weaken an inherited policy to make setup easier.
Only when no direct or applicable inherited policy exists, the domain owner approves, and a monitored rollout is appropriate, a starting example is a TXT record at _dmarc.example.com with value v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Substitute an approved, monitored reporting address. In the example.com zone, the relative host is _dmarc. p=none requests monitoring, not enforcement. RFC 9989 replaces RFC 7489 and removes pct; do not build a new rollout around that retired tag. DMARC policy and discovery
For a child policy at _dmarc.support.example.com, use relative host _dmarc.support in the parent example.com zone or _dmarc in the delegated support.example.com zone. A _domainkey delegation does not move DMARC into that namespace.
A report destination in a different Organizational Domain from the policy domain requires the report-generating receiver to check DNS authorization; a destination within the same Organizational Domain is excepted. For a policy at example.com, reports.example.com is within the same Organizational Domain, whereas a mailbox under example.net is not. Authorization DNS does not replace the owner’s approval to share report data with that recipient. Aggregate-report authorization, RFC 9990 section 4
Stronger enforcement is a separate decision across all legitimate routes, not a reward for one successful ticket. RFC 9989 section 7.4 requires valid DKIM for domains publishing p=reject; retain existing protection and account for indirect-mail interoperability before changing policy. Enforcement considerations
Verify public DNS and a real support conversation
These are read-only command templates. Replace every uppercase placeholder with the corresponding account-generated name or observed message identity:
dig +short CNAME GENERATED_OWNER_FQDN
dig +short TXT SELECTOR._domainkey.SIGNING_DOMAIN
dig +short TXT OBSERVED_MAIL_FROM_DOMAIN
dig +short TXT _dmarc.VISIBLE_FROM_DOMAIN
Repeat the CNAME lookup for all four rows. Each answer must match the supplied target. A DKIM TXT query can follow a CNAME to the public key; use the selector actually present in the delivered message when checking active signing. Compare an authoritative answer with a public recursive resolver if results differ, and allow cached answers to expire.
Next, use controlled, valid mailboxes and fictitious ticket content to start a ticket through the approved inbound path and send its normal support response to an external mailbox. Do not enable new forwarding recipients or change MX, nameservers, DNSSEC, credentials or the outgoing route just to complete this tutorial; those require separately approved changes. Inspect its original headers, then reply from that mailbox and verify the support workflow separately. Repeat for each distinct brand, domain, and outgoing-server choice. A ticket marked resolved is not a mail-authentication result.
Obtain Authentication-Results produced inside the actual receiving service’s known processing boundary. Confirm that service’s documented handling of externally supplied authentication headers with its administrator; ignore attacker-supplied or untrusted fields. Header position or a matching authserv-id string alone is not proof of origin. Capture header.from, smtp.mailfrom, the DKIM signing domain, selector, and the receiver’s SPF, DKIM, and DMARC results. Authentication-Results trust boundary
Acceptance requires the intended branded visible From, the intended Freshdesk signature passing and aligning under current policy, and trusted receiver dmarc=pass. A DMARC pass via SPF alone does not prove this DKIM setup works. Reject a rewritten provider-owned From as proof of your brand’s authentication. For the illustrative From help@example.com, passing d=mail.example.com aligns only in relaxed mode when both share Organizational Domain example.com; passing d=example.com aligns in both modes. An unrelated provider envelope does not align merely because SPF passes. No universal Return-Path is assumed. Record SPF independently: fail means the connecting source was not authorized by that evaluated policy, permerror calls for syntax/multiple-policy/lookup-budget investigation, and temperror calls for transient DNS or lookup-failure investigation. Diagnose each even when DKIM supplies DMARC pass; no qualifier guarantees delivery or rejection. Save the message ID and time so the evidence can be linked to the configuration change. EmailAuth’s raw versus aligned DKIM results explains why another passing signature need not authenticate this From identity.
Troubleshoot in the right order
Records missing publicly: Confirm authoritative nameservers, zone selection, exact owner spelling, suffix handling, and record type. Waiting will not repair a record published in the wrong zone.
CNAME exists but Freshdesk remains unverified: Compare all four target values character by character, including unintended spaces. Retest after cache expiry. Freshdesk documents that propagation can sometimes take up to 48 hours; this is not a promise that a misconfigured record will fix itself. Escalate a persistent mismatch with the account, domain, expected records, public answers, and verification screenshot.
Freshdesk verifies, but the message uses another sender: Check the actual outgoing-server choice and support address used for that ticket. A successful domain configuration does not prove that a particular mailbox used it.
Custom mailbox cannot send: Investigate authorization, SMTP connectivity, and service limits rather than rotating DNS records. Freshdesk documents these as separate connection errors. Custom-mailbox failure diagnosis
DMARC passes, but mail is filtered: Authentication is only one input. Review rejection text, recipient rules, reputation, and message content without weakening the domain’s policy.