Direct answer: A Qualtrics Brand Administrator with a branded license can add a custom From domain in Admin > Organization Settings > Messaging > Custom email domains. Publish the newly generated DKIM TXT key, maintain a valid MX whose target has A/AAAA DNS, confirm applicable DMARC, and click Activate. Qualtrics marks its SPF include optional for activation. For its documented vendor-owned envelope sender, aligned custom DKIM is the important DMARC path. An external SMTP relay follows a separate setup. Qualtrics custom From documentation
Account configuration, customer DNS queries and delivery tests have not been performed.
Contents
- Choose native sending or SMTP relay
- Prerequisites: brand access, DNS and sending scope
- Add the custom domain and generate its DKIM key
- Publish DNS without disrupting receiving mail
- Activate and check the public records
- Prove alignment on a real distribution
- Troubleshooting activation and delivery
- Keep SMTP relay changes separate
- Frequently asked questions
- Review scope
Choose native sending or SMTP relay
| Sending route | Domain control | What this guide verifies |
|---|---|---|
| Qualtrics-owned From domain | Qualtrics operates the sender domain | Do not publish customer-domain records to authenticate a vendor-owned identity |
| Native custom From domain | Your brand supplies a custom visible From; Qualtrics sends | Generated DKIM, MX requirements, activation and actual DMARC alignment |
| SMTP relay | Qualtrics passes mail through your email server | Final server's SPF/DKIM, connection security and aligned delivered messages |
A familiar visible From address alone does not identify the SMTP envelope. Qualtrics documents bounces@bounces.qemailserver.com as the envelope sender for its native sending path. SPF can pass for that vendor domain without aligning with surveys.example.com. Adding _spf.qualtrics.com to your own SPF does not rewrite the envelope or prove alignment. Check actual headers before drawing conclusions about a tenant-specific route. Native envelope and optional SPF
A vanity survey URL, an allowed self-enrollment email domain, a Reply-To address and a custom sending domain solve different problems. Do not treat one as proof that the others are authenticated.
Prerequisites: brand access, DNS and sending scope
Qualtrics requires a branded license with a unique brand ID for a custom From domain. A Brand Administrator performs the application steps; IT publishes public DNS. Confirm license eligibility with the account team if necessary. Custom From domains are available across the brand, not restricted per user, and allow users in that organization to send from addresses under the configured domain. Review that scope before choosing a sensitive corporate domain. License and brand-wide scope
Qualtrics recommends a subdomain. A purpose-specific domain such as surveys.example.com can make ownership and reporting clearer. It is still subject to the applicable organizational DMARC policy unless a more specific policy applies; a subdomain does not automatically isolate all reputation or security effects.
Prepare a change worksheet containing the brand ID, domain, intended From and Reply-To, authorized DNS administrator, current selectors, MX, SPF, DMARC and TTLs. Record the old values for rollback. Retain working receiving MX records and unrelated authentication records.
Add the custom domain and generate its DKIM key
- Sign in as a Brand Administrator and open Admin > Organization Settings > Messaging.
- Under Custom email domains, choose Add domain and enter the intended domain.
- Choose a selector. Qualtrics commonly suggests
qualtrics, but use the selector you actually configure. Multiple brands sharing one domain must use distinct selectors; Qualtrics recommends a brand ID as one option. - Choose the supported key size. The interface offers 1024 or 2048 bits; prefer 2048 where supported by your security requirements and DNS host.
- Click Add, then copy every displayed Domain, Type and Value field for the MX/DKIM/DMARC configuration.
- Send the public DNS instructions to the authorized DNS owner, without exposing account secrets.
Qualtrics generates a new custom DKIM key each time the domain is configured. Existing MX does not eliminate the need to publish the current key. Its documentation allows multiple custom domains but specifies one active selector per domain in the brand workflow. Do not improvise a two-active-selector rotation: coordinate the cutover and retain old DNS only where needed for queued messages or other brands. Generation, selectors and key limits
Publish DNS without disrupting receiving mail
| Record | Source of truth | Validation |
|---|---|---|
| DKIM TXT | Generated selector owner and public key | Exact owner and complete key match the current brand registration |
| MX | Existing valid receiving setup or an IT-approved MX configuration | MX exists and its target resolves to valid A/AAAA records |
| DMARC TXT | Organization's approved policy at the applicable owner | Single policy, valid syntax and intended inheritance/alignment |
| Optional SPF authorization | Qualtrics documents include:_spf.qualtrics.com |
Merge only where needed; do not duplicate a policy or assume aligned SPF |
Current MX requirement: Beginning June 8, 2026, Qualtrics requires a valid A/AAAA record for the MX host when sending from a custom domain. Therefore, finding an MX hostname alone is not enough. Check its address resolution too. The same page's older wording that “any MX record” works must be read with this newer requirement. Do not add a dummy MX or replace working corporate MX with an arbitrary destination. Current MX requirement
Before publication or activation, the routing owner must separately approve the complete proposed record set: full owners, MX numeric priorities and target hostnames, and any issued A/AAAA destination addresses. Receiving a provider packet is not approval of its routing consequences. Reconcile it with the authorized design, preserve corporate mailbox and website routing, and compare the complete approved set at authoritative and recursive DNS. Stop on unapproved destinations, extra conflicting records or mismatched priorities; do not accept one matching target as proof of the whole set.
Publish DKIM as TXT, not CNAME, for this documented native workflow. If your DNS host appends the zone automatically, use the relative owner it expects. Inspect the resulting fully qualified name to avoid example.com.example.com. A long TXT key may require multiple quoted character strings within one TXT record; preserve the complete key and follow the DNS host's syntax. A CNAME cannot coexist with other data at the same owner; resolve any conflict with the responsible service owner rather than deleting another service's record.
For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.
Is the Qualtrics SPF record required?
Not for native custom From activation: Qualtrics explicitly calls it optional and says SPF need not show Verified. If your reviewed sending route calls for the documented include, merge that authorization into the existing policy at the correct owner. Never paste a second v=spf1 record or replace the whole policy with a Qualtrics-only example. Preserve the existing terminal all policy and all legitimate senders. Qualtrics SPF requirement
If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.
SPF evaluates the MAIL FROM domain. It allows one SPF policy per owner and at most ten evaluated DNS-querying terms across the complete evaluation, including nested includes and redirects. Adding the include to a domain not used in MAIL FROM does not authenticate a different envelope identity. SPF, RFC 7208
Which DMARC policy should I publish?
Qualtrics requires DMARC with at least p=none; an existing stricter policy should remain. The vendor says organizational-domain DMARC can cover a custom subdomain. Inspect actual policy discovery and any subdomain policy before adding another record. Do not overwrite the established policy with the example shown in a setup window. Qualtrics DMARC prerequisite
DMARC passes when at least one authenticated identifier aligns with the visible From domain: either SPF or DKIM. Relaxed alignment permits an organizational-domain match; strict aspf=s or adkim=s requires an exact domain match for the respective mechanism. With the documented Qualtrics envelope, custom aligned DKIM can pass DMARC even when SPF is unaligned. p=reject does not itself enable strict alignment. DMARC, RFC 9989
Where there is no policy, IT can approve a monitored initial p=none policy and a valid report mailbox after considering all senders. It is not enforcement. Current RFC 9989 makes pct obsolete; do not promise a percentage rollout using that tag. Aggregate reports follow RFC 9990; authorize external report destinations where required. Failure reports under RFC 9991 can disclose message information, so do not enable them without privacy review. Aggregate reporting, failure reporting
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. Only when no direct or applicable inherited policy exists and the domain owner approves initial monitoring, an illustrative first record is TXT with value v=DMARC1; p=none. This requests no reports by itself; add rua only for a provisioned, approved destination after checking the reporting rule below. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.
Activate and check the public records
After publication, click Activate. Qualtrics says records can take up to 24 hours to become visible to its checks. Compare values before waiting: time does not repair a wrong selector or a key from another brand. Activation and errors
These read-only commands use illustrative names. Replace them with your exact domain, selector and MX target:
dig +short TXT SELECTOR._domainkey.surveys.example.com
dig +short MX surveys.example.com
dig +short A MX-HOST.example.com
dig +short AAAA MX-HOST.example.com
dig +short TXT _dmarc.surveys.example.com
dig +short TXT _dmarc.example.com
Expect the current public key, a valid MX target with appropriate address resolution, and an applicable DMARC policy. Use authoritative and recursive queries to distinguish bad publication from caching. Check the SPF domain seen in a delivered message separately; a root-domain query alone cannot validate another domain's SPF.
Prove alignment on a real distribution
After activation, send an authorized small test using the actual distribution and intended custom From address. Open the recipient's original message and trust only Authentication-Results inserted by that receiving service. A copied signature or user-supplied header is not receiver evidence.
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.
| Acceptance item | Evidence to record |
|---|---|
| Correct distribution identity | Brand, distribution type, timestamp, message ID and visible From |
| SPF | spf=pass or other actual result, with smtp.mailfrom domain |
| DKIM | Passing signature with intended header.d and generated header.s |
| DMARC | dmarc=pass for the intended visible From, with aligned mechanism identified |
| Receiving behavior | Actual receipt, any spam placement and distribution/bounce status separately |
Require the expected branded DKIM signature to pass and align; an SPF-only DMARC pass does not complete DKIM setup. Investigate actual SPF fail, permerror and temperror independently even when DKIM supplies the aligned DMARC pass.
For a message with multiple signatures, EmailAuth’s DKIM selector guide explains how to keep each signing domain and selector together when deriving its public-key lookup. Do not pair one signature’s selector with another signature’s domain.
Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.
Illustrative diagnosis, not test evidence: A message from surveys.example.com has SPF pass for bounces.qemailserver.com and DKIM pass for surveys.example.com. The SPF domains are unaligned; DKIM supplies the aligned pass. If DKIM instead passes only for a Qualtrics-owned domain, neither pass demonstrates DMARC alignment with your custom From. Correct the active domain/key/route rather than adding increasingly broad SPF authorizations.
Repeat for reminders, thank-you messages or other materially different workflows you use. A default custom From can be added through Qualtrics Support; the source also describes collaboration emails and triggers using the default, and Employee Experience projects applying the EX default automatically. Test the actual message class rather than assuming all defaults are identical. Default From behavior
Troubleshooting activation and delivery
| Symptom | Likely boundary | Next check |
|---|---|---|
| No valid MX | MX missing, invalid or unresolved target | Query MX and its A/AAAA; preserve real receiving mail |
| Unable to retrieve domain key | Wrong selector, owner, subdomain or DNS zone | Compare generated Domain and public TXT owner |
| Failed to validate DKIM key | Key exists but differs from current registration | Check new key generation, copy errors and another brand's selector |
| SPF not Verified | Optional native SPF is not configured | Do not treat that alone as an activation blocker; verify required records |
| Invalid From or Reply-To | Address/domain not authorized for the brand | Ask the Brand Administrator to review valid sending choices |
| Activated but DMARC fails | Wrong selected sender, signing domain or route | Inspect receiver headers and correct alignment |
| Authenticated but bounced or filtered | Recipient, reputation, content or delivery issue | Inspect distribution history and recipient diagnostics, not just DNS |
Qualtrics documents these key/MX errors and From-address boundaries in its custom From guide. Preserve a redacted message and distribution ID for support; do not send participant lists or message contents unnecessarily.
For survey invitations and reminders, inspect Distributions > Emails: EQD17 indicates missing domain authorization, EQD18 a likely organizational mail-server/relay configuration fault, and EQD19 failure to connect to that server. These are survey-distribution diagnostics, not universal DKIM errors or codes for XM Directory and other project types. Keep the exact code with the route evidence rather than changing DNS for every delivery failure. Qualtrics distribution errors.
Keep SMTP relay changes separate
The relay option requires a branded license and Brand Administrator. Its current setup lives under Admin > Extensions > SMTP Relay, supports Basic or OAuth2 connection methods, and requires the server details plus authorized access for the brand. Once configured, the documentation says mail uses your own domains rather than default Qualtrics domains; Support is involved in setting the default From address. SMTP relay workflow
After Connect Account, the documented flow is Users > Give access to all users. This makes the SMTP resource usable across the brand; those users cannot edit or delete its credentials. Review that access scope before enabling it. The connection offers Yes / 1 for enforced TLS and No / 0 for opportunistic STARTTLS, not simply an encryption on/off switch. Choose the organization-approved security mode; do not downgrade transport to bypass a connection failure.
Have IT review TLS, access scope, sending capacity and the final server's SPF/DKIM configuration. Do not publish credentials in DNS or disable account security merely to follow a legacy SMTP example. A successful relay connection does not prove final-hop DMARC alignment. Older support-configured relays may not appear in Extensions; removing a self-service relay can reactivate an older configuration. Confirm the effective route before rollback.
Creating or storing persistent relay credentials, granting broader relay access, or making any MFA exception requires separate explicit security-owner approval of that change. Authentication troubleshooting does not implicitly authorize these access or security changes; preserve existing protections while the owner reviews the supported integration.
Review scope
No customer account configuration, DNS changes or real-message tests were performed. Validate the account-specific records and delivered-message evidence before treating your configuration as complete. Authentication does not guarantee delivery or inbox placement.