Identify the Qualtrics sending route
This guide covers the native custom From domain workflow in Qualtrics, with an explicit boundary around SMTP relay configurations. A research team may select a familiar sender address while a different system supplies the SMTP envelope and DKIM signature. Begin by recording the brand, the visible From domain, and whether delivery uses Qualtrics infrastructure or an organizational relay. Treat those as separate routes in the change plan.
The documented native route requires an eligible branded license and a Brand Administrator. It grants domain use across the brand rather than restricting it to individual users. Qualtrics recommends a dedicated subdomain. Since June 8, 2026, the MX host must also have a valid A or AAAA record. These prerequisites deserve review before anyone creates DNS entries. Qualtrics custom From documentation
A dedicated research subdomain gives the change owner a clearer inventory of users, mail flows, and DNS dependencies. It does not by itself guarantee separation from organizational DMARC policy. Agree which team owns respondent replies, which addresses may appear in From, and who can authorize future brands. Record whether the proposed address is already used by a mailbox or another mailing platform so that an authentication change does not accidentally become a receiving-mail migration.
Prepare the brand and DNS change
Qualtrics places custom email domains in the Messaging section of Organization Settings. Its separate custom-header feature can tag brand mail, but adding a descriptive header is not DKIM configuration. Organization-level settings also cover several kinds of mail, including distributions and workflow-related messages. Therefore, a successful survey invitation should not be treated as proof for every other business workflow without a separate test. Qualtrics Organization Settings
In the custom-domain flow, add the intended domain and select a DKIM selector. Use a unique selector for each brand sharing a domain. Copy the generated record owners, types, and values to the DNS change request, publish them at the authoritative host, and activate after verification. Qualtrics documents DKIM, MX, and DMARC requirements; its optional SPF example is not a substitute for DKIM alignment. Use the records generated for the current setup rather than a copied key from another brand. Qualtrics custom From documentation
Before saving the DNS change, export the existing values and identify every record that will change. Check the fully qualified owner after the DNS editor appends its zone suffix. Preserve existing receiving-mail records unless the responsible mail owner has reviewed a specific replacement. For the MX dependency, query both the MX target and the target's address records. An MX label alone is an incomplete check when the named host has no address.
Use a ticket to connect the brand administrator's generated configuration to the DNS administrator's published result. Include collection times and TTLs so a later investigator can distinguish an outdated cache from an incorrectly published value. Public keys may be kept as evidence; private signing keys, account secrets, and respondent contact lists do not belong in the worksheet.
Evaluate alignment on the message
SPF evaluates the sending server against the SMTP identity, not simply the visible From address. Maintain one applicable SPF record at each owner, preserve legitimate senders when merging authorization, and assess the lookup limit rather than adding multiple standalone policies. An include added to an unrelated domain cannot change the identity used in a received message. SPF RFC 7208
DMARC passes when a passing SPF or DKIM result aligns with the visible From domain. A passing mechanism for an unrelated provider domain is not enough. Record the actual alignment mode and domains rather than writing only “SPF passed” in the ticket. DKIM evidence includes the signature's d= domain and s= selector, which together identify the public-key lookup. DMARC RFC 9989 DKIM RFC 6376
Run controlled tests using harmless content and recipients authorized for testing. Capture the receiver's trusted Authentication-Results and the complete relevant headers, with personal data minimized. Compare an invitation and a reminder from the same survey, then test any additional workflow included in the release. A user-interface verification badge establishes a configuration checkpoint; received-message evidence establishes what actually authenticated for that route.
Do not change the organization's enforcement policy merely to make one campaign launch. If legitimate routes have not been inventoried, document that dependency and use the established change process. Authentication also does not prove consent, good list quality, inbox placement, or respondent engagement.
Keep SMTP relay work in a separate change
If the organization uses its own SMTP relay, stop applying the native-route worksheet as if it were the relay's configuration. Capture the relay service, submission method, sender restrictions, outbound signing owner, and the person responsible for its logs. Require the relay operator's current supported configuration and authentication evidence. This article does not approve new persistent credentials, an MFA exception, or broader access to a relay.
Qualtrics distribution error codes help separate these faults. EQD17 concerns authorization to send from a domain; EQD18 indicates a likely mail-server configuration problem; EQD19 concerns connection to the organization's server. Those codes are documented for survey distributions, not every Qualtrics project type. Use the exact product and event before applying the diagnosis. Qualtrics distribution error messages
A failed connection is not evidence that a DKIM key is wrong. Conversely, successful SMTP submission is not proof that the final message passed DMARC. Keep submission logs and recipient headers as distinct evidence, connected by a safe test identifier and timestamp.
Qualtrics acceptance worksheet
Complete a separate proposed record for each brand and delivery route. These fields are not observations from a live tenant.
- Scope: brand identifier, license eligibility, administrator, survey or workflow, native or relay route, and release owner.
- Identity: approved From address, reply handling, organizational domain, applicable DMARC policy, and alignment modes.
- Native configuration: chosen selector, generated public DNS instructions, activation status, and other brands using the domain.
- DNS: authoritative nameservers, exact record owners, public answers, MX target address records, TTLs, and capture times.
- Relay branch if applicable: approved service, responsible operator, outbound signing ownership, and separately reviewed connection requirements.
- Message evidence: test type, time, receiver, envelope domain, DKIM domains and selectors, trusted authentication results, and observed alignment.
- Decision: routes tested, routes excluded, unresolved errors, rollback owner, and approval still required.
Fictional diagnosis of a passing SPF result
This example is fictional. A research team sees SPF pass on a survey invitation and assumes its newly branded From address is protected. The recipient nevertheless reports DMARC failure. Inspection shows that the SPF identity belongs to the sending service and the message has no passing aligned DKIM signature for the research domain.
The proposed investigation compares the current brand's selector with the published key and checks whether the administrator activated that exact domain. A second brand using the same domain is investigated separately rather than allowed to overwrite the first brand's selector. The repair is accepted only after fresh receiver evidence demonstrates the intended alignment. This is an illustrative diagnosis, not a performed change or a claim about any customer.
Evidence and release gates
Current first-party documentation supports the native workflow and the route distinction. No customer tenant, DNS zone, relay, or received message was accessed. Actual license eligibility, brand access, generated values, MX address resolution, activation, and message-level alignment remain pending. Human SME review, visual reader review, and publication approval are also pending. Keep the candidate unpublished and preserve unresolved route-specific questions in the release record.
Protect receiving mail when reviewing the native domain
A sending-domain request can change receiving dependencies when it includes MX records. Record the current inbound purpose and the accountable mail owner before approving any replacement. An address record for the MX target is necessary under the documented prerequisite; it is not proof that the full domain configuration or delivery route passed testing.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.