Why does Qualtrics need an A or AAAA record for an MX host?
Published 7 Jul 2026
Updated 7 Jul 2026
9 min read
Summarize with

Qualtrics needs an A or AAAA record for an MX host because an MX record only names the mail server. That named mail server still has to resolve to an IP address before mail can be delivered to it. Since June 8, 2026, Qualtrics has checked that the MX host behind a custom From domain resolves through DNS before allowing that domain to send.
The part that trips teams up is the word host. If the custom From domain is feedback.example.com and its MX points to mx1.mail.example.net, Qualtrics is checking whether mx1.mail.example.net has an A or AAAA record. An A record on feedback.example.com does not fix a dead MX target.
The practical rule
Fix the hostname named in the MX value, or replace the MX with a current inbound mail host that already resolves and accepts mail for the subdomain.
What Qualtrics is checking
In the custom From setup, Qualtrics asks for DNS records that prove the domain is usable for email. The MX check is not the same as SPF, DKIM, or DMARC. It verifies that the domain has a valid inbound mail route, even when the messages are mainly outbound survey notifications.
|
|
|
|---|---|---|
MX | From domain | Names a mail host |
A | MX host | IPv4 answer exists |
AAAA | MX host | IPv6 answer exists |
DMARC | From domain | Policy exists |
Compact view of the records involved.
I treat this as a basic domain hygiene check. A custom sending domain that has an MX pointing to a hostname with no DNS answer looks unfinished. It also means replies, out-of-office messages, abuse reports, and human responses have nowhere reliable to go.
MX validation outcomes
How a custom From subdomain normally looks to a DNS validator.
Healthy
Pass
The MX target resolves to A or AAAA and the mail service is current.
Needs review
Check
The MX resolves, but the receiving service has not been confirmed.
Broken
Fail
The MX target returns NXDOMAIN or has no address records.
The DNS chain that matters
The DNS path is simple once the names are separated. The From domain has an MX record. The MX record points to a host. The host has an A or AAAA record. Mail systems connect to the IP address returned by that final lookup.

Flowchart showing a From domain MX lookup resolving to an A or AAAA record.
Valid DNS shapedns
feedback.example.com. 3600 IN MX 10 mx1.mail.example.net. mx1.mail.example.net. 3600 IN A 203.0.113.10
That example passes the specific Qualtrics requirement because the MX target resolves to an IP address. The receiving service still needs to be configured to accept mail for the subdomain, but DNS has the basic chain Qualtrics is looking for.
Broken DNS shapedns
feedback.example.com. 3600 IN MX 10 mx1.old.example.net. ; mx1.old.example.net returns NXDOMAIN
The common mistake
The most common mistake is looking up the A record for the sending subdomain and assuming that proves the MX is valid. It does not. Web and mail DNS use different lookup paths.
Wrong check
- Subdomain A: Looking up the A record on the custom From subdomain only proves that name has a web-style address.
- False comfort: A valid answer there still leaves a broken MX target unresolved.
Right check
- MX target: Look up the hostname returned by the MX record and check for A or AAAA answers.
- Mail route: Confirm the receiving system accepts mail for that exact subdomain.
Do not create records in the wrong zone
If the MX target is a hostname owned by an old provider, you usually cannot fix it by adding an A record in your own DNS zone. Replace the MX with a current mail host, or ask the provider that owns the hostname to restore it.
This is also why an old subdomain can appear to work for years and then fail when a platform starts validating DNS more strictly. The old setup was already weak, but nothing enforced the check until the platform changed its activation rules.
How to fix it
I would fix this by deciding where replies for the custom From subdomain should go, then making the MX match that decision. Even if nobody expects replies, the domain still needs a real inbound path. Sending from a domain with broken receiving DNS is bad practice because mailbox providers use domain consistency as one quality signal.
- Find the MX: Query the custom From domain, not the organizational root unless that is the exact sending domain.
- Check the target: Resolve each MX hostname for A and AAAA records and treat NXDOMAIN as broken.
- Choose the route: Use the MX records supplied by Qualtrics if it handles replies, or your own inbound provider if it does not.
- Configure receiving: Make sure the mail system accepts mail for the subdomain, even for a no-reply mailbox.
- Retest sending: Send one live message and inspect authentication results before resuming volume.
Commands to isolate the faultbash
dig +short MX feedback.example.com dig +short A mx1.mail.example.net dig +short AAAA mx1.mail.example.net
For background on why this affects bounce handling and reputation, the same issue shows up when MX records and bounces are connected incorrectly. If a domain sends mail but has no usable inbound path, domains without MX records create the same kind of confusion.
How to validate the domain
After the MX target resolves, I check the whole sending identity. That means DNS health first, then a real message test. Suped's product is useful here because it brings DMARC monitoring, SPF and DKIM checks, blocklist (blacklist) visibility, and issue detection into one workflow instead of leaving each record as a separate manual check.
A quick domain health checker pass tells you whether MX, SPF, DKIM, and DMARC records are visible. Then an email tester run confirms what happened to a real message after Qualtrics sent it.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For ongoing control, DMARC monitoring helps catch authentication drift after DNS changes. Suped adds real-time alerts and automated steps to fix issues, which matters when a survey subdomain depends on both your DNS team and a third-party platform.

DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
What to ask Qualtrics and IT
If ownership is unclear, split the question in two. Ask Qualtrics whether it expects to process replies for the custom From domain. Ask IT which inbound mail service should accept mail for that subdomain. The answer decides the MX.

Qualtrics custom email domain screen showing an unverified MX record.
Ticket text I would send
We send Qualtrics mail from feedback.example.com. Please confirm whether Qualtrics handles replies for this subdomain. If yes, provide the required MX values. If no, we will route the MX to our inbound mail provider and configure that provider to accept mail for feedback.example.com.
That wording keeps the work concrete. It avoids asking someone to "add an A record" without naming the host that needs it, which is how teams end up fixing the wrong DNS name.
Views from the trenches
Best practices
Check the MX target hostname first, then confirm it has live A or AAAA DNS answers.
Keep custom sending subdomains on current inbound routing, even when replies are rare.
Record why each MX exists so old vendor hostnames are removed during DNS reviews.
Common pitfalls
Checking the subdomain A record while the broken name is the MX target leads teams off path.
Leaving old gateway MX records in place after a mail provider migration creates NXDOMAIN failures.
Assuming no replies means no MX matters ignores how receivers score basic domain hygiene.
Expert tips
Ask Qualtrics whether it expects to process replies before changing the MX route.
Use short TTLs before MX cleanup so corrections propagate quickly after verification.
Test one real message after DNS changes and read the authentication results, not just DNS.
Expert from Email Geeks says the A record to check is on the MX target hostname, not the custom From subdomain.
2026-06-29 - Email Geeks
Expert from Email Geeks says an MX record that points at NXDOMAIN is broken even when the sending subdomain has an A record.
2026-06-29 - Email Geeks
Fix the MX target first
Qualtrics is not asking for a random A record on the custom From domain. It is checking whether the mail exchanger named by that domain's MX record resolves to an IP address. If the MX host is stale, misspelled, unpaid, or left behind after an old provider migration, the fix is to replace the MX with a current receiving host.
Once that chain is clean, confirm SPF, DKIM, and DMARC for the same sending identity. Suped's product is the best overall practical choice for most teams because it turns those checks into monitored issues with clear fix steps, alerts, and a shared view across domains.

