AWS SES – Introduction & DNS Records

Introduction – Configure SES Services

Amazon email configurations involve several methodical configurations, and Amazon stated practices we adhere to.

We do our configurations initially from Amazon SES, and then add things to IAM, Lambda, SES, and S3.

For a new Amazon AWS account in Australia, we configure SMTP keys for SES Oregon. These will be seen in the IAM settings once created. Never lose these keys. It is rare that these keys fail in the far future, but if they do, you have to create new keys.

We add an SES domain name, and then place associated records into our DNS. If we are to use a 3rd party like MS Exchange, we do not request certain records when adding the domain because we cannot have both MS Exchange and SES MX and SPF/DKIM/DMARC records co-existing on the same domain.

If using SES to receive emails, we add configurations that forward the emails to you (and others). You cannot reply to the emails from the domain name, which is why any reasonable number of emails should go through a 3rd party like MS Exchange, Proton, etc. If you reply, you would be using your existing email domain, such as Gmail.

If we are using SES to receive inbound emails, we create more configurations so that emails go into an Oregon S3 bucket (AWS cloud storage). We add to this some Lambda functions that process the email content looking for spam, spf/dkim/dmarc passed/gray/failed records,  and so forth. These functions are added to an SES Email Rule. A default rule will simply place emails into the S3 bucket but we need the Lambda rules to stop junk email as best we can, and then forward the emails to your email client or other people. Once configured, we send a test a domain email address manually from our own email client. We check it arrived in the S3 bucket, and we use Oregon CloudWatch logs for checking the Lambda functions are working as intended, or not.

For a new Amazon AWS account, emails are in “sandbox” mode. We initially add one domain email address to SES, and as many as you wish later. Let’s take admin@mydomain.com as the first email we add to SES. SES will send an email to the S3 bucket. You manually download the email to your PC and add the .eml file name extension. You double click it so it opens in your email client, and then click on the verification address. Sandbox mode will now accept that address for your testing. Also note, admin@ is usually used for purchasing SSL certificates.)

You can of course download the raw email without a .eml extension and cut and paste the verification URL into your browser. This helps if we have not added all the Lambda processing rules.

Whether SES or another provider, we check our domain emails work before continuing with Linux services.

When we move out of sandbox mode, all email addresses will work, however, if we are using Linux sendmail commands in shell scripts, the from address and to address must be verified even when sandbox mode is removed. For instance, sendmail from admin@mydomain.com to  me@gmail.com.

These configurations are part of an end-to-end EC2 Solution.

We can allow SES to create an email bucket. However, we can manually add an email bucket if you wish, as shown below. It is helpful to see these steps.

Configure an SES/S3 Bucket for forwarding email

We will block all public access to the bucket. Select Oregon for Australia – in the top right region menu.

File that are at rest on the S3 buckets are encrypted.

Use the options in the diagram below to create an e-mail bucket. I enable ACL’s for my own work. If not, one can get stuck with inability to modify permissions on that bucket. The diagram should use Oregon, not Sydney. It shows creation of a sub-directory and a life cycle that applies to the sub-directory only. Being familiar with these steps is helpful.

Comment: If you create a non-email bucket in your local region, you can remove privacy in order to share file links with other people. In that case, you upload a file, and from the parent directory choose the option to make all files public. Non-local buckets have a higher file transfer cost. It is not significant for emails. Buckets can have sub-directories or hidden directories.

We have various “aws” commands we can use in shell scripts to work with the contents of a bucket via our SMTP keys.

If the bucket has sub-directories, these may not appear visible if they have no objects in them. The life cycle rules may also not show, or not update readily – they are an oddity, but it is good to set e-mails to be stored for 365 days in keeping with Australian practice for keeping email records.

As we manually added the bucket, we go to the bucket Permissions tab and edit the Bucket Policy. Add these lines with your own Amazon AWS Account number – as shown in the top right account pop down menu.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSESPuts",
            "Effect": "Allow",
            "Principal": {
                "Service": "ses.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::MYEMAIL_BUCKET_NAME/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceAccount": "YOUR_ACCOUNT_NUMBER"
                },
                "StringLike": {
                    "AWS:SourceArn": "arn:aws:ses:*"
                }
            }
        }
    ]
}

In the above example, use your own values.

Let’s add a 365 day life cycle policy.

Go to the Management tab. Click on “Create lifecyle rule”. These rules can be modified at any time. If you are having difficulty seeing your modifications, try a full page refresh on the “Objects” tab.

There are two types of lifecyles we use. One expires (deletes) all object for the entire bucket, and one only deletes files under a folder.

Here is the diagram for global expiry:

Here is the diagram for folder expiry. There must be no global rules for this to work.

We will next go to the SES console and where our DNS records are kept, to allow us to access the S3 bucket with incoming emails.

As a note, I do not use registrar services that give me no access to the DNS CAA records.

If your email already goes, say, via MS Exchange, it is still good to see the notes below, but do not configure it.

Open your Domain DNS records, wherever they are managed. You will add SES records to them.

From your SES console, check you are in your email region – Oregon for Australia.

Go to Configuration > Identities > “Create identity” (button) > Identity type: Domain

If the domain registrar does not give free access to DNS CAA records, I would transfer to another. An IT person should do transfers if you are not sure.

The basics for a transfer are:

Backup your WordPress files and database, and store on your PC.

Download the existing DNS records to a .csv spreadsheet.

Unlock the domain, remove private ID protection (if used), copy the transfer/authentication key.

Initiate a transfer from the new registrar and supply them the transfer key. You may be asked to create the DNS records even though the domain is not yet transferred. Use your .csv spreadsheet.

After transfer, revise A and AAA records if applicable.

If the new registrar asks you to change the NS Name Server records, do so on the new and existing registrar. Wait a little while until DNS Checker confirms the NS records if you had been asked to do this. You must not end up in a situation where the NS records are not seen – hence check with https://dnschecker.org/

When transfer is confirmed, you should be able on many services to click on a confirmation button so that the transfer is immediate, rather than a few days.

Your existing registrar details for email and registrant address (etc.) must be okay before transferring. For instance, if the email is an old one that no longer exists, you must no proceed until that is corrected. This can be difficult.

Transfers should not incur a fee, but some registrars charge money if a mistake is made. Note: any cPanel emails may be okay if the DNS records are completely separate to the domain name.

You can ask VentraIP Australia to transfer everything to them at no cost. If cPanel emails are not in question, we are fine, but if they are, you can always backup the emails to a public account such as outlook.com. Transferred emails usually lose their time and date stamps.

The transfer will check you have a valid domain eligibility if using .com.au, .au and so on. Trust accounts may have to provide documentation. Make sure your new registrar is able to transfer .com.au and .au (assuming Australia for these example.)

Let’s say you add a domain to SES and wish to use all those records.

You can ether publish them to Route53, or place with your own registrar. Amazon hosted zones may use multiple entries within double quotes, while other registrars use no quotes, placing each entry into a separate record. Amazon also uses a full stop (.) after some records, but this is not usual for other providers. DNS records are sensitive. Use an IT person if required. Providers usually add the  PTR reverse pointer record for you behind the scenes. You can check with mxtoolbox.com. Don’t worry about the message, “SOA Expire Value out of recommended range”. Until your domain website is up and running, you will see a http not working warning.

If your DNS records work with email, there must be DMARC/DKIM records. For example, if using Amazon SES, the records for laurenceshaw.au look like this:

hostname	                     ttl	type	    content	priority
laurenceshaw.au	                     3600	A	    (IP4 address)	
laurenceshaw.au	                     3600	CAA	    0 issue sectigo.com	
laurenceshaw.au	                     3600	CAA	    0 issue letsencrypt.org	
laurenceshaw.au	                     3600	CAA	    0 issue digicert.com	
n5zXXXXXXXXXXXXXXXXXX._domainkey.laurenceshaw.au	3600	CNAME	n5zXXXXXXXXXXXXXXXXXX.dkim.amazonses.com	
6hlXXXXXXXXXXXXXXXXXX._domainkey.laurenceshaw.au	3600	CNAME	6hlXXXXXXXXXXXXXXXXXX.dkim.amazonses.com	
dogXXXXXXXXXXXXXXXXXX._domainkey.laurenceshaw.au	3600	CNAME	dogXXXXXXXXXXXXXXXXXX.dkim.amazonses.com	
www.laurenceshaw.au	             3600	CNAME	laurenceshaw.au	
mail.laurenceshaw.au	             3600	MX	    feedback-smtp.us-west-2.amazonses.com	10
laurenceshaw.au	                     3600	MX	    inbound-smtp.us-west-2.amazonaws.com	10
laurenceshaw.au	                     3600	NS	    (Name Server)	
laurenceshaw.au	                     3600	NS	    (Name Server)
laurenceshaw.au	                     3600	NS	    (Name Server)
mail.laurenceshaw.au	             3600	TXT	    v=spf1 include:amazonses.com ~all	
*._report._dmarc.laurenceshaw.au     3600	TXT	    v=DMARC1	
_dmarc.laurenceshaw.au	             3600	TXT	    v=DMARC1;p=quarantine;pct=25;rua=mailto:dmarc@laurenceshaw.au	
laurenceshaw.au	                     3600	TXT	    v=spf1 include:amazonses.com ~all

For Amazon mail, the key records are shown above.

Here is an example screenshot from SES when I added a domain. (These will be a little different to the values shown above.)
When adding the domain, Amazon asks for the mail. configuration, so just use that as shown above, and the DKIM RSA_2048 bit value.
If you are not using Route53, don;t tick the option to publish to Route53, and manually create the DNS records with your own registrar.
You must have the dmarc and spf/dkim types of records. If using MS Exchange, as an example, you don’t need to add these records, but you can still add verified email addresses. If for some reason you have a mix of Amazon versus 3rd party records, you cannot have a conflict of the spf/dmarc and MX records. I have tried to do so in case a mail server goes off line and emails route to SES with a lower priority during an outage, but MS Exchange complained.

When you add the SES DNS records, you wait for Amazon to email you to say the domain is verified, and DKIM records are verified.