To be honest, based on my experiences, sending email is hard. Sometimes the email we expect goes to inbox, it is not. Internet is a weird place we love. For this reason, I am delegating email wroks to 3rd party, like AWS SES. But's also not like simple setup for using it.

Whenever setup email on AWS SES, basically we need to setup:

  • Create configuration set
  • Verify domain ownership
  • Setup correct SPF, DKIM, and DMARC

Configuration set

Think of a configuration set as a "sending profile" for your emails. By default, when you send an email with SES, it's like sending it into a black box. You know it was sent, but you don't know what happened next. Did it get delivered? Did it bounce? Did the user mark it as spam?

A configuration set allows you to apply a specific set of rules and, most importantly, get detailed feedback on the outcome of your emails. For example: noreply email.

With noreply email, you're not expecting a reply, but you absolutely need to know if your password resets, welcome emails, or critical notifications are actually reaching your users. A high bounce or complaint rate for these emails can get your account suspended and ruin your application's reputation.

Step-by-step guide to creating configuration set

Assuming we are on AWS Management Console.

Step 1: Navigate to the SES Console

  1. Log in to your AWS Management Console.
  2. In the main search bar, type "Simple Email Service" and select it.
  3. On the left-hand navigation pane, under Configuration, click on "Configuration sets".

Step 2: Create the Basic Configuration Set

  1. Click the "Create set" button.
  2. You'll see a simple form. Let's fill it out:
    1. Configuration set name: Give it a descriptive name. This is what you'll use in your code later. Recommendation: noreply-email-configuration.
    2. Sending IP pool: Keep this on "Shared IP pool". Explanation: As a new sender, you get to build your reputation on a pool of IPs shared with other vetted AWS customers. This is called "IP warming." Using a dedicated IP is an advanced feature for very high-volume senders who need to manage their own IP reputation. For noreply@yourowndomain.com, shared is perfect.
    3. Reputation metrics: Check the box for "Enable reputation metrics". Explanation: This turns on the Virtual Deliverability Manager (VDM) for this set. It's a dashboard that gives you a high-level view of your bounce rates, complaint rates, and overall account health. It's an invaluable, free monitoring tool.
  3. Click "Create set".

Step 3: Configure Event Destinations (The Most Important Step!)

This is where we tell SES, "When something happens to an email I send with this profile, please tell me about it." We will send these events to Amazon CloudWatch.

Click on the name of the configuration set you just created (noreply-email-configuration).

You'll see a few tabs. Click on the "Event destinations" tab.

Click the "Add destination" button.

On the "Add destination" screen, select the event types you want to track. For a noreply address, we care most about delivery failures and negative feedback.

Check these boxes

  • Rejects: SES rejected the email before even trying to send it (e.g., [ because the address is on a suppression list)
  • Bounces: The recipient's server rejected the email. This includes "hard bounces" (invalid address) and "soft bounces" (mailbox full). This is critical to track.
  • Complaints: The user clicked the "This is Spam" button. This is also critical to track. A high complaint rate is the fastest way to damage your sender reputation.
  • Deliveries: The recipient's mail server accepted the email. This is good for confirming success.

You can ignore these for now: Sends, Opens, Clicks. Open and click tracking is more for marketing emails. For transactional emails, we just care that they get there.

Next, choose the Destination. Select "Amazon CloudWatch". This is the easiest and most powerful way to monitor these events. SES will automatically publish metrics (like Reputation.BounceRate and Reputation.ComplaintRate) to CloudWatch. You can then create alarms—for example, "Send me an email if my bounce rate goes above 5%.".

Leave the "Value source" as Message Tag. This is for more advanced filtering which we don't need right now.

Under "Dimension name" and "Default value", you can give it a name to help you filter in CloudWatch.

  • Dimension name: ses:configuration-set
  • Default value: noreply-email-configuration

This creates a nice key:value pair for your metrics. Then, click "Add destination".

That's it! Your configuration set is now ready

Verify domain ownership

Once we verify yourowndomain.com, you can send emails from any address at that domain (noreply@yourowndomain.com, support@yourowndomain.com, welcome@yourowndomain.com, etc.) without having to verify each one individually. This is a massive time-saver.

Verifying your domain is the first and most critical step to setting up authentication protocols like DKIM (DomainKeys Identified Mail).

DKIM is non-negotiable for good deliverability. It adds a digital signature to your emails, proving to receiving mail servers (like Gmail and Outlook) that the email is genuinely from you and hasn't been tampered with.

This significantly reduces the chance of your emails landing in the spam folder.

The only thing you need is access to your domain's DNS settings. This is typically managed through your domain registrar (like GoDaddy, Namecheap, Google Domains) or your DNS provider (like Amazon Route 53, Cloudflare).

Navigate to the Simple Email Service (SES) console in AWS.

On the left-hand navigation pane, under Configuration, click on "Verified identities".

Click the "Create identity" button. In the "Identity details" section:

  • Identity type: Select Domain. This is the key choice.
  • Domain: Enter your domain name. For example: yourowndomain.com.
  • Assign a default configuration set: You can leave this unchecked, the configuration set in our application code for more granular control.

Expand the "Advanced signing and notification settings" section. Signing key length: Ensure "Easy DKIM" is selected.

Explanation: This is AWS's streamlined method for setting up DKIM. SES will generate the public-private key pair for you. The public key is what you'll add to your DNS, and SES will automatically handle signing your outgoing emails with the private key. It's the simplest and most reliable way to get DKIM working.

You can ignore the MAIL FROM domain and notifications settings for now. These are more advanced configurations. Click "Create identity".

After you click "Create identity", AWS will present you with a screen showing a list of DNS records that you must add to your domain. This is how you prove to AWS that you own and control the domain.

You will see two types of records:

  • Domain Verification Record (1 record): This is a TXT or CNAME record that simply proves ownership.
  • DKIM Records (3 records): These are three CNAME records that point to AWS's DKIM keys. When a receiving server gets an email from you, it will look up these records to find the public key and verify the email's signature.

What's Next?

Congratulations! Your domain is verified. But there's one final, crucial step. You must move your account out of the SES Sandbox.

By default, all new SES accounts are in a "sandbox" environment to prevent fraud and abuse. While in the sandbox, you have two major restrictions:

  • You can only send emails to other verified identities (email addresses or domains on your own account).
  • You have a very low sending limit (e.g., 200 emails per day).

To send emails to any user in the world, you must request production access.

  1. In the SES console, you should see a banner about being in the sandbox. Click the link to request a sending limit increase.
  2. Fill out the form detailing your use case (e.g., "sending transactional emails like password resets and welcome notifications for our SaaS application, YourBrand").
  3. Explain how you will manage bounces and complaints (you can mention that you've set up a configuration set to monitor these events with CloudWatch!).
  4. Submit the request. AWS support is typically quick to approve legitimate requests (usually within 24 hours).

Once you're out of the sandbox, yourowndomain.com domain is fully configured and ready to send high-deliverability emails to your users.

Setup SPF, DKIM, and DMARC

Think of it like this

SPF (Sender Policy Framework) is your guest list. It tells the world, "Only servers on this list are allowed to send email for me."

DKIM (DomainKeys Identified Mail) is your tamper-proof seal. It puts a digital signature on your emails that proves they really came from you and haven't been altered.

DMARC is the bouncer at the door. It looks at an incoming email, checks both the guest list (SPF) and the seal (DKIM), and then follows a strict set of instructions—your policy—on what to do if the email looks suspicious.

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance.

It's a DNS record (TXT record) that you publish for your domain. This record gives instructions to receiving email servers (like Gmail, Microsoft 365, etc.) on how to handle emails that claim to be from your domain (yourowndomain.com) but fail authentication checks.

Most importantly, DMARC solves the problem of email spoofing and phishing. It prevents attackers from sending fraudulent emails to your customers that look exactly like they came from support@yourowndomain.com.

DMARC does two incredibly powerful things, as its name suggests:

Conformance (The Policy)

p=none (Monitoring Mode)

Instruction: "Do nothing to the email. Just deliver it as you normally would, but please send me a report about it."

Function: This is always the first step. It's a "listen-only" mode that lets you gather data without impacting your email deliverability. You can see who is sending email on behalf of your domain (both legitimate and fraudulent senders) and fix any SPF/DKIM issues before tightening the policy.

p=quarantine (Quarantine Mode)

Instruction: "The email looks suspicious. Please put it in the recipient's spam/junk folder."

Function: This is the middle step. It protects your users from potentially fraudulent emails by filtering them away from the inbox, but it doesn't block them entirely. It's a great way to test your configuration before moving to the final, strictest policy.

p=reject (Reject Mode)

Instruction: "This email is fraudulent. Block it completely. Do not even deliver it to the spam folder."

Function: This is the ultimate goal. This policy provides the highest level of protection for your brand and your users, ensuring that only authenticated, legitimate emails from yourowndomain.com ever reach an inbox.

Reporting (The Feedback)

This is arguably the most valuable feature of DMARC. Your DMARC record includes an email address (using the rua= tag) where receiving servers can send you aggregate reports.

What are these reports?

They are XML files sent daily that give you a summary of all the emails seen across the internet claiming to be from your domain.

What's in them?

  1. The IP addresses of servers sending email from your domain. Whether those emails passed or failed SPF and DKIM.
  2. The total volume of messages.

Why is this a game-changer?

For the first time, you have visibility into your email ecosystem. These reports will tell you:

If a third-party service you use (like Mailchimp, Zendesk, etc.) is correctly configured to send email on your behalf.

  • If your own servers are misconfigured.
  • If a malicious actor somewhere in the world is trying to spoof your domain.

You would add this as a TXT record in your DNS settings for _dmarc.yourowndomain.com.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourowndomain.com

Let's break that down:

v=DMARC1: This just states that this is a DMARC version 1 record. It's always the same.

p=none: This sets the policy. We are starting in monitoring mode.

rua=mailto:dmarc-reports@yourowndomain.com: This is the reporting address. You're telling servers like Gmail to send their daily aggregate reports to this email address.

These XML reports are hard for humans to read. It's highly recommended to use a third-party service (like Postmark, Dmarcian, or EasyDMARC) that can parse these reports and give you beautiful, human-readable dashboards.

How to Implement DMARC

  1. Confirm SPF and DKIM: Make sure you have valid SPF and DKIM records in place. DMARC relies on them, so they must be set up correctly first. (We've already done DKIM! with AWS easy DKIM).
  2. Create a DMARC Record with p=none: Go to your DNS provider and create a new TXT record for _dmarc.yourowndomain.com with the value v=DMARC1; p=none; rua=mailto:your-reporting-address@yourowndomain.com.
  3. Monitor the Reports: For the next few weeks, watch the reports that come in. Identify all the legitimate sources sending email for you and ensure they are passing SPF and DKIM. If you see failures from a service you use, you need to fix its configuration.
  4. Move to p=quarantine: Once you're confident that all your legitimate email is passing authentication, update your DMARC record to p=quarantine. Monitor for any issues.
  5. Move to p=reject: After another period of monitoring, update the record to p=reject. You have now fully secured your domain against email spoofing.

By implementing DMARC, you're not just improving deliverability; you're building trust and actively protecting your users and your brand's reputation. It's a fundamental part of a modern, secure email strategy.

What is DKIM?

"Easy DKIM" on AWS SES is the setup for DKIM. We have already done it when you verify yourowndomain.com on SES setup.

It's not a different or lesser version of DKIM; it's AWS's user-friendly, managed process for implementing full DKIM authentication on your domain.

Here is a breakdown of what that "Easy DKIM" checkbox actually does for you:

It Creates the Cryptographic Keys

DKIM works on a public/private key pair. When you select "Easy DKIM", AWS automatically generates this secure key pair for you. You don't have to run any complex commands or manage the private key yourself. The highly secure private key is stored within SES.

It Creates the Cryptographic Keys

SES takes the private key and automatically adds a unique DKIM digital signature to the headers of every email you send from that verified domain. This is the "authentication" part of the process.

It Gives You the Public Keys to Publish

Your only job in the "Easy DKIM" process is to take the public keys that AWS gives you (in the form of three CNAME records) and add them to your domain's DNS settings. This is how you make the public key available to the world.

When an email server like Gmail receives your email, it sees the DKIM signature, looks up the public key in your DNS, and performs a check. If the signature is valid, it proves two things:

  1. The email genuinely came from your domain.
  2. The email's content wasn't altered in transit. Easy DKIM vs. The "Hard Way" (Bring Your Own DKIM)

The alternative to "Easy DKIM" is called "Bring Your Own DKIM" (BYODKIM). In that scenario, you would be responsible for:

  • Generating your own private/public key pair.
  • Providing the private key to SES.
  • Publishing the public key in your DNS.
  • Managing key rotation and security.

This is far more complex and is only necessary for very specific compliance or security requirements. For over 99% of users, Easy DKIM is the recommended and correct way to set up DKIM on SES.

What is SPF?

SPF stands for Sender Policy Framework. It's a simple TXT record you add to your DNS that publicly lists all the servers and services that are authorized to send email on behalf of your domain (yourowndomain.com).

Is this IP address on the official guest list?

If yes, the email passes the SPF check.

If no, the email fails the SPF check, and the server sees it as a potential forgery.

This is extremely effective at stopping basic email spoofing where an attacker sends email from their own server but makes it look like it's from your domain.

You need to make a list of every single service that sends email for yourowndomain.com. Forgetting a service can cause its emails to be marked as spam or rejected.

Common examples include:

  • Transactional Email: AWS SES (which we know you're using)
  • Corporate/Business Email: Google Workspace (Gmail), Microsoft 365
  • Marketing/Newsletters: Mailchimp, SendGrid, ConvertKit
  • Customer Support: Zendesk, Intercom, Help Scout
  • Billing/Invoicing: Stripe, Chargebee

For our example, let's assume you use AWS SES for your application emails and Google Workspace for your corporate email (you@yourowndomain.com).

An SPF record is a single line of text with specific tags. It always starts with v=spf1 and ends with an all mechanism.

Start with the version: v=spf1

Add your sending services using include: For each service, you'll add an include: statement. The service's documentation will tell you exactly what to include

  • For AWS SES: include:amazonses.com
  • For Google Workspace: include:_spf.google.com

You combine these into one line:

v=spf1 include:amazonses.com include:_spf.google.com

End with the "all" mechanism. This tells receiving servers what to do with emails from sources not on your list. There are two common choices:

~all (SoftFail)

This is the recommended setting. It tells the server,

"If the sender isn't on this list, it's suspicious, so you can mark it as spam, but I'm not 100% sure, so maybe let it through."

This provides protection without the risk of blocking legitimate emails if you've misconfigured something.

-all (HardFail)

This is a stricter setting. It says,

"If the sender isn't on this list, it is fraudulent. Reject it outright."

This is the ultimate goal, but you should only use it after you have monitored your DMARC reports for a few weeks and are absolutely certain that all legitimate sending sources are included in your SPF record.

So, our complete, recommended SPF record is:

v=spf1 include:amazonses.com include:_spf.google.com ~all

Now you just need to add this record to your domain's DNS settings.

Very Important Rules for SPF. YOU CAN ONLY HAVE ONE SPF RECORD.

A domain must never have multiple SPF records (e.g., two separate TXT records that both start with v=spf1).

This is a common mistake.

If you have more than one, SPF validation will fail. If you need to add a new service, you must edit your existing SPF record, not add a new one.

Be Aware of the 10 DNS Lookup Limit.

The SPF specification says that a receiving server will not perform more than 10 DNS lookups to resolve an SPF record.

Each include: statement counts as one lookup. If you use many services, you can exceed this limit. This is an advanced topic, but it's good to be aware of. For now, with just two services, you are perfectly safe.

That's it! After DNS propagation (usually a few minutes to an hour), your domain will be protected by SPF.

You have now fully configured the three pillars of email authentication, giving your emails the best possible chance of landing in the inbox while protecting your brand from spoofing.

Test it!

You have a few easy options to send your first email. The AWS console is perfect for this kind of one-off test.

Navigate to the SES Console.

On the left-hand menu, click "Verified identities" and select your yourowndomain.com domain.

Click the "Send test email" button.

A "Send test email" form will appear. Fill it out carefully:

  • From-address: test@yourowndomain.com (or noreply@yourowndomain.com).
  • Scenario: Choose "Custom". This is important because it lets you test delivery to any address now that you're out of the sandbox.
  • To-address: Enter your personal email address (e.g., your.personal.email@gmail.com).
  • Subject: SES Production Test for YourBrand
  • Body: This is a test email to confirm that AWS SES is configured correctly. SPF, DKIM, and DMARC should all pass.
  • Configuration Set: This is critical! In the dropdown, select the configuration set you created earlier (yourbrand-transactional-noreply). This ensures the send is monitored.

Click "Send test email". You should get a success message with a unique Message ID.

If the email arrived in either your inbox or spam folder, then congratulations, SES is working! Now for the professional-level checks. This is how you confirm that your SPF and DKIM setup is perfect.

In your email client (like Gmail), open the test email you just received.

Find the option to view the original, raw message with all its headers. In Gmail, click the three vertical dots (â‹®) next to the reply button and select "Show original".

A new tab will open with a lot of technical information. Don't be intimidated! You're only looking for the Authentication-Results section at the top.

It should look something like this:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=s1 header.b=...
       spf=pass (google.com: domain of [email protected] designates ... as permitted sender) [email protected];
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourowndomain.com

This is your report card. Look for three beautiful words:

  1. dkim=pass ✅ (Your tamper-proof seal is valid)
  2. spf=pass ✅ (Your sending server is on the guest list)
  3. dmarc=pass ✅ (Your email passed the bouncer's checks)

If you see pass for all three, your technical setup is flawless. This is a huge milestone!

Finally, let's make sure our configuration set is doing its job.

  1. Go to the AWS CloudWatch console.
  2. On the left-hand menu, click Metrics -> All metrics.
  3. In the metrics dashboard, find and click on the SES namespace.
  4. Click on the "Configuration Set" dimension.
  5. You should see metrics for your yourbrand-transactional-noreply set. Click on the metric named "Delivery".
  6. You should see a graph with a data point of 1 (or more, if you've sent multiple tests).

Seeing this data point confirms that your configuration set is successfully capturing events.

This means that when a real bounce or complaint happens, you can be confident that it will be tracked here, allowing you to trigger alarms and protect your reputation.

What if Something Went Wrong?

Email went to Spam?

If all authentication passed, this is common for brand-new domains. It's called "warming up."

As you send more legitimate, non-spammy email that users engage with, your reputation will build and your emails will start landing in the inbox.

You've done the technical part right.

Authentication Failed?

If SPF or DKIM did not show pass, the most common reason is a typo in the DNS record or DNS propagation delay.

Go back to your DNS provider and carefully compare the record name and value against what AWS provided.

Email Never Arrived?

If it's not in your inbox or spam, check your CloudWatch metrics for a Bounce or Reject event. This will give you a clue as to what happened.

You have now run a full, end-to-end test of your entire email sending infrastructure. You've validated that it works, that it's secure, and that it's being monitored.

You're ready to integrate it into your YourBrand application with confidence.

Bonus, extra recommendation

When we setup domain with ses. Usually we got: MAIL FROM record is not aligned if we have not setup mail form yet.

By default, when you send an email from noreply@yourowndomain.com through SES, the situation looks like this:

Header From: noreply@**yourowndomain.com**
Envelope From / MAIL FROM: 0100017...-....@**us-east-1.amazonses.com**

The domains do not match. This is what "not aligned" means.

Why Does Alignment Matter?

For a long time, this misalignment was fine. However, as spam filtering has become more aggressive, systems like DMARC now check for this alignment as a major sign of legitimacy.

DMARC Alignment

Your DMARC policy (which we set up) checks if the domain in the Header From matches the domain in the Envelope From (for SPF) and the domain in the DKIM signature.

When your MAIL FROM is an amazonses.com address, your email fails the SPF alignment check for DMARC.

Trust and Reputation

Major email providers like Microsoft 365 and Gmail are increasingly strict about this. A fully aligned email is a strong signal that you own your sending infrastructure from end to end.

Professionalism

It removes the "via amazonses.com" or "on behalf of" text that can sometimes appear in certain email clients. It makes your email look like it came directly from you, and only you.

The Solution

Setting Up a "Custom MAIL FROM" in SES. AWS created a specific feature to solve this exact problem. You can tell SES to use a subdomain of your domain for the Envelope From address.

This makes the domains align perfectly.

before

MAIL FROM: 0100017...-....@**us-east-1.amazonses.com**

after

MAIL FROM: ...@**bounces.yourowndomain.com**

This will pass aligned, because bounces.yourowndomain.com is part of yourowndomain.com.

Step-by-Step fix the alignment

Navigate to Verified Identities in SES: Go to the SES console, click "Verified identities", and click on your yourowndomain.com domain.

Find the Custom MAIL FROM Section: In the identity's details, scroll down to the "Custom MAIL FROM domain" tab and click the "Edit" button.

Configure the Subdomain.

MAIL FROM domain: Enter a subdomain you want to use for this purpose. It is a best practice not to use your root domain.

Good choices are bounces.yourowndomain.com, mail.yourowndomain.com, or ses.yourowndomain.com. Let's use bounces.yourowndomain.com.

Behavior on MX failure: Leave this as the default "Use default MAIL FROM".

Add the New DNS Records. Just like with domain verification, SES will now generate the DNS records you need to add to your DNS provider. It will give you two new records for the subdomain (bounces.yourowndomain.com)

  • One MX Record: This record tells the internet that any bounce-back emails for bounces.yourowndomain.com should be directed to AWS SES's servers.
  • One TXT Record: This is a specific SPF record for the subdomain. It authorizes SES to send email on behalf of bounces.yourowndomain.com.

Go to your DNS provider (GoDaddy, Route 53, etc.) and add these two new records exactly as AWS provides them.

Wait for Verification: Back in the SES console, the status for your Custom MAIL FROM will be "pending". After DNS propagates (usually within an hour), the status will change to "Verified".

Once that status is "Verified" you don't have to do anything else. AWS SES will automatically start using your custom MAIL FROM domain for all emails you send from @yourowndomain.com.

If you send another test email to Gmail and check "Show original", you will now see:

  • The Return-Path (Envelope From) will be an address at bounces.yourowndomain.com.
  • The spf=pass result will now be aligned with your yourowndomain.com domain.
  • Your dmarc=pass result will be even stronger.