Confirm the Freshservice mail-server route
Use this workflow for a business-owned domain whose mail is sent through the Freshservice mail server. The reviewed provider guide excludes public-domain addresses and custom mail servers. Before starting, record the mailbox, domain, sending transport, workspace, account and Freshworks organization. These distinctions matter when several accounts use the same domain.
Inventory the service-desk workflows whose notifications must work, including the customer-facing replies relevant to your configuration. Give each an owner and expected From and reply destination. A single administrator's test is not proof of every workspace or mailbox. Do not combine a transport migration, a domain policy tightening and this authentication change into one untraceable rollout.
Open the correct configuration page
For a single workspace, the documented path is Admin > Channels > Email > Email Settings and Mailboxes > Set up SPF and DKIM email authentication. With multiple workspaces, use Admin > Global Settings > Account Settings > Service Desk Security. A verified custom-domain email using the Freshservice mail server supplies the domain automatically; it is not added or edited on this page. Source: Freshservice, Step-by-step guide to add SPF and DKIM email authentication.
If the domain is missing, investigate the mailbox's verification and transport instead of entering speculative DNS records. Confirm the account and organization with the service-desk owner. A custom SMTP connection can look similar to an ordinary support address while using a different signing service. Resolve that boundary before changing any shared domain record.
Publish the generated records without breaking another account
Choose Get Started, copy the four generated CNAMEs and publish them at authoritative DNS. Return, expand the domain and use Verify; the panel shows per-record status. The provider also notifies account and super administrators on completion. Source: Freshservice's setup guide.
Before saving DNS, map every requested owner to its current record and dependent service. If there is a selector collision, do not overwrite a working account. The guide offers regeneration for different selector keys, while its fourth record remains unchanged. Multi-account instructions depend on whether both accounts belong to the same Freshworks organization. Use that exact documented branch after confirming organization membership, or ask support to resolve the intended record set. Do not improvise several targets at a single CNAME owner.
Regeneration is a change to a signing configuration, not a harmless refresh. Preserve the previous account's status and DNS and coordinate the transition. Determine whether a record being removed belongs to the newly attempted setup or an existing working one. If that is unclear, stop removal and obtain provider guidance; deleting shared records to clear a dialog can disrupt other service desks.
Compare authoritative DNS with the account
Check each final owner and alias target against the generated values. An editor that appends the domain may require only the relative host label. If an owner acquires the zone suffix twice, correct the record rather than waiting. Check authoritative answers first and recursive caching second; a stated propagation estimate is not a guarantee that an incorrect record will become valid.
Do not assume every CNAME has the same protocol role simply because the wizard groups SPF and DKIM together. Inspect the received-message identities to establish the effective authentication. Avoid adding an unrelated SPF include or replacing a root policy to fix a failed selector lookup. Any separate SPF update requires one reviewed policy, all legitimate senders and its DNS-lookup dependencies.
Verify real service-desk messages
Trigger controlled messages from each intended workspace and sending domain without using private ticket content. Retain the original received message and trusted receiver Authentication-Results. Record the exact account/workspace, From domain, envelope identity, DKIM d=/s= and the expected reply route. Verify the reply workflow independently; a signature says nothing about where a customer response is handled.
Synthetic example: a notification from help@example.com has a valid signature with d=example.com and a receiver-confirmed DKIM pass. That exact signing-domain match can provide the aligned DMARC path. A second workspace sending From help@different.example has not been authenticated by the first test, even if the same employee manages both. Domain ownership and account configuration do not transfer through organizational familiarity.
SPF authenticates the envelope identity; DKIM authenticates a signing domain; DMARC needs at least one passing aligned path to visible From under the applicable alignment mode. A provider-owned signature can be valid without aligning with your custom From. Conversely, authentication can pass while a message still lands in spam. Keep the protocol result and delivery outcome separate.
Preserve recovery and explicit completion gates
If product verification fails, retain the exact per-record failures and authoritative output. If the signature is absent after verification, inspect the actual transport and mailbox configuration. For a signature failure, investigate selector/key lookup and modifications after signing. For a passing aligned message with poor placement, investigate the delivery error and recipient handling rather than weakening policy.
Save prior records and mailbox settings and agree on a recovery route before production changes. Do not use Remove Records casually on a live shared-domain setup. Acceptance requires the correct product state, DNS answers and received-message evidence for every in-scope account and workflow. This article retains the original live-evidence requirement: no tenant, DNS or delivery tests were executed here. Independent review, human SME approval and publication remain pending.
Record what is unknown before reusing selectors
Written case FS-01 assumes account Helpdesk-A works for example.com, while Helpdesk-B proposes the same domain. Their Freshworks organization relationship is unknown, and the proposed record values have not been supplied. The administrator cannot choose the source’s same-organization or different-organization branch from domain spelling alone. Confirm membership and retrieve the exact generated owners before planning changes; preserve A’s live configuration while resolving any collision. The provider’s unchanged fourth record is a reason to inspect each record, not a guarantee that regeneration produces an entirely clean namespace. DNS, B’s product validation and received-message results are all unknown in this case. No regeneration, deletion or message occurred.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.