How do Zoho and ProtonMail handle unknown users?

You're validating addresses before a send and you get different bounce responses from Zoho, ProtonMail, Gmail, and Outlook. Why aren't they consistent? And more importantly, how should you adjust your validation logic to handle them?

Zoho takes a business-focused approach. When you hit a non-existent user, you'll get a standard 550 response with "550 5.1.1 User unknown." Zoho applies strict rate limiting for new senders to block spammers quickly. So if you're testing large recipient lists, you might hit throttling even before you get all your bounce responses.

ProtonMail prioritizes privacy. They'll return a 550 for unknown users, but they're protective about enumeration attacks (where someone tries to figure out which addresses exist). This means ProtonMail might delay responses intentionally to prevent attackers from harvesting your valid addresses. You'll see "550 5.1.1 The email account does not exist," but the timing might be slower.

Both follow RFC 5321 standards for basic bounce codes. Both implement rate limiting. But they reveal far less detail than Gmail or Outlook. You won't get verbose error messages about why they rejected you. Privacy-focused doesn't mean secretive. It means minimal information.

Here's where your validation logic needs adjustment. First, treat any 550 5.1.1 from any provider as a hard bounce. That's consistent across both. Second, build in retry delays. These providers are slower to respond, and you don't want to timeout prematurely. Third, respect their rate limits. If you're getting throttled (421 or 451 responses), back off immediately. Don't treat rate limit signals as hard bounces.

The practical difference: Zoho is stricter and faster to reject. ProtonMail is protective and slower. Both are less verbose than mainstream providers. That means you can't rely on detailed error messages to guide your suppression strategy. You need to stick with what they do give you: the standard bounce codes.

Your next move: Test a small batch of addresses you know are valid against both providers. See what response times and codes you actually get. Then adjust your validation timeout and rate limit handling before running a full list validation.