Decoding Email Bounce-Back Errors: 550, 552, 554 & More

You hit send, and ten seconds later a robot writes back instead of your customer. The subject line says something like "Undelivered Mail Returned to Sender," and buried in it is a three-digit code that means nothing to you. Here's how to actually read that message instead of just resending and hoping.

Symptom: a bounce-back instead of a reply

The email you sent (or one your WordPress site tried to send) comes right back, usually within a minute or two, wrapped in an auto-generated message from either your own mail server or the recipient's. It'll contain a few consistent pieces:

• A numeric SMTP code, like 550, 552, or 421
• An "enhanced status code" in the form X.Y.Z, like 5.1.1 or 4.2.2
• A short human-readable reason - "mailbox unavailable," "message too large," "relay access denied"
• A Diagnostic-Code: header with the raw response from the far-end server

That combination is the actual answer to "why didn't this email arrive." You don't need to guess - the server already told you.

Cause: bounce codes follow a fixed structure

Every bounce (technically a Non-Delivery Report, or NDR) carries two codes stacked together. The first digit of the plain SMTP code tells you whether it's worth retrying:

The enhanced status code (5.1.1, 5.7.1, etc.) narrows it down further - the middle digit is the category (addressing, mailbox, mail system, network, or policy), and the last digit is the specific reason. Here are the ones that show up constantly in cPanel/Exim and Google/Microsoft mail logs:

Fix: match the code to the cause

550 5.1.1 - user unknown

This means the address is misspelled, was deleted, or never existed. Double-check the recipient's address for typos first - it's the address, not your server, nine times out of ten. If you're the one receiving the bounce for your own domain's incoming mail, check cPanel → Email Accounts to confirm the mailbox exists and isn't disabled.

552 5.2.2 - mailbox full

The recipient needs to clear space, not you. If it's happening on your own hosted mailbox, log into cPanel → Email Accounts and check the quota bar next to the account. Either raise the quota or have the user delete old mail (Sent and Trash folders are usually the biggest offenders in webmail).

554 / 550 5.7.1 - blocked or rejected as spam

This is the most common one for hosting customers, and it has three usual causes:

• Missing or broken SPF/DKIM - the receiving server can't verify your domain is allowed to send. Check via cPanel → Email Deliverability, which flags any missing DNS records.
• Your server IP is blacklisted - check it against Spamhaus, Barracuda, and SORBS. A shared IP getting flagged from another tenant's abuse is common on cheap shared hosting.
• Content triggered a spam filter - lots of links, spammy phrases, or an attachment type the recipient blocks (.exe, .zip with macros, etc.).

Run exim -bt user@yourdomain.com over SSH, or check WHM → Track Delivery, to see exactly which rule or filter rejected the message and why.

421 / 450 - temporary failure or greylisting

These aren't errors so much as "try again later." Greylisting is a deliberate anti-spam tactic: the receiving server temporarily refuses a first-time sender, expecting a legitimate mail server to retry within a few minutes - which spam bots usually don't bother doing. If it's a one-off, leave it; Exim will retry on its own for up to 3-5 days by default. If every email to one specific domain keeps hitting 421/450, your server's sending rate is probably too aggressive for their rate limits - space out bulk sends.

552 5.3.4 - message too large

Check the recipient's attachment size limit (Gmail and Outlook both cap around 25MB) against what you sent. For anything bigger, switch to a shared drive link instead of an attachment - it's more reliable anyway.

553 5.1.8 - sender address rejected

The receiving server looked up your domain's MX or SPF record and didn't like what it found - often because the sending address doesn't match a valid, resolvable domain. Confirm your domain's MX record actually points somewhere and SPF includes your sending server (cPanel → Zone Editor if you manage your own DNS).

Where to read the raw bounce message

Don't just read the summary line - open the full bounce email as plain text (in Gmail: the three-dot menu → Show original) and look for the Diagnostic-Code: or Remote-MTA: header. That's the unedited response straight from the receiving server, and it's usually far more specific than the friendly subject line - it'll often name the exact blocklist or filter rule that rejected you.

On the server side, WHM's Track Delivery tool (or /var/log/exim_mainlog over SSH) shows every attempt for a given message, including retries and the exact SMTP response at each hop.

Prevention: stop the bounce before it happens

• Keep SPF, DKIM, and DMARC records valid - check cPanel → Email Deliverability monthly, not just when something breaks
• Validate email addresses at signup (a simple regex plus a confirmation email catches most typos)
• Watch your own IP reputation - if you send bulk mail, use a dedicated sending IP rather than a shared one
• Set a sane mailbox quota and alert users before they hit 100% instead of after
• Don't send large attachments raw - link to cloud storage instead

Most bounce-backs aren't mysterious once you read past the subject line. The code is the diagnosis; you just have to look at it instead of the plain-English summary next to it.