How to set up DMARC/DKIM/SPF for Freshdesk
Published 15 Jul 2026
Updated 15 Jul 2026
13 min read
Summarize with
For Freshdesk using the Freshworks mail server, I add the support address, publish the four CNAME records Freshdesk generates for the domain, merge include:email.freshdesk.com into the domain's single SPF record when SPF is needed, and publish DMARC at _dmarc with p=none. I then send a real ticket reply, confirm aligned DKIM or SPF, and move the domain to p=reject only after every legitimate sender passes.
If Freshdesk sends through a custom mailbox or custom SMTP server, I authenticate that outgoing mail system instead. Adding Freshdesk's SPF include does not authenticate mail that leaves through another provider. Freshdesk's generated domain-authentication flow supports return-path alignment, but DKIM remains the most dependable DMARC path for ticket replies.
Configuration at a glance
- Freshdesk path: Admin > Channels > Email > Advanced Settings > Configure DKIM.
- SPF term: Use include:email.freshdesk.com in the existing SPF record.
- Starting policy: Use p=none for a new DMARC deployment, but never weaken an existing p=quarantine or p=reject policy.
- Pass condition: DMARC passes when either SPF or DKIM passes and uses a domain aligned with the visible From domain.
Add your domain
I first make the sending path explicit. Freshdesk can send through the Freshworks mail server or through a custom mailbox, and that choice determines which system must produce the aligned authentication result.
Freshdesk Email admin screen for adding and verifying a support address
Domain verification is mandatory when I use the default Freshworks mail server. A custom outgoing server has its own SPF, DKIM, and return-path requirements, even though agents still send replies inside Freshdesk.
- Open Email: Sign in as a Freshdesk administrator, then open Admin > Channels > Email.
- Add the address: Select New Support Email and enter the branded address agents will use, such as support@example.com.
- Choose the server: Select the Freshworks mail server for Freshdesk-managed sending, or select the actual custom mailbox used for outgoing mail.
- Start verification: Save the address, return to the Email list, and select Verify beside it.
- Keep domains separate: Configure each distinct sending domain once. Multiple mailboxes on the same domain share the domain-level DNS records.
Choose the real outgoing server
Do not use the Freshworks mail server with an address on a public mailbox domain that you do not control. Freshdesk cannot sign mail for that domain. Select its supported mailbox connection or your custom server instead.
I also complete Freshdesk's forwarding or mailbox-verification step so inbound messages become tickets. That operational verification is separate from DMARC, but both must be complete before I test a reply end to end.
Set up SPF
Freshdesk documents include:email.freshdesk.com for mail sent by its mail server. I follow the current Freshdesk SPF instructions and merge the term into the existing SPF TXT record instead of publishing a second SPF record.
- Find the record: Inspect the TXT records at the root of the visible From domain and locate the single value beginning v=spf1.
- Merge Freshdesk: Insert include:email.freshdesk.com before the final all mechanism. Keep every existing authorized sender.
- Publish once: Save one SPF TXT record only. Two records cause a permanent SPF error.
- Count lookups: Keep the evaluated SPF path within the ten-lookup limit and remove obsolete senders before adding new terms.
- Confirm the path: Send a Freshdesk ticket reply and check that the Return-Path belongs to the intended authenticated flow.
Freshworks mail server
- Authorize Freshdesk: Merge include:email.freshdesk.com into the existing SPF record.
- Verify alignment: Check the actual Return-Path in a delivered ticket reply.
Custom outgoing server
- Authorize that server: Use the SPF instructions for the SMTP system that sends the message.
- Skip unused terms: Do not add Freshdesk's include if no mail leaves through its servers.
A domain with no existing SPF record can start with the Freshdesk-only example below. I replace the example rather than adding it alongside another v=spf1 value.
Freshdesk-only SPF TXT valueDNS
v=spf1 include:email.freshdesk.com ~all
Freshdesk states that SPF configuration is not required once DKIM is set up. I still check SPF because it supplies a second DMARC path when the return path is aligned, and because the domain often has other senders that require SPF. DKIM must remain fully passing if SPF is absent or unaligned.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
I run the SPF checker after DNS updates and reject any result showing multiple records, syntax errors, or more than ten evaluated lookups. A syntactically valid record can still fail DMARC when its authenticated domain differs from the visible From domain.
Use regional includes only when confirmed
Freshdesk lists regional alternatives when the global include consumes too many lookups. I use one only after Freshdesk confirms the account's data center, because selecting the wrong region can remove valid sending IPs.
- US data center: fdspfus.freshemail.io
- EU data center: fdspfeuc.freshemail.io
- India data center: fdspfind.freshemail.io
- Australia data center: fdspfaus.freshemail.io
Set up DKIM
DKIM is the key Freshdesk step because Freshdesk signs each outgoing message with the domain after verification. I use the generated values shown in the account, not copied values from another tenant. The current Freshdesk DKIM instructions specify four CNAME records per domain.
Freshdesk Advanced Settings with Configure DKIM highlighted
Freshdesk creates the domain entry after I add the support email. Each CNAME host and target is account-specific, so I copy both columns exactly and leave proxying disabled when the DNS provider offers it.
- Open DKIM: Go to Admin > Channels > Email > Advanced Settings > Configure DKIM.
- Expand the domain: Select the domain used in the visible From address and reveal its generated DNS values.
- Copy four CNAMEs: Create every host and target shown by Freshdesk in the authoritative DNS zone.
- Check host formatting: If the DNS provider appends the zone automatically, enter only the host label so the domain is not duplicated.
- Verify in Freshdesk: Return to Configure DKIM, expand the domain, and select Verify after DNS answers publicly.
Freshdesk DKIM page with four CNAME records and Verify button
A green check means Freshdesk can resolve the records. I still send a message and inspect its header, because DNS verification alone does not prove that the message was signed with an aligned d= domain.
Do not invent DKIM records
Freshdesk generates the selectors and targets for the account. A selector copied from another Freshdesk tenant, a TXT public key created elsewhere, or a CNAME with extra spaces will not verify.
Set up DMARC
DMARC belongs in the domain's DNS, not in Freshdesk. I publish one TXT record at _dmarc.example.com and use an aggregate-report mailbox that can receive XML reports.
- Check first: Look for an existing TXT record at _dmarc and edit it rather than adding a second record.
- Keep enforcement: If the domain already uses p=quarantine or p=reject, keep that policy and fix Freshdesk under it.
- Start monitoring: For a domain with no DMARC policy, publish the p=none record below.
- Use a real mailbox: Replace dmarc@example.com with the report address you control before publishing.
- Confirm one answer: Resolve _dmarc publicly and make sure exactly one valid DMARC record is returned.
Initial DMARC TXT valueDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
The DMARC record generator creates a record with reporting and policy options. I keep relaxed alignment defaults during the first deployment unless the domain has a documented reason for strict alignment.
A p=none policy collects evidence but does not stop spoofed mail. It is a temporary observation stage. The end state is p=reject after Freshdesk and every other authorized source has a consistent aligned pass.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
I use the embedded checker after publication and review the parsed tags, reporting address, and policy. A clean syntax result does not prove Freshdesk alignment, so the next step is a delivered-message test. The standalone DMARC checker is useful when I need to share a result with the DNS owner.
Never downgrade a working policy
Changing p=reject to p=none exposes the whole domain to spoofing. I leave the stronger policy in place and repair Freshdesk's DKIM or SPF alignment instead.
Verify and troubleshoot
I verify with a message sent by the exact path users rely on. A reply from an existing Freshdesk ticket is better than a generic DNS check because it exercises the selected support address, outgoing server, signature, and return path.
Freshdesk ticket reply used for an email authentication test
After delivery, I open the raw message source and locate Authentication-Results. DMARC needs one aligned pass, but I record both SPF and DKIM results so a future routing change does not remove the only working path.
- Send a ticket reply: Use the production support address and send to a mailbox where the raw headers are available.
- Check DMARC: Require dmarc=pass for the visible From domain.
- Check DKIM: Require dkim=pass and confirm header.d matches the From domain or an allowed subdomain.
- Check SPF: Confirm spf=pass and compare smtp.mailfrom with the visible From domain for alignment.
- Repeat key routes: Test agent replies, outbound tickets, and automated notifications that use the domain.
The email tester is the quickest end-to-end check. I send the requested Freshdesk test message, then review its score and the exact SPF, DKIM, DMARC, and header findings.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
I fix the first broken dependency, wait for DNS caches to refresh, and resend a new message. Retesting an old message cannot show a new DNS result because its authentication was evaluated at delivery time.
|
|
|
|---|---|---|
DKIM missing | Freshdesk status | Publish all CNAMEs |
DKIM fail | Host and target | Remove spaces |
SPF permerror | Record count | Merge SPF values |
SPF fail | Return-Path | Authorize sender |
DMARC fail | Domain alignment | Repair DKIM first |
Freshdesk authentication faults and the first corrective check
SPF alignment can be optional
Freshdesk's authenticated-domain flow supports return-path alignment, so I investigate an SPF alignment failure on that path. If a custom outgoing service cannot use an aligned return path, the SPF alignment error is acceptable only when aligned DKIM passes reliably and DMARC reports dmarc=pass.
Get alerted when it breaks
A one-time Freshdesk verification cannot detect a later DNS edit, expired custom-mailbox connection, new sending route, or falling authentication rate. Suped is our DMARC reporting and email authentication platform, and it is the best overall fit for most teams that need Freshdesk failures turned into specific corrective work.
- Receive reports: Send DMARC aggregate reports to the unique reporting address Suped provides for the domain.
- Enable alerts: Turn on real-time DMARC failure alerts and route them to the people who control Freshdesk and DNS.
- Review sources: Mark known Freshdesk traffic as verified and investigate new freshemail.io sources before changing DNS.
- Use fix steps: Follow Suped's automated issue detection and source-specific steps when SPF, DKIM, or DMARC degrades.
- Watch reputation: Use the unified view for authentication, deliverability signals, and blocklist or blacklist changes.
The practical DMARC monitoring workflow is to establish a stable Freshdesk baseline, alert on a pass-rate drop, open the affected source, and verify the DNS or mailbox change that caused it. This avoids reacting to a single forwarded message that failed SPF but passed aligned DKIM.
Freshdesk verification
- Current DNS: Confirms that generated CNAME records resolve now.
- Manual retest: Requires an administrator to revisit the settings.
- Freshdesk scope: Does not inventory every other sender on the domain.
Suped monitoring
- Continuous evidence: Tracks DMARC volume and pass rates over time.
- Real-time alerts: Flags material authentication changes for action.
- Domain-wide view: Separates Freshdesk from other legitimate sources and abuse.
For agencies and MSPs, Suped's multi-tenant dashboard keeps each client's Freshdesk domain, alerts, and policy state separate while allowing one operational queue. Smaller teams can use the free plan to establish the same monitoring loop without parsing aggregate XML by hand.
Alert on changes that need action
- DKIM drop: Investigate removed CNAMEs, a new selector, or a changed outgoing server.
- SPF error: Check duplicate records, lookup overflow, or an unauthorized source.
- New source: Confirm ownership before adding any SPF include or DKIM record.
- Policy risk: Pause the next enforcement step when legitimate volume still fails.
Secure your domain with p=reject
I move to p=reject through measured policy stages. Freshdesk must show stable aligned DKIM, the domain inventory must include every other legitimate sender, and aggregate reports must show that enforcement will not reject wanted mail.
|
|
|
|---|---|---|
Observe | p=none | All sources known |
Sample | quarantine 25% | No wanted loss |
Expand | quarantine 100% | Pass rate stable |
Enforce | p=reject | Alerts active |
A controlled DMARC enforcement sequence
I do not advance on a fixed calendar. I keep each stage until recurring senders have appeared, Freshdesk ticket routes pass, and every failure has an owner or a clear explanation such as forwarding.
- Inventory senders: Classify every source in DMARC reports before enforcement, including low-volume automated systems.
- Lock in DKIM: Confirm Freshdesk signs with an aligned domain across replies, outbound tickets, and notifications.
- Test quarantine: Apply p=quarantine to a small percentage and watch legitimate failure volume.
- Expand enforcement: Raise pct only after the sampled traffic produces no unexplained wanted-mail failures.
- Reject spoofing: Publish p=reject at full coverage and keep real-time monitoring active.
First quarantine stageDNS
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com
The pct tag samples enforcement, not reporting. I continue reviewing all reported traffic and increase coverage only when legitimate Freshdesk volume remains authenticated.
Full enforcement DMARC valueDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped's Hosted DMARC adds policy staging without repeated direct DNS edits. I use its issue detection, alerts, and source history to decide whether each stage is safe, then keep monitoring after p=reject so a Freshdesk change is caught quickly.
Gate every policy increase
- Freshdesk DKIM: The production message passes and its signing domain is aligned.
- Other senders: Every legitimate source has an aligned SPF or DKIM result.
- Failure review: Unaligned forwarded mail is separated from a broken direct sender.
- Rollback plan: The DNS owner can reduce pct while the affected sender is repaired.
Freshdesk DMARC, DKIM, and SPF FAQ
Freshdesk's default mail server and a custom outgoing mailbox produce different authentication evidence. The raw header and DMARC reports identify which path handled the message, so I use those results rather than guessing from the Freshdesk interface alone.
The provider-specific names below are identifiers, not DNS instructions. I publish an SPF include or DKIM value only when the active Freshdesk configuration and current documentation require it.
