You sent an email — maybe an invoice, a password reset, or just a reply to a client — and ten minutes later it's back in your inbox with a subject line like "Undelivered Mail Returned to Sender" and a wall of text under it. Most people skim past that wall of text, assume the recipient's address is wrong, and move on. Half the time that's not even close to the real problem. The bounce message is actually telling you exactly what went wrong, in a format that looks like gibberish until you know what you're reading.
Read the Bounce Message Before You Guess
Every bounce-back carries an SMTP status code, usually three numbers separated by dots, like 550 5.1.1 or 421 4.7.0. The first digit tells you the category, and it matters more than anything else in the message:
- 2xx — success (you won't see this in a bounce)
- 4xx — temporary failure. The server will keep retrying for a while, usually up to 48-72 hours, before giving up.
- 5xx — permanent failure. The message is dead. Retrying won't help until whatever caused it is fixed.
The second set of numbers (the "enhanced status code," like 5.1.1) narrows it down further. Here are the ones that show up most often in cPanel mail logs:
| Code | Meaning | Typical Fix |
|---|---|---|
| 550 5.1.1 | Recipient address doesn't exist | Check for a typo; confirm the address with the recipient |
| 552 5.2.2 / 4.2.2 | Recipient's mailbox is full | Nothing to fix on your end — ask them to clear space |
| 550 5.7.1 | Message rejected as spam or policy violation | Check SPF/DKIM/DMARC alignment and IP reputation |
| 421 4.7.0 | Temporary block — usually rate limiting or greylisting | Wait and retry; check if you're on a blocklist |
| 554 5.7.1 | Sending IP is blacklisted | Check your IP against major RBLs and request delisting |
| 553 5.1.8 | Sender address rejected — domain doesn't match SPF | Fix SPF record or "From" domain mismatch |
If you only remember one thing from this article, make it this: don't troubleshoot blind. Open the actual bounce and read the code before you touch SPF records, restart Exim, or open a support ticket. It saves a lot of wasted effort.
Cause 1: Typo or Dead Address (550 5.1.1)
This is the most common bounce by a wide margin, and it's also the most boring — nothing on your server is broken. Double-check the address character by character, especially if it was typed by hand or copied from a scanned business card. A missing dot, an extra letter, or a stale address from a contact who left the company will all trigger this exact code. If it worked last month and stopped working now, the recipient's mailbox may have been deleted or the domain itself may have expired — check with a quick dig MX theirdomain.com.
Cause 2: Mailbox Full on Their End
A 552 or soft 4.2.2 means the message reached their mail server just fine, but their inbox has no room left. This is entirely on the recipient's side. If it's an internal address you also manage, log into WHM and check List Accounts > Disk Usage for that mailbox, or have the user clear old mail from Webmail. If it's someone else's inbox, there's nothing to fix — the message will keep queuing for a day or two and then give up.
Cause 3: Your Sending IP Is Blacklisted
A 554 or any bounce text that mentions "blocked," "reputation," or a URL pointing to something like Spamhaus or Barracuda means the receiving server checked your IP against a real-time blocklist and refused the connection outright. Shared hosting IPs get flagged occasionally because of one bad neighbor account sending spam. Check your IP at a site like mxtoolbox.com's blacklist checker, and if it's listed, most blocklists have a self-service delisting form. On SkyServer shared hosting, if your dedicated IP keeps landing on a blocklist despite clean sending, open a ticket — we can usually trace which account triggered it and get it resolved faster than a delisting request alone.
Cause 4: SPF, DKIM, or DMARC Alignment Failure
A 5.7.1 with wording like "not authorized," "SPF check failed," or "message does not comply with DMARC" means the receiving server verified your domain's authentication records and they didn't match up. This usually happens after switching email providers, adding a marketing tool (Mailchimp, HubSpot) that sends "from" your domain without being added to SPF, or after tightening DMARC to p=reject without updating every sending source first. Pull your current SPF record with:
dig TXT yourdomain.com +shortand confirm every service that sends mail as your domain is actually included. A DKIM signature that's missing or broken shows up the same way — check it under cPanel's Email Deliverability tool, which flags any DNS record that doesn't match what cPanel expects.
Cause 5: You Hit an Hourly Sending Limit
If the bounce comes back almost instantly and mentions "exceeded the max emails per hour" or similar, that's not the recipient's server talking — that's your own Exim server refusing to send in the first place. cPanel accounts on shared hosting have a per-hour cap (often 500, but it varies by plan) to stop compromised scripts from turning your account into a spam cannon. Check WHM > Email > Manage Hourly Email Limits if you have WHM access, or ask support to check it on your behalf. If you're legitimately sending high volumes — newsletters, transactional receipts at scale — that traffic belongs on a dedicated SMTP relay like SendGrid or Amazon SES, not through the shared mail queue.
Where to Actually See This in cPanel
Don't rely on guessing from the bounce email alone — cPanel keeps a proper record. Log in and open Email > Track Delivery, then search by recipient address or date. It shows every attempt, the exact SMTP response from the receiving server, and whether it was accepted, deferred, or bounced. This is the single most useful screen for this problem and most people never open it. If you have WHM/root access, the same data lives in more detail under Exim Mail Queue Manager, where you can also see anything still stuck retrying.
Prevention
- Keep SPF, DKIM, and DMARC records current any time you add or remove a sending service — check them after every change, not just at setup.
- Warm up a new sending domain gradually instead of blasting a full contact list on day one; sudden volume spikes are what trigger blocklisting.
- Use a dedicated transactional email service for anything automated at scale (order confirmations, password resets on a busy site) so a shared queue limit never becomes a customer-facing outage.
- Check Track Delivery weekly if your domain sends a meaningful volume of mail — catching a pattern of 5.7.1 bounces early is a lot easier than untangling it after a client complains.
- Never buy or scrape address lists. It's the fastest way to rack up 5.1.1 bounces and tank your sender reputation at the same time.
Frequently Asked Questions
Why did I get a bounce for an email I sent weeks ago?
Some receiving servers queue and retry temporary (4xx) failures for several days before finally giving up and sending a permanent bounce. If you see a bounce for something sent a while back, check the code — it's very likely a 4xx that just took its time to expire.
Does a bounce mean the recipient never saw any part of the email?
Yes, for both 4xx and 5xx bounces the message was never delivered to their mailbox at all. A message that lands in spam still counts as delivered — that's a different problem with a different fix (check SPF/DKIM alignment and content, not the bounce log).
Can I stop bounce notifications from showing up in my inbox?
You can, but we'd recommend against it — bounces are your only signal that something didn't arrive. If the volume is genuinely overwhelming, set up a filter to route them to a dedicated folder instead of deleting them outright.
My bounce message is in a language I don't recognize — what do I do?
Look past the localized text for the SMTP code itself (the three-number sequence like 550 5.1.1) — that part is standardized regardless of the receiving server's language, and it'll tell you the actual cause using the table above.
I fixed my SPF record — why am I still getting 5.7.1 bounces?
DNS changes need time to propagate, and some receiving mail servers cache SPF lookups for hours. Give it up to 24 hours, then re-check your record with a fresh dig TXT query to confirm it actually updated the way you expect before assuming the fix didn't work.
