SES Mail From - Can't Receive Email OR Fail Validation - Pick your poison

What do you have configured under SES > Configuration > Email receiving?

I have one Rule Set and it is active. In that Rule Set, I have 1 active rule that saves to an S3 bucket and it does not have any Recipient Conditions. There are no IP filters other inbound restrictions / rules. Using the "10 inbound-smtp.us-east-1.amazonaws.com" address for MX works fine to receive emails to the S3 bucket but "10 feedback-smtp.us-east-1.amazonses.com" does not using the same setup.

If your configured identity/domain is abc.com and your custom MAIL FROM domain is ses.abc.com:

1. the MX server (10 inbound-smtp.us-east-1.amazonaws.com) should be configured for abc.com
2. the MX server (10 feedback-smtp.us-east-1.amazonses.com) should be configured for ses.abc.com

I added the inbound-smtp to the existing MX record my top level domain and changed the MX record for the subdomain to the feedback-smtp value. But, I still receive 550 Mailbox does not exist errors when sending to SES. The only way I can get the email to be received by SES is to have the MX record for the subdomain (i.e ses.abc.com) set to the inbound-smtp value. not feedback-smtp.

When the MX records are set as I described, is AWS verifying both records are now correct in the console?
What are the TTLs set to for your DNS records? Are you waiting this amount of time, after making the changes, before testing?

SES shows both the domain and the Mail From are valid/verified. The TTL was originally set to 1 hour. I changed that to 5 minutes. However, I waited over an hour before sending a new email to ensure that the the server would request a new DNS lookup.

Changing the MX record for the MAIL FROM subdomain (ses.abc.com) has no effect on where mail is delivered @abc.com. It would, however, affect where mail is delivered @ses.abc.com. Your DNS records should be correctly configured as AWS has verified those entries. Not that this should matter, but are you sending your test from an external domain outside of SES to your top-level domain @ SES? Possibly the DNS has not completed updating on the server you are sending the test from. Maybe try again in a little while. What mail server is answering/responding in the headers of the 550 error?

Let me clarify because I think I may not have been clear in the context before.

I have a TLD called "abc.com" and it uses a well know email host. The MX record for abc.com points to that email host and everything works well in terms of user based emails. We created a subdomain called "ses.abc.com" to be used for user responses to emails we send out (reply_to). The outbound email has a reply address like UniqueID@ses.abc.com. We parse the UniqueId out when someone replies. That tells us what the outbound correspondence was. We never need email for user@abc.com to get to SES. The MX record for ses.abc.com is the one that is giving problems.

We can get the Domain Identity for abc.com verified by adding the 3 required CNAME records to abc.com. We also get SES Custom MAIL FROM Validation by using the expected "10 feedback-smtp.us-east-1.amazonses.com" value in the MX record for ses.abc.com. However, we only get 550 Mailbox Not Found rejection errors from whatever the sending server is (i.e. the person sending the email to UniqueID@ses.abc.com) when the MX record for ses.abc.com is set to the feedback value.

But, once I pass validation for Mail FROM using feedback value I can then reassign to the "10 inbound-smtp.us-east-1.amazonaws.com" value. This is the only way the email successfully gets to SES is if the MX record for ses.abc.com is set to the inbound value. However, a few hours later or maybe the next day, the SES automated validation runs again and terminates the MAIL FROM because it is not set to the feedback value.

I have tried sending emails to SES from the abc.com user accounts and several other providers like Yahoo, Google, etc with the same results. I have even gone so far as to create a brand new domain "abc2.com" and set that up purely with SES - so there is no chance it points to our email host for the other domain. This domain exhibits the exact same behavior.

Thank you for clearing that up! I configured it this way today and it seems to be working. As long as the automated validation passed later (and it should), we should be good to go.