For Trakdesk's native helpdesk email service, open Admin → Email Settings → Configure DKIM, publish the account-issued ownership TXT record, then add the three CNAME records issued for your domain. Use Validate Records until every record is validated. Trakdesk documents this as the activation point for custom-domain signing on agent and automated helpdesk messages.
For this DKIM-enabled route, Trakdesk says its provider manages both DKIM and SPF. Do not add a separate root SPF include just because a different Trakdesk article shows arthur.trakdesk.com. That article expressly exempts domains configured through the DKIM workflow. See the official DKIM procedure and SPF route distinction.
Domain authentication, support-address verification and inbound forwarding are separate steps. This guide covers native Trakdesk sending, not Configure SMTP Server with your own mail server, and not the unrelated Trackdesk affiliate platform.
The retrieved Trakdesk articles display a blank “Last updated” field; their footer year is not an update date. No customer configuration, verification email, DNS change or message test was performed for this guide.
On this page
- Confirm the native route and permissions
- Verify the support address and plan inbound routing
- Prove domain ownership with the issued TXT
- Publish all three issued CNAMEs
- Validate records and understand SPF
- Preserve DMARC or add an approved first policy
- Test native replies and automations
- Troubleshooting and rollback
- Frequently asked questions
Confirm the native route and permissions
An administrator performs the documented setup. The DKIM and support-account articles list Starter, Professional, Business and Enterprise; confirm that your actual account exposes the feature rather than inferring a current commercial entitlement from that list.
Check whether the account uses native Trakdesk delivery or an enabled external SMTP configuration. The custom SMTP article describes a different workflow in which helpdesk messages flow through your own server. Authenticate that actual server or relay if it is your chosen route. Do not silently disable it to make a native-domain guide apply.
For native setup, obtain permission to edit the authoritative DNS zone for the intended support From domain. The DNS host may not be your registrar. Record the current support address, sending route, group/brand assignments, SPF and DMARC policies, and existing DKIM or NS delegations. Save their current values before any authorized change.
Choose an appropriate unused branded subdomain when the DKIM wizard requests one. A name already used for a website, mailbox route or another sender is not safe to repurpose. The new CNAMEs do not justify moving the domain's nameservers or replacing its receiving MX records.
Verify the support address and plan inbound routing
The support-account instructions distinguish a Trakdesk elastic address, such as an account-issued address under yourcompany.trakdesk.com, from an existing company address such as support@example.com.
If the support account is already correctly configured and verified, retain it. For a new account:
- As an administrator, open Admin → Email Settings.
- Use the upper-right dropdown and choose Add Email Account.
- Enter the account name and actual support email address, choose the elastic-email alias, and assign the correct group and, where applicable, brand.
- Review the Email Forwarding choice against the approved inbound routing plan. Using the company address this way requires forwarding on its existing mail server to the correct account-issued elastic address.
- Select Submit only when ready to send a verification email to that support address.
- An authorized recipient opens that message and follows its verification link. Trakdesk says the account must be verified before it can send or receive.
Do not confuse this email-address link with DKIM's DNS validation. Completing one does not complete the other.
Forwarding also has consequences beyond authentication: it transfers incoming messages and attachments into the selected helpdesk account and can create tickets and automatic notifications. Confirm the exact source mailbox, destination elastic address, group/brand and data-sharing authorization before enabling it. Do not forward all company mail or replace MX merely to connect one support address.
Trakdesk distinguishes server-side forwarding, which preserves the original requester's headers, from manually forwarding in a mail client, which can make you the requester. Its optional Original requester setting parses the message body for the original sender. That is a ticket-processing feature, not SPF or DKIM authentication, and should not be enabled indiscriminately as an email-security fix.
Prove domain ownership with the issued TXT
Open Admin → Email Settings, select Configure DKIM from the upper-right dropdown, and choose Add. Enter the preferred subdomain and domain.
Before submitting that form, publish the ownership TXT displayed by your account. The official wizard screenshot shows a generated host beginning trakdesk- and a value beginning trakdesk-dns-verification=. Both contain account-specific tokens.
Type: TXT
Owner: <EXACT-OWNERSHIP-HOST-ISSUED-BY-TRAKDESK>
Value: trakdesk-dns-verification=<EXACT-ISSUED-TOKEN>
This describes the record's shape, not a usable record. Copy the full host and value from the active wizard, including the complete token. Do not reuse the token shown in a documentation screenshot or invent a replacement.
Check the DNS panel's suffix behavior. If it expects a relative name, enter the part relative to the selected authoritative zone; if it expects a full name, use the exact full owner. Confirm that the saved record has not acquired the domain suffix twice. A separately delegated child zone or _domainkey namespace has its own authority, which must be respected.
Once the TXT is published and available to Trakdesk, use Submit to finish adding the domain configuration. The ownership TXT is not a DKIM public key, an SPF policy or a replacement for the CNAMEs issued next.
Publish all three issued CNAMEs
For the newly added domain, open its menu and DNS Records. The official screenshot shows three rows: one branded-subdomain CNAME and two _domainkey CNAMEs. They are not three separate TXT public keys.
Copy each complete current row from your account:
Type: CNAME
Owner: <ISSUED-BRANDED-SUBDOMAIN-OWNER>
Target: <ISSUED-BRANDED-SUBDOMAIN-TARGET>
Type: CNAME
Owner: <FIRST-ISSUED-DKIM-OWNER>
Target: <FIRST-ISSUED-DKIM-TARGET>
Type: CNAME
Owner: <SECOND-ISSUED-DKIM-OWNER>
Target: <SECOND-ISSUED-DKIM-TARGET>
The documentation uses email, s1, s2, a sample domain and tenant-specific SendGrid targets. Those are evidence of the workflow, not universal values to copy. Use all three actual issued records and preserve their types. Do not build a separate SendGrid account configuration or generate your own DKIM key to replace Trakdesk's packet.
Check owners and existing dependencies
For an illustrative issued owner s1._domainkey.example.com, a panel managing example.com often expects s1._domainkey. For s1._domainkey.support.example.com managed in the parent zone, it often expects s1._domainkey.support; in a separately delegated support.example.com zone, it often expects s1._domainkey. Apply the same logic to the actual issued names, not a guessed selector.
A CNAME must not coexist at the same owner with TXT, A, AAAA, MX or a different CNAME. See RFC 1034, section 3.6.2. If an issued s1 or s2 name is already used by another SendGrid-backed application, do not replace that application's target. Resolve the collision with the domain and service administrators before proceeding; do not assume Trakdesk offers an undocumented selector-rename control.
Keep the required aliases visible
Use DNS-only, not HTTP proxying, for these authentication CNAMEs. An orange-cloud web proxy is not part of the mail-authentication route. Cloudflare's proxy documentation distinguishes such non-web records from proxied web traffic.
The required result is a publicly visible CNAME answer at each issued owner, not just an A/AAAA answer synthesized from its target. Turn per-record Flatten OFF where that control is available, and ensure applicable whole-zone “flatten all CNAMEs” settings do not flatten these issued aliases; DNS-only is not necessarily enough. Coordinate any shared-setting change with the DNS owner so other records keep working. Preserve existing DNS delegations rather than replacing or deleting them. Apex CNAMEs can be flattened automatically, and Cloudflare documents same-zone targets being flattened regardless of the ordinary setting. Do not move issued records to the apex or invent replacement targets. If unavoidable flattening still conceals an alias, have the DNS administrator and Trakdesk resolve a supported configuration before validation. See Cloudflare's flattening rules.
After publication, compare the authoritative and public CNAME answers with the exact issued targets. Allow for TTLs and cached negative answers before repeating platform validation.
Validate records and understand SPF
Return to the domain's dropdown and select Validate Records. Each row must change to validated. The official DKIM article says that, from this point, native helpdesk emails are signed using the custom domain. If propagation is incomplete, correct any actual mismatch and repeat validation after the relevant cache interval; do not repeatedly delete and recreate correct records.
Why the separate arthur include is not a required step
The SPF article presents include:arthur.trakdesk.com for its separate SPF setup, but explicitly says DKIM-configured domains do not need that additional DNS-manager SPF record because the email provider manages both mechanisms. The DKIM article's appended SPF link does not override that exception.
Do not add a root include, a second SPF policy or TXT at a CNAME owner merely to satisfy a generic checklist. Preserve the company's existing SPF for other senders. If a different, approved route actually requires an SPF change, keep one v=spf1 policy per evaluated owner, preserve legitimate authorizations and qualifiers, and respect the 10 evaluated DNS-dependent term limit, including nested includes and redirects. Any all mechanism makes redirect= ignored. RFC 7208 defines these rules.
SPF checks the actual SMTP MAIL FROM, not automatically the visible support From. A branded CNAME and green dashboard do not establish one universal Return-Path for every Trakdesk message or guarantee strict alignment. Inspect the actual message before diagnosing which SPF policy was evaluated.
Preserve DMARC or add an approved first policy
Keep the effective direct or inherited DMARC policy, alignment settings and authorized report destinations. Do not weaken enforcement to hide an unvalidated route, add duplicate DMARC records or overwrite an existing policy with a tutorial default. Policy discovery is defined in RFC 9989, section 4.10.1.
Only if no direct or applicable inherited policy exists, legitimate senders have been inventoried, and the owner approves an initial monitoring policy, this is a first-record baseline for the example From domain example.com:
Type: TXT
Full owner: _dmarc.example.com
Value: v=DMARC1; p=none
The relative owner is commonly _dmarc in the example.com zone. For a From domain support.example.com managed in that parent zone, the full owner is _dmarc.support.example.com and the relative input is commonly _dmarc.support. In a separately delegated support.example.com zone, use _dmarc there. Verify the resulting full name. An empty direct lookup alone does not rule out inherited policy, and a child record must not bypass existing protection.
That baseline requests no reports by itself. Add rua only for an actual owner-approved destination, with receipt and authorization arranged. If its Organizational Domain differs from the Organizational Domain of the domain where the policy was discovered, the report-generating receiver must check external-reporting DNS authorization. A destination within the same Organizational Domain is excepted; merely using a different hostname is not enough. RFC 9990, section 4 defines the rule. The owner's separate data-sharing decision still applies.
Test native replies and automations
Use controlled recipients and an authorized test ticket. Test both an agent reply and the automated notifications you actually use, through native Trakdesk with the intended verified support address. Do not treat an employee-mailbox message or a forwarded screenshot as evidence for this route.
Before interpreting results, have the receiving service's administrator identify the actual receiving processing boundary and its documented handling of externally supplied Authentication-Results. Use results produced inside that known boundary or the receiving service's verified message trace. Ignore attacker-supplied or untrusted result fields. A familiar authserv-id or header position alone does not prove origin. See RFC 8601, section 7.1.
For each original received message, require:
- The intended custom support From, not a provider rewrite.
- A passing intended Trakdesk DKIM signature whose
d=aligns with that From under the effective policy. - A trusted receiver
dmarc=passresult. - A recorded actual MAIL FROM and independently understood SPF result.
DMARC can pass through either aligned SPF or aligned DKIM, but a pass through SPF alone does not prove this DKIM setup works. Relaxed alignment requires the same Organizational Domain; strict alignment requires identical domains. A child envelope domain can relaxed-align to a parent From without satisfying strict SPF alignment. RFC 9989, section 4.4 defines the comparison.
Use the s= and d= from the same signature to construct its DNS lookup. EmailAuth's DKIM selector guide explains this process. Domain validation is configuration evidence; delivered authentication is a separate acceptance gate.
Troubleshooting and rollback
The ownership form will not accept the domain
Check the current account-issued token, its exact owner, authoritative DNS and duplicated suffixes. The ownership TXT must be available before completing domain setup. Do not substitute a sample token or publish the value at the DKIM selector name.
One CNAME remains unvalidated
Compare the full owner, type and target with the current packet. Check proxying, applicable flattening, old conflicting records and cached answers. Investigate existing selector use rather than deleting another sender's CNAME. Validate again after the corrected answer is publicly visible.
DKIM is validated but the support account cannot send or receive
Check the separate address-verification link and account state. For a custom inbound address, check the approved server-side forwarding destination and group/brand mapping. Authentication does not configure receiving-mail routing.
DKIM passes but DMARC fails
Compare the passing signing domain with the actual visible From and strict/relaxed settings. Confirm the message used the intended native route and account. A provider-owned passing signature or a different brand's configured domain is not sufficient.
SPF has an error despite aligned DKIM
Identify the evaluated MAIL FROM first. Fail can indicate a wrong source or route; temperror indicates temporary lookup trouble; permerror can reflect duplicate policies, invalid syntax or excessive DNS-dependent evaluation. Investigate these even if DKIM produces DMARC pass. Do not “fix” a provider-managed envelope by blindly adding arthur.trakdesk.com to the company's root policy.
The change must be rolled back
Pause the affected new sending route and preserve its evidence. Have the account and mail administrators restore the previously approved route or support-address configuration if needed. Restore only DNS values changed in this rollout, after checking that no other sender depends on them. Do not delete a shared selector, ownership proof or forwarding rule simply because a test failed, and do not weaken DMARC as a rollback shortcut. Re-test both inbound ticket handling and outbound identity after an authorized restoration.