Return 556 from a relay without connecting onward
03A 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.
The relay sends 556 5.1.10 Domain does not accept mail upstream. This example follows the companion RFC’s SHOULD; it is a permanent negative completion of this RCPT, not a DNS reply or onward delivery.
Source for this drawing: RFC 7504 · Read RFC section 4 ↗
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.
Adds 556 for externally determined destination no-mail status. RFC 7505 supplies the null MX declaration and recommends enhanced status 5.1.10 for that cause.
Read the updated RFC section ↗556 is returned by the intermediate SMTP system to its upstream client, not by the DNS server and not as a greeting from the uncontacted target.
- 556 is returned by the intermediate SMTP system to its upstream client, not by the DNS server and not as a greeting from the uncontacted target.
- In this example an established session and MAIL command have already succeeded. RCPT TO supplies a recipient domain, and a DNS lookup finds its single null MX record: preference 0, exchange dot. A null MX domain MUST NOT advertise any other MX (RFC 7505 §3).
- The relay learns the no-mail condition without opening a connection to the target. Null MX is one method; RFC 7504 does not make it the only possible source of that information.
- RFC 7505 §4.1 says a submission or relay server rejecting an envelope recipient due to null MX SHOULD use 556 and enhanced status 5.1.10. The three-digit and enhanced codes are different fields.
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 ↗