Domain not found is what your mail server tells you when the recipient's domain does not exist in DNS.

Definition

Domain not found is the bounce you get when a sending mail server looked up the domain to the right of the @ sign in DNS and got no usable answer back.

The address may be spelled wrong, the domain may never have been registered, the registration may have lapsed, or the name may exist in DNS with nothing that tells other servers where mail should go. In each of those cases the message stops before the recipient's mail server ever sees it.

RFC 5321, the SMTP standard, is direct about it. A sending server must look the recipient domain up in DNS, and if the lookup returns a non-existent domain error, that situation must be reported as an error rather than queued and retried.

What a domain not found bounce actually says

The wording changes from provider to provider, but the shape is the same: a status code, an enhanced status code with three numbers, and a diagnostic line quoting the server that refused. The example below was written for this page from the field names in RFC 3464, the delivery status notification standard.

Final-Recipient: rfc822; anna@{{domain}}
Action: failed
Status: 5.1.2
Diagnostic-Code: smtp; 553 5.1.2 recipient domain not found

Final-Recipient: rfc822; anna@{{domain}}
Action: delayed
Status: 4.4.3
Diagnostic-Code: smtp; 451 4.4.3 temporary DNS failure, will retry
Will-Retry-Until: {{date}}

RFC 3464 defines the two Action values that matter here. Failed means the reporting server has abandoned any attempt to deliver to that recipient, and no further notices should be expected. Delayed means it has not delivered yet but will keep trying, and it may send more notices later.

The optional Will-Retry-Until field, allowed only on delayed notices, gives the date after which the server expects to give up. Read three things before you act: the first digit of the status, the three-part status, and the diagnostic line, which quotes the server that refused and is not always the recipient's server.

The email error domain not found, code by code

People searching for the email error domain not found are usually holding a bounce with a number on it. The numbers come from two standards, and they answer different questions about the same failure.

RFC 5321 defines the three-digit reply. A reply in the 4yz range means the error condition is temporary and the client should try again. A reply in the 5yz range means the client should not repeat the exact request, although a human can correct the spelling and start over.

RFC 3463 defines the three-part enhanced code. Its first number carries the same split: 4.x.x is a persistent transient failure where sending later may succeed, and 5.x.x is a permanent failure that will not be fixed by resending the message in its current form.

RFC 5248 set up the IANA registry for these enhanced codes, so new codes such as the null MX statuses are registered there rather than invented by each vendor. The registry also lists which three-digit replies a code usually travels with, and for X.1.2 that column says not given.

RFC 5321 defines the two reply codes you are likely to see. 550 is requested action not taken, mailbox unavailable. 553 is requested action not taken, mailbox name not allowed. Either can arrive with a domain not found line, so the enhanced code and the text tell you more than the reply code does.

How Gmail, Microsoft and Yahoo word it

The big mailbox providers publish their own error references, and they do not all use the codes the same way. Read the provider's text next to the number, because the same number can mean different things in different systems.

Gmail and Google Workspace

Google's SMTP error reference lists 553 with status 5.1.2 and text saying Google was not able to find the recipient domain. It asks the sender to check for spelling errors and for spaces, periods or other punctuation typed after the recipient's address.

The same reference lists 550 5.1.1 for an email account that does not exist, which is the address not found case. It also uses 550 5.7.27 for a message blocked because it did not pass SPF authentication, which is not the null MX meaning RFC 7505 gives that code.

Microsoft Exchange Online

Microsoft's troubleshooting article for 550 5.1.1 through 550 5.1.20 says those errors generally indicate that the recipient cannot be found or that message routing information is invalid. It names recipient domain configuration issues among the causes and points admins at domain configuration, MX records and service health.

Microsoft's own table gives some codes meanings of its own. In Exchange Online, 5.1.10 is recipient not found and 5.1.8 is an account blocked for sending spam, while 5.4.1 relay access denied is described as caused by mail server or DNS misconfiguration. A 5.4.14 is a routing loop, not a DNS lookup failure.

Yahoo

Yahoo's sender error reference covers the mirror case: an unresolvable RFC 5321 or RFC 5322 from domain, meaning the domain in your MAIL FROM or From header does not appear to be valid. Yahoo returns it as either a 451 temporary failure or a 554 permanent failure.

Yahoo says it decides whether the domain exists with an SOA query. If you send from several subdomains, it says SOA records must be set up for them as well as an A or MX record, so a working mail record alone does not guarantee that Yahoo sees the domain as real.

What your mail server did before it gave up

RFC 5321 sets out the order. The sending server first asks DNS for the MX records of the recipient domain. If it finds a CNAME, it processes the new name as if it were the original. If it gets a non-existent domain error, that must be reported as an error.

If the answer is a temporary error instead, the standard says the opposite: the message must be queued and retried later. That is why one bounce says failed and another says delayed, from the same address on the same day.

If DNS returns an empty list of MX records, the address is treated as though it had an implicit MX record with preference 0 pointing at the host itself. A domain with an address record and no MX record can still receive mail, so a missing MX record alone does not always cause this bounce.

Each MX record must name a host that returns at least one address record, such as A or AAAA. RFC 2181 adds that the MX target must not be an alias, a CNAME. If MX records exist but none of them can be used, RFC 5321 says the situation must be reported as an error.

DNS and MX lookup failure, in plain terms

A DNS and MX lookup failure is not one event. It is a chain of lookups, and the bounce text rarely tells you which link broke. Walking the chain in order is the fastest way to stop guessing about DNS issues.

• The name itself: does the domain exist in DNS at all, or does the answer say there is no such name?
• The delegation: is the domain pointed at name servers, and do those name servers actually answer for the zone?
• The mail records: does the zone publish MX records, and is there an A or AAAA record to fall back on if it does not?
• The MX targets: does each host name in an MX record resolve to an address, as RFC 5321 requires, without passing through an alias?
• The signatures: if the zone is signed with DNSSEC, do the signatures validate, or does a validating resolver refuse the answer?
• Your own resolvers: can the sending server reach a DNS server at all, which RFC 3463 treats as a directory server failure?

The first links produce a permanent answer. The last one produces a temporary answer that your server should retry. Treating all of them as dead addresses is how good contacts get suppressed by mistake, and how a sending infrastructure problem gets blamed on the list.

NXDOMAIN, NODATA and SERVFAIL: three different DNS answers

DNS answers carry a response code. RFC 1035 defines code 3 as Name Error, and says it is meaningful only in a response from an authoritative name server, where it signifies that the domain name referenced in the query does not exist. RFC 2308 calls that answer NXDOMAIN.

The same table defines code 2 as Server failure, meaning the name server was unable to process the query because of a problem with the name server. That is SERVFAIL, and it says nothing at all about whether the domain exists.

RFC 2308 adds a third case it calls NODATA: the response code is NOERROR, but there are no relevant answers in the answer section. The name exists. The record type you asked for does not, and the authority section usually carries the zone's SOA record instead.

That last column matters more than it looks. A negative answer for a name that does not exist can sit in a resolver cache for as long as the zone says, so a domain that was fixed an hour ago can still bounce for you while it works for someone else.

RFC 2308 also advises resolvers to cap how long they keep negative answers. It says values of one to three hours have been found to work well as a default, and values over one day have been found to be problematic. Your resolver's actual cap is its own setting.

DNSSEC adds one more route to SERVFAIL. RFC 4035 says that when no signature on a response can be validated, a validating recursive server must return response code 2 to the client that asked. A broken signature can therefore look like a server failure rather than a missing domain.

The cases behind the error, separated

Sales teams lose time when they treat one message as one problem. It is at least six, and the right move is different in each.

There is a seventh case that is not an error at all. RFC 7505 lets a domain publish a null MX, a single MX record with preference 0 and a single dot as the target, to say that it accepts no email. A domain doing that must publish no other MX record.

The point of a null MX is speed. RFC 7505 explains that a domain with no MX record and no mail listener at its address records can leave senders retrying for a long period, typically a week. With a null MX the failure shows up on the first attempt, with reply 556 and status 5.1.10.

Typos in the domain

Check spelling first, before you open a terminal. Microsoft's 5.1.x article says the wrong email address is the most common issue behind those errors, and Google's guidance for this error asks the sender to look for spelling mistakes and stray punctuation after the address.

• Transposed letters: gmial.com, hotmial.com, outlok.com. A hand-typed address from a business card or a call.
• Wrong top level domain: .co instead of .com, .con instead of .com, or a country domain the company does not use.
• A host name instead of the domain: an address at www.example.com when mail is served at example.com.
• Trailing characters: a period, a comma or a space pasted in with the address from a spreadsheet.
• A guessed pattern: a first name and last name rule applied to a domain the company never used for mail.

RFC 7505 names this class directly when it explains why null MX exists: mail often has an incorrect address because it was mistranscribed or misunderstood, and its examples are a www host name, the wrong top level domain and a lookalike spelling with a digit in place of a letter.

Expired domains and domains that were never set up

A domain that lapses stops resolving, and every address on it stops working at once. For a prospect list, an expired domain is a signal about the company, not about the address format. Something changed, and your record is older than the change.

The same answer comes back from a domain that was bought and never finished. The registration exists at the registrar, but no name servers were set, or the name servers do not carry the zone. To a sending server, both look like a name that is not there.

Either way, no amount of retrying helps, and the fix is not yours to make. What you can do is ask what the domain change means for the account before you delete the contact. A rebrand can mean the same people at a different domain.

Hard bounce or soft bounce?

Many sending tools sort email bounces into hard and soft. Those labels are vendor vocabulary, not standard terms, but they map onto the standards well enough: a 5.x.x domain not found is a hard bounce, and a 4.x.x DNS failure is a soft bounce that may still turn into a delivery.

The useful question is not which bucket the tool chose but which DNS answer sits underneath. A hard bounce from NXDOMAIN invalidates every address at that domain. A soft bounce from SERVFAIL invalidates nothing yet, and suppressing on it throws away addresses that may be valid.

A domain not found is also different from a catch-all email domain. A catch-all domain resolves and accepts mail for any mailbox, so it never produces this bounce, while a domain not found never gets as far as a mailbox check. That is why a DNS test comes first on this page.

Temporary DNS failure versus permanent

This is the distinction worth building into your process, because it decides whether a contact is dead or just unlucky for an hour.

RFC 5321 sets the retry rhythm. After a failed attempt the sender must wait, the retry interval should be at least 30 minutes, and the give-up time generally needs to be at least 4 to 5 days. A delayed notice is not a bounce, and a queued contact is not yet lost.

Providers set their own windows inside that guidance. Microsoft says Exchange Online keeps trying to deliver for 24 hours and sends a 4.4.7 report only after that, naming a missing or incorrect MX record at the destination as one cause.

The first digit is not proof on its own. Postfix, an open source mail server, documents restrictions that refuse a sender or recipient domain with no MX and no A record, and its default reply code for them is 450, a temporary code. Run your own DNS test before you trust either digit.

One practical rule follows. Do not suppress on a 4.x.x notice. Wait for the final report, which will either be a delivery or a permanent failure at the end of that window.

How to test it with nslookup or dig

Two commands settle the argument quickly. nslookup ships with Windows, and dig is part of the BIND 9 tools from ISC. Both let you name a second DNS server, which is the step that separates a dead domain from a cached or local failure.

nslookup -type=MX {{domain}}

nslookup -type=NS {{domain}}

nslookup -type=MX {{domain}} {{secondResolver}}

dig {{domain}} MX +short

dig @{{secondResolver}} {{domain}} MX

Reading the answer

Microsoft's nslookup reference lists the messages the tool prints when a lookup fails, and two of them map straight onto this bounce. Nonexistent domain means the computer or DNS domain name does not exist. Server failure means the name server found an internal inconsistency and could not return a valid answer.

A third message, No records, means the name is valid but the name server has no records of the type you asked for. That is the NODATA case: the domain is alive, and it simply publishes no MX record.

In noninteractive mode, the first parameter is the name you want to look up and the second is the DNS server to ask. Leave the second out and nslookup uses your default server, which is exactly the resolver you want to step around when you verify a failure.

The dig manual notes a detail that matters in scripts: dig exits with return code 0 when it received a DNS response, including an NXDOMAIN status. A script has to check the response itself, not the exit code, to find dead domains.

The order to run them in

1. Query MX first

   If MX records come back, the domain exists and publishes mail routing. Your bounce is about something further down the chain.

2. Query NS if MX fails

   No name server records, or a nonexistent domain answer here, means the problem is the registration or the delegation, not the mail setup.

3. Resolve each MX target

   Look up the host name from each MX record and confirm it returns an address record. RFC 5321 requires one.

4. Repeat against a second resolver

   Run the same query against a different DNS server. A different answer points at a cached negative answer or a local failure rather than a dead domain.

5. Write the answer on the record

   Note what you found next to the contact, with the date. The next person to look does not have to repeat the work.

Domain not found versus address not found

These two bounces look alike in an inbox and mean very different things for an account. RFC 3463 splits them cleanly by which side of the @ sign failed.

The blast radius row is the one to act on. A 5.1.1 costs you one contact. A 5.1.2 costs you the account, and every other contact you hold at that domain is going to fail the same way on the next send.

Domain not found next to the other DNS errors in email

Sending tools often flatten several different DNS errors into one label, hard bounce. The label is fine for suppression and useless for diagnosis, because each of these errors breaks at a different point in the lookup and each needs a different test.

Two habits fix most of the confusion. Verify the domain with a lookup before you act on the label, and store the enhanced status code with the contact so a later cleanup can tell these errors apart without repeating the work.

When the domain not found is yours, not theirs

Read the diagnostic line before you blame the prospect. RFC 3463 defines a separate status, 5.1.8, for a bad sender's system address: the sender's system does not exist or cannot accept return mail. That is your domain failing, not the recipient's.

This can show up on a fresh sending domain. The domain was registered for outreach, the sending tool was connected, and nobody published the DNS records that let a receiver confirm the domain exists or send a reply back to it.

Receivers check this in different ways. Yahoo says it tests the From and MAIL FROM domains with an SOA query. Postfix documents a sender domain check that rejects a MAIL FROM domain with no MX and no A record. Microsoft's 4.4.7 article tells admins to confirm their own domain has not expired for non-payment.

RFC 7505 warns about the sharper version of the same mistake. A mail system should not publish a null MX for a domain it uses in the envelope sender or the From address, because a domain that does so risks having its mail rejected. The suggested rejection is reply 550 with status 5.7.27.

Fixing it on your own domain

If the failing domain is one you control, the work is DNS work, and it is short. The order below follows the chain a sending server walks, one step at a time.

• Confirm the registration: the domain has to be current and not suspended. Nothing below this line matters if it is not.
• Point it at name servers: set the delegation at the registrar to the name servers that actually host your zone.
• Publish MX records: add the records your mail provider gives you, with the priority values it specifies.
• Check each MX target resolves: every host name in an MX record must return an A or AAAA record and must not be a CNAME, which are requirements in RFC 5321 and RFC 2181.
• Remove any null MX: a single MX record with a dot as its target means the domain accepts no mail, and it must not sit alongside real records.
• Cover your sending subdomains: if you send from a subdomain, make sure it resolves too, including the SOA answer Yahoo says it checks.
• Wait for caches, then retest: a negative answer already in a resolver cache lives as long as the zone's SOA settings allow.

Microsoft's own note says updates to a domain's DNS records can take up to 72 hours to reach all DNS servers on the internet. Test from more than one resolver before you decide a fix failed.

The same list is the checklist for a new outreach domain before anything is sent from it. A domain that cannot receive mail cannot receive replies, and a reply is the entire point. Pair it with a proper email warm up before the first sequence.

What a domain not found bounce means for list quality

At the contact level, this bounce is a data quality verdict. At the domain level it is a verdict on the source, because a domain that does not resolve was often wrong on the day it was added, or has aged out since.

• Group the failures by domain, not by address. One dead domain can produce a bounce for every contact you hold there, all with a single cause.
• Trace it back to the source. If one provider or one scrape supplies most of your dead domains, that is a supplier problem. Compare it against your other B2B data sources.
• Separate pattern guessing from verified addresses. Guessed addresses on a wrong domain fail this way, and they are cheap to identify.
• Check the company before you delete it. A dead domain can mean a rebrand or an acquisition, and the account may still be worth something under a new name.
• Keep the reason on the record. Storing the status code with the contact means the next campaign does not repeat the send.

This is the core of email hygiene: remove invalid addresses on a schedule instead of waiting for bounces to do it. Enrichment helps only if it is re-run, which is the argument for periodic lead enrichment rather than one import that ages quietly.

Handling the bounce in your CRM and sequencer

Many sending tools classify bounces for you and collapse this case into one bucket called hard bounce. That is often right and occasionally expensive, so give the process one manual step.

1. Suppress the address immediately

   A permanent failure should stop the sequence for that contact on the same day, not at the end of the cadence.

2. Pause the whole domain

   Hold every other contact at the same domain before the next send. They share the cause, so they will share the result.

3. Verify the domain once, by hand

   Run the lookups above. It tells you whether to suppress the account or only the address.

4. Record the code, not just the word bounce

   Store the enhanced status, so a later cleanup can tell a dead domain from a dead mailbox.

5. Fix the source, then re-import

   If the domain was a typo, correct it at the source list as well as in the tool, or the next import brings it back.

Where this sits in the wider workflow is covered in outbound sales automation. The rule to automate is simple: a 5.x.x domain status suppresses the domain, and a 4.x.x status waits.

Preventing it before the next send

• Validate the domain at import. A lookup on the domain of every new row catches dead domains before a single message is queued.
• Normalize the address first. Trim spaces, strip trailing punctuation and lowercase the domain, which removes the punctuation errors Google's guidance warns about.
• Flag lookalike domains. Addresses one character away from a known provider domain are worth a second look before they go out.
• Re-check domains before a large send. A list built months ago has aged, and a big send is the worst place to discover it.
• Know which addresses are on free providers. A free email domain is a working domain, so a domain failure on what looks like one points at a mistyped spelling.
• Build the list from sources you can re-verify. The method matters more than the volume, which is the argument in how to make a prospect list.
• Watch your own bounce trend. Repeated sends to dead domains are one of the avoidable problems covered in email deliverability.

Mistakes when handling this bounce

• Suppressing on a 4.x.x delay notice. The standard expects retries for days, and the message may still be delivered.
• Reading the code as proof of the cause. A 5.4.4 says the route could not be determined, not that the domain is gone.
• Reading a vendor code with the RFC meaning. Exchange Online's 5.1.10 and Gmail's 5.7.27 do not mean what RFC 7505 says.
• Fixing one contact and leaving the others at the same dead domain in the sequence.
• Assuming the recipient is at fault when the diagnostic line points at 5.1.8 and your own sending domain.
• Re-testing from the same resolver that gave you the failure and trusting a cached negative answer.
• Trusting dig's exit code in a script. It returns 0 on an NXDOMAIN response.
• Deleting the account record with the address. The domain changed, and the company did not necessarily disappear with it.
• Blaming reputation or content for a recipient DNS answer. A recipient domain not found happens before the recipient's server sees the message.

In a sequence

When a domain really is gone and you still want the person, the message has to travel on another channel. The note below is short, says what happened without accusing anyone, and asks one question. It fits any cold email program as a manual step.

Hi {{firstName}},

I wrote to you at {{oldAddress}} and it came straight back: the domain does not resolve, so nothing reached your inbox.

The note was about {{topic}}.

If that is still your area, what address should I use? If it moved to someone else, who is that now?

{{senderName}}

Frequently asked questions