InboxRatio
Check your domain

SMTP error 550: one code, two opposite problems, and the fix for each variant

RFC 5321 gives 550 a single line: requested action not taken, mailbox unavailable, followed by three examples in parentheses. Mailbox not found. No access. Command rejected for policy reasons. The first example is a problem with the recipient; the last is a problem with you. A bare 550 doesn't say which, and that is why generic advice about the "550 error email" so often misfires.

The digits settle one thing. A reply starting with 5 is a permanent negative completion: the receiver has refused, and the client shouldn't repeat the same request unchanged. What was refused, and why, lives in the rest of the line. This guide is the fix-it layer; the full code grammar is in the SMTP reply codes reference.

Read the whole line first

A complete rejection has three parts:

550 5.1.1 The email account that you tried to reach does not exist.

The basic code (550) sets the retry contract. The enhanced status code (5.1.1) follows RFC 3463's class.subject.detail grammar, and its middle number names the problem area: x.1.x addressing, x.2.x the mailbox, x.4.x network and routing, x.7.x security or policy. The text is the receiver's own explanation. In a bounce message, the same line sits in the Diagnostic-Code: field; email bounce back shows where to find it.

One caveat governs everything below. M3AAWG's Sender Best Common Practices note that most receivers return status codes that follow the RFCs, while the descriptive text varies greatly from one receiver to the next. Some codes even shift meaning: Microsoft's Exchange Online documentation uses 5.2.2 for a sender exceeding its submission quota, while RFC 3463 and Gmail use x.2.2 for a full mailbox. Read each code against the documentation of whoever sent it.

The variants at a glance

| Enhanced code | Typical text (documented by) | Whose problem | Fix | |---|---|---|---| | 5.1.1, 5.1.10 | Account does not exist; recipient not found (Gmail, Microsoft) | Recipient address | Correct or suppress | | 5.2.1 | Account is inactive (Gmail) | Recipient mailbox | Suppress | | 5.7.26, 5.7.27, 5.7.30, 5.7.23, 5.7.515 | Sender unauthenticated; SPF or DKIM failed (Gmail, Microsoft) | Your authentication | Repair SPF, DKIM, DMARC | | 5.7.25 | Sending IP lacks a matching PTR record (Gmail) | Your DNS | Repair reverse DNS | | 5.7.1 | Policy prohibits the message; delivery not authorized (Gmail, Microsoft) | Recipient policy or your reputation | Investigate before resending | | 5.7.1, 5.7.57, 5.4.5 | Unable to relay; client not authenticated; daily sending limit (Microsoft, Gmail) | Your own outbound server | Fix submission or quota |

Variant one: the address does not exist

M3AAWG's Sender Best Common Practices name "user unknown" the most common permanent failure. Gmail returns 550 5.1.1 with text saying the account you tried to reach does not exist and asking you to check for typos or unnecessary spaces. Microsoft's documentation lists 5.1.1 as "Bad destination mailbox address" and 5.1.10 as "Recipient not found". Yahoo's error-code page shows the same condition as a 554 delivery error stating that the user doesn't have a yahoo.com account. RFC 3463 defines x.1.1 plainly: the mailbox specified in the address does not exist.

For a one-off message, check the spelling, then ask the recipient for a current address; Microsoft's documentation notes that resending the original message causes the same failure. For list mail, suppress the address on the first occurrence. A 5.1.1 is the textbook hard bounce, and repeated sends to mailboxes that don't exist count against your sender reputation.

If every address at one domain fails together, check the domain before blaming the addresses. A missing or broken MX record shows up in seconds in the MX lookup, and RFC 3463's x.1.2 covers a destination system that doesn't exist or can't accept mail. Microsoft's 5.4.1 needs a second look for the same reason: its documentation uses the code both for "Recipient address rejected: Access denied", meaning the address doesn't exist, and for "Relay Access Denied", meaning the receiving server doesn't accept mail for that domain at all, which Microsoft attributes to a mail server or DNS misconfiguration.

Variant two: the mailbox exists but won't accept mail

RFC 3463's x.2.1 describes a mailbox that exists but is not accepting messages, and Gmail's text for 550 5.2.1 says the account is inactive. The outcome matches variant one: suppress. Don't confuse it with a full mailbox. Gmail reports that as a temporary 452 4.2.2, which gets retried, and escalates to a permanent 552 5.2.2 only when the inbox is both out of storage and inactive.

Variant three: your authentication failed

This family has grown since the mailbox providers made authentication a condition of delivery. Gmail documents 550 5.7.26 for unauthenticated senders, with text stating that Gmail requires all senders to authenticate with either SPF or DKIM, plus 550 5.7.27 and 550 5.7.30 for bulk mail that fails SPF or DKIM respectively. Microsoft's Exchange Online documentation lists 5.7.23 for a Sender Policy Framework violation at the destination, and Outlook.com rejects non-compliant high-volume mail with 550 5.7.515, as documented on our Outlook sender requirements page.

The recipient is irrelevant here: every address at that provider will fail the same way. Run your domain through the email authentication checker, then work the specific fault. It may be a broken SPF record (SPF permerror covers the five ways records break), a sending service that isn't signing with your DKIM key, or a DMARC failure caused by misalignment. The full requirement sets are collected for Gmail and Yahoo.

550 5.7.25 is a close relative. Gmail uses it when the sending IP has no PTR record, or when the forward DNS entry doesn't reference the sending IP. The reverse DNS checker confirms both directions.

Variant four: a policy or reputation refusal

RFC 3463 names x.7.1 "Delivery not authorized, message refused": the sender isn't authorized to send to the destination, which the RFC notes can result from per-host or per-recipient filtering. Receivers use it for two very different situations.

The first is the recipient organization's own rules. Microsoft's documentation describes 5.7.1 rejections when a distribution group accepts mail only from members or authorized senders, and when a transport rule matches the message. Gmail's 550 5.7.1 text likewise says the user or domain you are sending to (or from) has a policy that prohibits the email. The fix sits on the recipient's side, so ask their administrator whether a rule or group restriction is blocking you.

The second is reputation. When the text names a blocklist, cites poor reputation or links a remediation page, the receiver is refusing your sending IP or domain. Check both with the blacklist checker and follow email blacklist removal for any listing. Outlook.com's own policy codes and their documented meanings are on the Outlook requirements page, and Microsoft SNDS shows how your IPs look from Microsoft's side. Treat a reputation 550 as a warning about placement elsewhere too; the wider diagnosis is in why emails go to spam.

Variant five: your own server refused to send it

Some 550s never reach the recipient's provider, because your own outbound server rejected the submission; the mail client shows it the same way. Microsoft's documentation lists 5.7.1 "Unable to relay", where a sending system isn't permitted to relay through the server, and "Client was not authenticated", plus 5.7.57 for an application or device relaying through smtp.office365.com with a configuration problem. Gmail's reference lists 550 5.4.5 for an exceeded daily user sending limit. The fix is configuration or quota, not the recipient: authenticate the application correctly, or move volume sending to a service built for it, as covered in SMTP relay and sending email with Microsoft 365.

What about 554?

RFC 5321 defines 554 as "Transaction failed", or, when it is the greeting on a new connection, "No SMTP service here". It is the catch-all permanent failure, and the method doesn't change: read the enhanced code and the text. Yahoo's error-code page groups 553 and 554 as permanent problems and says mail returned with a 5xx error should not be retried; Gmail uses 554 5.6.0 for a malformed message. A 554 at connection time arrives before any recipient has been named, so it concerns your sending host rather than any address.

When a 550 deserves a second look

Receivers are imperfect, and three patterns deserve a pause before bulk suppression. A burst of 550s at one company's domain in a single send usually means a receiver-side change, such as a migration or a new filter, rather than hundreds of simultaneous departures. A 550 citing policy or authentication says nothing about the address, so suppressing it deletes a valid contact and leaves the real fault in place. And M3AAWG's BCP, while asking for immediate suppression when a receiver says no such user exists, recommends removing addresses with other failures only after consecutive bounces, at least twice over two weeks or more, to absorb one-off receiver errors. The per-bounce decision logic is in hard bounce vs soft bounce.

The repair sequence

  1. Get the full line. Basic code, enhanced code and text, from the server log or the bounce's Diagnostic-Code: field.
  2. Sort by the middle number. x.1 and x.2: the address or mailbox. x.7: authentication, policy or reputation. x.4: routing or configuration, including your own relay.
  3. Address problems: correct or suppress the address, and check the domain's MX records when many addresses fail together.
  4. Authentication problems: repair SPF, DKIM or DMARC, then confirm spf=pass and dkim=pass in a delivered message with the email header analyzer.
  5. Policy and reputation problems: check blocklists, follow any URL in the text, and contact the recipient's administrator about organization-level rules.
  6. Resend only after the change. An identical request earns an identical 550.

Related guides

About this guide

Written by InboxRatio Editorial. Reply-code definitions follow RFC 5321 and enhanced status codes follow RFC 3463. Provider-specific codes and texts come from Google's Gmail SMTP error reference, Microsoft's Exchange Online non-delivery report documentation and Yahoo's Sender Hub error-code page, all checked on 11 September 2026; receiver-variance and bounce-removal guidance comes from the M3AAWG Sender Best Common Practices (version 3.0). No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on protocol and provider documentation rather than our measurements; the protocol is in how we test and our source rules in sources.

Last updated

14 October 2026. RFC references and provider error codes reviewed quarterly.

Frequently asked questions

What does SMTP error 550 mean? The receiving server permanently refused the request, usually for a specific recipient. RFC 5321 defines 550 as mailbox unavailable, with examples covering a mailbox not found, no access, and rejection for policy reasons. The enhanced code after it, such as 5.1.1 or 5.7.1, tells you which applies.

Is a 550 error a hard bounce? For list management, a 550 about the address (5.1.1, 5.2.1) is a hard bounce, and the address should be suppressed. A 550 about policy, authentication or relaying is also permanent, but it describes your sending setup, so fix that instead of deleting the contact.

What does 550 5.7.1 mean? Delivery not authorized. The receiver refused on policy grounds: a recipient-side rule such as a restricted distribution group, a reputation or blocklist refusal of your server, or your own outbound server declining to relay. The text after the code says which.

What is the difference between error 550 and 554? 550 means mailbox unavailable and is usually tied to one recipient. 554 is a general transaction failure, and as a connection greeting it means the server won't accept SMTP from you at all. Both are permanent; the enhanced code and text give the cause.

Should I retry after a 550 error? Not unchanged. RFC 5321 tells clients not to repeat a permanently refused request as-is, and Yahoo's documentation says 5xx mail should not be retried. Correct the address, fix authentication or configuration, or clear a listing first, then send again.

Why do I get a 550 error when the email address is valid? Because the refusal concerns the sender or the message rather than the address: failed SPF or DKIM, a missing PTR record, a blocklisted IP, a recipient-side rule, or your own server refusing to relay. An enhanced code in the x.7 range is the usual tell.

A 550 is the receiver stating, on the record, what it refused. Read past the three digits to the enhanced code, fix the variant it names, and run the email authentication checker before you send the message again.