SMTP response received
550 No such userYou received this code because the receiving mail server refused the message because the recipient address does not exist on their system. The mailbox was never created, was deleted, or the domain does not accept mail for that local part. This is a permanent addressing failure per RFC 5321, and the correct sender response is immediate suppression of the address from future sends. Continuing to send to a suppressed no-such-user address damages sender reputation and triggers spam-trap-like accumulation of hard bounces that eventually cascades to blocklist listings.
๐ In this guide
๐ค Who sees this code
- Deliverability lead investigating a spike in hard bounces on a specific campaign
- Ops team managing bounce processing pipelines that need proper suppression logic
- Marketer whose list quality degraded over time and now sees increasing no-such-user rates
๐ง What this guide fixes
- Confirm the no-such-user code is a genuine addressing failure and not a policy rejection in disguise
- Suppress the address immediately in your sending platform
- Prevent future no-such-user accumulation via list hygiene
โก Do these 3 things first (before diving deeper)
Read the exact diagnostic text following the code
Different receivers phrase no-such-user differently: 550 No such user, 550 5.1.1 User unknown, 550 Address does not exist, 550 Recipient not found. All map to the same operational meaning: the mailbox is not accepting mail because it does not exist. Cross-reference against 550 5.1.1 User unknown which handles the enhanced status code variant explicitly.
Distinguish from policy rejections dressed as addressing failures
Some receivers (notably Microsoft 365 with directory-based edge blocking) return no-such-user wording for addresses that do exist but are behind policy protection. Cross-check by sending from a different IP or via a different ESP: if the same address bounces the same way from every path, it is a real no-such-user. If it bounces from you but delivers from your legitimate transactional relay, it is a policy rejection in disguise (see 550 5.4.1 Office 365 for the Microsoft path).
Check the timing pattern of the bounce
Real no-such-user bounces are consistent across time and sender path. If a specific address bounced with no-such-user last month and again this month, it is a genuine dead mailbox. If it bounced today for the first time after months of successful delivery, the mailbox may have been recently deleted (employee left, account cancelled), same operational response but useful for understanding list decay patterns. The hard bounce vs soft bounce guide covers classification for logging systems.
Common causes of 550
- The mailbox was never created at this domain. The local part before the @ symbol has no corresponding mailbox on the receiving mail server. Common origins: purchased or scraped email lists containing fabricated addresses, typos in email collection forms (user typed
jonh@example.cominstead ofjohn@example.com), addresses generated by data brokers for pattern matching, and spam trap addresses seeded by researchers to catch senders with poor list hygiene. Every one of these is a hard bounce and must be suppressed immediately. - The mailbox was deleted after the address was collected. User accounts get deleted for many reasons: employee leaves an organization, subscriber cancels a service, provider closes an account, ISP prunes inactive users. The address was valid when you collected it but is no longer. This category of bounce accumulates over time as your list ages. Real-world decay rates: 20 to 30 percent annually for typical B2C consumer lists, higher for B2B lists tied to employment turnover. See our bulk email verification guide for revalidation cadence.
- Recipient domain uses subaddressing but sender does not respect it. Some domains implement plus-addressing (
user+tag@example.com) or dot-variations that route to the same mailbox. Others enforce strict local-part matching. If you haveuser+newsletter@example.comin your list but the domain does not implement plus-addressing, the address bounces as no-such-user even thoughuser@example.comexists. Same for Gmail dot handling on non-Gmail domains. Address normalization at collection reduces this class of bounce. - The receiving domain does not accept any mail (parked or defunct). Some domains are technically registered but have no active mail service. MX records may point to a nullhost that rejects everything with no-such-user, or the domain may have valid MX but the receiving server responds with catch-all rejection because no local users are provisioned. This affects entire domain families and often surfaces as a batch of no-such-user bounces from the same domain. Cross-check by running
dig +short MX example.comagainst a small sample of addresses at that domain. - Address was intentionally invalidated (spam trap conversion). Some spam traps are recycled abandoned mailboxes: the address was legitimate years ago, was abandoned, and now returns no-such-user for months before being converted to an active trap. Continuing to send to no-such-user addresses without suppression is exactly what triggers the recycled trap phase, your persistent sends signal poor list hygiene, and the address becomes a full-fledged trap. Suppress on the first hard bounce to break this cycle.
How to fix 550, step by step
- Suppress the address immediately in your sending platform. The correct operational response to no-such-user is instant, permanent suppression. Any ESP or transactional relay worth using has an automated suppression list that catches 5.1.x class codes. Verify yours is configured: check your suppression list dashboard, confirm the bounced address is on it. If it is not, the ESP is not processing bounces correctly and you have a systemic problem. Manual suppression: add the address to a do-not-send list your sending code checks before every send. See our suppression lists guide for schema, retention, and cross-ESP portability.
- Do NOT retry the same address. Retrying 5.x.x class rejections violates RFC 5321 semantics and damages sender reputation. Receivers track how many times you send to known-bad addresses as a reputation signal. A no-such-user retried 10 times looks like a spammer testing address validity. Configure your sending stack to hard-suppress on first 5.1.x bounce, and monitor for any code paths that inadvertently retry.
- Parse the bounce report per RFC 3464. Automated bounce processing requires reading DSN (Delivery Status Notification) messages that receivers return per RFC 5321 and RFC 3464. Extract Original-Recipient, Action=failed, Status=5.1.1 or similar, and Diagnostic-Code from the DSN. Our DSN parsing guide covers the exact structure and edge cases. Do not rely on the human-readable text of the bounce email, it varies wildly and breaks parsing regexes.
- Audit your list acquisition process to prevent future no-such-user accumulation. A high rate of no-such-user bounces (above 2 percent of sends) signals list hygiene problems upstream. Common sources: no double opt-in at collection, imported historical lists without verification, purchased or scraped data, form fields with no email validation. Fix at the source: implement double opt-in on signup forms, validate addresses at collection with a real-time API, refuse to import legacy lists without full re-validation. See our email verification guide for the collection-side pattern.
- Revalidate stale segments before sending to them. Segments older than 6 months, or that have not been mailed in 30+ days, have unknown decay. Batch-verify them through a validation service before sending to catch dead mailboxes. Our bulk email verification guide covers the operational cadence. SMTPing catches invalid addresses, disposables, catch-all traps, role accounts and dead mailboxes before you send, 13 validation types, 25 free daily, no card required.
- Distinguish no-such-user from catch-all responses. Some domains accept all incoming mail regardless of the local part (catch-all configuration). Sending to
random@catchall-domain.comgets a 250 OK response but the message may silently discard or land in a bulk trap. Catch-all addresses look valid to SMTP verification but are unreliable in practice. Our catch-all detection guide and catch-all email address explainer cover the detection heuristics.
๐ How each provider sends this exact code
โ How this code differs from adjacent ones
550 5.1.1 User unknown551 5.1.1 Recipient not exist550 5.2.1 Mailbox inactivePrevention going forward
no-such-user is a symptom of list hygiene problems accumulated over time. Preventing recurrence means treating list quality as ongoing infrastructure with defined verification cadence, not a one-time cleanup event.
- Implement double opt-in on every signup form. Single opt-in produces addresses that were never confirmed by their actual owner, guaranteeing eventual no-such-user bounces and enabling malicious signups with fabricated addresses.
- Validate addresses at the collection point with a real-time email verification API. Catching invalid addresses before they enter your database prevents them from ever generating bounces. Trade a small integration effort for zero recurring bounce cleanup work.
- Revalidate stale segments (6+ months unused) before sending. Address decay is real: 20 to 30 percent annually for consumer lists, higher for B2B. Batch validation catches decay before it turns into hard bounces and reputation damage. Our bulk verification guide covers the operational rhythm.
- Never purchase, rent, or scrape email lists. Purchased lists guarantee no-such-user rates above 20 percent, hit spam traps, and directly cause blocklist listings (see 550 5.7.1 Spamhaus for the downstream consequences). Any short-term reach gain from a purchased list is dwarfed by the deliverability damage it causes.
- Track bounce rate as a health metric with alerts. A sudden spike in no-such-user bounces signals either bad list acquisition, an operational bug pulling from a stale segment, or a subscriber sync that reintroduced already-suppressed addresses. Alert on any deviation from your baseline so you catch it before reputation damage propagates.
Frequently asked questions about 550
Should I remove the address after the first no-such-user bounce or wait for a pattern?
What is the difference between no-such-user and mailbox full?
Can no-such-user bounces damage my sender reputation?
What if my ESP is auto-retrying no-such-user bounces?
How do I tell if a no-such-user bounce is a spam trap?
Do disposable email addresses show up as no-such-user?
Stop 550 bounces before they happen.
SMTPing catches invalid addresses, disposables, catch-all traps, role accounts and dead mailboxes before you send. Fewer bounces means less firefighting and a healthier sender reputation. 13 validation types, 25 free daily, no card required.
๐ Deep dive on related codes
About the Author
Alaa ยท LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. Iโve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
