Identify the transport before choosing the setup
Freshdesk's domain-verification procedure applies to its default sending server. A custom email server is a different transport whose DKIM setup must be handled at that service. Start by recording each support address, its actual server choice, visible From, reply destination and responsible support-team owner. Do not infer transport from the address alone.
Separate inbound support forwarding from outbound authentication. A message reaching the helpdesk and becoming a ticket does not prove that the helpdesk's reply has a valid aligned signature. Conversely, correct outbound DKIM cannot fix an inbox-forwarding or ticket-threading issue. Plan one test for each direction, using controlled mailboxes and fictitious ticket content.
Obtain and publish the generated record set
An administrator opens Admin > Channels > Email > Advanced Settings > Configure DKIM. Copy the four generated CNAME records into the authoritative DNS service, then return, expand the domain and select Verify. Setup is per domain, not per mailbox on that same domain. Check the status indicators and the account-admin confirmation. Source: Freshdesk, Configuring DKIM records.
The account values, not a sample from a blog, determine the owner names and targets. Before adding them, inspect any existing record at each owner. If another application occupies a selector, do not delete it or attempt to combine multiple CNAME targets. Freshdesk's guide directs record-conflict cases to support. Give support the exact account, owner names and conflicting values so the issue can be resolved without guessing.
Some DNS editors append the zone name automatically. A host such as selector._domainkey.example.com can become selector._domainkey.example.com.example.com if entered in the wrong field form. Review the resulting fully qualified owner after saving; a visually plausible short label is not enough. A generic request to wait for propagation should follow, not precede, this check.
Keep shared-domain changes narrowly scoped
A single business domain may serve several Freshdesk accounts, other Freshworks products and unrelated mail systems. Maintain a record-to-owner map. Identical required records do not need duplicate publication, but different targets at the same CNAME owner are a conflict. Do not interpret a documentation shortcut about overlapping values as permission to build a multi-target CNAME record.
Do not change the domain's SPF policy merely because this wizard is labelled DKIM. SPF and DKIM are separate authentication mechanisms, even when a vendor's record set supports several aspects of delivery. Use the actual configured transport and current account instructions to decide whether a separate SPF update is necessary. If updating SPF, keep one policy and preserve all other authorized senders within its DNS-lookup limits.
Test the complete support conversation
Start a controlled ticket through the intended inbound path, then send a reply from the support address under test. Retain the original message at the receiving mailbox. Record the support address and account, visible From, envelope domain, DKIM d=/s= and trusted receiver Authentication-Results. Test a second support address on a different domain separately. Addresses sharing a configured domain can share DNS setup while still having different operational settings.
Synthetic example: support@example.com replies with a valid signature d=example.com and SPF pass for an unrelated provider envelope. Exact-match DKIM can supply the aligned DMARC path; the unrelated SPF result does not. If a second support mailbox uses a custom server and lacks that signature, do not assume the Freshdesk-default-server configuration applies to it. Identify the real transport and fix authentication there.
DKIM verifies a signature associated with a domain. DMARC requires a passing aligned SPF or DKIM identity relative to visible From under the applicable mode. Neither mechanism guarantees inbox placement or makes impersonation universally impossible. Verify ticket threading and reply delivery independently from authentication.
Diagnose validation and delivery in sequence
If the domain is absent from the configuration page, check the support-email setup and verification status before inventing records. If validation fails, compare each generated value with authoritative DNS, checking omissions, spaces and duplicated suffixes. If records appear correct but product verification still fails, retain the account context, record output and exact error for support.
If DNS and product verification pass but the recipient reports missing mail, preserve the actual sending error and headers from any received sample. A missing signature points to a route or configuration mismatch; an invalid signature needs key and message-integrity investigation; an aligned pass with poor placement calls for a delivery investigation. Do not rotate unrelated keys or lower domain-wide DMARC policy as a first response.
Accept only demonstrated coverage
Keep previous records and support settings and an approved alternative route before changing customer-facing mail. Remove old records only after dependency review. The completion record must identify every tested support domain and transport, DNS and product validation, receiver authentication and reply/threading outcome. This is a documentary guide with a synthetic example, not a live Freshdesk test. Independent checking, human SME approval and publication are still required.
Keep authentication and ticket closure separate
Written support case FD-01 assumes help@example.com uses the default Freshdesk server and a controlled reply has trusted DKIM pass with d=example.com, s=demo1. That exact aligned path can satisfy DMARC, with SPF otherwise unknown. Now separately assume the reply-to address routes the next response into the wrong queue. Authentication acceptance does not close that workflow defect. The support owner should correct the approved reply route and repeat the harmless conversation test; replacing DKIM or lowering DMARC would not address the stated problem. A second mailbox using custom SMTP remains outside this default-server result. These are stipulated teaching inputs, not an executed ticket or observed customer incident.
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.