Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

SES sometimes fails to reach existing email accounts

-3

With the SES service, we've identified 10+ cases of email addresses being added to our account's suppression list due to not existing even though they definitely do exist and worked before. The addresses work again once manually removed from the suppression list. Our clients randomly stop receiving emails due to this.

They receive a permanent bounce such as:

"bounceType": "Permanent",
"bounceSubType": "General",
"bouncedRecipients": [
    {
        "emailAddress": "...",
        "action": "failed",
        "status": "5.1.1",
        "diagnosticCode": "smtp; 550-5.1.1 The email account that you tried to reach does not exist. Please try\n550-5.1.1 double-checking the recipient's email address for typos or\n550-5.1.1 unnecessary spaces. For more information, go to\n550 5.1.1  https://support.google.com/mail/?p=NoSuchUser ffacd0b85a97d-43617e3541dsi7370839f8f.51 - gsmtp"
    }
],
"timestamp": "2026-02-05T01:20:24.000Z",

Sometimes they're the sole destination of the failed email delivery, other times they're grouped with another address that actually does not exist. They are always Gmail addresses, with or without custom domains, though that may be survivorship bias. The first address which we noticed was suppressed on 24 December 2025 at 00:39 (UTC+00:00), and it's been happening every month until at the very least March 16, 2026 at 12:40 (UTC+00:00), but likely have had more since. Happened in the region eu-west-1. The AWS account used to send these emails is a production account that sends from hundreds to several thousands of emails per hour.

We've mitigated by programmatically unsuppressing addresses from bounce notifications but this is not perfect, some emails still fail to be delivered.

This type of bounce should never occur for legitimate addresses at random times, and is highly problematic for us. It affects our biggest, or most active, clients.

Topics
Front-End Web & MobileBusiness Applications
Tags
Amazon Simple Email Service
Language
English
asked 9 days ago42 views
1 Answer
0

The issue you're experiencing with legitimate email addresses being incorrectly marked as non-existent and added to your suppression list is concerning. When Amazon SES receives a permanent bounce with a "5.1.1" status code indicating the email account doesn't exist, it treats this as a hard bounce and adds the address to your account-level suppression list.

There are several factors that could be contributing to this problem:

Potential causes:

  • Some ISPs, including Gmail, may temporarily reject messages from sending mail servers as an anti-spam measure through a process called "greylisting." While this typically causes temporary rejections, in some cases the responses from receiving mail servers can be misinterpreted.
  • There may be intermittent issues with the recipient's ISP that cause legitimate addresses to appear invalid temporarily.
  • The diagnostic codes you're receiving are coming directly from the recipient's mail server (Gmail in your cases), suggesting the issue may originate from their side rather than SES itself.

Recommended actions:

  1. Contact the affected email recipients or their ISP to verify there are no known delivery problems or temporary issues with their mail infrastructure.
  2. Since you have a production account sending high volumes, consider opening a technical support case with AWS (if you have a paid support plan). Provide the specific recipient addresses, request IDs or message IDs from your SendEmail responses, timestamps, and the pattern you've identified.
  3. Continue monitoring for patterns - note the timing, volume, and any commonalities beyond Gmail addresses.
  4. While your programmatic unsuppression approach is a reasonable mitigation, working with AWS Support to investigate the root cause would be the best path to a permanent solution.

The fact that these addresses work immediately after removal from the suppression list suggests there may be transient issues occurring at the time of the original bounce that warrant deeper investigation with AWS Support.
Sources
Understanding email deliverability in Amazon SES - Amazon Simple Email Service
Amazon SES Delivery problems - Amazon Simple Email Service

answered 9 days ago
EXPERT
reviewed 9 days ago
  • Joao Esteves
    9 days ago

    I have opened a case with AWS Support with a lot of details but we don't have a paid plan since we almost never need it. We were suggested to make a public question instead, but in my opinion it should be treated by AWS Support nonetheless as all signs point to a serious issues in AWS' side. It might be a problem within Gmail, but AWS SES, as the service we contract, should communicate with them or at least be more transparent with us about Gmail errors so we can take the initiative with Gmail.

    As for contacting ISPs, I don't think this applies since it's Gmail. As for contacting Gmail, is their public community the only available venue? https://support.google.com/mail/community

  • repost-User-51499087
    9 days ago

    This is a community Q&A forum, not a support queue. AWS will not conduct service-side investigations or engage with a 3rd party on your behalf.

    Technical support from AWS support engineers costs money. If you need AWS to investigate internal SES logs or escalate service-level issues, you need a paid support plan. Hard stop.

  • Joao Esteves
    9 days ago

    Of course this fits an AWS support case, but it was that support that suggested I created a post here. I searched and found no relevant existing posts. I'm not expecting a guaranteed resolution from this but maybe others affected can use this post to share their circumstances. Support costs money but I'd expect any company would be interested about errors in their high volume and high valued service that are no fault of their clients, this is not some optimization or configuration error. This isn't some unknown, shady service, it's the most widely used mailbox provider. This is why I shared the most details I could about our case in AWS Support to facilitate their side. We do not need Support to handle our case in 1 day like their plans advertise, we are OK with waiting.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content