SMTP Recipient Rejection: Should You Check the Domain or the Mailbox?

When a delivery log shows a rejection beside a recipient address, it is easy to assume that the individual mailbox is the problem. But an SMTP 556 recipient rejection, especially when it follows the RCPT command, can indicate information about whether the host reached through the recipient domain accepts mail connections rather than about one user mailbox. Making this distinction helps avoid investigating the wrong layer. SMTP is the email transfer protocol in which sending and receiving systems exchange commands and replies. RCPT is the command that contains the recipient address to which a message is being directed. This article focuses only on interpreting a 556 reply after RCPT and on why it should not be confused with a 521 reply.

At a glance

• A 556 reply after RCPT can be associated with information that mail will not be accepted at the target.
• The first investigation should concern the recipient domain and target mail acceptance, before individual mailboxes.
• A 556 is handled as a permanent negative completion reply to the command.
• A 521 is for connection opening and is not designed to assess a specific recipient after RCPT.

First, check which command received the reply

In an SMTP error log, examine not only the code but also the command to which that code was returned. For this issue, the important sequence is a 556 reply following the RCPT command that contains the recipient address. RFC 7504 explains that after a command such as RCPT, which contains a forward-pointing address, a server can return 556 because it has information that the mail will not be accepted.

Therefore, when you see 556, the first question does not have to be “Does this mailbox exist?” A narrower, source-aligned first question is: does the target host reached by the recipient address accept mail connections? Moving the investigation to the recipient domain and target mail acceptance is more appropriate to this reply context.

• Find the RCPT command in the log.
• Confirm that the 556 reply immediately follows that command.
• Start with the recipient domain and target mail acceptance.
• Do not treat this reply alone as proof about an individual mailbox.

Source: [2]

Why can 556 point to the domain or target host level?

RFC 7504 describes an intermediate SMTP system, typically a relay, that would normally try to open a mail connection to the host named in a forward-pointing address. If that intermediate system can determine, without opening a connection, that the host does not accept mail connections, it is appropriate for it to return 556.

The key distinction is that this description is not an assessment of one user’s mailbox. It concerns an intermediate system determining that the target host does not accept mail connections before it opens a connection. The recipient address in the log therefore does not require you to reduce the investigation to that user account alone.

Example scenario: a sending system issues RCPT [email protected] and then receives 556. Under the defined use of 556, the first check in this example is whether the target reached for example.com accepts mail connections. The reply does not by itself show that the mailbox named person was deleted or is full.

• Keep the RCPT context with the 556 reply.
• Assess the possibility that the target host does not accept mail connections first.
• Do not interpret the recipient address independently of the domain and target host information.

Source: [2]

How should a sending system treat a 556 reply?

According to RFC 7504, a client is expected to handle a 556 reply received after RCPT like any other permanent negative completion reply to that command. A permanent negative completion reply is a reply class indicating that the relevant command did not complete successfully.

This means the rejection should be treated as a negative result for the command, rather than assumed to be a temporary interruption. However, this standard definition does not itself say that one particular mailbox caused the failure. Read the command sequence together with the target mail acceptance context for which 556 is defined.

• Record 556 as a permanent negative result for the RCPT command.
• Keep the reply code and command sequence together.
• Draw only the conclusion supported by the source: target mail acceptance should be investigated.

Source: [2]

Why DNS becomes relevant in this context

At the time RFC 7504 was written, interpretation of a special DNS record found during a DNS lookup associated with an RCPT command was the only standardized detection method specified for 556. DNS is the system used to query records associated with domain names. This explains why domain-level information can matter when assessing a 556 reply.

This does not mean that a particular DNS record must be faulty in every 556 event. The source sets a narrower boundary: interpreting a special DNS record in a DNS lookup associated with RCPT is the standardized detection method described. Do not jump to changing DNS records; first confirm the RCPT and 556 context in the error log. For the role of DNS records in email, see DNS records explained: A, CNAME, MX and TXT.

• Treat DNS as an investigation area associated with the recipient domain.
• Do not separate the meaning of a special DNS record from the RCPT and 556 context.
• Do not change a DNS record without confirming the error context.

Source: [2]

Do not give 521 and 556 the same meaning

RFC 7504 reserves 521 for use at connection-opening time. It indicates that a host does not accept mail under any circumstances. It is therefore not defined as a reply for assessing a particular recipient address after RCPT.

In addition, 521 should not be used where a server rejects mail from particular hosts or addresses, or where mail for a particular destination host is not accepted. RFC 7504 says that 554 is more appropriate for most of those conditions. The practical result is straightforward: do not treat a 521 at connection opening and a 556 after RCPT as the same failure signal; their timing and defined scope differ.

• Read 521 in the connection-opening context.
• Do not equate a 556 after RCPT with 521.
• Take into account that 521 is not appropriate for particular source, address, or destination conditions.

Source: [2]

Practical checklist

• Confirm in the SMTP log that 556 followed the RCPT command.
• Keep the RCPT line containing the recipient address together with the reply.
• Start by investigating the recipient domain and the target host’s mail connection acceptance.
• Treat 556 as a permanent negative completion reply for RCPT.
• If you see 521, confirm that it is a different code used at connection opening.
• Do not interpret a 556 after RCPT alone as the status of an individual mailbox.

For a 556 reply after RCPT, the first point of investigation is not one recipient mailbox but whether the target host associated with the recipient domain accepts mail connections. Preserve the reply’s place in the command sequence, treat 556 as a permanent negative result, and do not confuse it with the connection-opening reply 521. This creates a more accurate investigation order without drawing mailbox conclusions that the error record does not support.

Frequently asked questions

Does a 556 reply after RCPT mean that the recipient mailbox does not exist?

No. The 556 context in RFC 7504 concerns an intermediate system being able to determine, without opening a connection, that the target host does not accept mail connections. The reply alone does not prove the state of a particular mailbox.

Can I use a 521 reply for a recipient rejection after RCPT?

521 is reserved for connection opening and indicates that the host does not accept mail under any circumstances. RFC 7504 says it should not be used for particular sources, addresses, or cases where mail for a particular destination host is not accepted.

What is the relationship between 556 and DNS?

At the time RFC 7504 was written, interpreting a special DNS record found in a DNS lookup associated with RCPT was the only standardized detection method specified for 556.

Sources

[2] rfc7504.txt