I want to remove company.in domain from the list of verified domains but want to continue sending emails using do-not-reply#company.in DKIM enabled+verified email identity. To achieve this, I have followed this guide which is pretty straightforward but haven't been successful in the sense that the domain gets removed from the list only for some days(~4) only to show up again in the list of verified domains somehow.
What could be the cause of this auto-magical verification and corresponding fix ?
After corresponding with AWS premium support:
Started off by checking your verified identities in the "ap-south-1 - BOM" region of SES and I saw the following 2 identities:
Domain = company.in (Introduction date: 2021-09-02 20:25)
Email address = do-not-reply#company.in (Introduction date: 2020-10-23 13:29)
After pulling out CloudTrail logs for DeleteIdentity API in the region "ap-south-1" for the last 90 days. I could see a single API call on "2021-08-31" for the domain "company.in" (exactly as mentioned by you). Also, checking the VerifyDomainIdentity API in the CloudTrail logs for the past 90 days, I was not able to see any.
This confirmed that I deleted the domain successfully on "2021-08-31" and it got re-verified itself on "2021-09-02", 3 days after.
I did a DNS query on your domain "company.in" and was able to identify that Route-53 is the DNS provider. On checking your domain's DNS configuration in Route-53, I was able to see the following 3 DKIM CNAME records published:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx._domainkey.company.in xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.dkim.amazonses.com
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy._domainkey.company.in yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy.dkim.amazonses.com
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz._domainkey.company.in zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.dkim.amazonses.com
Now, coming to the reason for this strange behavior, I would like you to know that if there is a verified email identity of the same domain that was removed, and it has DKIM enabled+verified, then the domain will be automatically added to the verified identities even if you manually remove it.
Reason being, one can only have DKIM for domains they own and adding the DKIM record proves ownership, a criteria to verify your domain(s) in SES. Therefore, SES assumes that you are the domain owner due to the DKIM CNAME records published in your domain's DNS records and thus, automatically adds the domain to your SES verified domains.
To mitigate this, there are 2 options:
Either remove DKIM settings from the domain, which will mean disabling DKIM for the email address and removing the DKIM CNAME records from domain's DNS.
If you require DKIM for sending and don't want to alter the DKIM settings, then the only way would be to add a policy on the SMTP/IAM user, to only allow sending from certain email addresses - https://docs.aws.amazon.com/ses/latest/DeveloperGuide/control-user-access.html
We have an app whose domain is on Godaddy, the frontend (ReactJS) is hosted on Firebase and the backend (Django) is on AWS. We follow subdomain-naming just like Slack does i.e. xyz.ourdomain.com. However, for every customer we have to do these manual steps and wait for hours for records to propagate:
Add an A record to Godaddy where e.g. Name would be XYZ and Value would be the value provided to us by Firebase when we add a custom domain there which is Value: 151.101.1.195 (Firebase shows this message there: Your site will show a security certificate warning for a few hours, until the certificate has been provisioned.)
Then we need to authorize our domain URL xyz.ourdomain.com on Firebase and Google Cloud Console (however that is not a major worry for now)
The last step is some customisation from backend which is necessary and can be automated by me easily
I just want to know how to create wildcard entries so that when one enters *.ourdomain.com, it points to the Firebase hostings. Ideally, we want to remove the time it takes for records to propagate.
This level control is not built into firebase as it is designed to work as your primary domain app, as such you can redirect all subdomains in your DNS to point to your root domain with the following guide:
Log into your GoDaddy account.
Click “Domains.”
Click “Manage DNS.”
Click Add and select CNAME from the dropdown list.
Complete the fields listed:
Host: The host name should be set to the wildcard (" * ").
Points to: This is the URL you are setting as the destination for the host. ...
Click “Save.”
You additionally have the option for 301 permanent redirects.
I am a new Full Stack Dev and I am already stuck with hosting my portfolio on AWS Amplify and using a domain that is through Google Domains. I am aware that using AWS is quite a bit of overkill for a simple portfolio but I would like to get the experience with AWS and I enjoy the challenge.
I've already accessed my DNS tab in my Google Domains page. According to AWS we need to create our two CNAME records. One for the domain and one for the ACM validation certificate. I have also created a synthetic record for the forward because Google Domains does not support ANAME/ALIAS records.
I've confirmed that the data that I've entered into the CNAME records were correct and that I've allowed time for the records to update yet in my Amplify portal it still shows that I need to configure my CNAME records.
Are there any thoughts on whether this could be a hiccup on the Google or the AWS end? Should I just give in and transfer my DNS to Amazon Route 53? Any thoughts would be appreciated, thank you!
AWS' recommended steps work, up until the forwarding part: https://docs.aws.amazon.com/amplify/latest/userguide/to-add-a-custom-domain-managed-by-google-domains.html
To correctly setup forwarding, do the following:
You have registered the address: myaddress.com
Go to the 'Website' tab under domains.google.com/registrar/myaddress.com
Click 'Add a forwarding address'
Edit the 'Forward from' section. This defaults to two entries: 'myaddress.com' and 'www.myaddress.com'. Remove the one beginning with 'www', in the other use the prefix '#' like so:
Enter 'www.myaddress.com' into the 'Forward to' field
Click 'Forward'. This will add two records, which should now be visible in the 'DNS' tab.
Following these steps should mean you don't get asked to delete the CNAME record you made in the steps provided by AWS (that points at cloudfront).
I am doing exactly what you are doing - if you were looking at Actions > View DNS Records, in the "Update DNS records" box. You may have missed the alert box with a link to View Docs - where the procedure for google is, are you referring to the configuration that i think is needed for other providers?
Where does it say you need to configure CNAME records? Is your site live?
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/