How to set up DMARC/DKIM/SPF for Freshworks
Published 5 Aug 2026
Updated 5 Aug 2026
13 min read
Summarize with
For Freshworks, verify the custom support address and publish the account-generated CNAME records shown in Freshservice or Freshdesk. Add one DMARC TXT record at _dmarc, then test a real message. Start a new DMARC deployment with p=none. If the domain already uses p=quarantine or p=reject, keep that policy while fixing Freshworks authentication. Freshworks supports a custom return path through its generated records, so SPF and DKIM can both contribute to DMARC.
Use the instructions in your account
Freshworks menu labels and DNS targets differ by product, region, account age, and mail-server choice. The Freshservice setup steps describe four generated CNAME records. The Freshdesk DKIM steps also require four generated CNAME records. Copy the values displayed in your own account instead of copying DNS targets from another tenant.
Add your domain
Freshworks authenticates a domain already attached to a verified custom support address. In Freshservice, the domain appears automatically on the authentication page after the address is verified, and it cannot be added or edited on that page. Use a domain your organization controls. Public mailbox domains cannot be authenticated this way.
- Choose the mail server. Use the Freshworks mail server if Freshworks will send replies. If you selected your own outgoing server, authenticate that server instead.
- Add the address. In Freshservice, open Admin, Channels, Email, then Email Settings and Mailboxes. Add the custom support address and complete its mailbox verification.
- Open authentication. Select Set up SPF and DKIM email authentication. With multiple workspaces, use Admin, Global Settings, Account Settings, Service Desk Security.
- Start the domain. Confirm that the expected domain appears, then select Get Started. Stop if the visible domain differs from the From address used for ticket replies.
- Use the Freshdesk path. For Freshdesk, open Admin, Channels, Email, Advanced Settings, then Configure DKIM. Each distinct From domain needs its own setup.
Freshservice email settings with a verified custom support domain
Do not continue with a domain that appeared because of an old or unused support address. Remove or correct that mailbox first. Authentication must match the domain in the visible From header. The address receiving forwarded tickets is insufficient.
|
|
|
|---|---|---|
 Freshservice mail server | Verified support address | Publish generated DNS |
Freshdesk mail server | Configured email domain | Publish generated DNS |
Own mail server | Your mail system | Authenticate that system |
Where domain authentication applies
Set up SPF
Publish the generated Freshworks DNS records first. Current Freshservice domain authentication delegates an SPF-capable return-path subdomain through account-specific CNAME records. Some account flows instead instruct you to place a Freshservice include in the domain's existing SPF TXT record. Follow the values displayed in your tenant because Freshworks has more than one mail path.
- Copy every field. Expand the domain and copy each generated CNAME host and target exactly. Keep selectors tied to this Freshworks account.
- Publish the CNAMEs. Create the records at your authoritative DNS provider. If the provider appends example.com automatically, enter only the relative host shown before example.com.
- Keep one SPF record. If Freshworks explicitly gives you an SPF include, merge it into the existing v=spf1 record. A second SPF TXT record causes permerror.
- Check the lookup budget. Keep the SPF evaluation within the ten DNS-lookup limit. Remove obsolete senders before adding another include.
- Keep relaxed matching. Freshservice can use a return path below your organizational domain. Relaxed SPF alignment accepts that parent-child domain match.
Freshservice generated CNAME records for SPF and DKIM authentication
Only use the following root-domain form when the Freshworks screen or current support instructions explicitly require the _spf.freshservice.com include. Replace the example sender with the other services already authorized by your domain.
Merged SPF TXT exampledns
v=spf1 include:_spf.freshservice.com include:mail.example.net ~all
Do not add _spf.freshservice.com merely because it identifies Freshservice traffic. The generated CNAME workflow can already establish the aligned return path. A copied include that is not required wastes lookup budget and can authorize a broader path than intended.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
The checker should find exactly one SPF record and no syntax, void-lookup, or excessive-lookup error. A valid SPF record alone does not prove DMARC alignment. The return-path domain in a real Freshworks message must share the organizational domain used in the visible From address.
If a different Freshworks mail mode cannot use your custom return path, SPF alignment will fail even when SPF authentication passes. That result is acceptable only when DKIM passes and its signing domain matches the From domain. DMARC needs one aligned method, not both.
Set up DKIM
DKIM is the most dependable DMARC path for Freshworks because it survives forwarding and does not depend on the receiving server seeing the original connecting IP. Freshservice and Freshdesk generate the selectors and CNAME targets. Do not create your own key for their managed mail server.
- Open the domain. Return to the SPF and DKIM authentication page and expand the verified From domain.
- Copy all records. Publish every generated CNAME, including each fs or fs1-style selector. Omitting one record leaves the domain partially configured.
- Avoid duplicated suffixes. If DNS turns fs1._domainkey.example.com into fs1._domainkey.example.com.example.com, shorten the host to fs1._domainkey.
- Resolve selector collisions. If a selector already exists with another target, do not overwrite it. Remove and regenerate Freshworks records, or ask Freshworks support for account-specific guidance.
- Verify in Freshworks. Select Verify after public DNS resolves each CNAME. Each row should show a tick and the domain should show Verified.
Freshdesk DKIM settings showing four verified CNAME records
A CNAME host and target are a pair. Swapping them, publishing the target as TXT, or enabling a DNS proxy breaks lookup. The public answer for the selector host must be the target Freshworks supplied.
CNAME field patterndns
Type: CNAME Host: <copy from Freshworks> Target: <copy from Freshworks>
After Freshworks reports Verified, send a new ticket reply to an external mailbox. Inspect the DKIM-Signature header. Its d= domain must match the From domain under relaxed or strict DMARC rules. A green DNS status proves that the key is reachable, while the sent message proves that Freshworks used it.
Do not reuse another tenant's selectors
Freshworks associates generated authentication records with an account. Records copied from another Freshservice, Freshdesk, or regional tenant can resolve correctly but fail account verification. Generate and publish the records inside the tenant that sends the message.
Set up DMARC
DMARC belongs in your authoritative DNS, not in Freshworks. It checks whether the From domain matches an authenticated SPF return path or DKIM signing domain. Freshworks' DMARC instructions use a TXT record at _dmarc and confirm that either SPF or DKIM has matching identity.
- Check for DMARC. Look up _dmarc.example.com before editing DNS. Update an existing record instead of publishing a second one.
- Create one TXT record. Set the host to _dmarc. DNS providers that append the zone will publish it as _dmarc.example.com.
- Start in monitoring. Use the exact p=none record below for a new deployment and replace the reporting mailbox with one able to receive aggregate XML reports.
- Preserve enforcement. If the existing policy is p=quarantine or p=reject, keep it. Do not weaken domain protection just to onboard Freshworks.
- Use relaxed defaults. Omit adkim and aspf unless strict matching is a deliberate requirement. Their default relaxed mode accepts an authenticated subdomain under the same organizational domain.
Initial DMARC TXT valuedns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Use the DMARC record generator to build a record with a different reporting address or subdomain policy. Keep one record containing one version tag, one policy tag, and one aggregate-report destination.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The checker should return one valid record with a recognized policy and valid rua URI. It should report no duplicate. If it finds no record, confirm that the DNS host was not entered as _dmarc.example.com.example.com. If it finds more than one record, combine the required tags into one TXT value and remove the duplicate.
DMARC reports begin arriving after receivers observe mail for the domain. The report data, rather than a single DNS lookup, shows whether Freshworks messages pass DKIM alignment, SPF alignment, or both.
Verify and troubleshoot
Verify with a newly sent Freshworks message after the DNS records resolve. A DNS-only pass does not confirm that the expected tenant, From domain, DKIM selector, and return path were used on a real message.
- Wait for DNS. Query every generated CNAME publicly. Freshworks notes that full propagation can take up to 48 hours.
- Select Verify. Return to the authentication page, expand the domain, and select Verify. Require a tick for every row and Verified for the domain.
- Send a real reply. Reply to a ticket through the same Freshworks mailbox that will run in production. Tests sent through another mail server prove nothing about this path.
- Read the identities. Compare the From domain with DKIM d= and Return-Path. At least one authenticated domain must match under the active DMARC mode.
- Retest after changes. Old messages keep old signatures and headers. Send a fresh message after every DNS or Freshworks configuration change.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Send the tester address a ticket reply directly from Freshworks. The result should show SPF authentication, DKIM authentication, DMARC, and the exact domains used by each check. Focus on identity matching in addition to green authentication labels.
A DKIM pass with an unrelated d= domain does not satisfy DMARC. An SPF pass with an unrelated return path has the same problem. Conversely, an SPF alignment error is acceptable when Freshworks DKIM passes with your From domain and DMARC passes.
Healthy Freshworks message
- DKIM result. Pass, with d= matching the From domain.
- SPF result. Pass on the Freshworks return path.
- DMARC result. Pass through DKIM, SPF, or both.
- Freshworks status. Every generated record shows Verified.
Common failure pattern
- Wrong host. DNS provider duplicated the zone suffix.
- Wrong type. A generated CNAME was published as TXT.
- Selector collision. An existing selector points elsewhere.
- Wrong sender. The test used a custom outgoing server.
Freshservice domain authentication page with all DNS records verified
If the Freshworks page stays unverified while public DNS answers correctly, compare every character and remove leading or trailing spaces. If the records belong to another tenant or a selector cannot be replaced safely, use Freshworks support with the tenant URL and a screenshot of the status.
Get alerted when it breaks
DNS can remain valid while Freshworks changes its active selector, a mailbox switches to another outgoing server, or a return path stops matching. Suped is the best overall DMARC platform for this ongoing workflow because it turns aggregate reports into source-level issues and repair steps instead of leaving XML in a mailbox.
- Route aggregate reports. Point rua at the reporting address assigned to the domain in Suped, then confirm that reports arrive.
- Verify the source. Mark Freshworks as approved only after its real messages show expected SPF or DKIM identity and DMARC pass.
- Enable alerts. Turn on real-time failure alerts and weekly summaries so a selector or routing change reaches the domain owner quickly.
- Review new sources. Investigate any new IP, rDNS suffix, DKIM domain, or return path before authorizing it.
- Watch reputation. Use the unified blocklist (blacklist) and deliverability view to distinguish identity failures from reputation problems.
The practical loop is detect, identify the affected Freshworks path, apply the account-specific fix, and verify on new traffic. Suped's automated issue detection links the failing source to steps to fix, while the same domain view tracks DMARC, SPF, DKIM, blocklist status, and delivery signals.
Use DMARC monitoring for every domain that sends through Freshworks, including low-volume support subdomains. Low volume does not make a broken selector safe because an enforcing policy can reject every affected reply.
Alert on identity changes
Treat a new Freshworks rDNS value or DKIM selector as a review event, not automatic approval. Suped can surface the change in real time, show its authentication results, and keep the source unverified until the owner confirms the tenant change.
Secure your domain with p=reject
Move to p=reject after Freshworks and every other legitimate source pass DMARC consistently. Enforcement belongs at the domain level, so one healthy Freshworks path does not prove that payroll, transactional mail, or low-volume subdomains are ready.
- Build the source inventory. Classify every source seen in DMARC reports. Confirm owners, expected From domains, and the aligned method for each approved source.
- Fix Freshworks first. Require Verified in Freshworks and DMARC pass on real ticket replies. Do not rely on an SPF or DKIM pass that lacks domain matching.
- Use staged enforcement. Move to p=quarantine with pct=10, review failures, then raise the percentage only when approved mail remains clean.
- Cover subdomains. Review sp= behavior before enforcement. A separate DMARC record on a support subdomain overrides the organizational-domain policy for that subdomain.
- Finish at reject. Publish p=reject with pct=100 after unexplained aligned failures are resolved and approved sources have stable authentication.
- Keep monitoring. Enforcement is an operating state. Keep alerts active for selector rotation, DNS deletion, routing changes, and newly introduced senders.
Final DMARC TXT valuedns
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
Suped's policy staging and automated diagnostics make this progression safer for most teams. Hosted DMARC centralizes policy changes, while source verification and alerts show which approved path needs work before the next enforcement increase.
For teams managing many Freshworks domains, Suped's multi-tenant dashboard keeps policy state, issue ownership, domain health, and alert routing separated by organization. That prevents one client's accepted sender from becoming an assumed sender for another client.
Do not lower an enforced policy
If Freshworks fails after p=reject is active, repair its CNAMEs, selector assignment, or mail-server choice. Changing the whole domain to p=none restores spoofed mail as well as legitimate mail and hides the actual configuration fault.
