A bounce label is not a diagnosis. Preserve the full SMTP response and delivery status notification before deciding whether to suppress, repair, reduce, or retry.
550 5.7.1 is not a diagnosis.
It contains a basic SMTP reply, an enhanced status code, and usually some provider-specific text. To diagnose it, you need the receiving system, the sending identity, and the surrounding pattern.
Reducing all of that to hard bounce throws away the evidence an operator needs.
People often call all of these bounce codes, but a 4xx SMTP reply is a temporary failure, which operators call a deferral. A later delivery status notification (DSN) is a separate report. RFC 5321 RFC 3464
An SMTP response may look like this:
550 5.7.1 Message rejected because of sender policy
There are three pieces to preserve:
550 is the three-digit SMTP reply.5.7.1 is the enhanced status code.RFC 5321 defines the basic reply architecture. RFC 3463 defines enhanced status codes in class.subject.detail form. Microsoft exposes the enhanced code and SMTP response text as separate parts of a non-delivery report (NDR). RFC 5321 RFC 3463 Microsoft
Store all three fields. If the platform keeps only 550, it has already discarded most of the evidence.
A 4xx reply means the current attempt failed under a condition classified as temporary. The sending mail system normally delays and retries. A 5xx reply means the exact request should not simply be repeated unchanged. RFC 5321 defines that distinction for SMTP replies, RFC 3463 defines the matching transient and permanent classes for enhanced status codes, and Google's Workspace administrator documentation and Yahoo's sender documentation both use it. RFC 5321 RFC 3463 Google Workspace Yahoo
Those classes describe the disposition of the attempt. They do not prove the root cause.
A temporary response can reflect rate limits, unusual traffic, reputation, content, authentication lookups, or a system problem. A permanent response can identify a nonexistent address, but it can also identify failed authentication, blocked sending infrastructure, message-policy rejection, or lack of relay permission.
Treat the class as a delivery decision, then use the enhanced code and diagnostic text to determine the cause.
The enhanced status code adds a subject and detail to the broad result. The subject families are:
x.0.x: other or undefined statusx.1.x: addressing problemsx.2.x: mailbox problemsx.3.x: mail-system problemsx.4.x: network or routing problemsx.5.x: protocol or command problemsx.6.x: message content or media problemsx.7.x: security or policy problemsThe IANA registry and RFC 3463 define the standardized categories.
The category is still not a complete diagnosis. Gmail uses 5.7.1 for several different policy and reputation conditions. Exchange Online's NDR table uses the same broad family for authorization, relay, authentication, and access-denied or banned-sender conditions. Google Microsoft
Read the provider's text and current documentation before assigning a cause.
Not every receiver supplies a valid enhanced status code, and some reuse broad codes for several causes. Treat the enhanced code as structured evidence, not infallible truth; the diagnostic text and event pattern still matter.
The reporting system and the remote system may not be the same. A Microsoft-generated non-delivery report can describe a rejection issued farther downstream.
A delivery status notification can contain the final recipient, action, transport-independent status, reporting or remote mail server, diagnostic code, last attempt time, and sometimes a retry deadline. RFC 3464 defines those fields, while Microsoft's Exchange Online NDR format and Amazon SES bounce notifications show how those fields surface in a provider's reports and APIs. RFC 3464 Microsoft Amazon SES
A negative SMTP reply records the outcome of that transaction attempt: a 4xx defers it, while a 5xx rejects the request in its current form. A delivery status notification can arrive later after a server previously accepted responsibility for the message. Preserve both the original handoff result and the later DSN.
Save the full response with:
Without that context, the operator is often guessing.
Message-authentication and policy failures involving SPF, DKIM, DMARC, or reverse DNS often appear in the x.7.x family in the IANA registry and in Gmail's and Exchange Online's published codes, although exact codes differ by receiver. Yahoo's published examples show that a receiver may return a plain three-digit reply with text and no enhanced code at all. SMTP AUTH and TLS failures occur at different protocol stages and may produce different replies, or no enhanced status code at all. Diagnose the stage before treating them as one class of failure. IANA Google Microsoft Yahoo
Suppressing the recipient does not repair authentication. Stop or isolate the affected sending stream, correct the configuration, and then verify with controlled traffic.
If the same authentication response appears across many unrelated recipients at one receiver, that pattern is stronger evidence than one event.
Across the current Gmail, Yahoo, and Microsoft error tables, temporary and permanent responses cover rate, content, policy, authentication, and reputation conditions. Google Yahoo Microsoft
Group related responses by:
If deferrals begin clustering at one receiver, reduce or pause that affected stream and inspect the evidence. Google specifically tells senders to reduce volume when mail begins bouncing or deferring and increase slowly only after SMTP errors decline. Amazon SES gives the same operating advice during IP warm-up. Google Amazon SES
Do not re-inject the same recipient and message merely because a dashboard labels the initial deferral a soft bounce. First determine whether the mail transfer system still has the original message queued for retry.
5.1.1 conventionally means a bad destination mailbox address. RFC 3463 and IANA define it that way. Microsoft lists mistyped, nonexistent, moved, and stale-cache conditions, while Yahoo tells senders not to retry a confirmed nonexistent account. RFC 3463 IANA Microsoft Yahoo
Once the full response confirms that diagnosis, suppress the address.
Do not infer nonexistent recipient from 550 alone. Google and Microsoft publish many 5.x.x failures unrelated to a bad address. A valid address rejected by policy or authentication needs a different corrective action.
RFC 5321 requires delayed retries after transient failures and recommends eventual expiration. Yahoo likewise notes that the sending server may retry temporary failures automatically. RFC 5321 Yahoo
Actual retry schedules vary by provider. Do not assume every host retries at the same interval or for the same number of days.
The campaign system should record the deferral and final outcome. It should not blindly inject another copy because a simplified dashboard says soft bounce.
After the receiving server returns 250 OK at the end of the message data, it has accepted responsibility for the message. That is a successful SMTP handoff. It is not proof that the message reached the primary inbox.
RFC 5321 defines the transfer of responsibility. Google's sender FAQ lists spam foldering as an enforcement outcome distinct from rejection, and Yahoo says that adjusting a sender's reputation after review still does not guarantee inbox delivery. RFC 5321 Google Yahoo
Use precise language in reporting:
5xx response says the same request should not be repeated unchanged.When a response arrives:
Using the wrong response category can trigger the wrong operational action. Save the evidence first.
Size domains and density to your sending target and see the capacity that holds.
Book a Call