554 5.4.4 and 553 5.1.2: The Recipient's Domain Can't Be Found

Both 554 5.4.4 and Gmail's 553 5.1.2 mean the recipient's domain has no usable route for mail, so every address at that domain will fail. Check the spelling of the domain first. If it's spelled right and still has no mail records, the domain is dead or doesn't take mail: remove the address. Only when many ordinary domains fail at once is it your server's DNS.

Sources, read 3 November 2026: RFC 3463 (enhanced status codes), RFC 5321 section 5.1 (locating the target host), RFC 7505 (null MX) and Google's Gmail SMTP errors and codes.

What the codes say

Code	Text you'll see	Defined as
554 5.4.4	"SMTPSEND.DNS.NonExistentDomain; nonexistent domain" (Exchange), or "unable to route"	RFC 3463 X.4.4 "Unable to route": the next hop couldn't be found because routing information wasn't available. A DNS lookup that returns only an SOA record is its example
553 5.1.2	"We weren't able to find the recipient domain." (Gmail)	RFC 3463 X.1.2 "Bad destination system address": the destination "does not exist or is incapable of accepting mail"

Our code pages have the cross-provider detail: 554 5.4.4 and 553 5.1.2.

How mail finds a domain

RFC 5321 has the sender look up the domain's MX records. If there are none, it falls back to the domain's own address record (the "implicit MX"). If MX records exist but none is usable, or there's no record at all, the RFC says the situation must be reported as an error. That error is what you're reading.

RFC 7505 adds the null MX: a single MX record pointing at "." means "this domain accepts no mail". Senders that honour it fail the address immediately. See what a null MX record is.

The usual causes

1. A typo in the domain. gmial.com, outlok.com, a company name missing a letter. Common on hand-typed forms and event sign-ins.
2. The domain expired or was never registered. Old B2B lists collect these as companies close or rebrand.
3. The domain resolves but takes no mail. It has a website and nothing else, or a null MX.
4. The recipient's DNS is broken. Their name servers are down or misconfigured. Rare, and it usually shows as a temporary 4.4.x first.
5. Your own DNS. If your server's resolver fails, every domain looks nonexistent. The tell: big, obviously real domains failing together.

What to do

1. Read the domain in the bounce. If it's a typo with an obvious fix, correct it only where you can confirm the right address (a customer record, a reply); don't guess silently. The email typo corrector flags the common ones.
2. Look up the domain's mail records. Check if a domain accepts email walks through it; no MX and no A record means remove.
3. Suppress the address and move on. One 5.4.4 is enough for a domain that doesn't exist.
4. If the failures are widespread, test your server's DNS resolution before touching the list.
5. Clean the rest of the list for the same problem before the next send (below).

Find them before sending

You don't need to bounce to find dead domains. Extract the domains from your list, look up their MX records in bulk, and drop the ones with no route: the bulk DNS lookup does the lookups in your browser. Watch for domains that are about to lapse too; what happens when you email an invalid address covers why these count as hard bounces.

Limits

A domain that resolves today can lapse next month, so DNS checks age. And a domain with working MX records tells you nothing about the mailbox: the address can still bounce with 550 5.1.1 user unknown.

Where SimpleVerifier fits

Verification checks the domain's mail route first, so addresses at nonexistent domains come back invalid without anything being sent, and the rest get a mailbox check. Upload the list at /verify; the first 100 checks are free with a Google sign-in. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. See pricing.