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.
Related
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.
We are currently using AWS WorkMail for the email addresses of our team members, and we are using AWS SES to send automated emails from an EC2 instance.
Due to different reasons we want to move the email addresses of our team members to a different email service (not hosted on AWS). However, we want to continue to send emails from noreply#... using AWS SES.
What would be the best approach for this? I was thinking of the following:
Setting the MX DNS-Entry to our new email server
Setting the TXT DNS-Entry from v=spf1 include:amazonses.com ~all to v=spf1 include:amazonses.com include:ournewserver.com ~all
Sending emails using SMTP on the new server
Would that be a good approach? Is there anything else I have to do or anything else I have to keep in mind when doing those changes?
Thanks a lot in advance!
From my perspective this looks fine, I would recommend that you do it in a staged approach:
Lower TTL records on all records
Add the SPF record first as it should be non-breaking
Update MX records/SMTP.
Lowering the TTLs will make for a quicker rollback. Try to seperate all steps with a gap longer than the TTL so that you can be more determined over how to rollback the particular step.
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.
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
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.