Keep a permanent failure at the right scope
04A 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.
Separate later human-directed attempt changes the recipient to alice@example.com. The earlier permanent result did not prove this different address invalid; the new command’s result is still pending.
Source for this drawing: RFC 7504 · Read RFC source: §4; failure classes: RFC 5321 §4.2.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Handle 556 like any other permanent negative completion for that command: the command was not accepted and its requested action did not occur.
- Handle 556 like any other permanent negative completion for that command: the command was not accepted and its requested action did not occur.
- Under RFC 5321 §4.2.1, a client SHOULD NOT repeat the exact request in the same sequence after 5yz. Human-directed correction later is distinct from automatic retry of the same failed request.
- Other recipient commands can have different results. The illustrative second RCPT receives 250, but that is recipient acceptance for this transaction, not proof of final message delivery.
- A 4yz reply is temporary and the client SHOULD try again under SMTP retry rules. A temporary DNS failure is not evidence for 556; RFC 5321 §5.1 instead requires queuing and later retry.
- 521 concerns a host, not necessarily every MX host for a domain. 556 concerns the known no-mail destination. Neither reply authenticates a peer or secures DNS; ordinary DNS/DNSSEC protections remain separate.
Fictional example.com and example.org names. Separate comparisons reset the scene; chosen reply text and timings are not protocol defaults. This is an educational model, not an SMTP implementation.
Read the RFC section ↗