SMTP Codes and Bounce Messages: Reply Reference

Read an SMTP Reply in Its Command Context

An SMTP reply has a three-digit code, a command context and sometimes an enhanced status code. A bounce adds DSN fields describing the outcome for individual recipients. This reference explains those meanings and their limits; a number alone does not establish the root cause.

The SMTP replies on this page are illustrative examples, not captured provider output or results of executed tests.

A reply gives a status class and sometimes a detailed diagnostic; it does not always reveal the root cause. Interpret it with the command, destination, queue record and full response. Message acceptance is distinct from inbox placement and reading.

This reference combines command, reply and DSN meanings with short scenarios, diagnostic checks and operating guidance. For a detailed incident record, controlled correction and retry verification, follow the email delivery troubleshooting guide.

What SMTP Error Codes and Bounces Actually Mean

SMTP (Simple Mail Transfer Protocol) is the language mail servers use to talk to each other when delivering email. Every step of that conversation is answered with a three-digit status code:

• 2xx – Successful completion of a command; message acceptance is confirmed by the final success reply after message data
• 3xx – Intermediate reply (more input is required)
• 4xx – Temporary error (try again later)
• 5xx – Permanent error (do not retry as-is)

You may encounter those codes in two places:

• In the live SMTP session, as your server talks to the recipient’s server
• Inside a bounce message (Delivery Status Notification, DSN) sent back to the envelope sender when delivery fails

Enhanced status codes use class.subject.detail, such as 5.1.1 or 4.7.0. The class is 2, 4 or 5; the subject and detail can each contain one to three digits. RFC 3463 and later registrations define meanings in the IANA registry. Preserve the complete text when a provider’s diagnostic differs from the expected meaning; do not infer a specific failed mechanism from the broad family alone.

Two key concepts are:

• Soft bounces – usually 4xx codes. The receiving server is saying “not now, maybe later”. Your mail server should keep the message in queue and retry until its configured queue lifetime expires; continued failure then results in a final bounce.
• Hard bounces – usually 5xx codes. The responding server reports a permanent failure for the command or delivery attempt as currently made. Retrying without changing anything will just produce more errors.

A 4xx deferral need not produce an immediate bounce. Read the DSN Action as well: delayed means attempts continue, while failed means attempts to that recipient have ended, even when the reported cause is a persistent 4.x.x condition. A 5xx policy or size rejection does not automatically make the address invalid.

The Most Common 4xx SMTP Errors (Temporary Failures)

4xx errors indicate temporary problems. They often relate to rate limits, greylisting, transient DNS issues, or resource limits on the receiving server.

421 – Service Not Available / Temporary Deferral

Example codes:

• 421 4.3.2 Service not available, closing transmission channel
• 421 4.4.2 Connection dropped

421 means the responding SMTP service is unavailable and closes the transmission channel. Overload, maintenance or rate policy are possible causes; the text and the replying server’s logs distinguish them. It can occur after a command, not only when opening a connection.

Interpretation and related checks:

• 421 closes the transmission channel; it is not limited to connection opening.
• Maintenance, capacity and rate policy are possible reasons. The full diagnostic and replying server determine which applies.
• 4.3.2 in the example narrows the classification to a system not accepting network messages; do not assign that detail to every 421.

450 / 451 – Requested Action Not Taken / Local Error

Example codes:

• 450 4.2.1 Mailbox temporarily unavailable
• 451 4.3.0 Temporary server error. Try again later
• 451 4.7.0 Temporary policy deferral; try again later

These are illustrative replies, not captured provider output. Depending on the complete diagnostic, investigate:

• The recipient’s mailbox is locked or temporarily unavailable.
• The remote server is experiencing resource issues (disk full, high load).
• Your message has been greylisted – a technique where an initial attempt is deliberately deferred and a later retry may proceed after a waiting period, subject to other delivery checks, to filter senders that do not retry.

Interpretation and related checks:

Greylisting may defer an initial attempt until the receiver’s waiting period is satisfied. It does not guarantee acceptance on the second or third attempt, and other checks can still fail. Use the queue checks below; the companion workflow gives the detailed correction and verification sequence.

The temporary reply class is separate from queue lifetime. A persistent 4.x.x condition can ultimately appear with DSN Action: failed when attempts end. The reference below defines those fields; the checklist covers queue ownership, and the companion workflow expands the timing and verification steps.

452 – Insufficient System Storage / Too Many Recipients

Example codes:

• 452 4.2.2 Mailbox full
• 452 4.5.3 Too many recipients

What it usually means:

• The base 452 reply concerns insufficient system storage; identify the responding server before checking disk or quota. The enhanced codes in these examples narrow the context.
• The recipient’s mailbox has reached its storage quota.
• You are sending to too many recipients in a single SMTP transaction, and the remote side has reached its recipient capacity for that transaction. A separately configured message-wide policy may behave differently.

Interpretation and related checks:

• For mailbox full, let the user know via another channel (SMS, chat) if important. Your server can keep retrying for some time.
• For too many recipients, reduce the RCPT TO count per SMTP transaction. Let the queue-owning MTA track each recipient: after successful end-of-data acceptance, retry only recipients not accepted in that transfer. Do not recreate the whole recipient list and resend to recipients already accepted. A lost final reply leaves acceptance uncertain and requires record reconciliation.

454 / 455: AUTH, STARTTLS and Command Parameters

Example codes:

• After AUTH: 454 4.7.0 Temporary authentication failure
• After STARTTLS: 454 TLS not available due to temporary reason
• For MAIL FROM/RCPT TO parameters: 455 Server unable to accommodate parameters

These are separate examples. RFC 4954 uses 454 for a temporary AUTH server failure and says the client should not prompt for a different password on that basis. RFC 3207 uses 454 for temporary STARTTLS unavailability. RFC 5321 uses 455 when MAIL FROM/RCPT TO parameters temporarily cannot be accommodated unless the extension defines another code; unrecognized or unimplemented parameters use 555. None of these meanings is a generic SPF/DKIM/DMARC failure.

Interpretation and related checks:

• Record the preceding command, full reply and advertised EHLO extensions. Inspect the AUTH service or TLS configuration on the server that failed.
• Do not disable required TLS to bypass a 454. For 455, verify the requested parameters and retry policy; an unsupported parameter is a different condition.
• SPF/DKIM/DMARC concern message identity and alignment, separate from SMTP AUTH. Use the sender-authentication guide when the actual diagnostic points to those checks. HELO/PTR consistency alone does not repair an AUTH backend or unsupported command parameter.

The Most Common 5xx SMTP Errors (Permanent Failures)

5xx indicates a permanent failure for the command or attempt; investigate before resending unchanged. One legacy compatibility exception matters: RFC 5321 says clients should treat an old 552 “too many recipients” reply as temporary and split subsequent recipient attempts. This is distinct from the permanent 552 5.3.4 message-size example below.

530: Authentication Required or STARTTLS First?

Under RFC 4954, 530 5.7.0 Authentication required means that the requested operation requires authentication that is not currently in force. RFC 3207 also permits a server that is not publicly referenced and requires TLS first to return 530 Must issue a STARTTLS command first; its enhanced code can also be 5.7.0.

Choose the branch from the preceding command and complete reply, not from 530 or 5.7.0 alone. For application submission, verify the provider’s configured, trusted submission endpoint and TLS mode. Establish and validate required TLS before sending credentials, then perform the authentication required by that service. Offering your mailbox credentials to an arbitrary recipient MX is not a general solution to this reply.

550 / 5.1.x / 5.2.1 – Address Rejected or Mailbox Unavailable

Example codes:

• 550 5.1.1 User unknown
• 550 5.1.0 Address rejected
• 550 5.2.1 Mailbox disabled, not accepting messages

What it usually means:

• The recipient email address does not exist on the target system (typo, deleted account, different alias).
• The mailbox is disabled, blocked, or not accepting new mail.

Interpretation and related checks:

• 5.1.1 identifies a nonexistent destination mailbox; 5.1.0 is less specific and 5.2.1 means the mailbox exists but is disabled.
• The full diagnostic and destination context matter before classifying a recipient as invalid.
• Mailbox, alias and routing checks differ from SPF or content-policy checks; do not substitute one for another.

550 / 5.7.x – Policy, Authentication and Reputation Problems

Example codes:

• 550 5.7.1 Relaying denied
• 550 5.7.1 Message rejected as spam by content filter
• 550 5.7.1 SPF check failed
• 550 5.7.26 Multiple authentication checks failed

These illustrative policy replies do not all identify the same mechanism. In the registry, 5.7.26 means multiple authentication checks failed contrary to local policy; it does not specify which checks or uniquely identify DMARC. Use the full reply and receiver documentation to investigate:

• The server you contacted will not relay mail to that recipient for your connection; check relay authorisation and whether you contacted the correct server.
• Your sending IP or domain has a poor reputation or appears on blocklists.
• SPF, DKIM, or DMARC authentication failed for this message.
• The receiving server’s content filter considers the message spammy or dangerous.

Interpretation and related checks:

Read the full reply before selecting a mechanism. A relay denial calls for the correct submission service and authorization; a message-authentication diagnostic calls for the actual verification and alignment result. A named blocklist calls for checking the relevant connecting IP and that list. See the sender-authentication guide and reputation recovery guide for the corresponding workflows. No fixed set of “spam words” guarantees acceptance. For relaying denied, check that you are using the correct submission server and authorised credentials or client IP. Verify your own server is not an open relay: forwarding to non-local destinations must be restricted to authorised clients.

551 / 553: Non-Local Recipient and Mailbox Name

Example codes:

• 551 User not local; please try <forward-path>
• 553 5.1.3 Invalid destination mailbox address syntax
• 553 5.1.2 Bad destination system address

What it usually means:

• 551 reports a non-local recipient and suggests a forwarding address; it does not by itself tell you to switch submission providers or authenticate to a new smarthost.
• 553 concerns an unacceptable mailbox name. 5.1.3 identifies invalid address syntax, while 5.1.2 concerns the destination system/domain being invalid for mail.
• Read which address and command were rejected. The envelope MAIL FROM, envelope RCPT TO and visible From header are different fields.

Interpretation and related checks:

• Validate the complete address using the application’s supported parser; quoted local parts and internationalized-address support make blanket “no spaces” rules unreliable.
• Confirm recipient or forwarding changes through a trusted channel. Do not automatically rewrite an address from an untrusted 551 response.
• For a submission/smarthost policy issue, follow that provider’s authenticated-client and authorized-sender requirements; distinguish it from a non-local recipient response.

552 / 554: Storage, Message Size and Transaction Failure

Example codes:

• 552 5.3.4 Message size exceeds fixed maximum message size
• 554 5.7.1 Message rejected due to content restrictions
• 554 5.7.1 [IP] blocked using DNSBL
• 554 5.7.1 Permanent spam rejection

552 is the base storage-allocation reply; 5.3.4 specifically identifies a per-message size limit. 554 is a broad transaction failure and can also mean no SMTP service at connection opening. For the illustrative replies above, investigate:

• The complete encoded message, including MIME overhead and headers, is too large for the responding server’s limit; raising your own limit does not raise the receiver’s.
• Content filters or antivirus engines blocked the message.
• Your sending IP or domain appears in one or more blocklists.

Interpretation and related checks:

• Total encoded message size includes MIME overhead and headers. Changing the sender’s local limit does not raise the receiver’s limit.
• 554 with a policy explanation is different from a size diagnosis; preserve the actual text rather than labeling every 554 as spam.
• If file sharing replaces an attachment, recipient authorization and appropriate expiry still matter.

Read the Reporting MTA, Recipient and Diagnostic Together

The following combines a hypothetical human-readable explanation with selected delivery-status fields. It is not a complete MIME email. A real message/delivery-status part separates per-message fields from each recipient group with a blank line:

From: MAILER-DAEMON@example.com
Subject: Undelivered Mail Returned to Sender

This illustrative message could not be delivered.
<user@example.net>: host mx.example.net[203.0.113.10] said:
    550 5.1.1 <user@example.net>: User unknown
    (in reply to RCPT TO command)

Reporting-MTA: dns; mail.example.com

Final-Recipient: rfc822; user@example.net
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.net
Diagnostic-Code: smtp; 550 5.1.1 User unknown

Key parts to focus on:

• Reporting-MTA: the MTA whose delivery/relay attempt is described; here it reports a remote RCPT rejection.
• Final-Recipient: the envelope recipient for this result group. Process each recipient separately.
• Action: failed means attempts have ended; delayed means the MTA will continue trying.
• Remote-MTA: identifies the remote source of the diagnostic when one was involved. Its absence can indicate a locally generated diagnostic.
• Diagnostic-Code and Status: preserve both the transport’s detailed reply and the enhanced classification. Match them with your own submission, envelope recipient and queue record.

For bulk campaigns, it is useful to categorise bounces by status code:

• 5.1.x – Address problems (user unknown, invalid destination domain); network/routing conditions have the separate x.4.x family.
• 5.2.x – Permanent mailbox status, such as a disabled mailbox; a full mailbox commonly uses temporary 4.2.2.
• 5.7.x – Security and policy rejections (authentication, spam, encryption requirements).

Automation can classify validated delivery reports and suppress confirmed invalid addresses from further sends. DSNs can be forged: correlate them with actual submissions and recipient records before changing a list. Do not treat every 5xx as an invalid address or silently convert a suppression into a user unsubscribe request.

Successful Replies Depend on the Command

The following table shows selected replies in the basic flow. It is not an exhaustive list of extensions or provider policies. A command success must not be promoted into a claim about final delivery.

If the final success reply is lost, the client may not know whether acceptance occurred. Recreating the message can produce duplicate delivery. RFC 5321 §4.5.3.2.6 specifically distinguishes this end-of-data timeout; use the queue checks below and the incident workflow for detailed record reconciliation.

500, 501 and 503: Syntax and Command Order

500 means the command is unrecognized, 501 concerns parameter/argument syntax, and 503 reports a bad command sequence. These are not interchangeable DNS or authentication diagnoses. For example, a RCPT command without a preceding MAIL command requires a 503 response under RFC 5321.

501 5.5.4 Invalid domain name in HELO

This illustrative reply concerns the command argument. EHLO/HELO normally identifies the client by FQDN; an address literal is defined when no meaningful domain name is available. Postfix’s outgoing name is controlled by smtp_helo_name, whose default is myhostname. PTR/forward-DNS consistency may be required operationally but does not replace syntax validation or prove the cause of this reply.

Multiline Replies and Conflicting Diagnostic Text

A multiline SMTP reply uses the code followed by a hyphen on continuation lines and a space on the final line. All lines have the same three-digit code. This independent format example is not a captured server capability list:

250-First line
250-Second line
250 Last line

Preserve the full reply through its final line. 250- is not an error or a separate status code. The three-digit reply and an enhanced code such as 5.1.1 have different syntax. If an actual provider uses text inconsistent with the registered meaning, keep the raw response and compare it with that provider’s documentation; do not rewrite the evidence.

Enhanced Codes That Need Separate Interpretation

SPF evaluates the connecting IP for MAIL FROM, or HELO where applicable. DKIM verifies selected canonicalized headers/body under a signing domain. DMARC needs at least one successful SPF or DKIM identity aligned with the visible From domain. These are different from SMTP AUTH login. PTR and forward-DNS consistency is another check; none of them alone guarantees inbox placement.

Keep transport direction in view: STARTTLS upgrades a session, MTA-STS/DANE validates destination policy, and REQUIRETLS carries a message transport requirement. Do not silently bypass mandatory policy with cleartext fallback. Publishing an inbound policy for your own domain will not repair a remote recipient MX’s TLS failure.

What DSN Fields Prove and What They Do Not

A minimal DSN includes Reporting-MTA and, for each recipient, Final-Recipient, Action and Status. A missing optional field does not by itself make a report malformed. Process each recipient group separately, and keep invalid-address suppression distinct from a user’s unsubscribe request.

First Decisions for Common Delivery Problems

These scenarios are hypothetical. Base the next action on the complete reply matched to your own submission, not the code alone; more than one cause can coexist.

These are independent illustrative replies, not a multiline response from one SMTP session:

550 5.7.1 Service unavailable; Client host blocked
554 5.7.1 Message rejected as spam
451 4.7.0 Try again later (greylisting)
421 4.7.0 Too many messages from this IP, try again later

A Compact Diagnostic Checklist

1. Identify the event and responsible layer. Record timestamp and time zone, SMTP command, full reply, queue/provider ID, envelope recipient and responding server. Use the detailed code to narrow address/mailbox, policy/identity or system/network checks. Do not assume Reporting-MTA and Remote-MTA are the same machine.
2. Validate the recipient and routing. Confirm the address through a trusted channel; inspect the recipient domain’s MX and the selected MX host’s A/AAAA resolution. SMTP can use an implicit MX when none exists; unusable MX records and a null MX announcing no mail service are different cases. After a domain transfer, check the authoritative DNS zone and the panel’s local/remote mail routing.
3. Inspect the actual sending identity. Confirm that SPF authorizes the actual legitimate outbound IP for MAIL FROM/HELO. Compare the DKIM selector, actual verification result and visible From alignment in DMARC reports. SPF’s limit of 10 DNS-causing terms includes nested evaluation; remove unnecessary dependencies while preserving legitimate senders; automatic flattening is not a default repair. PTR changes may require the IP provider. A DKIM pass alone establishes neither alignment nor inbox placement.
4. Separate connection and TLS direction. Check host, port, connectivity, certificate and mandatory TLS policy separately for application-to-submission and MTA-to-recipient-MX traffic. Changing the application’s SMTP AUTH password or disabling required encryption does not repair a remote MX failure.
5. Find the queue owner. The application, local MTA and external provider must not independently recreate the same retry. At a 452 recipient limit, after successful end-of-data acceptance, retry only recipients not accepted in that transfer; do not rebuild the whole list and resend accepted recipients. If the final reply was lost, reconcile application and MTA/provider records; Message-ID alone does not prevent duplicate delivery. Retry interval and total queue lifetime are separate MTA controls; a one-time code’s useful life is not the SMTP queue lifetime.
6. Read logs and metrics together. Inspect the configured Postfix/Exim log destination, such as /var/log/mail.log, /var/log/maillog or the journal depending on the installation, and each recipient’s queue state; not every setup logs a complete SMTP transcript. Compare queue depth, oldest-message age, 4xx/5xx rates and destination distribution over the same interval. State whether the denominator is messages, recipients or attempts: retries can inflate counts. On shared hosting, collect available panel records and ask the provider for MTA evidence you cannot access.

Infrastructure Choices and Operating Responsibility

Postfix’s default_destination_rate_delay, default_destination_concurrency_limit and default_destination_recipient_limit control different things. Transport-specific settings can override them; setting the recipient limit to 1 changes the destination scope of delay/concurrency from domain to recipient. For Exim, consult the installed version’s router, transport and retry configuration instead of copying Postfix parameter names. There is no universal safe sending rate: assess small changes against documented receiver limits and queue measurements.

Include updates, access-controlled centralized logs, queue-growth/age alerts and tested mail/configuration restores in the operating plan. Multiple MX hosts can improve inbound resilience when recipient lists, filtering and routing are consistent; they do not by themselves repair outbound delivery. Use the installation and redundant-MX guides below for implementation details.

Reduce Recurring Failures

• List hygiene: Use permission-based signup and double opt-in where appropriate; suppress confirmed invalid addresses. Keep invalid-address suppression separate from a user’s unsubscribe request, and do not treat opens as address validation or proof of delivery.
• Abuse controls: Protect SMTP/API credentials and use MFA for supported management logins. Stop mail from compromised WordPress installations, plugins or forms and remediate the source; use per-account limits and unusual-volume/queue alerts.
• Gradual introduction: Increase legitimate, permission-based traffic on a new IP or domain gradually, adjusting to refusals, deferrals and complaints. A fixed warm-up calendar cannot guarantee acceptance; moving blocked traffic to another IP does not fix its cause.
• Traffic separation: Plan separate queues, priority and sending sources for password resets/orders and marketing. This helps limit bulk-mail delays for critical notifications; it does not guarantee complete reputation isolation when domains or IPs are shared.

Where to Go After Reading the Reply

Combining code, command and recipient state identifies which evidence is still missing. For the correction and retry sequence, follow the email delivery troubleshooting guide. The following articles cover separate infrastructure and operational topics:

• domain transfer
• why domain transfers break email and how to avoid it
• on email deliverability over IPv6, PTR, HELO and blocklists
• on SMTP security with MTA-STS, TLS-RPT and DANE/TLSA
• VPS
• dedicated server
• building a mail server on a VPS with Postfix and Dovecot
• email redundancy architectures with multiple MX and backup MX
• cleaning and hardening hacked WordPress sites
• transactional email for WordPress and WooCommerce
• original sender reputation recovery guide (in Turkish)

Official Sources

Standard meanings were compared with these documents and registries on 4 November 2026. Verify product- or receiver-specific behavior against its version and complete diagnostic separately.

• RFC 5321: SMTP
• RFC 3463: Enhanced Status Codes
• RFC 3464: Delivery Status Notifications
• IANA: SMTP Enhanced Status Codes
• RFC 4954: SMTP AUTH
• RFC 3207: STARTTLS
• RFC 8689: REQUIRETLS
• RFC 9989: DMARC
• Postfix: Configuration Parameters