SMTP Error 521

What is SMTP error 521?

SMTP 521 is a permanent (5xx) reply code that means "Host does not accept mail." It is a real, standardized code: it was first described in the experimental RFC 1846 (1995) and formally incorporated into SMTP by RFC 7504 (June 2015), which ended the RFC 1846 experiment.

Per RFC 7504, 521 is "reserved for use at connection-opening time to indicate that the host does not accept mail under any circumstances." In other words, the moment your client opens the TCP connection, the server answers with 521 instead of the usual 220 greeting:

S: 521 example.com does not accept mail
C: QUIT

RFC 7504's IANA update assigns 521 to enhanced status code X.3.2 ("host on which the mailbox is resident is not accepting messages") and assigns 556 to X.1.10. So a compliant 521 reply should be accompanied by 521 5.3.2 (or 4.3.2/2.3.2 per severity), not left bare.

521 vs 556

RFC 7504 actually standardizes two codes. The distinction matters:

• 521 is sent at connection-opening time by a host that itself never accepts mail (it replaces the 220 greeting).
• 556 ("Domain does not accept mail") is returned by an intermediate SMTP system (relay) during the dialog — for example after RCPT TO — when it can determine, without opening a connection to the final host, that the destination domain accepts no mail (such as via the DNS "null MX" convention, RFC 7505).

If you see a relay reporting that the final destination accepts no mail mid-session, the standards-compliant code for that is 556, not 521.

What causes SMTP error 521?

521 is almost always a statement about the recipient host's configuration, not about your message or your sender authentication. Common triggers:

• The destination host is a "dummy" SMTP server whose only job is to tell connecting clients it never accepts mail. RFC 7504 says 521 "SHOULD be used for dummy SMTP servers whose sole purpose is to notify systems that attempt to open mail connections that the host never accepts mail."
• You connected to a host that is not a mail server — for example, a web server, an A record without a matching mail service, or a host that has decommissioned its mail role.
• The target domain receives no mail — for instance via the DNS "null MX" convention (RFC 7505). In the relay-during-dialog case this is signaled with 556 rather than 521 (see above).

A server returning 521 may either send the reply and close the connection immediately, or stay open and answer 521 to every command except QUIT (RFC 1846 suggests a 5-minute timeout). Leaving the connection open helps clients treat the failure as permanent rather than retrying.

What 521 does NOT mean

This is the most important distinction. RFC 7504 is explicit: 521 "SHOULD NOT be used for situations in which the server rejects mail from particular hosts or addresses or in which mail for a particular destination host is not accepted." So if you receive 521, it is generally not:

• An SPF authentication failure — RFC 7208 explicitly recommends 550 5.7.1. A DKIM or DMARC failure is typically surfaced as 550/554 by provider convention, but RFC 6376 and RFC 7489 do not themselves mandate a specific reply code; the choice is left to the receiving MTA.
• A per-sender or per-IP block (blocklist/RBL) — those use 554 or 550 5.7.1.
• An unknown mailbox — that is 550 5.1.1.

If your bounce text says "521" but also references "blocked sender" or authentication, the sending platform may be mislabeling a 550/554 policy rejection. Read the full reply string, not just the number.

How do I fix SMTP error 521?

1. Confirm the recipient domain actually accepts mail. Look up its MX records: dig MX recipient-domain.com. If you see a single MX of . (a null MX per RFC 7505), the domain has declared it accepts no mail — there is nothing to fix on your end; the address is undeliverable by design.
2. Verify you are connecting to a real mail server, not a placeholder host. If you hardcoded a hostname or IP, re-resolve it via MX rather than A records, and confirm an SMTP service is listening on port 25 (server-to-server), or 587/465 for authenticated submission (RFC 8314).
3. Check whether an intermediate relay is reporting that the destination accepts no mail. Read the bounce/NDR header for the reporting MTA. Note that a relay signaling this mid-dialog should use 556; a literal 521 should come from the destination host itself at connection time.
4. Contact the recipient's mail administrator if you believe the domain should accept mail. Because 521 is a recipient-side configuration statement, only they can change it — resending or "fixing" your authentication will not help.
5. If you are receiving 521 on your own server unexpectedly, audit your MX/SMTP configuration: a misconfigured null MX, a firewall returning a banner, or a decommissioned mail role can cause your host to emit 521.