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
| Scenario | What you see | What it means |
|---|---|---|
| Domain genuinely has no mail service | 521 Host does not accept mail immediately on connect | Deliberate — this domain was never meant to receive mail (common for parked or web-only domains) |
| Domain migrated mail providers | 521 from an old MX that is still technically resolving | Stale DNS — the MX record itself needs updating, not a delivery retry |
| Temporary server outage (different condition) | Connection refused or timeout, not 521 | A 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
- 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.
- 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.
- 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.
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