A beginner-friendly guide to setting up SPF, DKIM, DMARC, Amazon SES, and custom email templates so your emails actually reach the inbox

Who This Guide Is For

If you are building an app on AWS and using Cognito to handle user sign-up and login, you have probably noticed that Cognito sends emails automatically — a verification email when someone signs up, and a password reset email when they forget their password.

But if those emails are landing in spam, or not arriving at all, this guide is for you.

We are going to fix that problem from scratch. No prior knowledge of email infrastructure is assumed. Every term will be explained.

What Is the Problem, Exactly?

When your app sends an email from something like no-reply@yourdomain.com, the email does not go directly from your laptop to the user's inbox. It travels through mail servers, and along the way, the receiving server (Gmail, Outlook, etc.) checks a simple question:

"Can I trust that this email actually came from this domain?"

If the answer is unclear or no, the email gets flagged as spam — or silently dropped.

To answer that question, three things need to be in place on your domain: SPF, DKIM, and DMARC. These are DNS records (small pieces of configuration stored on your domain) that prove your emails are legitimate.

We will set all of them up in this guide.

The Stack We Are Working With

Here is what this guide assumes:

• You have an AWS account
• You have a Cognito User Pool set up (or are planning to set one up)
• Your domain is managed in Route 53 (AWS's DNS service)
• You want Cognito to send emails from your custom domain, like no-reply@yourdomain.com

If your domain is with GoDaddy, Namecheap, or another provider, the DNS steps will look slightly different in their interface, but the records you need to add are identical.

Step 1: Understand What Amazon SES Is

Before we do anything, let us understand a key service: Amazon SES.

SES stands for Simple Email Service. It is AWS's service for sending emails. By default, Cognito uses its own basic email system, which has very low sending limits and no support for custom domains. That is why emails look generic and often end up in spam.

The fix is to connect Cognito to SES, and configure SES properly with your domain. SES is free for low volumes, and the setup is a one-time thing.

Step 2: Verify Your Domain in Amazon SES

Before SES can send emails on behalf of your domain, it needs to confirm that you actually own it. This is called domain verification.

Here is how to do it:

1. Log in to the AWS Console and search for "Amazon SES" in the top search bar.
2. In the left sidebar, click "Verified identities".
3. Click "Create identity".
4. Choose "Domain" and type your domain name (for example, mydomain.com).
5. If your domain is in Route 53, check the option that says "Use Route 53 to publish DNS records automatically." AWS will handle the DNS setup for you.
6. Click "Create identity".

If you are not using Route 53, SES will show you a CNAME record that you need to manually add in your DNS provider's dashboard. Copy it exactly as shown and add it there.

Once AWS detects the record, the status will change to "Verified". This can take anywhere from a few minutes to a couple of hours.

Step 3: Set Up DKIM

DKIM stands for DomainKeys Identified Mail. Think of it like a wax seal on a letter — it proves the email came from you and was not tampered with in transit.

Every email sent through SES gets a digital signature. The receiving server checks that signature against a public key stored in your DNS. If they match, the email is trusted.

When you verified your domain in the previous step, SES automatically generated DKIM keys for you. You just need to add the DNS records.

SES will show you three CNAME records under the "DKIM signatures" section of your verified identity. If you used Route 53 automatic publishing, these are already added. If not, copy all three and add them as CNAME records in your DNS provider.

Once AWS confirms the records are live, DKIM status will show "Verified."

Step 4: Set Up SPF

SPF stands for Sender Policy Framework. It is a DNS record that tells the world which servers are allowed to send email from your domain.

Without SPF, anyone could send an email claiming to be from your domain. Receiving servers know this, which is why they check for it.

Here is how to add it:

1. Go to Route 53 in the AWS Console.
2. Click "Hosted zones" and open your domain.
3. Click "Create record".
4. Set the record type to "TXT".
5. Leave the record name empty (or use @ if required).
6. In the value field, paste this exactly:

"v=spf1 include:amazonses.com ~all"

1. Click "Create records".

What this record says: emails from this domain are allowed to come from Amazon SES servers. The ~all at the end means "treat anything else with suspicion but do not block it outright." This is the safe starting point.

Step 5: Set Up DMARC

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is the policy that ties SPF and DKIM together.

DMARC tells receiving servers: "Here is what to do if my emails fail the SPF or DKIM check." Without DMARC, servers make their own decisions, and those decisions often mean spam folder.

Here is how to add it:

1. In Route 53, go to your hosted zone again.
2. Create another TXT record.
3. Set the record name to _dmarc (Route 53 will automatically append your domain, making it _dmarc.yourdomain.com).
4. In the value field, paste this:

"v=DMARC1; p=quarantine; rua=mailto:youremail@yourdomain.com"

1. Replace the email address with one you actually check.
2. Click "Create records".

What each part means:

• v=DMARC1 — this is a DMARC record
• p=quarantine — if authentication fails, send the email to spam (safer than p=reject when you are just starting, which would block emails entirely)
• rua=mailto:... — where AWS should send weekly reports about your email activity

Once you are confident your setup is working correctly, you can upgrade to p=reject to fully block unauthenticated emails.

Step 6: Exit the SES Sandbox

Every new AWS account starts in something called the SES sandbox. In sandbox mode, you can only send emails to addresses you have manually verified. This is a security measure AWS uses to prevent spam from new accounts.

The problem is, your real users have not verified their emails with AWS. So if you are still in sandbox mode, your emails will fail silently.

To exit the sandbox:

1. Go to Amazon SES in the AWS Console.
2. Click "Account dashboard" in the left sidebar.
3. Under "Sending limits", you will see a message about sandbox mode. Click "Request production access".
4. Fill in the short form. Select "Transactional" as the mail type (since you are sending verification and password reset emails, not marketing).
5. Describe your use case clearly: something like "Sending user verification and password reset emails for a web application."
6. Submit the request.

AWS typically approves this within a few hours to one business day. You will get an email confirmation once approved.

Step 7: Connect Cognito to SES

Now that SES is properly configured, you need to tell Cognito to use it instead of its default email system.

1. Go to the AWS Console and open "Amazon Cognito".
2. Click on your User Pool.
3. Go to the "Messaging" tab.
4. Under "Email", click "Edit".
5. Change the "Email provider" from "Send email with Cognito" to "Send email with Amazon SES".
6. Under "SES Region", choose the same region where you set up your SES identity.
7. Under "FROM email address", enter no-reply@yourdomain.com (or whatever address you want to send from, as long as the domain is verified in SES).
8. Optionally, set a "FROM sender name" like "MyApp Support". This is what appears as the sender name in the user's inbox.
9. Save the changes.

From this point on, all Cognito emails — verifications and password resets — will go through your verified SES identity with proper authentication.

Step 8: Customize Your Email Templates

This step is optional but strongly recommended, especially for beginner projects. Cognito's default email messages are very generic, and a branded email builds trust with users (and also looks less like spam to mail filters).

In the same "Messaging" section of your Cognito User Pool:

1. Click on "Message templates".
2. You will see options for "Verification message" and "Password reset message".
3. Click edit on each one.
4. You can write a plain text or HTML message. Here is a simple example for the verification email:

Subject: Verify your email for MyApp

Hi,

Thank you for signing up. Please verify your email address by entering the code below in the app:

Your verification code: {####}

If you did not sign up for MyApp, you can ignore this email.

Regards,
The MyApp Team

The {####} placeholder is automatically replaced by Cognito with the actual verification code or link.

Keep the message clear, short, and professional. Avoid using words like "free", "click here", or excessive capitalization, as these can trigger spam filters even when authentication is correct.

How to Confirm Everything Is Working

After setting everything up, use a free tool called MXToolbox to verify your DNS records:

• Go to MXToolbox and run an "SPF Lookup" for your domain. You should see the SES include statement in the result.
• Run a "DMARC Lookup" for your domain. You should see your DMARC policy.
• For DKIM, you can run a "DKIM Lookup" using the selector that SES provided.

To test the full email delivery, use Mail Tester. It gives you a temporary email address. Trigger a verification email from your Cognito signup flow to that address, then check your score. A score of 8 or higher means your setup is solid.

Quick Checklist Before You Go Live

Before launching your app to real users, confirm the following:

• Domain is verified in Amazon SES
• DKIM records (3 CNAMEs) are added and verified
• SPF TXT record is added to your domain
• DMARC TXT record is added to _dmarc.yourdomain.com
• SES sandbox mode has been exited (production access approved)
• Cognito is configured to use SES as the email provider
• Custom email templates are set up with a clear sender name and message

Conclusion

Email deliverability is one of those things that most developers only think about after something breaks. Verification emails going to spam, users not completing sign-up, support tickets about missing password reset emails — these are all symptoms of the same root cause: an unauthenticated domain.

The good news is that fixing it is straightforward. SPF, DKIM, and DMARC are one-time DNS configurations. Connecting Cognito to SES takes less than ten minutes. And once it is done, your emails will reliably reach inboxes.

If you are building something on AWS and handling user authentication, getting this right early will save you a lot of headaches later.

Need Help?

If you run into any issues with the setup — whether it is a DNS record that does not verify, SES sandbox approval, or connecting things in Cognito — feel free to reach out. I am happy to walk you through it.

Email me at khantanseer43@gmail.com

AWS #AmazonSES #Cognito #EmailDeliverability #SPF #DKIM #DMARC #Route53 #Serverless #AWSCommunity #CloudComputing #BackendDevelopment #AWSBuilder #EmailAuthentication #LearnAWS #WebDevelopment