Why bounce codes matter
You hit send, and a few seconds later a "Mail Delivery Subsystem" message lands in your inbox with a string like 550 5.1.1 User unknown. That three-digit number is the receiving server telling you exactly why it refused your message. Read it correctly and most bounces take minutes to fix. Ignore it and the same problem quietly damages your sender reputation and pushes future emails toward the spam folder.
This guide explains the three codes you'll see most often (550, 421 and 554), how to read the enhanced status code that comes with them, and what to do about each one. It applies whether you send one-to-one business email or bulk campaigns.
550 – permanent rejection. The mailbox doesn't exist, or the receiving server refused you by policy. Fix the address or your authentication; don't keep retrying.
421 – temporary deferral. The receiving server is busy, rate-limiting you, or greylisting. Your mail server retries automatically; act only if it keeps happening.
554 – permanent rejection, usually policy. Most often a spam, reputation or blocklist decision. Check authentication, blocklists and content.
Read the whole bounce message. The enhanced code (like 5.1.1 or 5.7.1) and the text after it tell you far more than the three digits alone.
Prevention beats cleanup. Authenticate your domain with SPF, DKIM and DMARC, and keep your lists clean.
How bounce codes work
Every email is handed from server to server using SMTP (Simple Mail Transfer Protocol), the sending protocol covered in our guide to IMAP vs SMTP vs API. At each step the receiving server answers with a three-digit reply code, defined in RFC 5321. The first digit tells you the outcome:
First digit | Meaning | What your server does |
|---|---|---|
2xx | Success | Message accepted |
4xx | Temporary failure (soft bounce) | Queues the message and retries, typically for up to several days |
5xx | Permanent failure (hard bounce) | Stops and sends you a bounce notice |
Modern servers also add an enhanced status code in the format class.subject.detail, defined in RFC 3463. The class repeats the outcome (2, 4 or 5). The subject narrows down the area:
Subject digit | Area | Example |
|---|---|---|
x.1.x | Addressing | 5.1.1 – recipient address doesn't exist |
x.2.x | Mailbox | 4.2.2 or 5.2.2 – mailbox full |
x.3.x | Mail system | 5.3.4 – message too big for the system |
x.4.x | Network and routing | 4.4.1 – no answer from host |
x.5.x | Protocol | 5.5.1 – invalid command |
x.7.x | Security or policy | 5.7.1 – delivery not authorised; 5.7.26 – failed authentication |
The same basic code can carry very different enhanced codes. A 550 5.1.1 is a typo or a dead address, while a 550 5.7.1 is a policy block. Always diagnose from the enhanced code and the human-readable text, not the three digits alone.
A quick note on what isn't a bounce: automatic replies such as vacation messages arrive as normal emails, not delivery failures. If you're setting those up, see our guide to out-of-office automation.
550, 421 and 554 explained
550: Requested action not taken (permanent)
A 550 means the receiving server refused the message and won't accept it if you try again unchanged. It has two very different families of causes:
Address problems (5.1.x). The mailbox doesn't exist, was deactivated, or the domain is misspelled (
gmial.com). Fix: correct the typo or remove the address from your list.Policy problems (5.7.x). The address is fine, but the server rejected you: your IP or domain is on a blocklist, your message failed SPF, DKIM or DMARC checks, or the recipient's admin blocks external senders. Fix: check your domain authentication and blocklist status before touching your list.
Mailbox-full errors (5.2.2) sometimes also arrive as 550 or 552. Treat a single full mailbox as temporary, but remove the address if it stays full for weeks.
421: Service not available (temporary)
A 421 means "not now." The receiving server is overloaded, under maintenance, or deliberately slowing you down. Common triggers:
Rate limiting. You sent too much, too fast, from a new or low-reputation IP or domain. Large mailbox providers often defer mail this way before they block it.
Greylisting. Some servers temporarily reject every first attempt from an unknown sender, then accept the retry a few minutes later.
Server or network trouble on the recipient's side.
Fix: usually nothing. Your mail server retries automatically. Act if 421s persist for more than a day or two, or spread across many domains at once: slow your sending rate, check your reputation, and confirm your authentication.
554: Transaction failed (permanent)
A 554 is a catch-all permanent failure, and in practice it nearly always means a policy decision. Common causes:
Your sending IP or domain is on a blocklist such as Spamhaus.
The message failed authentication or the recipient's DMARC policy.
Content filters flagged the message as spam or as carrying a malicious link or attachment.
The recipient server refused the connection outright (554 at connection time often means "no SMTP service here" or "you're blocked").
Fix: read the text after the code, which often names the blocklist or policy. Then check blocklists, verify SPF, DKIM and DMARC, and review the content. Our email security and TLS guide covers how receiving servers judge suspicious mail.
Quick reference
Code | Type | Most common cause | First thing to do |
|---|---|---|---|
550 5.1.1 | Hard | Address doesn't exist | Check for typos, then remove |
550 5.7.1 | Hard | Policy or blocklist rejection | Check blocklists and authentication |
421 4.7.0 | Soft | Rate limiting or greylisting | Let it retry; slow down if it persists |
554 5.7.1 | Hard | Spam or policy rejection | Read the reason, fix reputation or content |
550 or 554 5.7.26 | Hard | Failed SPF/DKIM/DMARC | Fix your DNS authentication records |
How to troubleshoot a bounce, step by step
You'll need the full bounce message (or your sending logs), access to your domain's DNS settings, and a few minutes.
Classify it. 4xx means temporary, 5xx means permanent. A one-off 4xx needs no action; a 5xx always does.
Read the enhanced code and the text. Look for 5.1.x (address), 5.2.x (mailbox), or 5.7.x (policy and security). The text often names the exact reason, such as a blocklist name or "DMARC policy."
For address errors, check the address. Look for typos in both the name and the domain. Confirm the domain has valid MX records. If the person changed jobs or the address was closed, remove it.
For policy errors, check your authentication. Confirm SPF, DKIM and DMARC are published and passing for your domain. If you send from your own domain, our guide to business email on your own domain explains why these records matter.
Check your reputation. Look up your sending IP and domain on major blocklists such as Spamhaus. If you send to Gmail users in volume, Google Postmaster Tools shows how Gmail sees your domain. If you're listed, fix the cause first, then request delisting.
Fix the sending pattern. For bulk mail, send only to engaged contacts, ramp up volume gradually on new domains or IPs, and keep marketing and transactional mail separate (see transactional vs marketing emails).
Monitor. Track your bounce rate after each send. A common industry rule of thumb is to keep it under 2%; anything higher signals a list or reputation problem worth investigating.
A worked example
An online store emails 10,000 subscribers and gets 500 bounces, a 5% bounce rate. Here's how the bounces break down and what the team did:
Bounces | Code | Diagnosis | Action |
|---|---|---|---|
300 | 550 5.1.1 | Old and mistyped addresses, many from an imported list | Removed all 300; added address validation at signup |
150 | 421 4.7.0 | One large provider rate-limited a sudden volume spike | Let them retry; split future sends into smaller batches |
50 | 554 5.7.1 | Domain had no DMARC record and SPF didn't include the sending service | Published SPF, DKIM and DMARC |
On the next campaign, bounces fell to 50 out of roughly 9,700 sends, about 0.5%. The fixes were boring, which is the point: most bounce problems come down to list hygiene and deliverability basics.
Common mistakes
Treating every 550 as a bad address. A 550 5.7.1 is a policy block. Deleting a valid contact won't fix it; fixing your authentication or reputation will.
Retrying hard bounces. Repeatedly sending to addresses that returned 5.1.1 is one of the fastest ways to damage your sender reputation.
Panicking over a single 421. Temporary deferrals are normal and usually resolve on their own. Watch for patterns, not one-offs.
Skipping SPF, DKIM and DMARC. Major mailbox providers now expect authenticated mail, and unauthenticated messages are increasingly rejected with 5.7.x codes.
Using purchased or scraped lists. They're full of dead addresses and spam traps, which drive up both 550s and 554s.
Reading only the number. The text after the code is where the real diagnosis usually sits.
FAQ
What does a 550 error mean?
The receiving server permanently refused the message. Check the enhanced code: 5.1.1 means the address doesn't exist, while 5.7.x means you were blocked by policy, often because of failed authentication or a blocklist.
How do I fix a 421 error?
Usually you don't need to. Your mail server retries automatically. If 421s keep appearing, reduce your sending speed and check your sender reputation.
What causes a 554 error?
Most 554s are policy rejections: spam filtering, blocklisting, or failed SPF, DKIM or DMARC checks. The text after the code usually names the reason.
What's the difference between a hard and a soft bounce?
A hard bounce (5xx) is permanent, so stop sending to that address until the cause is fixed. A soft bounce (4xx) is temporary and is retried automatically.
What is an enhanced status code?
It's the three-part code after the main reply, such as 5.1.1 or 4.7.0. It pinpoints whether the problem is the address, the mailbox, the network or a security policy.
How can I prevent bounces?
Authenticate your domain with SPF, DKIM and DMARC, validate addresses when people sign up, use double opt-in for marketing lists, and remove hard-bounced addresses promptly.
How often should I clean my email list?
Remove hard bounces after every send. For bulk senders, a broader review of inactive contacts every few months keeps bounce rates low.
Can NevTan Mail help prevent authentication-related bounces?
Yes. NevTan Mail includes guided custom-domain setup with SPF, DKIM and DMARC verification, so messages from your team's mailboxes are authenticated from day one.
Send email that gets delivered
Many of the 550 and 554 rejections above come down to one thing: a domain that isn't properly authenticated. NevTan Mail gives your team secure business email on your own domain, with guided SPF, DKIM and DMARC setup, TLS encryption on every connection, and calendar, tasks and notes in the same workspace. See all features or read what NevTan Mail is and how it works.
