SMTP Error Codes and Bounce Messages: Fixing 4xx–5xx Delivery Issues

Why SMTP Error Codes and Bounce Messages Matter

If you send any serious volume of email – newsletters, order confirmations, password resets, CRM notifications – sooner or later your reports start filling with mysterious 4xx and 5xx errors. Messages look fine, sending app says “queued”, but recipients never see them. Instead you get cryptic bounce messages: 550 5.1.1 User unknown, 421 4.7.0 Temporary deferral, 554 5.7.1 Message rejected due to policy.

Behind every one of those codes there is a concrete technical reason: DNS issues, sender reputation problems, rate limiting, mailbox misconfiguration, or simply an invalid address. If you learn to read SMTP error codes and bounce messages properly, you can turn a frustrating black box into a predictable system you can debug and improve.

In this article we will walk through what the most common 4xx and 5xx SMTP codes really mean, how to decode bounce messages, and a practical checklist to fix delivery issues on your own server or hosting. We will also look at how to prevent future bounces with better DNS, authentication, and list hygiene, based on what we see every day on the dchost.com infrastructure.

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 – Success (message accepted)
• 4xx – Temporary error (try again later)
• 5xx – Permanent error (do not retry as-is)

Those codes usually appear twice:

• 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 original sender when delivery fails

Modern MTAs also attach an enhanced status code of the form X.Y.Z, for example 5.1.1 or 4.7.0. The first number repeats the class (2/4/5), and the following numbers narrow down the reason (address problem, policy issue, media error, etc.).

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 for a configurable period (often 1–3 days).
• Hard bounces – usually 5xx codes. The receiving server is saying “no, never” for this message as currently sent. Retrying without changing anything will just produce more errors.

Understanding whether you are facing a soft or hard bounce is the first decision point: should you tune retry behaviour and patience, or should you immediately investigate and change something on your side?

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.7.0 Temporary system problem. Please try again later
• 421 4.4.2 Connection dropped

What it usually means: The remote mail server is overloaded, undergoing maintenance, or temporarily refusing new connections from your IP (for example due to rate limiting).

What to do:

• Make sure your MTA is configured to queue and retry messages for a reasonable window (not fail immediately on first 421).
• Check whether you are opening too many concurrent SMTP connections to the same recipient domain and tune your concurrency limits.
• If the bounce text mentions rate limiting, slow down your sends or spread them over time.

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.1 Greylisted, please try again later

What it usually means:

• 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 the first attempt is deliberately rejected and later attempts are accepted to filter spammers who do not retry.

What to do:

• Ensure your server retries with increasing delays (backoff). Greylisting typically allows the second or third attempt.
• If those codes persist for days, it may be a sign of a deeper issue (misconfigured mailbox, disk problems). In that case, contact the receiving admin with full bounce details.

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 recipient’s mailbox has reached its storage quota.
• You are sending to too many recipients in a single SMTP transaction, and the remote side enforces a per-message limit.

What to do:

• 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 your RCPT TO count per message and send in smaller batches.

454 / 455 – Temporary Authentication or Policy Issues

Example codes:

• 454 4.7.0 Temporary authentication failure
• 455 4.7.1 Client host rejected temporarily

What it usually means: The remote server could not verify your identity or policy checks (SPF, DKIM, DMARC, DNS lookups) due to a temporary problem.

What to do:

• Check that your DNS is healthy (A/AAAA, MX, SPF, DKIM records) and resolves quickly from multiple networks.
• Review your SPF, DKIM and DMARC configuration. Our detailed guide explains how to set up SPF, DKIM, DMARC and rDNS step by step.
• Make sure your server presents a valid HELO/EHLO hostname with correct reverse DNS (PTR).

The Most Common 5xx SMTP Errors (Permanent Failures)

5xx codes indicate permanent failures. Retrying without change makes no sense – you must fix the underlying issue or accept that this message cannot be delivered.

550 / 5.1.x – Mailbox Unavailable or Non-Existent

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.

What to do:

• Double-check the email address spelling and domain.
• Remove repeated 5.1.1 hard bounces from mailing lists – keeping invalid addresses damages your reputation.
• If this is supposed to be a valid address within your own domain, fix it in your mail system or control panel.

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 This message does not pass DMARC policy

What it usually means:

• Your server is trying to relay mail for a domain it is not authorised to send for.
• 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.

What to do (step by step):

1. Verify your server is not an open relay and only sends for authenticated users and authorised domains.
2. Check SPF, DKIM and DMARC records (syntax and alignment). Again, our article on raising email deliverability with SPF, DKIM, DMARC and rDNS walks through proper configuration.
3. Check your IP and domain against common blocklists (RBLs). If you are listed, follow the removal procedures and fix the root cause. The playbook for email sender reputation recovery and delisting goes into this in depth.
4. Review message content: avoid spammy keywords, malformed HTML, huge attachments, and suspicious links.

551 / 553 – Relaying and Address Configuration Issues

Example codes:

• 551 5.7.1 User not local; please try <forward-path>
• 553 5.1.2 Invalid or malformed recipient address
• 553 5.7.1 Sender address rejected

What it usually means:

• The remote server expects you to send via a different relay or smarthost.
• There is a syntax error in the sender or recipient address.
• The sending domain does not exist in DNS or is not allowed on that server.

What to do:

• Fix malformed addresses (no spaces, correct @ symbol, valid domain).
• Ensure your From address domain exists, has valid DNS and is allowed on your MTA.
• If using a smarthost or external relay, follow their documentation for authentication and allowed sender domains.

552 / 554 – Message Content, Size and Blocklists

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

What it usually means:

• Your message (including attachments) is too large for the recipient’s limit.
• Content filters or antivirus engines blocked the message.
• Your sending IP or domain appears in one or more blocklists.

What to do:

• Reduce attachment sizes or use download links for large files.
• Scan outgoing mail for malware; make sure your website or servers are not compromised and sending spam.
• Investigate blocklist listings and follow the steps in our reputation recovery guide mentioned above.

Reading Bounce Messages Like a Pro

A bounce message (Delivery Status Notification) is not just bad news – it is a structured diagnostic report. Let’s break down a typical example:

From: [email protected]
Subject: Undelivered Mail Returned to Sender

This is the mail system at host mail.example.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.

<[email protected]>: host mx.recipient.com[203.0.113.10] said:
    550 5.1.1 <[email protected]>: Recipient address rejected:
    User unknown in local recipient table (in reply to RCPT TO command)

Reporting-MTA: dns; mail.example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.recipient.com
Diagnostic-Code: smtp; 550 5.1.1 Recipient address rejected

Key parts to focus on:

• Recipient line – shows the affected address.
• Remote-MTA – the server that actually rejected the message.
• Diagnostic-Code – the SMTP code and human-readable reason.
• Status – the enhanced status code (5.1.1 here).

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

• 5.1.x – Address and routing problems (user unknown, invalid domain).
• 5.2.x – Mailbox full or mailbox policy issues.
• 5.7.x – Security and policy rejections (authentication, spam, encryption requirements).

Once you know the pattern, tools or scripts can automatically classify bounces and feed them into your CRM or mailing list system to unsubscribe invalid addresses, flag potential reputation problems, or suggest content changes.

Systematic Troubleshooting Checklist for SMTP 4xx–5xx

When you see a spike in 4xx or 5xx errors, treating them as random noise is tempting. Instead, approach them like any other infrastructure incident: structured, repeatable, and data-driven. Here is a checklist we use often in our own operations at dchost.com.

1. Confirm the Recipient and Basic DNS

• Is the email address spelled correctly?
• Does the recipient domain have valid MX records pointing to reachable mail servers?
• Does the domain itself resolve (A/AAAA records), or has DNS expired or been misconfigured?

This sounds basic, but a surprising share of 5.1.1 / 5.1.2 errors come from minor typos or expired domains, especially after domain transfers. Our article why domain transfers break email and how to avoid it is worth a read if you move domains often.

2. Check Sender Identity: SPF, DKIM, DMARC and rDNS

Modern mail systems rely heavily on these DNS-based signals:

• SPF – lists authorised sending IPs for your domain.
• DKIM – adds a cryptographic signature to prove message integrity and origin.
• DMARC – tells receivers how to treat messages that fail SPF/DKIM.
• rDNS (PTR) – maps your sending IP back to a hostname that should match your mail server’s HELO.

Misconfigured or missing records are a common trigger for 550/554 5.7.x errors. Besides the earlier guide we linked, our IPv6-focused article on email deliverability over IPv6, PTR, HELO and blocklists also explains how these pieces fit together in practice – the principles are the same for IPv4.

3. Investigate IP and Domain Reputation

If your codes mention spam, blocklist, reputation or abuse, it is time to check:

• Are you listed on prominent DNS-based blocklists (RBLs)?
• Do major providers show elevated spam complaint or bounce rates in their postmaster tools?
• Has any compromised script or mailbox on your hosting started sending spam?

Recovery involves both delisting and cleaning up the causes (compromised sites, weak passwords, poor list hygiene). The article on email sender reputation recovery, blocklists and safe IP warm-up is a practical companion to this step.

4. Look at Connection-Level and TLS Requirements

Some receiving domains now require TLS, MTA-STS policies, or have strict cipher requirements. If you see errors like:

• 5.7.0 TLS required but not offered
• 5.7.30 MTA-STS validation failed

Then you need to:

• Ensure your MTA is configured with a valid, up-to-date SSL/TLS certificate.
• Support modern TLS versions and ciphers (ideally TLS 1.2 and 1.3).
• Optionally, implement MTA-STS and DANE policies for your own domain to increase trust. Our guide on SMTP security with MTA-STS, TLS-RPT and DANE/TLSA explains how to approach this in a calm, incremental way.

5. Respect Rate Limits and Concurrency

Large bursts of mail to one domain can trigger 4xx deferrals or even 5xx reputation-based blocks. To avoid that:

• Throttle your sending rates per destination domain.
• Limit the number of concurrent SMTP connections to the same domain.
• Spread campaigns over time instead of blasting everything at once.

If you run your own MTA on a VPS or dedicated server, these knobs are usually in parameters like default_destination_rate_delay or default_destination_concurrency_limit (Postfix) or equivalents in other MTAs.

6. Inspect Local Logs and Queues

Do not rely only on the bounce text. On your server or hosting panel, check:

• Mail logs (e.g., /var/log/maillog or /var/log/mail.log) for full SMTP session transcripts.
• Mail queue for messages stuck in retry loops due to persistent 4xx responses.
• Possible local misconfigurations (wrong relayhost, authentication errors, broken DNS resolvers).

For users on shared hosting with cPanel/DirectAdmin, your control panel usually exposes mail logs and queue-related information. On VPS or dedicated servers from dchost.com, you have full SSH access to investigate and tune these parameters directly.

Infrastructure Choices: Shared Hosting, VPS and Dedicated SMTP

The way you handle SMTP errors also depends on where your mail is hosted:

• Shared hosting email – Quick to start, lower maintenance. However, IP reputation is shared; a neighbour’s misbehaviour can affect you.
• VPS-hosted mail server – Full control over IPs, DNS and MTA config. Requires more expertise but allows fine-grained tuning of queues, rate limits and authentication.
• Dedicated server or colocation – Suited for very high volume or compliance-sensitive environments; you own the full stack and can separate roles (inbound, outbound, filtering).

At dchost.com we see many customers start with shared hosting for basic mail needs and move to a VPS-based mail server once they need custom routing, multiple IP pools, or advanced filtering. If you are considering running your own stack (Postfix, Dovecot, rspamd, etc.), our real-world guide on building a mail server on a VPS with Postfix and Dovecot pairs nicely with this article.

Whatever you choose, make sure you have:

• Reliable, redundant MX records – see our article on email redundancy architectures with multiple MX and backup MX.
• Regular, tested backups of your mailboxes and configuration.
• Monitoring and alerting for queue growth and spike in 4xx/5xx error rates.

Preventing Future Bounces: Reputation, Lists and Hygiene

Fixing individual errors is good; reducing the baseline error rate is better. A few long-term practices pay off quickly:

Keep Your Lists Clean

• Use double opt-in for sign-ups so addresses are verified.
• Automatically suppress addresses that produce repeated 5.1.1 hard bounces.
• Segment inactive users and send less frequently to those segments.
• Make unsubscribing easy to reduce spam complaints.

Protect Accounts and Sites from Abuse

• Enforce strong passwords and two-factor authentication where possible.
• Monitor your CMS (WordPress, etc.) for malware that might send spam. Our guides on cleaning and hardening hacked WordPress sites explain how to stop compromised sites from damaging your mail reputation.
• Limit outgoing mail per account to detect sudden spikes.

Warm Up New IPs and Domains Gradually

New sending IPs or domains with no history are treated cautiously by big providers. To avoid 4xx deferrals and 5xx spam rejections:

• Start with small, engaged segments and grow daily volume slowly.
• Monitor bounce codes carefully during the first weeks.
• Spread load across IPs only once each IP has a clean history.

This gradual approach is at the core of the safe IP warm-up process discussed in our sender reputation recovery article.

Use Proper Transactional vs Marketing Flows

Mixing high-value transactional email (password resets, order confirmations) with bulk marketing on the same IP and domain can backfire: marketing complaints hurt transactional deliverability. When your volume grows, consider:

• Separating transactional and marketing traffic by subdomain and sometimes by IP.
• Giving transactional traffic stricter content and list hygiene rules.

If you run a busy e-commerce or membership site, our article on transactional email for WordPress and WooCommerce explores practical architectures to keep critical messages reliable.

Keep Your Email Flowing: Bringing It All Together

SMTP error codes and bounce messages are not random punishment – they are the receiving servers’ way of saying exactly what is wrong. When you understand the difference between 4xx and 5xx, between 5.1.1 and 5.7.1, you can go from guessing to debugging: fixing DNS, tightening authentication, cleaning lists, or adjusting rate limits with confidence.

The most reliable senders we see have three habits in common: they monitor their error codes and bounce patterns, they own their DNS and authentication configuration, and they treat reputation and list hygiene as ongoing processes, not one-time tasks. With the right hosting foundation – whether shared email, a tuned VPS, a dedicated server, or colocation at dchost.com – you can implement the checks and safeguards we covered here at your own pace.

If your reports are full of 4xx–5xx codes today, start with one concrete step: pick the top two or three error messages, trace them through this article’s checklist, and fix them systematically. As they fall away, open rates and user trust tend to rise quietly in the background. And if you are planning a more robust mail setup or need infrastructure tuned for serious sending, our team at dchost.com is happy to help you design a stack that keeps your messages where they belong: in the inbox, not on the error log.