I have had an EC2 server set up for a while in the Ohio region. Later, I went to set up email for it, and SES is not available for that region. So I fired up another server in N. Virginia, where SES is available. I go into SES, enter my domain (of the original EC2 over in Ohio), and verify it.
The verification of the domain worked, but now I cannot verify an email address, and I cannot receive email at that domain (I'm trying to dump it into an S3 bucket, if that matters). Is this impossible, to have SES trying to deal with email in another region from the original EC2? What would be the best solution for this situation here?
Any help is appreciated. I'm pretty new AWS in general, and still trying to figure out a lot of how it works.
UPDATE: Several days later, the email address has failed the verification. So as of right now, the domain is verified and enabled for sending, but an email address at that domain is failed. How does that happen, and what can I do?
I'm working with a client right now that has a legacy application hosted by a 3rd party vendor on their amazon account. That legacy app was using Amazon SES for their mailing.
I created the clients own amazon account (as I don't have access to continue the build out on clients account), and am now seeing the issue where I need to transition the SES DNS validation over to their account.
I'm wondering what kind of downtime I would see, or problems I'd create by updating the DNS entry of _amazonses.mydomain.com from what it was on the past account to this new account.
My concern is by updating that entry, I would break the legacy system which I don't have the ability to update.
Thank you
You don't have any downtime, you can verify the domains in two different account, it just you need to add multiple TXT value to the record "_amazonses.mydomain.com".
e.g: _amazonses.mydomain.com
"txt-value-1"
"txt-value0-2"
As long as your clients are using their own credentials, emails flow just fine, once you confirm everything is good, you can remove your record from there.
If no,
You can still use SES sending authorization and allow them to use the domain verified in your account, doing this, they can only use your sending domain to send emails but emails will go from their account and they will be charged, their account should be in production.
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/sending-authorization.html
I have two domains on my mailgun account. The first domain (https://my.domain) required me to add an SPF record and a DKIM record (pic._domainkey.my.domain). However, the second (https://subdomain.my.domain) required me only to add an SPF record.
I would like to delete the first domain from MailGun and all of the unnecessary DNS records. However, I am worried that after doing so the second domain will be Unverified, since it might suddently require some new DKIM record (e.g. pic._domainkey.subdomain.my.domain).
Can anybody reassure me that removing the first domain from my MailGun account will not cause the second to be unverified?
I tried to access the email and tried to store email in S3 bucket but it is not working.
SES configuration:
domain verified
email address verified
created rule set in rule set Recipient has provided
In S3 action bucket name given
AMAZON_SES_SETUP_NOTIFICATION has received.
After that if I receive any email from particular recipient it is not stored in S3.
If you are using Route53 for your domain management, you may have forgotten to set up MX record for it.
Here is an instruction of how to do it.
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/receiving-email-mx-record.html
TL;DR
Don't add AWS's MX record to an existing MX record; you need to create a new MX record with a domain that you're not currently using for emails.
Background
I wasn't entirely familiar with MX records and SES, and I already had an MX Record-Set in AWS Route53, I'm using GMAIL (G Suite).
So I followed all the necessary steps - SES-Receive-Inbound-Emails AWS Blog Post - and I still didn't understand why I don't see new emails in my S3 bucket; I could only see AMAZON_SES_SETUP_NOTIFICATION in the bucket.
As already mentioned in previous answers, you must add the AWS's MX record to receive emails, that will eventually be stored in your S3 bucket.
Lesson learned
Having multiple MX records in the same Record-Set is for backup purposes only. If the server is unreachable, it moves on to the next record on the list. Do not expect the email to be received by all the MX records, that will never happen.
Bad Solution
1 ASPMX.L.GOOGLE.COM
5 ALT1.ASPMX.L.GOOGLE.COM
5 ALT2.ASPMX.L.GOOGLE.COM
10 ALT3.ASPMX.L.GOOGLE.COM
10 ALT4.ASPMX.L.GOOGLE.COM
10 inbound-smtp.eu-west-1.amazonaws.com # <-- added this one
I also tried changing the priority of AWS MX from 10 to 1, which is silly, since I still want to receive emails to my mailbox via GMAIL.
Good Solution
Create a new aliased-subdomain and use it for SES.
Here's how:
Assuming I own mydomain.com, and my email address is willy#mydomain.com, I want to use the aliased-subdomain ses.mydomain.com
Add the aliased domain in your GSuite - Login with Admin account and go to Admin Console > Domains > Follow the steps - Add a domain alias > verify and confirm ownership > Domain Name provider = Other
Create a TXT record in AWS Route53 according to the guide in the previous step; this will verify that you own the aliased-subdomain
Back to AWS, Create a new Record-Set in Route53
- Name: ses.mydomain.com # replace 'ses' if necessary
- Type: MX
- Value: # this is temporary, we'll change it in the next steps
1 ASPMX.L.GOOGLE.COM
5 ALT1.ASPMX.L.GOOGLE.COM
5 ALT2.ASPMX.L.GOOGLE.COM
10 ALT3.ASPMX.L.GOOGLE.COM
10 ALT4.ASPMX.L.GOOGLE.COM
Setup SES to S3 - Follow the steps - SES-Receive-Inbound-Emails AWS Blog Post
Verify the aliased-subdomain ses.mydomain.com
Verify an email address - willy#ses.mydomain.com - check your regular inbox willy#mydomain.com open the email from AWS and verify this email address by clicking the verification link
Create a rule and add willy#ses.mydomain.com as a recipient
Edit the previously created MX Record-Set in Route53
- Name: ses.mydomain.com
- Type: MX
- Value: 10 inbound-smtp.${AWS_REGION}.amazonaws.com # replace ${AWS_REGION}
Send an email (from any mailbox) to willy#ses.mydomain.com - you'll see the email in your S3 bucket! Object name is hashed, you need to download and change its extension to .eml
I hope this helps. I was banging my head for a few hours about this one.
In case anyone else's registrar has a confusing settings menu:
I the SES setup menu they show MX record name = your domain, value = 10 inbound-smtp.us-east-1.amazonaws.com. The "10" is meant to be the priority, I just copy/pasted it directly into the server field with my registrar, which was causing the record to be invalid.
Just make sure that your rule set is shown in "Active rule set". Once you create the rule, it is by default goes into "inactive rule set" and you need to mark it is a "Set as a active rule set" and once you do that, it will go in the "Active rule set" section and it will be visible by clicking on "View Active Rule set" button.
If anyone else is still having trouble with this, here are things to check:
All of your 'pieces' are on the same region (S3 bucket, Route53 hosted zone, SES configuration)
SES has the permission to write to the S3 bucket (see this tutorial)
Bucket name is the same name as your domain name
Route53 hosted zone has MX records, which are injected automatically by SES configuration. You just have to pay attention when you do the setup
You will want to verify the rule set you are working with is active. Go to SES and click "Rule Sets" under the email receiving section in the sidebar. Click the "View Active Rule Set" button. Make sure this is the rule set you are currently expecting to be used. To activate the rule set from the "Rule Sets" screen, click on the checkbox next to the rule set and click "Set as Active Rule Set".
The MX record's hostname must end with "." like so:
10 inbound-smtp.us-east-1.amazonaws.com.
Otherwise the record's hostname will be suffixed by your domain name, which is not intended here.
The issue for me was that I had not made the rule set Active. Was losing my mind on the details of the setup but they were all correct.
Make sure you go to "View Active Rule Set" and ensure the inbound rule you created is listed there.
I had the same problem at first. But I notice that the "access denied" was not a configuration question, but something related to access this information directly in the Browser. After downloading the file with "Aws Cli" through the Terminal in Visual Studio Code, I could read the data. Pay attention to activate the rule - in the SES Panel - because NOTIFICATION MESSAGE is something wrong there. ;)
I'm not a expert, but in my expirience probably you have to assing privilegies to the bucket before SES can write elements, i was have similar problems at the begining, so i chose the option create Bucket in the action selection when configurating the rules, then the bucket is created automated with the permisions configured in correct way.
I have two different AWS account and only one domain server like example.com
Now, I cannot share smtp keys with different account, so how can I configure SES with same domain.
To answer your main question.
Yes you can use the verify the same domain (example.com) from multiple AWS Accounts. (If you have your DNS hosted in R53 then its even easier)
See the following excerpt from Amazon Docs
You want to verify the same domain multiple times and you can't have multiple TXT records with the same name—You might need to verify
your domain more than once because you're sending in different regions
or you're sending from multiple AWS accounts from the same domain in
the same region. If your DNS provider does not allow you to have
multiple TXT records with the same name, there are two workarounds.
The first workaround, if your DNS provider allows it, is to assign
multiple values to the TXT record. For example, if your DNS is managed
by Amazon Route 53, you can set up multiple values for the same TXT
record as follows:
In the Amazon Route 53 console, choose the
_amazonses TXT record you added when you verified your domain in the first region.
In the Value box, press Enter after the first value.
Add the value for the additional region, and save the record set.
The
other workaround is that if you only need to verify your domain twice,
you can verify it once with _amazonses in the TXT record name and the
other time you can omit _amazonses from the record name entirely. We
recommend the previous solution as a best practice, however.
Reference: http://docs.aws.amazon.com/ses/latest/DeveloperGuide/domain-verification-problems.html#domain-verification-common-problems
Also for best practice refer the below Doc
https://aws.amazon.com/blogs/ses/can-i-use-multiple-aws-accounts-with-ses/