RFC 7504 / START HERE
SMTP no-mail replies, before the details
SMTP means Simple Mail Transfer Protocol. This RFC defines two no-mail reply codes: 521 and 556.
A 521 opening reply says this host never accepts mail. A 556 reply comes from an intermediate relay that already knows a destination accepts no mail, without connecting to that target. A relay is a server that forwards mail onward.
The idea in one picture
Mail client
Relay checks domain
No-mail reply
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Without a clear no-mail answer, connection timeouts can waste resources on queues and retries. RFC 7504 standardizes the earlier 521 experiment and adds 556 to SMTP; it does not replace SMTP or the separate null MX DNS declaration.
A familiar example
A relay checks alice@example.org, finds that domain’s null MX declaration, and replies 556 to the upstream client. That rejects this recipient; it does not prove all other recipients failed or that the whole message was delivered. Neither code authenticates a server.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Say that this host never accepts mailSMTP means Simple Mail Transfer Protocol. Its client sends mail to a server. A dummy SMTP server can open a connection solely to say that this host never accepts mail.→
- Finish or continue after a 521 openingA 521 opening reply does not impose one mandatory immediate-close behavior. QUIT follows the normal SMTP rules; other commands have two permitted server responses.→
- Return 556 from a relay without connecting onwardA relay receives mail for onward delivery. If it can determine outside a target SMTP connection that a destination accepts no mail, it can report that fact upstream using 556.→
- Keep a permanent failure at the right scopeA permanent SMTP reply rejects the command it answers. A failed recipient is not proof that every other recipient failed, nor that a human can never correct the address.→
This introduction explains RFC 7504 (2015). Read the original RFC ↗