Amazon WorkMail account failing to receive email

Question

I previously set up an AWS WorkMail organisation and email address and I am using my custom domain hosted at Route 53. This has worked successfully.

However now I have created a second WorkMail address, I am unable to receive email to it (although I can send email from it). I receive the following error message:

The response from the remote server was:
550 5.1.1 Requested action not taken: mailbox unavailable

Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.1.1
Remote-MTA: dns; inbound-smtp.us-east-1.amazonaws.com. ([my-ip], the
server for the domain [my-domain.com].)
Diagnostic-Code: smtp; 550 5.1.1 Requested action not taken: mailbox 
unavailable
Last-Attempt-Date: Wed, 13 Dec 2017 09:07:52 -0800 (PST)

Could anyone provide advice as why there would be a problem for the second email, but not the first?

Edit: As per kiwicopple's suggestion I have ensured that both the custom domain is Set as Default and that this domain is selected for the email address. However, this has not resolved the issue.

Answer 1

A few years late but here's what I did to resolve:

1. Make sure the default domain is the one you want

Workmail > Domains > Select the domain > Click Set as Default

2. Make sure the user has the domain assigned to their mailbox

1. Users > Click on the user > Click Edit
2. In the Email address field make sure the domain dropdown has the correct field

That should be all. If you're still having issues then it could be the MX records still propogating. Wait a few hours and try again

Answer 2

Better late (2019!) than never.

I had to set the MX and CNAME records manually in the Route 53 Hosted Zones console.

So first up: Make sure you have your record sets for receiving mail set up in Route 53! You can check this by doing the following:

1. In the WorkMail AWS Console, go to Domain
2. Assuming your domain is the default, click on it
3. In the Domain Verification Status screen make sure that the records under Mail Setup (Required) are verified, meaning that they are set in Route 53 (for me I was missing an MX and CNAME record). If they are missing or something else besides verified, then that's a problem you need to fix in Route 53.
4. If the records are not in our Route 53 / Hosted Zones records, add them manually
5. You should now be able to receive mail in Amazon WorkMail.

Worked for me.

Answer 3

After verifying all the steps from the current answers here, you need to wait till the DNS MX record is propagated correctly.

For example, you can go to whatsmydns.net, type your domain and select MX record.

Then make sure the inbound SMTP records are pointing to AWS.

---

Otherwise, to find the right MX records, check at: AWS Regions and Endpoints.

So basically, go to your domain's Hosted zone in Route 53, and you should have the MX records like:

10 inbound-smtp.us-east-1.amazonaws.com 
20 inbound-smtp.eu-west-1.amazonaws.com 
30 inbound-smtp.us-west-2.amazonaws.com 

See also: AWS SES handle doesn't exist mailbox with Lambda

Answer 4

In my particular case, I had forgotten that I had setup AWS Simple Email Service (SES) with active rules pointing to a Lambda. These rules did not discriminate based on the destination email address, so they caught all emails going to the WorkMail domain and filtered them, dropping them and preventing delivery.

I went in and disabled the rule sets in the SES console, and I'm currently working on making the rules more specific to only target emails going to one specific domain instead of anywhere.

To make sure this is not the case for you:

• Go to SES within the Amazon Web Services web console.
• In the the left pane, go to "Rule Sets" under the Email Receiving section.
• Click on "View Active Rule Set".
• You'll be presented with a set of rules. You should see a set of rules here, with your WorkMail rule presumably at the bottom of the list.
• To make sure that SES rules are not preventing your mail from being received, disable any other rules than the WorkMail rule.
• Send an email to your WorkMail account and verify that it's working.

This was the answer for me, but this is because I embarrassingly forgot that I had done this.

As mentioned above, a better solution than just disabling rules is to make sure to specify filtering criteria on each rule to ensure it only applies to where it is valid.

Answer 5

Ok, I had this exact same problem. In my case it was because I was setting up a new domain to receive email through Amazon SES. What I didn't realize that is Amazon SES is used for processing Amazon Workmail.

So here I am, blindly working through the documentation setting up a new SES receiving rule set and making it active. Everything is working great!

A short time later I realize that none of my Amazon Workmail accounts are working! I send myself an email from a gmail address and it bounces with

550 5.1.1 Requested action not taken: mailbox unavailable

After about 10 minutes of wild eyed panic I realize the way to recover is to disable the new rule set I just created for SES and enable the INBOUND_MAIL rule set which contains all the rules that govern Amazon Workmail.

Then I add my new rule at the end of this rule set and now I have both Amazon SES and Amazon Workmail working at the same time.

So my scenario is different than the OP's. However I suspect, given the identical error message, that there have been Amazon SES changes that the OP either doesn't know about or does not think are relevant.

Answer 6

I have upvoted @AQuirky's answer, but here is what I found.

I had previously set up a rule for my domain, but not the same email account to receive email in SES. I was sending them to S3, where they are stored in what looks like RFC822 format. The plan was to batch them out and add them to an imap inbox with either a perl or Python imap client script to save the $4.

Workmail can do a good job on updating Route53, although I struggled with "awsapps" addresses until I changed the default.

It does not appear to have automatically fixed SES for me, and I blew away the rule, thinking it was a problem.

I had to create a new rule, and choose "Integrate with Workmail". It did tell me that this should not have been necessary, but yes it was.

Answer 7

Firstly, good answers above. It's 2024 and I'm not sure if AWS changed their layout but I had the same 550 response and the fix for me was in Workmail not SES, although I'd previously verified my domain under SES > Verified Identities, so that would have played a part too.

After verifying the domain, I had to go to WorkMail > Domains > > and update my DNS records. Luckily, there is a button that lets you add all the necessary DNS records into Route 53 with one click. Did that and a few refreshes later (for DNS record validation), when everything had a green tick against it, I started receiving mails.