What the bounce says
Exact wording as it appears in the rejection or NDR. Placeholders such as x.x.x.x and example.com stand for your own address and domain.
550 5.4.310 DNS domain does not exist 550 5.4.310 DNS domain example.com does not exist [Message=InfoDomainNonexistent]
Exchange Online tried to find where to deliver and DNS said the recipient domain does not exist. There is no server to contact, so the message cannot be delivered regardless of anything on the sending side.
Most common causes
- The recipient domain is misspelled
- The domain expired or its DNS zone was removed
- The nameservers for the domain are unreachable or misconfigured
- A recent DNS migration left the zone without records
What to verify next
- Confirm the exact recipient domain from the NDR
- Look up MX, A and AAAA for the domain from an external resolver
- Check the domain’s registration and nameserver delegation
- Retry once DNS resolves; Exchange retries automatically for a period
What Exchange looked for
Delivery starts with an MX lookup for the recipient domain. If there is no MX, Exchange falls back to A and AAAA records. When all three return nothing — or the domain itself returns NXDOMAIN — this code is generated. It is not a temporary lookup failure; that produces a different code.
The domain in the NDR is the one to check, exactly as written. A single-character typo in the domain part is the most common cause, followed by domains that lapsed or moved DNS providers without recreating their zone.
- NXDOMAIN or no MX/A/AAAA for the recipient domain.
- Check the domain exactly as the NDR shows it.
- Typos and expired registrations dominate.
Verify from outside your network
Query MX and A for the domain with a public resolver. If they resolve for you but not for Microsoft, the domain’s nameservers may be answering inconsistently or one of them is down. The propagation checker shows how several resolvers see it.
If nothing resolves anywhere, the domain owner needs to fix registration or DNS; the sender can only wait or confirm the address with the recipient another way.
When it is your own domain
If you are the recipient and mail to your domain suddenly fails with this code, check the registrar first — expiry and nameserver changes are the usual causes — then confirm the zone at the DNS provider actually contains MX records.
After restoring DNS, allow the TTL to elapse before expecting senders to succeed; some will have cached the negative answer.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- Negative DNS answers are cached; a fix is not visible everywhere immediately.
- The sender cannot repair the recipient’s DNS.
Common questions
The domain works in a browser.
A website only needs an A record. Mail needs MX (or falls back to A). Check MX specifically, and check the exact domain in the NDR.
Will Exchange retry?
It retries for a period before generating this NDR. Once generated, the message is not retried; resend after DNS is fixed.
Is this the same as 5.4.4?
5.4.4 is a routing problem inside the organization. 5.4.310 is an external domain that does not exist in public DNS.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Microsoft Exchange Online NDR reference.