What causes a 'domain not configured to use this MX host' bounce message?
Updated on 10 Oct 2026: We updated this guide with domain-owner repair steps, MX priority checks, and clearer retry and DNS caching advice.
A 'domain not configured to use this MX host' bounce usually means the recipient domain has an MX (Mail Exchange) record pointing at a mail server, but that server has no accepted-domain, local-domain, tenant, or route entry for that domain. In plain terms, DNS says 'deliver mail here', and the mail server replies, 'I am not configured to receive mail for that domain.'
When this error appears during the RCPT TO stage, treat it as a recipient-side configuration problem until the evidence proves otherwise. SPF failures normally have different wording. DKIM and DMARC checks require message headers, which have not yet been transmitted at this stage.
This is the pattern that matters. The remote MX host accepts the SMTP connection, then rejects the recipient because the domain is not in its mail routing configuration.
Typical bounce texttext
<user@example.com>: host mx1.provider.example[192.0.2.10] said: 451 Your domain is not configured to use this MX host. (in reply to RCPT TO command)
What the bounce means
SMTP delivery is not only a DNS lookup. The sender looks up the recipient domain's MX records, connects to the listed host, then asks that host whether it will accept mail for the recipient address. This bounce happens after the connection succeeds, which is why the host can return a specific rejection. Successful outbound email does not prove that the same domain can receive mail, because incoming delivery uses a separate MX and receiving configuration.
The important clue is that the named host is usually the recipient's listed MX. If live DNS still points to that host, the recipient's mail provider or admin needs to add the domain, restore the mailbox service, fix routing, or update DNS to the correct mail host.
|
|
|
|---|---|---|
4xx, such as 451 | Temporary failure (soft bounce); sender normally queues and retries | Recipient host |
5xx | Permanent failure (hard bounce); sender stops normal retries | Recipient host |
RCPT TO | Recipient rejected before message content is sent | Recipient host |
MX host | Usually selected through DNS; a forced route can override it | Recipient DNS or sender routing |
Domain | Mail domain rejected | Recipient admin |
How to read the key parts of the bounce.
A 451 response tells the sending system to queue the message and retry. Some servers return a 5xx code with similar wording, which stops normal retries. Read the full SMTP status and enhanced status code: the wording identifies the configuration mismatch, while the code determines retry behavior. Retries end when the sender's queue lifetime expires; an unresolved 4xx failure then produces a final non-delivery report (NDR). Repeated 4xx failures over hours or days still indicate a real mail setup problem.
Most common causes
The exact wording comes from the receiving system, so different providers phrase it slightly differently. The cause usually falls into one of these buckets.
- Stale MX: Public DNS still points to the old provider after a mail migration, domain renewal, or nameserver change.
- Missing domain: The MX host is correct, but the domain was not added to the mail tenant or accepted-domain list.
- Suspended service: Hosting, filtering, or mailbox service was disabled, often after billing or account changes.
- Bad gateway route: A filtering gateway is listed as MX, but its downstream route or accepted recipient map is wrong.
- Cached DNS: The sender or an intermediate resolver still has an old MX answer after a migration.
- Partial MX fleet: The domain exists on some published MX hosts but not others, so results depend on the selected host.
- Split delivery: Mail systems share the domain, but the accepted-domain mode, recipient lookup, or connector routes valid recipients incorrectly.
- Provider outage: The host is normally valid, but the provider has temporarily lost domain routing state.
A Microsoft Q&A case describes a domain that could send email but rejected incoming messages because a registrar-operated receiving filter was not configured. The reported domain-health checks looked correct, so the receiving route still needed investigation.
Likely recipient-side
- MX matches: The bounce host is the same host returned by current MX lookup.
- Known recipient: A second known recipient returns the same error, supporting a routing issue without proving every mailbox fails.
- Long delay: The same bounce repeats across normal SMTP retry windows.
- All senders: Other senders report the same remote rejection for that domain.
Worth checking on your side
- Wrong address: The local part or domain in the recipient address is mistyped.
- Old bounce: The bounce was generated before the recipient fixed DNS.
- Relay path: Your outbound relay is using stale DNS or a forced route.
- Queue status: Check whether the message is still deferred or has reached the retry limit.
MX bounce troubleshooting flowchart: compare the rejecting host with MX records, test a known recipient, and contact the receiving administrator.
Why the failure can be intermittent
A domain can work for some messages and fail for others when DNS publishes multiple MX hosts but only part of the fleet recognizes the domain. Different senders or retries can reach different hosts, so one successful test does not prove that every published MX target works.
Lower MX preference numbers are tried first. Equal-priority MX records are valid and distribute traffic between hosts. Backup MX hosts also need to accept or relay the domain. The selection rules are defined in RFC 5321.
|
|
|
|---|---|---|
Bounces name one MX host | Compare every MX target and its priority | Add the domain to that host or remove stale DNS |
Same-domain recipients fail | Review split delivery, accepted-domain mode, recipient lookup, and connectors | Configure the shared-domain route |
Failures started after migration | Compare TTLs, change time, resolver caches, and the old host | Remove stale MX records after transition |
Checks for intermittent or partial failures.
If a split-delivery or hybrid setup shares one domain across mail systems, each system needs to know which recipients are local and where to route the others. Depending on the platform, this can require an internal relay or equivalent accepted-domain mode plus a connector to the other system. An authoritative-domain setting on the wrong system can reject a valid recipient before that route runs.
Review message tracking or SMTP logs by remote hostname and IP address. Check each host's A and AAAA addresses too, because IPv4 and IPv6 nodes can have different routing state. If failures cluster on one MX node, fix that node's domain map or remove it from DNS. If the pattern follows only same-domain recipients, inspect internal routing and recipient lookup before changing public MX records.
How to check MX records and the rejecting host
Start by comparing the host in the bounce with live MX results for the recipient domain. Record every MX target and priority. If the bounce names a host that DNS returns now, the recipient's DNS is sending at least some mail to a server that rejects the domain.
Then check your own sending path separately. Confirm that your outbound relay uses current DNS rather than a forced route. A domain-health result alone does not establish why the remote host rejected this recipient.
MX and host address checksbash
dig MX recipient.example +noall +answer dig +short A mx1.recipient-mail.example dig +short AAAA mx1.recipient-mail.example # Windows alternative for the MX lookup nslookup -type=MX recipient.example
Replace the example domain and host with the recipient domain and the actual MX target. The dig MX output includes preference and TTL values. These lookups show DNS routing, not whether the host accepts the domain. Server-to-server SMTP normally uses port 25; this rejection shows that the SMTP connection already succeeded.
If you need a separate view of your own domain's public configuration, run Suped's domain health check and keep the result with the bounce. Its results identify DNS and authentication issues you control; they do not prove that this specific rejected message passed authentication.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A real-message test is useful for a separate sender-authentication investigation. Use Suped's email tester to inspect the authentication results and headers of the test message. A successful test to another destination does not verify the affected recipient domain; the original SMTP rejection remains the evidence for escalation.
Use at most one controlled test to a known address with permission. It can reproduce the failure on that route, but it does not validate every mailbox or every MX host.
If the bounce is part of a wider investigation, keep it with your normal bounce troubleshooting notes. The key evidence is the SMTP stage, the remote host, the IP address, the recipient domain, and the date.
What the sender should do next
If you are the sender, confirm the recipient address and MX evidence, then send the recipient a short escalation note through another channel. The SMTP response and routing evidence should guide the fix; sender authentication changes do not repair the receiving host's accepted-domain configuration.
- Capture evidence: Save the full bounce, including the remote host, IP address, SMTP code, and timestamp.
- Check DNS: Look up the recipient domain's live MX records and compare every target with the bounce host.
- Check outbound routing: Confirm your outbound relay is using the intended route and current recipient DNS.
- Contact recipient: Ask their admin to confirm the domain is configured on every listed MX host.
- Avoid duplicates: Let your mail system handle 4xx retries instead of sending manual copies.
Short escalation notetext
We tried to send mail to recipient.example and received this bounce: 451 Your domain is not configured to use this MX host. The rejecting host was mx1.provider.example at 192.0.2.10. Live MX lookup also points recipient.example to that host. Please confirm that recipient.example is configured as an accepted domain on the listed MX host, or update MX records to the correct mail host. Delivery attempt timestamp (include timezone): [timestamp] SMTP stage: RCPT TO
MX records control where inbound mail goes. They do not authenticate outbound mail or directly determine sender reputation. For more detail on how routing failures create bounces, read about MX records in the broader delivery context.
How to fix MX host configuration for your domain
If you own the affected domain, make DNS and the mail platform agree. The MX records must point to the mail host you actually use, and that host must have the domain enabled for inbound mail.
- Confirm the receiving service is active and the domain is added to the correct account or tenant. Complete any required ownership verification and enable inbound mail; publishing MX records alone does not provision the domain.
- At the authoritative DNS provider, copy the receiving provider's exact MX hostnames and priorities. Use hostnames that resolve directly to A or AAAA records, not IP addresses or CNAME aliases. Ask the DNS provider to fix wrong records and the mail provider to fix domain provisioning.
- Confirm the listed receiving host accepts the domain, the intended mailbox or alias exists, and any gateway forwards to the correct downstream service. If a hosting control panel has local or remote mail-routing settings, select the mode that matches where mail is received.
- During a migration, keep the old receiving service available while cached MX answers expire. Remove obsolete MX entries at the planned cutover and verify the new service before closing the old one.
- After fixing the configuration, send one agreed test to a known valid address and check the receiving logs. Let queued 4xx messages retry; resend messages that already produced a final NDR after confirming delivery works.
Expected configuration matchtext
DNS: recipient.example. 3600 IN MX 10 mx.provider.example. Mail platform: Accepted domain: recipient.example Inbound route: enabled Mailbox or alias: present
For DNS propagation checks, compare authoritative answers with the resolver used by the sending system. TTL (time to live) controls cache duration, as described in the DNS record reference. Lowering TTL after a change does not shorten an old answer already cached with its previous TTL. Do not wait a fixed 48 hours without checking which answers are still in use.
Compare authoritative and cached MX answersbash
dig +short NS recipient.example # Replace this host with an authoritative nameserver returned above dig @ns1.dns-provider.example MX recipient.example +noall +answer # Compare with the sending system's configured DNS resolver dig MX recipient.example +noall +answer
If authoritative DNS points to the correct host and that host still rejects the domain, contact the receiving mail provider with the full SMTP error. Waiting for DNS caches will not add a missing accepted-domain entry.
Using Suped for sender authentication checks
Suped's DMARC and email authentication platform helps you investigate authentication issues on domains you manage. For this bounce, use those results alongside the rejecting host's SMTP response to keep sender authentication separate from recipient routing.
Use Suped's DMARC monitoring to review sending sources and reported authentication results, then follow guided steps for issues you control.
Domain health checker sample results showing DMARC, SPF, DKIM scorecards and detailed validation checks
- Check your own domain's DNS and authentication results, and save relevant findings with the bounce.
- Review DMARC reports for legitimate sending sources that fail authentication.
- Use Suped's guided fix steps for SPF or DKIM configuration problems discovered separately.
- Review authentication alerts across the domains you manage.
DMARC aggregate reports describe authentication results reported by participating receivers. They do not provide a complete bounce log or diagnose a recipient's accepted-domain configuration. Use the original bounce and SMTP logs to identify the failing receiving route.
How to resolve the bounce
The direct cause is a mismatch between the recipient domain's MX records and the mail server's accepted-domain configuration. The host receiving the SMTP connection does not believe it should accept mail for that domain.
The fastest resolution usually comes from a precise escalation: the rejecting MX host, the recipient domain, the timestamp, and the request to verify accepted-domain configuration.
Frequently asked questions
Usually no. SPF problems normally appear as sender authentication or policy failures. This wording points to the recipient MX host not being configured for the recipient domain.
Some receiving systems use 451 for routing or domain-configuration failures because the issue can be fixed without changing the message. The sending system should queue and retry it. If the response repeats, treat it as a configuration problem and escalate it. If its queue lifetime expires first, the sender returns a final NDR; after the receiving configuration is fixed, resend messages that have already failed permanently.
You can confirm the evidence and contact the recipient, but you cannot add their domain to their MX host. The recipient's mail admin or provider needs to fix that.
Check the bounce timestamp, cached DNS, forced routes, and the A/AAAA addresses behind the current MX targets. Let queued 4xx messages follow normal retries and compare the sending resolver's answers with the recipient's DNS change. An unfamiliar hostname alone is not proof of stale MX, because a gateway or server's SMTP identity can differ from its published MX name.
Not always. It means the specific MX path used for delivery rejected the domain. Another published MX host can still work, but inbound mail through the rejecting host is broken.
One published MX host can be missing the domain while another accepts it, or a split-delivery route can mishandle only certain recipients. Compare successful and failed attempts by remote hostname, IP address, recipient path, and timestamp.
