← Blog/Deliverability

SMTP error 521: host does not accept mail for this domain

October 15, 2026·6 min read·By MailPilot

521 is formally defined by RFC 7504 (published 2015, extending the base SMTP reply code set) as

"Server does not accept mail" — a permanent, deliberate declaration that the host you connected to

will never accept mail for the domain in question, as distinct from a temporary outage or

misconfiguration. It is closely related to 556 Domain does not accept mail, also defined in the

same RFC, which carries the identical meaning from the domain's perspective rather than the host's.

A real transcript

Connected to mx.example.com.
521 Host does not accept mail (see RFC 7504)

Note this can be returned without a full EHLO exchange ever completing — the server declares

this immediately on connection, since it has nothing further to negotiate.

How providers use 521 differently from a routine outage

ScenarioWhat you seeWhat it means
Domain genuinely has no mail service521 Host does not accept mail immediately on connectDeliberate — this domain was never meant to receive mail (common for parked or web-only domains)
Domain migrated mail providers521 from an old MX that is still technically resolvingStale DNS — the MX record itself needs updating, not a delivery retry
Temporary server outage (different condition)Connection refused or timeout, not 521A true outage does not return 521; it fails to connect at all

How does SMTP error 521 impact email delivery

Because 521 is a deliberate permanent declaration rather than a transient fault, there is no

retry window that will resolve it. If you are the sender, the correct response is to stop sending

to that specific host and re-check whether you have the right MX record at all. If you administer

the receiving domain and are seeing this unexpectedly, it almost always means a DNS record still

points at infrastructure that has been decommissioned or was never configured to receive mail.

Diagnose it yourself

  1. Re-check the domain's actual MX records: dig MX recipientdomain.com +short — if they point

at a host returning 521, the DNS is stale or was misconfigured to begin with.

  1. Check whether the domain has any mail service at all: a domain used only for a website, with

no mailboxes ever provisioned, legitimately returns 521 for every sender, forever.

  1. If you administer the domain, confirm your current mail provider's documented MX values

match what is actually published, and correct any leftover record pointing at decommissioned

infrastructure.

Resolving SMTP error 521: causes and solutions

Server unavailability (as a false assumption)

Do not treat 521 as "server unavailability" in the retry sense — it is an explicit, permanent

statement that the host does not provide mail service, not evidence that it is temporarily down.

Configuration issues

The most common real cause: an MX record pointing at a host that is not configured to accept mail,

often after a provider migration where only some records were updated.

Email server policies

Some domains run a web server or other service on infrastructure that also happens to run a

minimal SMTP listener returning 521 as a deliberate catch-all, to be explicit that the domain

does not use email at this host.

Check every MX record, not just the first one

A domain can publish several MX hosts with different priorities, and it is possible for only one of

them to return 521 while the others still accept mail correctly — this happens most often

mid-migration, when a provider has decommissioned one old host but not yet removed its MX record.

Run dig MX recipientdomain.com +short and test each returned host individually (`openssl s_client

-starttls smtp -connect <each-host>:25`) rather than stopping once the first one you try returns

521; a sending MTA will normally fall through to the next-priority MX automatically, so a single

stale record among several working ones may already be resolving itself without your noticing, or

may be worth cleaning up anyway to stop it from being tried first on every attempt.

What not to do

  • Do not retry delivery to a host returning 521 — it is explicitly permanent by RFC 7504's own

definition, and there is no backoff window that will change the outcome.

  • Do not confuse this with a generic connection timeout or refusal, which looks similar at a

glance but means something different (a real, possibly temporary, infrastructure problem) and

may be worth retrying.

  • Do not assume the domain is wrong just because this appears — double-check the MX record is

current before concluding the recipient's email address itself is invalid; the address may be

fine once the correct, current mail host is used.

MailPilot's inbox-placement checks route through the provider's actual current infrastructure for

every connected mailbox, so a stale or decommissioned MX showing 521 is something you would catch

immediately in delivery reporting rather than discovering through a silent accumulation of

permanent failures.

MailPilot

Ready to reach the inbox every time?

Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.

Start free trial
Reach the Inbox, Every Time
Connect unlimited inboxes for warmup. Free 7-day trial, no credit card.
Try for Free
WORKS WITH
OZOHO
inbox placement99.2%
free trial7-day
companies trust us340+

Start for free - no credit card required.

Get started freeBook a demo