SMTP error 554 5.4.0: DNS or routing failure

554 5.4.0 combines a 5yz permanent failure with 4.4.0, RFC 3463's generic "other or

undefined network or routing status" code. It is the permanent counterpart to 451 4.4.4 (unable

to route, temporary): where 451 4.4.4 means a relay could not currently find a route and will

keep trying, 554 5.4.0 means the routing or DNS failure was severe or persistent enough that the

sending side's own queue, or an intermediate relay, gave up and converted it into a permanent

failure.

A real transcript

MAIL FROM:<you@yourdomain.com>
RCPT TO:<recipient@example.com>
554 5.4.0 Unable to route message, DNS lookup failed permanently

This is frequently generated locally by your own outbound queue after exhausting its retry window

on a persistent 451 4.4.x, rather than received directly from the recipient's server — the

non-delivery report (NDR) you receive may show your own MTA's hostname as the generating server,

not the recipient's.

Root causes behind SMTP Error 554 5.4.0

Network and routing disruptions

A path-level outage between your network and the recipient's that persisted through your entire

retry window without resolving.

DNS configuration errors

Missing, malformed, or permanently unresolvable MX records for the recipient domain — as opposed

to a transient DNS blip, this is a DNS configuration that will not fix itself.

Server configuration oversights

A smart-host or relay setting on your own side pointing at a permanently incorrect or

decommissioned address.

Diagnose it yourself

1. Run a full DNS check before touching anything else: dig MX recipientdomain.com +short,

then dig A <each-returned-host> +short — an empty or NXDOMAIN result at either step

confirms a genuine DNS failure rather than a transient resolver hiccup.

1. Check from more than one vantage point. A DNS failure that only reproduces from your own

network (not from a public resolver like 8.8.8.8 or 1.1.1.1) points at your local resolver

or network path, not the recipient's actual DNS configuration: `dig MX recipientdomain.com

@8.8.8.8 +short`.

1. Review your own queue's retry history for this recipient — if every attempt during the

retry window failed with the same routing condition, that confirms the failure was genuinely

persistent rather than a one-off that happened to coincide with your final retry.

1. Confirm your own outbound relay or smart-host configuration resolves correctly and points at

a currently valid address.

Solving SMTP Error 554 5.4.0

For Gmail

If you administer a Workspace domain and see this sending to another domain, confirm your own

outbound routing is not the broken half of the equation before concluding the recipient's DNS is

at fault.

For Outlook

Microsoft 365's own DNS and routing checks are generally reliable; a persistent 554 5.4.0 sending

to a Microsoft-hosted domain more often traces back to the recipient domain's own DNS delegation

being broken, not Microsoft's infrastructure.

For Yahoo

Yahoo-hosted domains with broken custom MX delegation (common after a provider migration) are a

frequent source of this specific permanent failure.

Still getting 554 5.4.0 after fixing DNS and SMTP settings?

If DNS checks out clean from multiple vantage points and the recipient's MX hosts are reachable,

the persistent failure may be happening at a relay in the middle of the path rather than at either

endpoint — checking a traceroute-style path analysis to the MX host's IP is the next step, which is

outside what SMTP-level diagnostics alone can show you: mtr -rw <mx-host-ip> (or traceroute if

mtr is unavailable) run from your own sending infrastructure will show exactly which hop in the

path is dropping or delaying packets, which a plain dig lookup cannot reveal since DNS resolving

cleanly only confirms the address exists, not that every hop along the route to it is actually

reachable.

What the retry behaviour actually looks like

Because this is almost always generated locally by your own queue after exhausting its 451 4.4.x

retry window rather than received fresh from the recipient, there is no further retry worth

attempting on the identical message — your own MTA has already made that decision after days of

trying. Re-queuing the same message manually just restarts the same retry cycle against the same

broken DNS or routing condition, and will reach the same 554 5.4.0 conclusion again unless the

underlying record has actually changed in the meantime.

What not to do

• Do not keep resending identically — this is a permanent 5xx; whatever caused the original

retry window to be exhausted will reproduce the same outcome on a fresh attempt unless the

underlying DNS or routing problem is actually fixed.

• Do not assume this reflects on your sending reputation or content — it is purely a network/DNS

condition, and content or authentication changes will not affect it.

• Do not edit your own SPF, DKIM, or DMARC records in response — none of those mechanisms

participate in routing or DNS resolution for the recipient's MX.

MailPilot's seed-inbox network delivers across multiple providers continuously, which surfaces a

genuinely broken recipient-domain DNS delegation as an isolated, persistent failure to that one

destination rather than something that looks like a drop in your own sending reputation.