Email Bounce Code 550: What It Means and How to Fix It

If you sent an email and it came back with a three-digit error starting with 550, you are looking at a permanent rejection by the recipient's mail server. The good news is that 550 is not a single error, it is a family of related ones, and once you know which variant you have you can usually fix the underlying cause in minutes. The bad news is that "550" by itself does not tell you why, so you have to read the rest of the bounce message before you do anything.

This guide unpacks what the 550 code means, the common variants you will see (5.1.1, 5.4.1, 5.7.1, 5.7.26), what causes each one, the step-by-step fix path, and how to keep them from coming back.

What email bounce code 550 means

A 550 is an SMTP response code. SMTP servers reply to every step of a mail conversation with a three-digit code: 2xx for success, 4xx for a temporary problem, and 5xx for a permanent one. Code 550 sits in the 5xx family, which means the recipient server received your message, looked at it, and rejected it permanently. The sender should not retry as-is. It is a hard bounce by definition.

The contrast with the 4xx family matters. A 4xx response, like the ones described in our guide to the transient email error, is a "come back later" reply where automated retry usually solves the problem. A 550 says: this attempt will never succeed under the current conditions. Resending without changing anything just guarantees a second 550.

Most 550 responses are extended with an enhanced status code (5.1.1, 5.4.1, 5.7.1, etc.). The first digit still indicates permanent vs temporary, the rest narrows down the category (address problem, relay problem, policy problem, authentication problem).

How to read a 550 bounce message

A bounce message arrives as a Delivery Status Notification (DSN) in your inbox, usually with a subject like "Mail delivery failed" or "Undelivered Mail Returned to Sender". It contains three useful elements: the numeric SMTP code, the enhanced status code, and a free-text explanation written by the receiving server.

A typical fragment looks like:

Remote host said:
    550 5.1.1 <[email protected]>: Recipient address rejected: User unknown
Reporting-MTA: dns; mail.yourdomain.com
Action: failed
Status: 5.1.1

The three pieces to look at:

• The three-digit code (550 here) tells you the failure family.
• The enhanced status (5.1.1) refines the reason. The first digit is the class (5 = permanent), the second is the subject (1 = address), the third is the detail.
• The text after the code, written by the remote system, names the exact problem: "User unknown", "Mailbox full", "Relay access denied", "Policy violation", "SPF check failed", and so on.

Copy that line verbatim into your notes before you do anything else. If you contact a recipient's admin or your ISP's support, that line is what they will ask for.

The main types of 550 errors

The variants you are most likely to see, grouped by category:

• 550 5.1.1 Recipient address rejected, User unknown: The mailbox does not exist on that domain. Usually a typo or an outdated address.
• 550 5.2.1 Mailbox full: The recipient's storage quota is exceeded.
• 550 5.4.1 Relay access denied: The SMTP server you tried to send through does not recognize you as an authorized user. Typical when sending via a home ISP's server while connected to a hotel or office network.
• 550 5.7.1 Message rejected (spam or policy): The receiving server's filters decided your message looks like spam, your IP or domain has poor reputation, or your message violated a published policy.
• 550 5.7.26 Authentication failure (SPF or DKIM): Your message did not pass SPF, DKIM, or DMARC checks at the recipient end.

Treating all of these as one error is the most common mistake people make with 550. A user-unknown 5.1.1 is a list-hygiene problem, a 5.7.1 spam rejection is a reputation problem, and a 5.4.1 relay denial is a client-configuration problem. The fix path is entirely different for each.

What causes a 550 error

Recipient-address problems

The simplest causes: a typo, an outdated address, a deleted account, or a mailbox over its storage quota. These produce 5.1.1, 5.1.0, or 5.2.1 codes. The fix is on the recipient side (clean up the quota) or on the sender side (confirm and correct the address before resending).

Relay and authentication problems

When the error mentions "relay denied" or "authentication failure", the SMTP server you are trying to send through is saying it does not trust you to send this message. Most common scenarios: you have your email client configured to send via your home ISP's outgoing server but you are connected to a different network (hotel wifi, the office, an airport), or SMTP authentication is disabled in the client and the server does not let unauthenticated clients relay mail.

The fix in this category is operational rather than reputational: switch the outgoing SMTP server to one matching your current network, or enable SMTP authentication in the client so the server can verify you are an authorized user.

SPF, DKIM, and DMARC failures

A growing share of 550 5.7.x errors come from sender-authentication mismatches. The receiving server checks the sending IP against the domain's SPF record, verifies the DKIM signature, and applies the DMARC policy. If SPF lookup fails, if the DKIM signature does not match, or if DMARC is set to reject and the message is not aligned, the server replies with a 550. This is more common right after a domain change, an ESP migration, or when a third-party tool (CRM, helpdesk, transactional sender) starts sending on your behalf without being authorized in SPF.

Spam and policy rejections

A 550 5.7.1 from a major mailbox provider usually means your message tripped the spam filter or your sending IP and domain reputation are poor. Triggers include a blocklisted sending IP, a brand-new domain ramping volume too fast, spam-pattern content, or a clean sender behaving badly on a shared IP because another tenant abused it. Improving your sender reputation is the only durable fix. Resending the same message does nothing.

Volume and rate triggers (especially Gmail)

Major providers enforce rate limits even when content is fine. Gmail's hard ceiling is 500 sends per day from a free account and 2,000 per day on a Workspace account. Exceeding either can produce a "550 Message Rejected" notice, and Gmail has thrown 550s for cold-outreach patterns around 100 sends per day from new domains. Cold outreach in 2026 typically needs a warmed-up sender, not a fresh domain blasting volume.

How to fix an email bounce code 550

Work through these steps in order. Skip ahead only when the previous step is already confirmed.

1. Classify the variant: Pull the full bounce text. Identify the enhanced status (5.1.1, 5.4.1, 5.7.1, 5.7.26, and so on) and the human-readable reason. The variant decides which of the next steps applies.
2. For address errors (5.1.x): Confirm the recipient address spelling. If a customer's CRM record was updated recently, check the new value. If the recipient's mailbox is full (5.2.1), reach them another way and ask them to free space.
3. For relay errors (5.4.1): Enable SMTP authentication in your email client, and verify it is using the SMTP server matching your current network. If you are away from your home network, switch the outgoing server to the one provided by your current ISP or use webmail.
4. For authentication errors (5.7.26 and many 5.7.x): Audit your SPF record. Make sure every sending source (ESP, CRM, helpdesk, internal mail server) is included and the record stays within the 10-DNS-lookup limit. Confirm DKIM is enabled and signing on every sending source. If DMARC is set to reject, confirm your authenticated domain aligns with the visible from-domain.
5. For spam and policy rejections (5.7.1): Check whether your sending IP or domain is on a public blocklist. If it is, follow the specific delisting procedure. Fix the reason you ended up there before re-applying. If your IP is shared, consider moving critical mail to a dedicated IP and warming it up.
6. For Gmail rate-limit 550s: Throttle sends to stay below the 500-per-day (free) or 2,000-per-day (Workspace) ceiling. For cold outreach, warm up the sender and add volume gradually rather than scaling instantly.
7. Verify before retrying: Send a test message to a mailbox you control on the same provider. Confirm it arrives and that no 550 returns. Only then resume normal sending to the original recipient.

How to prevent 550 errors going forward

Keep authentication aligned

Publish SPF, DKIM, and DMARC for every domain you send from, and audit them whenever you add a sending source. A clean authentication setup eliminates the largest single bucket of 550 5.7.x errors before they happen.

Maintain list hygiene

Verify recipient addresses before sending, especially for newsletters and cold outreach. Hard bounces from invalid addresses inflate your bounce rate, and ESPs that watch bounce rate will lower your sender score even when individual sends look fine. Aggressively remove repeat hard-bouncers from your list.

Watch your sending volume

Sudden volume spikes look spammy. Warm up new domains and IPs gradually, add only as much daily volume as engagement metrics support, and isolate one-off campaign sends from the steady transactional traffic so a bad campaign cannot drag everything else down. The full playbook lives in our guide on how to improve email deliverability.

Separate transactional from marketing

If you run both kinds of mail from the same domain, a poorly-targeted marketing campaign can drop your sender reputation and start producing 550s on transactional emails (order confirmations, password resets). Many senders solve this by putting marketing on a dedicated subdomain so reputation hits do not bleed into transactional traffic.

Monitor and respond to bounces continuously

550 codes are not a one-off cleanup. Set up an alert when your hard bounce rate jumps, and investigate the specific 5.x.x variant within hours rather than days. Catching a 5.7.1 spike on a new sending IP within the same day usually means a one-day reputation dip. Catching it a week later usually means weeks of recovery work.

The shortest version: read the enhanced status code, fix the specific category, and verify before resending. That alone closes the loop on most 550 bounces senders ever see.