Hello,
I'm seeing inconsistent SMTP authentication behavior on Amazon SES and would like to understand if this is expected.
Setup:
Region: eu-west-3
SMTP endpoint: email-smtp.eu-west-3.amazonaws.com, port 587 (STARTTLS)
IAM user with the standard AmazonSesSendingAccess policy (no Condition block, fully permissive, verified in the IAM console)
Important clarification up front: this is not a "raw Secret Access Key used as SMTP password" issue. The SMTP password was correctly derived from the IAM Secret Access Key using the standard documented algorithm (HMAC-SHA256 chain, AWS4 + region + "ses" + "aws4_request" + "SendRawEmail", base64-encoded) — I computed it independently with a script and confirmed it matches AWS's behavior, since it authenticates successfully in one context (see below).
The issue:
Using the exact same, correctly-derived SMTP credentials:
From a residential/personal network → 235 Authentication successful
From a shared web hosting provider's IP (mutualized hosting, many tenants on the same server) → 535 Authentication Credentials Invalid
Both tests were done with raw SMTP (openssl s_client -starttls smtp, full EHLO / STARTTLS / AUTH LOGIN sequence), completely outside of any application, using the identical username/password pair each time. The hosting provider's engineer reproduced the failing test independently on their end, confirming it's not a client-side quirk on my machine.
What I've already ruled out:
Network/firewall blocking — TCP/TLS connection to the SES endpoint establishes correctly from both locations (confirmed via netstat on the hosting side)
Public IP denylisting — checked via a standard lookup tool (MXToolbox), no entries found for the hosting IP
IAM policy restrictions — no Condition block, no IP restriction on the policy attached to the sending group
Credential encoding/copy-paste errors — tested with base64-encoded values directly, both from the AWS-provided SMTP password and from an independently computed one, same result
Application-level issue — reproduced the same failure with a bare Python smtplib script and raw openssl, no email client or application involved
My question:
Is there a known reputation-based or anti-abuse mechanism on the SES SMTP interface that could reject authentication (not just throttle/limit sending) based on source IP reputation, separate from public denylists? Since the failing IP is shared among many hosting customers, could another tenant's past behavior affect SES's acceptance of authentication attempts from that IP specifically — and if so, is there a way to check or request a review of this from the AWS side?
Alternatively, would migrating to the SES API (SigV4 over HTTPS) sidestep this entirely, since it doesn't use this SMTP AUTH path?
Thanks for any guidance.
