Reject an undeliverable recipient promptly
03A submission or relay server can detect null MX while processing a recipient and report permanent failure without a target connection.
The relay rejects that recipient. The recommended pair is 556 5.1.10; the message is not queued for repeated delivery attempts to this no-service domain.
Source for this drawing: RFC 7505 · Read RFC section 4.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
- RCPT TO
- The SMTP command specifying an envelope recipient.
- Relay
- An SMTP system that handles mail for onward delivery.
- Enhanced status
- A dotted status code giving a more specific reason than the basic reply.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The relay can reject the recipient before dialing the destination.
- Null MX allows delivery failure to be reported on the first attempt, avoiding pointless queuing and retries for that no-service destination.
- When a submission or SMTP relay server rejects an envelope recipient because the destination domain has null MX, it SHOULD use reply 556 and enhanced status 5.1.10.
- 556 means the domain does not accept mail; 5.1.10 identifies recipient-address null MX. This is different from rejection because a sender address has null MX.
The example RCPT command is sent to a submission/relay server, not to a nonexistent mail server at nomail.example. Supporting RFC7504§4 explains 556 as a permanent negative completion. The wording is SHOULD for the code choice, not an invented MUST that every implementation emits identical text. This error does not prove that a mailbox’s local-part is misspelled.
Read the RFC section ↗