PunchOp
Menu
Use casesGuidesCompareGlossaryNewsDNS readingMethodSign inPrivacyTermsParticipateJoin inspector beta →Submit a difficulty →
FR
Participate
Join inspector betaSubmit a difficulty
GuideOct 14, 2026Checked Oct 14, 2026

SMTP codes are a combination, not a single number

Read the reply class, the enhanced status and the text together. A 550 with 5.1.1 is not the same case as a 550 with 5.7.1.

An SMTP failure is three lists at once. Collapsing them to 550 throws away the only part that says what to check next.

The three lists

  1. Reply class (RFC 5321). The first digit is 2 (success), 4 (try again later) or 5 (do not retry the same way). 550 is one code inside class 5. It is not one cause.
  2. Enhanced status (RFC 3463, then the IANA registry). The form is class.subject.detail. The class digit should agree with the reply (5.1.1 with a 5xx, 4.2.2 with a 4xx). The subject digit says which part of the system is involved: 1 addressing, 2 mailbox, 3 mail system, 4 network, 7 security or policy.
  3. The text. Vendors reuse generic enhanced codes. 5.7.1 means “delivery not authorized” in the registry. Gmail, a relay and a recipient gateway can all emit it for different rules. The sentence after the code is part of the evidence.

A useful record keeps all three: 550 5.1.1 User unknown, not 550.

Why the panel is a product, not a lookup

The same reply code pairs with many enhanced codes. The same subject pairs with two classes.

What you saw Narrower reading What it still does not prove
550 alone Permanent failure, cause unknown Authentication, relay policy, or a bad recipient
550 5.1.1 … user unknown The recipient address was rejected That every address at that domain would fail
550 5.2.2 or 452 … mailbox full Storage or quota on that mailbox A content or authentication failure
4.2.2 versus 5.2.2 Same mailbox subject; 4 says retry, 5 says stop How long the mailbox stays full
550 5.7.1 Policy or authorization, text required Which rule fired, until the text or a vendor document says so
250 That server accepted this transaction Inbox placement, a later quarantine, or a read

4.2.2 and 5.2.2 are not two unrelated errors. They are the same subject (mailbox) under two classes. Treating every three-digit code as its own root cause, or every enhanced code as a unique incident, both miss the combination.

Codes that are generic on purpose stay unbound. 550 and 5.7.1 cover several causes. Binding them to one incident id would invent a precision the reply does not have. A specific code can be bound: 5.1.1 is an address status, 5.2.2 is mailbox full. Vendor codes that are not in RFC 3463 (for example Gmail 5.7.26 or Outlook 5.7.515) belong with that vendor’s text, not with a guessed RFC meaning.

What to keep from the session

  • The full line, including the enhanced code and the human text.
  • Which host returned it, and whether it was the relay, the recipient MX, or a later DSN.
  • The class: retry (4xx) or stop (5xx).
  • What you searched next, and what that search did not show.

Google’s relay catalog groups errors by mechanism (credentials, relay denied, limits). Use that catalog for a Workspace relay response. Do not paste a recipient-MX 5.1.1 into a relay-authentication checklist.

Limits

This page describes how to read a public status, not a measured rate of each combination on your tenant. RFC 3463 defines the structure. Vendors add codes and reuse generic ones. PunchOp’s registry keeps the lists separate and only attaches an incident label when the code is specific enough. A label is a hypothesis until the text and the path agree.

See also Google Workspace SMTP relay errors and the glossary entry for an enhanced status code.