Custom domain + receiving at SES - amazon-web-services

I'm wondering if anyone has done the below before, the documentation is not apparent since this is sort of combining two configurations on AWS...
I use SES for receiving mail more than sending it. It's a pretty good service to use as a catch-all for domains without multiple users, which works fine for... say, small non-profits in which one person answers all of the incoming email from a few public addresses. I have all incoming mail dumped into an S3 bucket and the SES active rule set triggers a Lambda function to parse the recipient of the incoming mail and forward it to predefined gmail addresses.
However, I have one account that wishes to send out fundraising mails to newsletter subs, and of course they'll want to buy their own IP from AWS for this purpose, to include DMARC and PTR records for minimizing their losses to spam filters.
SES has the capability to do this, by setting a 'custom domain' for your outgoing SES email. The catch is, by going through the motions to set this up I notice that SES designates the incoming MX you must use to feedback-smtp.(region).amazonses.com rather than the inbound-smtp.(region).amazon.ses.com that normal receiving at SES requires.
Can these two configurations (receiving as well as custom domain for outgoing) co-exist? Or does feedback-smtp.(region).amazonses.com get handled differently somehow?
Anyone done this before?

You don't need to worry about the Feedback MX address.
In SES, you can't have Custom mail from for naked domain (e.g: example.com)
You need to use something like mail.example.com and publish the MX record as feedback-smtp.(region).amazonses.com, this won't affect your incoming emails.
To comply with DMARC using that, you need to make sure that aspf is set to relaxed.
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/dmarc.html

Related

finding the email provider with amazon ses

With regard to this question in which I was using a barebones method to find the mail provider of a particular user, since I was using Amazon SES to send mails, but, am also quite new to it, I was wondering if Amazon SES provides a way to do so? Does Amazon SES give a way(api/service etc) to find the mail provider of the user that I'm sending email to?
Your question is a little vague in exactly what outcome you are trying to achieve with this data.
I am unsure if you are familiar with how mail delivery works on the Internet. My apologies if this is not news to you. At a basic level, email is simply ferried from machine to machine (SMTP server to SMTP server) until it find 'the' server that eventually your mailbox resides on. (This is a relatively gross oversimplification in modern times, but still true).
The first step is you get the message to a SMTP server with instructions to deliver the message, typically with a destination email address. Now, if you are using AWS SES APIs, there is the additional step that before it gets to the initial SMTP server, you first exercise the SES API which in turn ferries that message to Amazon's SMTP servers.
Now, the first SMTP server needs to know where to send it to. This is typically done by executing a DNS query on the destination domain and looking up the MX record. (More information on MX Records here). The MX record will contain an entry (or list of entries) which tell other SMTP servers how to contact that SMTP server for the domain. This is likely where your question is getting at - somehow identifying which 'provider' is in use. In current times, it is very common a large managed service provider like office 365 or similar runs that service for a domain. This is usually programmed into the client's MX record, which is the 'giveaway' that they are using O365 or whatever. However, plenty of domains run their 'own' servers and there is no technical reason preventing such. (Small lie: Since the beginning of time SPAM has been there and the 'reputation' of sending SMTP servers has been quite important in deterring SPAM, or at least was at some point in time. This is one of the reasons that AWS is so picky on you not sending unsolicited emails - it would count against the reputation of their SES SMTP servers sending it and they need it to be 'good' so they don't wind up on block lists at the Amazon level)
Here is the next complication and likely why even if an initial lookup was performed, the data cannot be guaranteed to give you what you want. Since the SMTP service is inherently hop-to-hop, there is nothing stopping the MX record at the DNS domain from merely being a proxy to another set of SMTP servers. Remember, that SMTP is one of the oldest protocols there is on the Internet and its simplicity is what made it functional before all of the infrastructure we have in place today. A SMTP server takes commands from users (or other SMTP servers) and then does its part to pass the message on closer to the actual user.
I am unsure if your end functionality would somehow modify the message sent based on the destination, or if perhaps it wouldn't send at all. Both are not supported by the AWS SES APIs (link). (BTW, it would have to be at the AWS SES APIs that did this, since this functionality simply isn't in the vocabulary of SMTP). You can look at the AWS SES API reference for what it can do, and what it can offer, but if modifying the message before delivery based on provider is what you want there is no current function in that.
Links:
https://en.wikipedia.org/wiki/MX_record
https://docs.aws.amazon.com/ses/latest/APIReference/Welcome.html
No, SES does not provide such functionality.

Is it OK to combine several email records (GSuite + Amazon SES)?

Just to be clear, is it ok for me to do this:
Continue using Gmail (GSuite) for my business domain (email address);
Also allow Amazon SES to work using the same email (by adding MX, TXT and CNAME) records?
In other words, can I have both and will both work w/out issues?
Thanks
You can do this, with no issues at all. We do this regularly; all our inbound and day-to-day user mail is handled by GSuite, but we send marketing and transactional mails through SES.
When you validate your domain with SES you’ll receive a set of DNS records to insert in to your zonefile. One of those will be an MX record that will look something like
10 inbound-smtp.regionInboundUrl.amazonaws.com
To have GSuite or another provider handle your incoming (and some outgoing) mail, simply do not create that MX record.
The other DNS records (DKIM, SPF etc) are best practice for sending emails as, at a very high level, they prove to the receiving server that the server that is delivering the message to them is authorized by the domain to send mail on its behalf.
From a practical perspective, sending mail from many places isn’t really an issue, but receiving mail at multiple places isn’t really possible.

Custom TXT record with Amazon SES

I use for my clients Amazon SES in order to send emails. So for each client I validate their domain. The problem is that the TXT record to validate the domain is _amazonses I would like to know if there’s is way to customize it or to change the way of validation so my client don’t see I am using Amazon SES
This can't be changed. Also, it's just one of the things that customers will need to change in DNS.
You will need to have your customers update their SPF records or you will have significant deliverability issues. DMARC (mentioned at the same link) will pose additional challenges, in some cases, and providing the wrong advice to your customers on their settings can break their ability to send email via existing channels.
Sending mail on behalf of your customers using their domains is distinctly non-trival and best avoided -- SES or not. Regardless of the vendor, you won't be able to mask it.

Use Amazon SES and Google GSuite for the same domain

I have a domain that I manage using Amazon Route 53. It contains TXT/MX records of Amazon Simple Email Service, that I use to process incoming email to a certain email address via AWS Lambda. I also need to register the domain to Google Admin, i.e. GSuite so that I may manage my business emails via Google console. How do I achieve this? I tried setting up Google Admin, entered the MX records of Google Mail, but it resulted in failure of AWS SES services.
It isn't possible to split email for a single domain across multiple services like this. When a sender on the Internet resolves your domain's mail exchanger (MX), the answer must contain a set of one or more hostnames for systems that will all behave identically for any given recipient email address.¹
The easy solution is to create a subdomain for your SES mail, for example contact.example.com, and simply use that domain for your SES messages.
If you really need to have all the addresses have exactly the same domain, set up a subdomain for SES as described above, but then configure GSuite to forward messages for the specific addresses that you want to go to SES, such as info#example.com, over to info#contact.example.com.
GSuite will then accept messages for those addresses, rewrite the recipient address, and hand them over to SES.
As a G Suite administrator, you can configure numerous email routing and delivery options to suit your organization. For example, you can route mail to Gmail and an external server. Or, you might need to route incoming mail for non-Gmail users. You can also set up routing policies that vary by organization
https://support.google.com/a/answer/6297084
¹behave identically from the sender's perspective. How they may handle the message internally is implementation specific, but for any given email address, all of the listed mail exchangers must accept or reject it, because an authoritative response of "No Such User" from any one of these systems will not trigger the sending system to try any of the others.

AWS SES handle doesn't exist mailbox with Lambda

I try to use AWS SES for handle some app data on get email.
I've verified mydomain.com with AWS SES. I want handle dynamic email to addresses 1#mydomain.com 2#mydoamin.com, where 1,2 id from database.
I want handle it with AWS lambda, but I can not do it because I get:
550 5.1.1 Requested action not taken: mailbox unavailable
Is there any way to bypass the creation of mailboxes?
How can I change to email address via SES, for send all emails to one pre existed mailbox?
Make sure your MX records are correctly setup and propagated.
To check, navigate 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: Amazon WorkMail account failing to receive email
First of all, you need to make sure you have your email domain verified under Identity Management - Domains in AWS Console.
After that, you have to verify your RuleSet is active. This means under Email Receiving - Rule Sets - View Active Rule Set you have to see your rule using the defined domain.
In your particular case:
Verify domain mydoamin.com
Check if the Active Rule Set really contains the SES rules for 1#mydoamin.com and .2#mydoamin.com
The error
550 5.1.1 Requested action not taken: mailbox unavailable
is not an AWS Lambda or AWS SES issue. It is an issue on the receiving end of the email. The problem is that there is no one on the receiving end of 1#mydomain.com to receive the email.
Lambda and SES cannot avoid the issue. To handle the issue, you must resolve it on the receiving end by:
creating an inbox, or
setting up aliases, or
wild-card the emails to a default inbox
The technical steps to accomplish this will depend on your receiving-end mail server.
I ran into this problem while setting up email forwarding from one address to another, and ultimately realised that when the SES rule set instructions asked for a 'recipient' email address, it was not the address I was forwarding emails to, but actually the initial email address that was receiving the email.
I was getting same error.
My problem was RuleSets.
SES>Email receiving>Rules Sets.
There should be rules here that allows your mail ID or any mail to your domain.
Encountered the same problem. While my domain was verified with SES I needed to create an SES identity. After creating the identity everything on https://aws.amazon.com/premiumsupport/knowledge-center/ses-receive-inbound-emails/ worked as expected.