Reachdesk SPF, DKIM and DMARC setup, step by step

To send Reachdesk gift correspondence from your company domain, open Organization → Settings → Domain → Add New, add the domain, and publish the exact records in its Domain Sync Process table. The DKIM portion can be one TXT record or two CNAME records. Add the issued Return-Path CNAME and ownership-verification TXT as applicable, verify the domain, then separately tick its Active checkbox.

Finally, check each user's Sending From address. Verification alone does not activate the domain, and activating a parent domain can change which From address Reachdesk selects instead of an authenticated subdomain.

Reachdesk's domain-verification guide and subdomain guide were both updated 28 August 2026. This guide covers native Reachdesk gift-outreach email, not unrelated marketing platforms or an external SMTP service.

On this page

• Choose the intended sender
• Get the account records
• Publish safely
• SPF and Return-Path
• Preserve DMARC
• Verify and activate
• Test the real identity
• Troubleshooting and rollback
• Frequently asked questions

Choose the domain and intended sender first

You need access to the organization's domain settings and authorization to publish DNS for the company domain or subdomain. The public instructions do not establish a narrower plan or named-role requirement. Confirm the controls in your account rather than assuming a particular entitlement.

Before changing settings, record which users should send from which domain, their current Sign Up Email, and the intended reply destination. Keep the existing active-domain list and DNS records for rollback. Domain and subdomain identities are unique per Reachdesk instance; do not work around an ownership conflict by publishing another instance's values.

Reachdesk's subdomain instructions describe these selection rules:

• Only the company subdomain is active: a user registered on the main domain can send with the corresponding subdomain address. Replies go to the user's sign-up address.
• The main domain and its subdomain are both active: Reachdesk prioritizes the user's sign-up domain, so Sending From matches Sign Up Email.
• Multiple subdomains are active: Reachdesk selects the shorter subdomain, such as sales.example.com rather than marketing.example.com. The public guide does not define equal-length tie handling; inspect the actual user assignment instead of guessing.
• No custom domain is active: correspondence falls back to gifts@reachdesk-mail.com.

You do not have to verify the main domain before using an authorized subdomain. Do not activate the parent simply to make the child work: that can select the parent identity instead. Reply routing to the sign-up inbox is distinct from the visible From and the SMTP Return-Path.

1. Add the domain and copy the correct record variant

Follow the official verification procedure:

1. Open Organization → Settings → Domain. The screenshot labels the tab Domains.
2. Click Add New.
3. Enter the authorized domain or subdomain, without www. or an @ prefix, and choose Add Domain.
4. Copy the complete account-generated table: full hostname, type and full value for every row.

The table, not a screenshot or a generic email tutorial, determines which DKIM branch applies:

• TXT branch: publish the one issued DKIM TXT record containing the public-key data.
• CNAME branch: publish both issued DKIM CNAME records. Do not replace them with a TXT key or omit the second alias.
• Both branches: also publish the issued Return-Path CNAME and the Verification Code TXT when the table supplies it.

For a new setup with the ownership code, that means three records with TXT DKIM, or four records with two-CNAME DKIM. The article's phrase “third record” does not turn both variants into a universal three-record recipe.

Reachdesk says some domains safely verified before the ownership-code update do not display that code and need no additional action for it. Do not invent a token for such a domain. If a new or unverified account's instructions are unclear, resolve that with Reachdesk rather than borrowing another tenant's code.

An inventory can look like this, using placeholders only:

DKIM: exact issued TXT owner and full value OR both issued CNAME owner/target pairs
Return-Path: exact issued CNAME owner and target
Ownership: exact issued TXT owner and verification value, when provided

The documentation screenshot's timestamp-shaped selector, tenant domain, key, Return-Path target and ownership token are illustrative. None is a universal value to copy.

2. Map every record to its full DNS owner

Publish at the authoritative DNS service for the actual owner, which may differ from the registrar. Preserve any separately delegated sending domain or _domainkey namespace.

For example, suppose the intended sending domain is the illustrative sales.example.com:

• An issued DKIM owner SELECTOR._domainkey.sales.example.com becomes SELECTOR._domainkey.sales in the parent example.com zone, or SELECTOR._domainkey in a separately authoritative sales.example.com zone.
• An ownership TXT issued at sales.example.com becomes sales in the parent zone, or @/blank only if that editor uses it for the apex of the actual sales.example.com zone.
• An issued Return-Path owner RETURN_LABEL.sales.example.com becomes RETURN_LABEL.sales in the parent zone, or RETURN_LABEL in the child zone.

Use full names where your editor requires them. Confirm the published result does not contain an auto-appended duplicate suffix. In a delegated _domainkey.sales.example.com zone, the DKIM owner's relative name would instead be the issued selector. Do not remove an NS delegation to insert a record at the wrong authority.

Reachdesk's instruction to leave the ownership-record name blank means the relevant domain owner, not always the company's top-level DNS zone apex. Match the table's full hostname before using @.

TXT and CNAME need different handling

For TXT DKIM, preserve the complete issued tagged value, including the full p= key. If the DNS editor divides a long value into quoted character strings, they must remain parts of one TXT record and concatenate without added spaces. Do not create competing DKIM key records at the same selector or paste a private key. See RFC 6376 section 3.6.

At each CNAME owner, do not add TXT, A, AAAA, MX or another conflicting CNAME. Ownership TXT may coexist with other unrelated TXT data at its own owner, but not with a CNAME at that same owner. Keep existing working selectors and resolve collisions with Reachdesk and the DNS administrator. RFC 1034 section 3.6.2 explains the alias restriction.

For Cloudflare, use DNS only for the issued aliases and turn Flatten off for each issued alias where a per-record setting exists. Check applicable whole-zone flattening, apex handling and same-zone-target behavior too, ensuring none hides a required CNAME answer. Proxy off alone is not enough. Coordinate any shared-setting solution with the DNS administrator and Reachdesk, preserving delegations and unrelated records rather than disabling global features blindly. See proxy status and flattening controls.

3. Understand the Return-Path without inventing root SPF

Reachdesk explicitly issues a Return-Path CNAME. Publish that exact alias. Do not infer a universal SPF include from the screenshot's infrastructure target or add a root SPF record merely because this guide covers SPF.

SPF evaluates the SMTP MAIL FROM identity, normally reflected in the received Return-Path, not the user's sign-up email, Reply-To or visible From automatically. The actual envelope local part and domain must be established from the message and account instructions. Publishing the CNAME does not by itself prove which identity a particular send used.

If the visible From is person@sales.example.com and the actual envelope domain is a child of sales.example.com, those domains can align under relaxed SPF alignment, but not strict aspf=s, which requires exact equality. Treat that as an illustration, not a promised Reachdesk runtime identity.

Where an SPF change is genuinely required, keep one v=spf1 TXT policy per evaluated owner. Preserve existing authorized senders and the chosen qualifier, and check the 10 evaluated DNS-dependent-term limit, including nested mechanisms. This is not simply a limit of ten written includes. An all mechanism causes a redirect modifier to be ignored, so do not merge a new all template into an existing redirected policy blindly. See RFC 7208. Qualifiers do not guarantee delivery or rejection, and a DKIM-based DMARC pass does not make an independent SPF error disappear.

4. Preserve the effective DMARC policy

Discover the policy that applies to the actual chosen From domain, including a direct record, any applicable inherited policy and an existing _dmarc alias. Keep established enforcement, alignment modes and approved report destinations. Do not duplicate DMARC or change an existing p=quarantine or p=reject to p=none just to make Reachdesk appear healthy.

Under RFC 9989, a passing aligned SPF or DKIM path can produce DMARC pass. Relaxed alignment compares Organizational Domains; strict alignment requires exact domain equality. A newly configured branded DKIM route should still be accepted only when the intended provider signature passes and aligns with the intended visible From, not merely because another path supplied DMARC pass.

Conditional first-policy example

Only when there is no direct or applicable inherited DMARC policy, and the owner approves an initial monitoring plan, consider a first record with this structure:

Type: TXT
Full owner: _dmarc.FROM_DOMAIN
Value: v=DMARC1; p=none

Replace FROM_DOMAIN with the domain in the intended visible From. For sales.example.com, publish at _dmarc.sales.example.com: relative _dmarc.sales in the parent zone, or _dmarc in its separately authoritative child zone. Do not place TXT alongside an existing CNAME or another DMARC policy. p=none is not enforcement, and without rua this example does not request aggregate reports. Monitoring needs an approved receiving service and a review process.

Before adding a rua address, approve the report recipient and data-sharing purpose. When the report URI host's Organizational Domain differs from that of the domain where the policy was found, the report-generating receiver must check DNS authorization. Destinations within the same Organizational Domain are excepted, even when the hostnames differ. See RFC 9990 section 4. Follow the report service's exact authorization instructions; protocol authorization does not replace privacy approval. Never copy a provider or competitor's report recipient into your policy without authorization.

5. Verify DNS, then activate the intended domain

Query both authoritative DNS and a recursive resolver using the full owners and issued types. Replace every uppercase placeholder; the commands below are not fabricated results:

dig @AUTHORITATIVE_SERVER FULL_ISSUED_OWNER ISSUED_TYPE +noall +answer
dig @PUBLIC_RESOLVER FULL_ISSUED_OWNER ISSUED_TYPE +noall +answer
dig @PUBLIC_RESOLVER FULL_RETURN_PATH_OWNER CNAME +noall +answer
dig @PUBLIC_RESOLVER FULL_DKIM_OWNER TXT +noall +answer

Check every issued row. Require the exact ownership token, full DKIM TXT value or both exact DKIM alias targets, and exact Return-Path alias. Follow DKIM CNAME chains to their public-key TXT data. An unrelated nonempty answer is not a match. Inspect the full DNS response without +noall +answer when an answer is empty, distinguishing negative answers, delegation problems and resolver errors.

Reachdesk says automatic verification can take up to 24 hours. Use Verify to request a manual check; if it remains unresolved beyond that interval, investigate DNS and contact Reachdesk with approved evidence. This is a documented interval, not a guarantee that any erroneous packet will eventually validate.

The domain should change from grey Unverified to green Verified. Then tick its Active checkbox separately. Check the actual user's Sign Up Email and Sending From on the user page before allowing branded correspondence. Recheck all affected users when adding or activating another domain, because parent-domain and multiple-subdomain priority can change their selected identity.

6. Confirm native message authentication

After an authorized setup, test the actual Reachdesk correspondence path with controlled recipients. A test must not create an unapproved gift order, charge, fulfillment or customer outreach. Use an approved test arrangement; a generic email from a different sending platform cannot substitute for this route.

For each affected user/domain combination:

1. Confirm the visible From matches the intended Sending From, not an unintended active parent or the default Reachdesk address.
2. Identify the intended Reachdesk DKIM signature and require trusted dkim=pass, with its d= aligned under the effective policy.
3. Require trusted dmarc=pass for that intended From domain. SPF-only DMARC pass does not validate the new DKIM setup; provider-owned fallback From is not success for your requested brand.
4. Inspect the real smtp.mailfrom/Return-Path and its SPF result separately. Investigate SPF fail, temperror and permerror even if aligned DKIM passes.
5. Confirm replies reach the approved sign-up inbox. Reply routing does not establish SPF or DKIM alignment.

Use receiver-controlled authentication diagnostics, or have the receiving administrator establish which Authentication-Results fields originated inside the service's known processing boundary. Confirm its documented handling strips or reliably distinguishes externally supplied fields, and ignore untrusted or attacker-supplied results. A familiar authserv-id string or header position alone proves nothing about provenance. If that boundary cannot be established, repeat the controlled test at a receiver with trustworthy diagnostics. See RFC 8601 section 7.1.

Read s= and d= from the same DKIM signature when investigating its DNS key. EmailAuth's DKIM selector guide explains the lookup. Two published CNAME selectors do not imply that both must sign every message. Preserve redacted diagnostic evidence without exposing recipient details or gift content. Authentication success does not guarantee inbox placement or prove every future send will pass.

Troubleshooting and safe rollback

• Verified but still using the default sender: check the separate Active checkbox and the user's Sending From assignment.
• A subdomain is verified but the parent appears in From: inspect whether the sign-up domain is also active. Reachdesk prioritizes it; do not alter SPF to fix a selection rule.
• The wrong child domain is selected: review all active children and the shortest-subdomain rule. Check actual assignments instead of assuming the last-added domain wins.
• Ownership verification fails: compare the exact table owner and token. Blank or @ in a parent zone may have placed a child-domain token at the wrong name.
• No verification-code row: a previously safely verified domain may legitimately omit it. Do not manufacture a value; clarify an unexpected missing row for a new setup.
• DKIM fails after DNS looks correct: compare the actual signature's selector and signing domain with the current issued packet, and check TXT completeness or both CNAME chains.
• SPF passes but DMARC fails: compare the actual envelope and DKIM domains with the selected visible From under the current alignment modes. Do not weaken policy or add an arbitrary root include.
• CNAME verification fails: inspect conflicts, suffix duplication, authority, proxying, applicable flattening and cached answers.

If an identity change causes trouble, pause affected outreach, preserve the packet and old active-domain settings, and restore a previously approved, verified selection only after checking its user-level effects. Deselecting all custom domains deliberately returns users to gifts@reachdesk-mail.com; that is a fallback identity, not proof the branded route is repaired. Deleting a domain is not a routine troubleshooting step. Keep DNS records needed by queued mail, other users or another application until their dependencies are resolved. Retest restored routes before resuming outreach.