550 Permanent Failure Email Error: Causes and Fixes (2026)

You launch a campaign, and ten minutes later the bounces arrive. Each one says 550 permanent failure for one or more recipients.

That 550 permanent failure tells you the message is dead. It does not tell you why, and the fix for a typo is very different from the fix for a blocklisted domain.

This guide decodes the enhanced codes that follow 550, using the exact bounce text Gmail and Microsoft 365 return. You get a fix for each code, the bounce rates that put a domain at risk, and a way to stop invalid addresses before they ever bounce.

Code meanings come from RFC 5321, RFC 3463, Google's Gmail SMTP error reference and Microsoft Learn, checked October 2026.

TL;DR: 550 Permanent Failure

• 550 is permanent. The receiving server refused the message, and retrying will not change the answer.
• The enhanced code is the diagnosis. 5.1.x is a bad address, 5.2.x a dead mailbox, 5.4.x a routing problem, and 5.7.x a policy or reputation block.
• 550 5.1.1 user unknown: the mailbox does not exist. Remove the address and never send to it again.
• 550 5.7.1 blocked: the server refused you on purpose. Check reputation, blocklists, and authentication.
• Relay denied: a server will not pass your mail on. Turn on SMTP authentication or fix relay settings.
• Keep hard bounces under 2% per campaign, and verify every list before upload.

What Does 550 Permanent Failure Mean?

A 550 permanent failure is an SMTP rejection: the receiving server refused your message and will not accept it if you try again. RFC 5321, the standard that defines SMTP, describes reply code 550 as “Requested action not taken: mailbox unavailable,” for example mailbox not found, no access, or command rejected for policy reasons.

The first digit carries the meaning: 2 means accepted, 4 means try again later, and 5 means the failure is permanent. That is why a 550 counts as a hard bounce, while a 4xx reply is a soft bounce your server retries on its own.

The phrase “for one or more recipients” comes from the bounce notice your own server sends back. It means at least one address on the message failed, while others may have been delivered.

Enhanced status codes: the part that matters

The 550 on its own is vague. The enhanced status code after it, defined in RFC 3463, tells you the real reason.

It reads class.subject.detail. In 5.1.1, the first 5 is the class (permanent), the 1 is the subject (addressing), and the last 1 is the detail (bad destination mailbox).

How to Read a 550 Bounce Message

Every bounce carries three clues: the reply code, the enhanced code, and the text the receiving server wrote. Here is a typical Gmail bounce for a mailbox that no longer exists.

From: Mail Delivery Subsystem <mailer-daemon@googlemail.com>
Subject: Delivery Status Notification (Failure)

Address not found
Your message wasn't delivered to jane.doe@example.com because the
address couldn't be found, or is unable to receive mail.

The response from the remote server was:
550 5.1.1 The email account that you tried to reach does not exist.
Please try double-checking the recipient's email address for typos
or unnecessary spaces.

• 550: the SMTP reply code. Permanent failure, do not retry.
• 5.1.1: the enhanced code. An addressing problem with the destination mailbox.
• The text:the provider's own explanation. Search this exact phrase in the provider's error reference.
• The rejecting server: the Remote-MTA line in the raw bounce shows whose rule fired. A Google host means Gmail rejected you, and a protection.outlook.com host means Microsoft did.

Gmail lists its codes in the Gmail SMTP errors and codes reference, and Microsoft documents its NDR codes on Microsoft Learn. Match the exact text, not just the number.

Sender Problem or Recipient Problem?

Before fixing anything, work out whose problem it is. The subject digit answers that most of the time.

Rule of thumb: 5.1 and 5.2 codes are list problems, and 5.7 codes are sender problems. The 5.4 codes can go either way.

Microsoft is the exception to watch. Its 550 5.4.1 Recipient address rejected: Access denied is a user-unknown bounce in disguise.

550 Error Codes and Fixes: Quick Reference

This table maps the 550 codes cold emailers see most, with the wording Gmail and Microsoft 365 use. Bounce text is shortened from each provider's published reference.

550 5.1.1 User Unknown

550 5.1.1 means the mailbox does not exist on the receiving server. Gmail words it as “The email account that you tried to reach does not exist,” and Microsoft as “Bad destination mailbox address.”

What causes 550 5.1.1

• Typos: a missing letter, a stray space, or .con instead of .com.
• Job changes: the person left the company, their mailbox was deleted, and the address on your list is now dead.
• Guessed addresses: pattern guesses like firstname.lastname@ sent without verification are a common source of 5.1.1 bounces in cold email.
• Domain changes: after a rebrand or acquisition, old addresses stop forwarding.

Microsoft tenants return two cousins of this code. 550 5.1.10 “Recipient not found” and 550 5.4.1 “Recipient address rejected: Access denied” both mean the address does not exist.

The second comes from Directory Based Edge Blocking, which rejects unknown recipients before the message enters the tenant.

How to fix 550 5.1.1

1. Check the address for typos against the original source.
2. Remove it from the campaign and add it to your sequencer's suppression list, so no future campaign sends to it.
3. If the contact still matters, find their current address. A 5.1.1 on a contact who was valid three months ago usually means a job change.
4. Verify the rest of the list before the next send. One 5.1.1 is a data point; ten in a batch means the whole list is aging.

Never retry a 5.1.1. Resending to a known-dead mailbox is one of the clearest signs of poor list hygiene a mailbox provider can see.

550 5.7.1 Blocked or Rejected as Spam

550 5.7.1 is the catch-all policy rejection. The receiving server read your message, applied a rule, and refused it on purpose.

Because it covers so much, the text after the code is everything. Look for one of these patterns.

Common 550 5.7.1 causes

• Spam or low reputation:Gmail's “This message is likely unsolicited email” or “likely suspicious due to the very low reputation of the sending domain.” Your domain or IP reputation has dropped.
• Blocklist:text that names a list, such as “blocked using zen.spamhaus.org,” means your IP or domain is listed.
• Recipient restrictions:Microsoft's “Delivery not authorized” means the recipient only accepts mail from certain senders, such as a group limited to members. Only their admin can change that.
• No authentication:Microsoft's “Client was not authenticated” means your tool connected without SMTP credentials.
• Bad format: Gmail rejects messages that break RFC 5322, such as a missing Message-ID or multiple From headers. This mostly hits homegrown sending scripts.
• Rate:Gmail's “This email has been rate limited” means you sent too much, too fast.

How to fix 550 5.7.1

1. Read the full text and match it to the provider's reference.
2. Look up your sending IP and domain on Spamhaus and the MXToolbox blacklist check.
3. Check domain reputation and spam rate in Google Postmaster Tools.
4. Confirm SPF, DKIM and DMARC pass, using the checks in the authentication section below.
5. Pause the affected campaign, cut daily volume, and verify the list before restarting.
6. If Microsoft blocked your IP, fix the cause first, then request removal through the Microsoft delist portal.

If the rejection is a recipient restriction, nothing on your side will fix it. Reach the person through LinkedIn or a call, and drop the address from email sequences.

550 Relay Denied

Relay denied means a server refused to pass your message on toward its destination. Microsoft returns “5.7.1 Unable to relay” or “5.4.1 Relay Access Denied,” and Google's SMTP relay returns “550 5.7.0 Email relay denied.”

It shows up in three situations, and each has a different fix.

1. Your sending tool is not authenticating

Your sequencer or app connected to an SMTP server without valid credentials, so the server treated it as an anonymous relay attempt. Microsoft 365 may return a related 5.7.57 “Client was not authenticated to send anonymous mail” error here too.

Turn on SMTP authentication, use the full email address as the username, and connect on port 587 with STARTTLS. Our guides to Office 365 SMTP settings and Gmail IMAP and SMTP settings list the exact values for each provider.

2. Your SMTP relay does not trust your IP

Google Workspace's SMTP relay service only accepts mail from IP addresses or accounts you allow. If your server's IP changed, you get “Email relay denied” or “Invalid credentials for relay.”

In the Google Admin console, open Apps > Google Workspace > Gmail > Routing > SMTP relay service. Add the new IP, or require SMTP authentication instead of IP allowlisting.

3. The recipient's MX record points to the wrong server

Microsoft's “Relay Access Denied” often means the recipient domain's MX record points to a server that does not host that domain. You cannot fix their DNS.

Run dig +short MX theirdomain.com to confirm. If the domain has no valid MX, remove the contact; if it looks misrouted, tell them through another channel.

550 Errors From SPF, DKIM and DMARC Failures

Since February 2024, Google's sender guidelines require every sender to pass SPF or DKIM. Anyone sending more than 5,000 messages a day to Gmail must pass SPF, DKIM and DMARC, with the From domain aligned.

Microsoft has its own version for Outlook.com. High-volume domains that fall short get 550 5.7.515, “sending domain doesn't meet the required authentication level.”

Authentication failures produce their own 550 codes:

• 550 5.7.26 (Gmail):unauthenticated, or failed the domain's DMARC policy.
• 550 5.7.27 and 5.7.30 (Gmail): SPF or DKIM failed.
• 550 5.7.40 (Gmail): no DMARC record on the sending domain.
• 550 5.7.25 (Gmail): the sending IP has no PTR (reverse DNS) record.
• 550 5.7.23 (Microsoft): SPF violation.
• 550 5.7.509 (Microsoft):DMARC failed and the domain's policy is reject.
• 550 5.7.515 (Outlook.com): a high-volume domain below the required authentication level.

Check every record from a terminal:

# Recipient domain: does it accept mail at all?
dig +short MX example.com

# Your SPF record (exactly one, starting with v=spf1)
dig +short TXT yourdomain.com | grep spf1

# Your DKIM key (selector varies: google, selector1, s1...)
dig +short TXT google._domainkey.yourdomain.com

# Your DMARC policy
dig +short TXT _dmarc.yourdomain.com

# Reverse DNS for a sending IP (should return a hostname)
dig +short -x 203.0.113.25

A minimal setup for a Google Workspace sending domain looks like this. Microsoft 365 domains use include:spf.protection.outlook.com and two DKIM CNAME records instead.

SPF    TXT  @                   v=spf1 include:_spf.google.com ~all
DKIM   TXT  google._domainkey   v=DKIM1; k=rsa; p=<public key from Google Admin>
DMARC  TXT  _dmarc              v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Publish only one SPF record per domain, and keep it under 10 DNS lookups. Start DMARC at p=none, read the reports, and tighten to quarantine once every sending source passes.

Other 550 Variants: Inactive, Full, Rate Limited

A few 550 bounces do not fit the three big buckets.

• 550 5.2.1 inactive account (Gmail): the mailbox exists but is disabled. Treat it like a user unknown and remove it.
• Mailbox full: the standard reply is 552 5.2.2, a soft bounce, but some servers send it as a 550. Retry for a few days, then remove the address if it keeps failing.
• 550 5.4.5 daily sending limit exceeded (Gmail): this one is about you, not the recipient. Your Google Workspace mailbox hit its daily cap, which resets on a rolling 24-hour window.
• 550 5.1.8 bad outbound sender (Microsoft 365): Microsoft blocked your own mailbox for sending spam, often after a compromise or a bad campaign. An admin must release it from Restricted entities in Microsoft Defender.
• 550 5.7.606 to 5.7.649 (Microsoft): your sending IP is banned. Fix the cause, then request delisting.

How 550 Bounces Damage Sender Reputation

Mailbox providers watch how often your mail hits addresses that do not exist. Senders who collect addresses with consent rarely hit dead mailboxes, so a high unknown-user rate looks like a bought or scraped list.

The damage compounds in four ways.

• Lower inbox placement: as domain reputation drops, more of your good mail lands in spam, not just the bounced mail.
• Spam traps: some long-abandoned addresses are recycled into spam traps. They stop bouncing, accept your mail, and flag you as a sender with a stale list.
• Blocklisting: a listing turns a list problem into 5.7.1 rejections at every server that checks that list.
• Domain-wide spillover: every inbox on the same domain shares the damage, so one bad list can stall a whole cold email setup.

Google also tracks spam complaints. Its sender guidelines say to keep the spam rate in Postmaster Tools below 0.1% and never let it reach 0.3%.

Bounce rate thresholds for cold email

Mailbox providers do not publish a hard bounce limit. These are the working thresholds we recommend for cold email programs.

How to Fix a 550 Permanent Failure: 7 Steps

Work through these in order. Most 550 problems are solved by step 3.

1. Read the full bounce. Note the enhanced code, the exact text, and the server that rejected you.
2. Suppress dead addresses.Add every 5.1.x and 5.2.1 address to your sequencer's blocklist so it never gets mail again.
3. Verify the rest of the list. If one batch produced several unknown-user bounces, verify every unsent contact before the next step goes out.
4. Check SPF, DKIM and DMARC. Use the dig commands above, or send a test to a Gmail address and open Show original: all three should say PASS.
5. Check blocklists. Look up your sending IP and domain on Spamhaus and MXToolbox. Request removal only after the cause is fixed.
6. Check reputation dashboards.Google Postmaster Tools shows domain reputation and spam rate. Microsoft's SNDS shows data for IPs you control.
7. Slow down and rebuild. Keep warmed inboxes at 30 to 50 sends a day and re-warm any burned domain. Our domain warm-up guide covers the schedule.

How to Prevent 550 Errors in Cold Email

Fixing bounces after they happen costs reputation you have to earn back. Prevention costs a fraction of a credit per contact.

• Verify every list before upload. That includes vendor lists sold as verified, because data ages between their check and your send.
• Re-verify anything older than 30 days. People change jobs constantly, and every move turns a valid address into a future 5.1.1.
• Segment catch-all domains. Catch-all servers accept every address during the SMTP check, then may bounce later. Send to them in a smaller, separate campaign and watch the bounce rate.
• Skip role addresses like info@ and sales@ for cold outreach. They draw more complaints and rarely reach a decision maker.
• Authenticate before the first send. SPF, DKIM and DMARC on every sending domain, with a PTR record set by your provider.
• Use separate sending domains so a bad campaign cannot hurt your primary domain.
• Warm up and cap volume: 30 to 50 sends per inbox per day after warmup. Our roundup of cold email warm-up tools compares the options.
• Turn on hard-bounce auto-suppression in your sequencer, so no 550 address gets a second email.

If you want a standalone verifier, our comparison of email validation services ranks the main options.

Verify Emails Before They Bounce With SyncGTM

SyncGTM stops 550 5.1.1 bounces at the source by checking every address before it reaches your sequencer. The Verify Email action runs waterfall verification across multiple providers and flags catch-all, disposable and role-based addresses.

Verification costs 0.1 credits per address. Find Work Email costs 1 credit, tries several data providers in turn, and charges nothing when no email is found.

That pairing fixes the job-change problem too. When a contact bounces with 5.1.1, look up their new work email instead of losing the lead.

Clean contacts sync straight into Instantly, Smartlead, or your CRM. Credit packs are on the SyncGTM pricing page.

Conclusion

A 550 permanent failure is the receiving server saying no, for good. The enhanced code after it tells you whether the problem is your list, your setup, or your reputation.

Remove 5.1.x addresses on the first bounce, fix SPF, DKIM and DMARC for authentication codes, and treat 5.7.1 as a reputation warning. Keep hard bounces under 2%, and the code rarely shows up again.

Start with a clean list: verify your next campaign with SyncGTM before it goes out.