A 550 permanent failure is a hard bounce. The receiving server rejected your message and won’t try again. The code that follows it, like 5.7.26 or 5.1.1, names the reason.
Most people read the word “permanent” and resend. That reproduces the bounce, because nothing has changed.
The number is the useful part. It tells you whether the problem is yours or theirs, and which setting fixes it. Here’s how to read it, and what to do next.
Key Takeaways
- The three-part code after 550 is the fix path. Read it before you change anything.
- The sub-code says whose problem it is. The .1, .2 and .4 families point at the recipient. The .7 family points at you.
- Most modern 550s are authentication rejections. Google and Microsoft both enforce SPF, DKIM and DMARC at the door now.
- Resending the same message from the same setup reproduces the same bounce.
What “550 Permanent Failure” Actually Means
SMTP replies come in two kinds. A 4xx is temporary, so the sending server queues the message and retries. A 5xx is permanent, and nothing retries.
That’s the whole difference: a 550 means the receiving server made a decision it doesn’t expect to reverse.
The detail lives in the enhanced status code, the three-part number defined in RFC 3463. Read it as class, subject, detail.
You can tell a lot from the middle digit alone:
- .1 – the address itself. Wrong, missing or not accepted.
- .2 – the mailbox. Full, inactive or over quota.
- .4 – routing. The server doesn’t handle mail for that domain.
- .7 – security or policy. Authentication, reputation or a rule that blocked you.
A .7 is yours to fix, and a .1 or a .2 usually isn’t.
Find Your Sub-Code: The 550 Cheat Sheet
Find your code in the left column. Every row comes from Google’s or Microsoft’s own documentation.
| Code | What it means | Whose side | What fixes it |
|---|---|---|---|
| 5.1.1 | The account doesn’t exist | Recipient | Check the address for typos |
| 5.1.10 | Recipient not found (Microsoft) | Recipient | Confirm the address is still active |
| 5.2.1 | The account is inactive, or rate-limited | Recipient | Nothing on your side |
| 5.2.2 | The mailbox is out of storage | Recipient | Reach them another way |
| 5.4.1 | Relay access denied (Microsoft) | Recipient | Their DNS or routing is wrong |
| 5.4.5 | Daily sending limit exceeded | You | Spread the send across more mailboxes |
| 5.7.0 | Relay denied, invalid credentials (Google) | You | Fix the SMTP credentials |
| 5.7.1 | A policy prohibits the message | Either | Ask the receiving admin which policy fired |
| 5.7.1 | Delivery not authorized (Microsoft) | Recipient | Their rules block outside senders |
| 5.1.8 | Bad outbound sender (Microsoft) | You | Secure the account, then appeal |
| 5.7.23 | SPF violation (Microsoft) | You | Publish or correct your SPF record |
| 5.7.25 | The sending IP has no PTR record | You | Add reverse DNS for the sending IP |
| 5.7.26 | Unauthenticated sender (Gmail) | You | Publish SPF, add DKIM |
| 5.7.27 | Failed SPF (Gmail) | You | Fix the record so the sending host passes |
| 5.7.28 | Unusual rate of unsolicited mail from your IP | You | Stop, clean the list, warm up |
| 5.7.30 | Failed DKIM (Gmail) | You | Publish the key, sign with your domain |
| 5.7.40 | No DMARC record, or no policy in it | You | Publish DMARC, start at p=none |
| 5.7.509 | Fails DMARC at p=reject | You | Align the From domain with SPF or DKIM |
| 5.7.515 | Outlook.com high-volume rule | You | Authenticate fully before bulk sending |
| 5.7.606–649 | Sending IP banned (Microsoft) | You | Request delisting |
One more fits no table. Many companies sit behind a filtering appliance, so the 550 comes back written by Barracuda, Proofpoint or Mimecast.
The text names the vendor and usually a reason, so treat it as a policy block and follow the link.
Is It You or the Recipient?
There’s a test, and it takes two minutes. Send the same message, from the same mailbox, to a Gmail address and a Microsoft 365 address you control.
If both bounce, the problem is yours. If only one bounces, the problem sits with that provider or that recipient.
The codes agree with the test. A .1, .2 or .4 is almost always recipient-side. The .7 family and Microsoft’s 5.1.8 are yours.
Read the full bounce. Paste the message into our free email header analyzer to see the authentication results in plain text.
Fix It Now: Gmail and Google Workspace
Google tightened this in February 2024 with its bulk sender requirements. Almost every Gmail 550 now traces back to authentication, reputation or a limit.
You’re Seeing 5.7.26, 5.7.27, 5.7.30 or 5.7.40 (Authentication)
These four are one problem with four faces. Gmail checked who you are and didn’t get an answer it trusts. Work through them in order:
- Publish an SPF record that lists whatever actually sends your mail.
- Turn on DKIM and sign with your own domain, not your provider’s.
- Publish DMARC at p=none to start.
- Make the visible From domain match the domain that passes SPF or DKIM.
Our SPF, DKIM and DMARC generators will write the records for you.
Then wait for DNS to propagate. One fresh test tells you more than another blast at the same list.
You’re Seeing 5.7.1 (Reputation) or 5.4.5 (Sending Limits)
5.4.5 is the daily cap, and it’s arithmetic rather than reputation. Google Workspace allows 2,000 messages a day and 3,000 external recipients. Trial accounts get 500. Split the send across days or across more mailboxes.
5.7.1 is a policy block, and more serious. Pause the campaign, check your domain and IP against the blacklists, then warm the domain back up before you resume.
A note on Postmaster Tools. Google’s reputation dashboard covers mail sent to personal Gmail addresses only. It won’t show you anything about the Workspace mailboxes most B2B outreach lands in.
Fix It Now: Microsoft 365 and Outlook
Microsoft rejects the SMTP layer too, and its codes are the more specific of the two.
You’re Seeing 5.7.23, 5.7.509 or 5.7.515 (Authentication and DMARC)
5.7.23 means your SPF record failed on the receiving side, so publish it or correct the hosts it lists.
5.7.509 is stricter. Your From domain fails DMARC and publishes p=reject, so Microsoft honours your own policy and drops the message. Align the From domain with whatever passes SPF or DKIM.
5.7.515 comes from Outlook’s requirements for high-volume senders, enforced from 5 May 2025. Send more than 5,000 a day to Outlook.com addresses without full authentication and you’re rejected.
Here’s the trap that catches most people. DKIM signs with the sending platform’s domain rather than yours. SPF passes on that same domain, and DMARC still fails, because neither aligns with the From address.
You’re Seeing 5.4.1 (Recipient) or 5.1.8 (Bad Outbound Sender)
5.4.1 is relay access denied. The receiving server doesn’t accept mail for that domain at all, which is their DNS or routing. Tell them.
5.1.8 is the one to take seriously. Microsoft blocked your account for sending spam, and that usually means it was compromised.
Change the password, check for forwarding rules you didn’t create, then request the unblock through the Microsoft 365 admin centre.
How to Stop 550s Coming Back
One bounce is a fault. A pattern is a reputation problem, and reputation takes longer to repair than DNS. Four habits cover most of it:
- Authenticate every domain you send from, including the occasional ones.
- Verify the list before you send. Dead addresses are what produce 5.1.1 at volume.
- Stay under the provider’s limits rather than at them.
- Keep cold outreach on a separate domain, so a bad week never touches your main one.
And warm the domain. A new one needs three to four weeks. A damaged one needs four to six, because you’re rebuilding a reputation rather than starting one.
Improve your deliverability rate to as much as 96% with TrulyInbox. From 2 October 2026, TrulyInbox monitors 44 domain and 38 IP blacklists. A listing shows up on the dashboard instead of in a bounce.
Close
The sub-code is the diagnosis. Read it, and the fix follows from it.
If 550s keep arriving after you’ve fixed the records, you have a reputation problem rather than a configuration one.
Run the deliverability checklist, then warm the domain properly with our email warmup platform.
Frequently Asked Questions
1. How Can I Fix the 550 Permanent Failure Error for One or More Recipients?
Read the sub-code first. If it’s 5.1.1 or 5.1.10, those addresses don’t exist, so remove them. A .7 code applies to your whole send instead. Fixing SPF, DKIM and DMARC clears it for every recipient at once.
2. How Do I Fix a 550 Error?
Find the three-part code in the bounce, then match it to its cause. Authentication codes need DNS records, limit codes need a slower send, and recipient codes need the address corrected or removed.
3. What Does a 550 Error Code Mean?
It means the receiving server rejected your message permanently and won’t retry. The 550 says only that. The enhanced code beside it, such as 5.7.26 or 5.2.2, carries the reason.
4. Why Am I Getting a Permanent Error for Email?
Usually one of three things. Your domain fails authentication, the address doesn’t exist, or your reputation triggered a policy block. The sub-code tells you which: a .7 is yours, a .1 or .2 is theirs.
5. Is 550 5.7.26 a Sender or Recipient Problem?
Yours. Google returns 5.7.26 when neither SPF nor DKIM passes, so Gmail can’t confirm who sent the message. Publish an SPF record, enable DKIM on your own domain, then send a fresh test.
6. Will Resending the Same Email Fix a 550?
No. A 550 is permanent, so the same message from the same setup gets the same answer. Repeated attempts add failures to your sending history. Fix the cause first.
