This guide covers eDesk channels sending through eDesk with your own domain. It does not configure Repricer, Feedback, external SMTP services or marketplace-owned addresses. No customer account, DNS change or message test was performed.
Quick answer
For eDesk's own-domain route, obtain the current DNS package from your channel's verification screen. Do not reuse a universal SPF include, DKIM selector or screenshot value. Publish the issued records at their exact owners, preserve existing mail routes, and verify both the intended DKIM signature and DMARC alignment on a delivered message. The provider's domain-compliance instructions describe the account-specific package.
xSellco is the former company brand; eDesk's current company history confirms its 2021 rebrand. That does not make every xSellco product's mail settings interchangeable.
First identify which service actually sends
An eDesk channel can use an eDesk-owned address, an external SMTP connection, or a custom address sent through eDesk. Those routes have different authentication responsibilities. The SMTP documentation locates the channel at Settings → Mailbox Settings → Channels → select the channel → Mailbox tab, and requires an eDesk administrator for SMTP configuration.
Use the current channel configuration to establish your route before changing DNS. A connected Gmail mailbox does not by itself prove that Google transmits the outgoing support reply. Conversely, an external SMTP route is not authenticated merely by publishing eDesk-issued DNS records.
The SMTP page retains historical mode-retirement text and older provider connection examples. This article does not recommend those examples, unencrypted submission or a password-based integration. For external SMTP, confirm the mail provider's current supported secure authentication method and use that provider's domain-authentication guide. For Microsoft-hosted mail, see the Microsoft 365 guide.
Collect the account-issued records
For the own-address route:
- Open Channel Domains in your eDesk account to identify affected channels using Send from own email address. Alternatively, in the affected channel's settings, click See details here in the verification notification.
- On the details screen, choose Download .csv DNS record set. The provider documents one MX, one TXT and three CNAME records; use your current export if the account differs.
- Record the domain, channel, record owners, types and complete values. Save the previous configuration separately.
- Check each affected channel. The provider says same-domain channels share the DNS change; different domains require their own records. Compare exports before deduplicating anything.
The domain-compliance instructions also describe a last-check timestamp and separate DKIM and MAIL FROM status. Use these to distinguish DNS publication from provider verification. If the documented own-address route or CSV is absent, stop and obtain current instructions rather than switching a live channel's sending mode.
Review the change before publishing
Have the domain owner approve the exact DNS changes. Identify the actual authoritative zone, including any delegated sending subdomain or delegated _domainkey namespace. A registrar login is not evidence that its DNS editor controls public answers. Keep a zone export and the current direct and inherited DMARC policies.
Compare each CSV owner with the DNS editor's naming rules. An editor may append the zone name to a relative label; entering the full name twice creates the wrong record. If the sending subdomain is separately delegated, edit that child zone rather than the parent. Do not delete an NS delegation to make a tutorial fit.
For example, an issued DKIM owner SELECTOR._domainkey.news.example.com is entered as SELECTOR._domainkey.news in the example.com parent zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com is separately delegated, its relative owner is SELECTOR. Replace this example selector with the account-issued label and retain the exact CNAME target. Do not move the record into a more convenient zone or remove the existing NS delegation. DKIM owner construction and relative DNS owner names.
Do not add the issued MX to your ordinary mailbox domain simply because both records say MX. Verify the exact owner and the approved purpose of that mail route. Preserve existing inbound mailbox delivery. An unexpected apex MX, unfamiliar destination or collision with an existing mail route needs provider and domain-owner clarification before publication. The export is evidence of requested values, not permission to reroute mail.
The eDesk instructions distinguish MX Priority from the destination hostname. If the DNS editor has separate fields, put the account-issued numeric preference in Priority and the account-issued mail-server hostname in Value, Target or its equivalent. If it expects a combined value, follow that DNS host's documented format. Do not copy the provider article's sample priority or Amazon hostname: neither is a universal customer value. Before saving, compare the exact full MX owner, numeric priority and target with both your current export and the domain owner's separately approved routing plan. An unexpected target or priority requires clarification, not activation.
Publish SPF at the correct owner
SPF checks the SMTP MAIL FROM domain, or HELO in relevant cases, not automatically the visible From address. Determine which owner the account's TXT record serves; do not move it to the apex or append an inferred Amazon authorization to your main SPF just because a sample mentions Amazon infrastructure.
At an owner already containing SPF, preserve legitimate senders and the existing policy's intent. There must be one applicable v=spf1 TXT policy, not a second competing policy. Review nested evaluation against the limit of 10 DNS-dependent terms, not simply 10 includes. An all mechanism causes redirect to be ignored. Qualifiers do not guarantee a particular inbox or rejection outcome. These are SPF protocol rules.
If the packet conflicts with an existing SPF owner, do not blindly concatenate strings. Establish whether the sending domain is shared, whether another service still uses it, and whether the requested policy can coexist safely. A distinct approved bounce subdomain may isolate the route, but it must be provisioned by the provider rather than invented locally.
Publish DKIM without changing its meaning
Copy each issued CNAME owner and target exactly. Do not manufacture selectors, paste private keys or substitute a public-key generator for the provider's signing setup. Keep existing selectors required by other mail streams or a planned rotation.
A CNAME cannot share its owner with ordinary TXT, A, AAAA or MX data. A conflict is a reason to investigate the ownership and dependencies, not to delete whichever record looks older. Publishing DNS also does not prove that eDesk has enabled the intended signer.
Use DNS-only records rather than HTTP proxying. Where literal CNAME answers are required, ensure flattening does not hide them: disable a relevant per-record flattening option where supported, and review applicable zone-wide behavior. Do not disable unrelated global features blindly. Cloudflare, for example, documents default apex flattening and same-zone target behavior that can override the setting. If mandatory behavior cannot preserve the required alias, stop for a supported configuration. Cloudflare's documented flattening behavior.
Keep DMARC protection intact
Inspect the visible From domain's direct policy and any applicable inherited policy before adding one. Do not replace existing protection with monitoring, duplicate the policy, weaken alignment or remove approved report destinations to make a single channel appear successful.
Only if no applicable policy exists and the domain owner approves an initial monitoring plan, a starting record can be TXT at _dmarc.<your-domain> with value v=DMARC1; p=none. Replace the placeholder with the actual From domain and map the owner to the correct zone. For visible From domain example.com, the full owner is _dmarc.example.com, entered as _dmarc in that zone. For news.example.com, the full owner is _dmarc.news.example.com, entered as _dmarc.news in the parent example.com zone or _dmarc in a separately delegated news.example.com zone. Do not create a child monitoring exception to an applicable protective parent policy. This example does not request reports and is not an enforcement policy. Plan monitoring and a later evidence-based protection decision separately. Current DMARC specification.
For aggregate reports, a destination in a different Organizational Domain from the policy domain requires receiver-side DNS authorization checks. A destination within the same Organizational Domain is excepted. The domain owner's approval to share report data is still a separate requirement. Never copy a third party's reporting mailbox from an example. RFC 9990, section 4.
Verify in three separate stages
1. Public DNS
Query the authoritative servers for each exact issued owner, then compare an ordinary recursive resolver. Use the NS delegation for the actual authoritative zone, not an assumed registrar nameserver. Replace every angle-bracket placeholder before running these illustrative commands:
dig NS <authoritative-zone>
dig @<authoritative-nameserver> TXT <issued-txt-owner>
dig @<authoritative-nameserver> MX <issued-mx-owner>
dig @<authoritative-nameserver> CNAME <issued-dkim-owner>
dig TXT <issued-txt-owner>
dig MX <issued-mx-owner>
dig CNAME <issued-dkim-owner>
Compare returned names and values with the account packet. For MX, compare the complete numeric-priority and target set at the exact owner with the approved routing plan and issued packet; a nonempty answer is not sufficient. Confirm that unrelated mailbox-domain MX records remain unchanged. Do not accept a result with a different destination or priority merely because a DNS checker reports a record exists. Repeat for all issued aliases. These commands are examples, not reported test results. Authoritative agreement with recursive disagreement can indicate cached old data; a wrong authoritative answer will not fix itself by waiting for propagation.
2. Provider verification
Check the current verification state for the intended domain and each affected channel. Resolve any mismatch between the exported packet and the published records. A stale check timestamp is not proof that a newly corrected record failed. Do not declare success from a downloaded CSV or a green DNS lookup alone.
3. A controlled delivered-message test
With approval, send a representative support reply through the intended channel to a controlled valid mailbox. Inspect the original headers, not just a forwarded copy. Use Authentication-Results produced inside the receiving service's known processing boundary, with its documented treatment of externally supplied result fields. Header order or a familiar authentication-server identifier alone does not establish trust.
Acceptance requires the intended provider DKIM signature to pass and its d= domain to align with the intended visible From, plus trusted dmarc=pass. A DMARC pass through SPF alone does not prove DKIM works. A reply rewritten to a provider-owned From address is not successful authentication of your original branded address.
Relaxed alignment compares Organizational Domains; strict alignment requires an exact domain match. Evaluate DKIM under adkim and SPF under aspf separately. A child bounce domain can meet relaxed SPF alignment without meeting strict alignment. Alignment rules.
Troubleshooting the failed layer
- CSV owner absent in DNS: check authoritative zone, delegation and duplicated domain suffix before repeating the same edit.
- MX visible at the wrong name: stop. Compare the authorized routing plan and restore only the unintended change; do not remove legitimate mailbox MX records.
- CNAME missing or replaced by addresses: inspect proxying, flattening and conflicting owner data.
- Provider verifies but DKIM fails on mail: confirm the actual channel and signing domain. The tested reply may use a different route.
- DKIM passes but DMARC fails: compare the signature's domain with the visible From and the applicable alignment policy.
- SPF fails while DKIM passes: investigate the actual envelope domain and sender authorization. A temporary DNS error and a permanent policy error are different problems; successful DMARC via DKIM does not erase either.
- Only some channels fail: compare their current sending routes and domain packets, not just their displayed company name.
Record the packet date, exact changes, public answers, provider status and controlled-message result. If rollback is needed, restore only the approved changed records from the saved values. Preserve later shared dependencies and retain DKIM records needed by queued messages or an authorized rotation. Do not change account credentials, nameservers or unrelated mail routing as a speculative fix.
Common questions
Is there one eDesk SPF include I can paste everywhere?
Use the current packet for your domain and sending route. This guide intentionally does not turn an old screenshot or an observed corporate SPF record into universal customer instructions.
Does connecting an inbox authenticate outgoing replies?
No. Inbox connectivity and outbound authentication are separate checks. Establish the actual sending route and verify the delivered message.
Can I use these records for all xSellco products?
No. The scope here is the documented eDesk own-domain channel route. A brand relationship does not prove another product has the same record issuance or signing behavior.
Does a verified setup guarantee delivery or ranking?
No. Authentication proves specific domain-use checks, not inbox placement, absence of abuse, search rankings or content quality. Keep the delivered-message evidence distinct from this documentary guide.