Brevo SMTP Relay authentication failing consistently with specific error codes after recent API key rotation

First off, great detail in your question! Just a tiny heads-up for future posts – a quick period after "thanks in advance!" makes it look even more polished. But let's get to the real issue here, that stubborn '535 authentication failed' error with your Brevo SMTP relay.

• API Key vs. SMTP Credentials: This is a common pitfall. Brevo (and many other email service providers) often have separate credentials for API access and SMTP relay. When you rotated your API key, did you specifically generate or update the SMTP username and password within your Brevo account? The API key itself is usually for direct API calls, not typically used as the SMTP password directly. You'll usually find dedicated SMTP credentials under your Brevo account settings, often in a section like "SMTP & API" or "Senders & IPs."
• Application Configuration Reload: Your sending application or server might be caching the old credentials. Even if you've updated the config file, a service restart might be necessary for the changes to take full effect. This is particularly true for long-running processes or containerized environments.
• Endpoint Verification: While you mentioned checking the endpoint, just re-confirm you're using the correct Brevo SMTP server address (e.g., smtp-relay.brevo.com or smtp.sendinblue.com, depending on your region/account setup) and the correct port (usually 587 with TLS/STARTTLS, or 465 with SSL). Mismatched ports or encryption types can sometimes lead to authentication failures.
• Firewall & Network Filters: You've verified no IP restrictions on Brevo's side, which is excellent. However, double-check your outbound network. Is there any firewall, proxy, or security group on your server's side that might be interfering with the connection or the authentication handshake to Brevo's SMTP servers? Sometimes a network device might drop packets or interfere with the TLS negotiation, causing a generic authentication failure.
• Brevo Account Status: Confirm your Brevo account is in good standing. While rare for a 535 error, a suspended or heavily rate-limited account could potentially cause unexpected issues, though it typically manifests as other error codes. Also, check your Brevo dashboard for any specific alerts or messages related to your sending domain or SMTP usage.
• Test with a Minimal Client: To isolate the issue, try configuring a simple mail client (like Thunderbird or a basic Python/PHP script) on the same server that's failing, using the new Brevo SMTP credentials. If that works, the problem is likely within your application's specific email service provider (ESP) configuration or code. If it still fails, it points more towards network or credential issues.

Focusing on that distinction between API keys and specific SMTP credentials is often the key to resolving this. Hope this helps your conversions!

Ah, got it! That distinction between API keys and actual SMTP credentials was exactly what we needed, emails are flowing again perfectly now. Seriously, thanks for pointing that out! But now that auth is sorted, we're noticing some odd deliverability to certain providers, especially Outlook.com, with emails occasionally landing in spam even though our content hasn't changed. Any ideas if that's something you've seen and might have a tip for?