What 550 5.1.10 Means
550 5.1.10 with the descriptive text 'RESOLVER.ADR.RecipNotFound' (sometimes 'RESOLVER.ADR.RecipientNotFound' or 'Recipient not found by SMTP address lookup') is Exchange Online's specific code for 'this recipient doesn't exist in our directory.' It's the Microsoft 365 equivalent of 550 5.1.1, but with a more specific RESOLVER-class error indicating the failure was at the address-resolution layer.
Microsoft 365, Exchange Online, and on-premises Exchange servers. The RESOLVER.ADR enhanced text is unique to Exchange. Other receivers express the same condition with different codes.
The recipient address you sent to doesn't exist in the destination's directory — maybe the person left the company, the address is misspelled, the address was alias-only and the alias was removed, or you're sending to a hand-typed address that was never valid.
How to Fix 550 5.1.10
- 1
Verify the email address is correct
Double-check spelling. Common typos: '@gmail.com' instead of '@yourdomain.com', missing dots in the local part, transposed characters. If the address came from a contact form or scraped list, treat it as suspect until validated.
- 2
Run the address through an email verifier
Use ZenVerifier or any reputable email verification service before sending. Verifiers do SMTP-level RCPT TO checks against the destination server, catching invalid addresses without actually sending a message that bounces. This is essential for cold email lists — sending to 5%+ invalid addresses tanks your reputation.
- 3
Check if the person changed roles or left
If the address was previously valid and is now bouncing, the person likely left the company. Check LinkedIn or the company's team page for a current contact. Many Microsoft 365 tenants leave departed-employee addresses unconfigured (vs. configured as catch-all forwarders), so the bounce starts the day they leave.
- 4
Look for a catch-all or alternate address
Some companies route all unknown addresses to a 'mailroom' or 'info@' catch-all. If you have a strong-signal lead but can't find the individual's address, try info@company.com or hello@company.com as a last resort. Quality is much lower but recovery is possible.
- 5
Remove the address from your sending list
Whatever the reason, the address is bad now. Mark it as bounced in your sending platform's suppression list. Continuing to send to known-bad addresses is the fastest way to damage your sender reputation. Most platforms suppress automatically after one 5.x.x bounce; verify yours does.
References
550 5.1.10 in the Cold Email Context
550 5.1.10 from Microsoft 365 recipients is one of the most common cold email bounces in B2B outreach, because Microsoft 365 dominates enterprise inbox share. The infrastructure-side mitigation is two-step: (1) verify addresses before they hit the sending platform, and (2) suppress immediately on first 5.1.10 to avoid repeat sends that compound reputation damage. ColdRelay's outbound layer flags 5.1.10 bounces as 'recipient-invalid' in the Sends log and auto-suppresses the address across all campaigns in the workspace, preventing the same bad address from being sent to twice. Pair that with ZenVerifier for pre-send verification and your invalid-recipient rate stays under 2%, which is the threshold Microsoft uses for reputation penalties.
Frequently Asked Questions
Is 5.1.10 the same as 5.1.1?
Closely related but distinct. 5.1.1 is the generic 'mailbox unavailable / no such user.' 5.1.10 is Exchange's more specific 'RESOLVER.ADR' variant indicating the failure happened at address resolution — typically the user exists in some form but the address you used doesn't resolve to a deliverable mailbox.
Will Microsoft 365 ever return 5.1.10 for a temporary problem?
No. 5.x.x is permanent. If the address bounces with 5.1.10 today, it bounces tomorrow unless the destination tenant adds it back. Don't keep retrying — that's reputation damage with no possible upside.
How is RESOLVER.ADR.RecipNotFound different from RESOLVER.ADR.ExRecipNotFound?
RecipNotFound is the generic 'not in directory' result. ExRecipNotFound is more specific to external recipient resolution, often appearing when an Exchange tenant tries to relay through Exchange Online and the recipient isn't in the connected forest. For inbound cold email senders, the two are functionally identical — the address doesn't exist where you sent it.
Should I use an email verifier for every cold email send?
Yes for the first send to a list. After the first round, your sending platform's suppression list handles repeats. Pre-send verification is the single highest-ROI quality control in cold email infrastructure — it catches 90%+ of would-be 5.1.10 bounces before they damage reputation.