SMTP error 553 5.1.2: bad destination system address

SMTP error 553 5.1.2 is a permanent rejection meaning the recipient's mail system, not

their specific mailbox, could not be found. The enhanced code 5.1.2 is RFC 3463's "bad

destination system address" - distinct from 5.1.1 (the mailbox name is bad, but the domain

resolves fine) and 5.1.3 (the address string itself is malformed syntax, covered separately).

Here, the domain's DNS does not lead anywhere a message could be delivered.

Fault: recipient's domain, from the sending side's perspective - though in practice this is

very frequently a typo in the recipient's domain name on the sender's side, since a genuinely

dead domain is rare compared to a mistyped one.

Why it happens

• A typo in the recipient's domain - test@mailpilotz.in instead of test@mailpilots.in -

resolving to a domain with no mail infrastructure at all, or no domain at all.

• **The recipient's domain has no MX record and no fallback A/AAAA record usable for

mail**, meaning there is genuinely nowhere to deliver to even though the domain itself might

resolve for web traffic.

• The domain's DNS has lapsed - an expired registration, a zone transfer gone wrong, or a DNS

provider outage that has left the domain's mail records unresolvable.

• A relay or forwarding system is rejecting on behalf of the real destination because *it*

cannot resolve the next hop, surfacing the failure as though the ultimate destination system

itself does not exist.

• A DNSSEC validation failure on the resolver the relay uses, where a domain's records exist

but fail cryptographic validation due to a misconfigured signing chain, causing a

security-conscious relay to treat the lookup as having failed entirely rather than returning a

potentially tampered answer.

The transcript

$ swaks --to test@mailpilotz.in --server (next-hop-relay)
-> RCPT TO:<test@mailpilotz.in>
<- 553 5.1.2 <test@mailpilotz.in>: Recipient address rejected: Bad destination
    system address

How the big three word it

Diagnose it

$ dig +short MX mailpilotz.in
$ dig +short A mailpilotz.in

Both commands returning nothing confirms the domain has no mail destination at all - this is the

fastest possible confirmation of this exact failure mode, and takes seconds.

$ whois mailpilotz.in | grep -i "no match\|not found"
No match for domain "mailpilotz.in"

If the domain does not exist in the registry at all, the cause is confirmed beyond any doubt -

this was never a reachable destination.

The fix, in order

1. Re-verify the recipient's domain for a typo before anything else - this is overwhelmingly

the most common real-world cause.

1. Confirm with `dig` whether the domain has any `MX` or fallback `A` record for mail.
2. Contact the recipient through a different channel (phone, a different known-good email

address, a shared contact) to confirm the correct domain if you are unsure which was intended.

1. If the domain legitimately has no mail infrastructure yet (a newly registered domain

still being configured), wait until the owner confirms DNS is live before retrying.

1. Remove the address from active sending lists once confirmed - unlike a transient mailbox

issue, an unresolvable domain will not start working again without action on the recipient's

side that you cannot control.

What not to do

• Do not retry this on a schedule. It is a permanent 5xx; the domain will not start

resolving simply because time passed, unless someone actively fixes its DNS.

• Do not confuse this with a mailbox-specific problem. The failure is at the domain level -

every address at that domain will fail identically, which is itself a useful diagnostic signal.

• Do not assume your own DNS or sending configuration is at fault. This error is entirely

about the *recipient's* domain resolution, not yours.

• **Do not keep this address in a list that affects your sending reputation metrics without

suppressing it.** An unresolvable domain inflates your bounce rate for no corrective reason if

left active.

MailPilot validates recipient-domain resolvability as part of its deliverability checks, which

catches a typo'd or genuinely dead destination domain before it accumulates as a repeated,

permanent bounce against your sending reputation.