Step-by-Step DNS Setup for AWS SES

Why DNS setup for AWS SES matters before sending any email

You’ve configured your app, written the perfect message, and hit send—only to see emails vanish into the void. No bounce. No error. Just silence. That’s not a delivery drop; that’s a DNS misstep.

Without correct DNS records, AWS SES can’t verify your domain ownership or prove you’re authorized to send. One missing or misaligned record can block your emails entirely, send them to spam folders, or harm your sender reputation—no matter how clean your content.

DNS setup for AWS SES isn’t optional. It’s the foundation. Every email sent through SES relies on exact records in your domain’s DNS: SPF, DKIM, and sometimes a third-party verification record. Get them wrong once, and delivery fails before the message even leaves your server.

Key takeaways

Incorrect DNS records prevent AWS SES from validating domain ownership, blocking delivery before it starts.
Even a single misconfigured record—like a typo in a DKIM selector—can cause emails to be rejected or marked as spam.
Proper DNS setup enables authentication, improves inbox placement, and protects your sender reputation with email providers.

What DNS records does AWS SES require for email sending?

You need three DNS records to send email reliably with AWS SES: SPF to authorize AWS to send on your behalf, DKIM to cryptographically sign emails and prove authenticity, and DMARC to tell receiving servers how to handle emails that fail SPF or DKIM checks. All three are essential for inbox placement and building sender reputation. Without them, your messages risk being marked as spam or rejected outright.

SPF: Authorizing AWS SES to Send

SPF (Sender Policy Framework) tells receiving mail servers which IPs or services are allowed to send email from your domain. For AWS SES, you must add a record that includes v=spf1 include:amazonses.com -all. This line authorizes Amazon's servers to send on your domain’s behalf. SPF alone doesn’t prevent spoofing—only aligns IP permission. You’ll find SPF best practices outlined in RFC 7208.

DKIM: Authenticating the Message

DKIM adds a digital signature to each email. This verifies that the message wasn’t altered in transit and confirms it originated from your domain. AWS SES provides a unique DKIM key for your verified domain. You must add a CNAME record in DNS pointing to a provided AWS endpoint. Receiving servers check this signature against the public key stored in DNS. It’s a critical trust signal—most major ISPs require it for high deliverability.

DMARC: Defining the Policy

DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM. It tells receivers what to do with messages that fail authentication. A DMARC record like v=DMARC1; p=quarantine; rua=mailto:[email protected] tells servers to either quarantine or reject unauthorized messages. It also enables reporting, helping you monitor delivery issues. Without DMARC, even properly signed emails may be rejected if SPF or DKIM checks fail inconsistently.

Record Type	Function	Required for AWS SES	Common Missteps
SPF	Authorizes specific IPs/services to send from your domain.	Yes	Overlapping SPF records, missing `include:amazonses.com`.
DKIM	Digitally signs emails to prove authenticity.	Yes	Incorrect CNAME value, missing DNS propagation time.
DMARC	Defines policy for failed authentication and enables feedback.	Yes	Setting `p=reject` too early without monitoring.

Setting these correctly matters: a failure in any one can cause delivery issues, even if the others are perfect. You can test your DNS setup with third-party tools like MXToolbox. If you’re unsure, use MailTester’s inbox placement test to see how your messages land in real inboxes across providers.

Once set, allow 24–48 hours for DNS propagation. Test your setup with AWS SES’s built-in verification or a real-time API like MailTester’s Email Verification API. Properly configured, you’ll see better inbox placement and fewer bounces across platforms.

Step-by-step: Configure SPF, DKIM, and DMARC records in DNS

You need to add three DNS records—SPF, DKIM, and DMARC—to prove ownership and improve deliverability when sending with AWS SES. SPF authorizes AWS to send emails on your behalf, DKIM signs each message to confirm authenticity, and DMARC tells receiving servers what to do if authentication fails. These records help avoid spam filters and improve inbox placement. You can verify your setup with tools like MxToolbox or MailTester’s inbox placement tester. AWS SES handles the heavy lifting, but DNS changes are required for full validation.

Set up SPF and DKIM with AWS SES

Log in to your domain’s DNS provider—Cloudflare, Route 53, GoDaddy, or another—using your admin credentials. This is where you manage your domain’s DNS records.
In AWS SES, go to the domain verification section and select “Verify a Domain.” Enter your domain name and follow the prompts. AWS will generate the required records.
Copy the SPF record value provided by AWS SES. It includes an include:amazonses.com tag, which authorizes AWS SES to send email from your domain. This is critical—without it, your emails may be rejected.
Add a TXT record in your DNS provider’s interface with name @ and the copied SPF value. This record is read by mail servers to verify sending permissions.
Return to AWS SES and click “Verify SPF.” The service checks your DNS record. Wait a few minutes. If it fails, check your record for typos or incorrect placement.
Generate the DKIM record in AWS SES by selecting “Generate DKIM” under the domain verification section. Copy the full TXT value.
Add a TXT record with name mail._domainkey and paste the DKIM value. This enables message signing and helps receivers trust your emails as authentic.
Wait 1–5 minutes for DNS propagation, then return to AWS SES and verify the DKIM record. Most providers update within 60 seconds, but delays are common in high-traffic environments.

Finalize with DMARC for monitoring and protection

Create a DMARC record as a TXT record with name _dmarc. Use a policy like v=DMARC1; p=none; rua=mailto:[email protected];. This sets a baseline policy—no enforcement yet—but collects reports on failed authentication.
Use a DMARC monitoring tool to review alignment and detect issues. The RFC 7483 standard defines DMARC’s structure and function. Start with p=none and gradually tighten to p=quarantine or p=reject as you confirm alignment.
Test deliverability using a real email service like MailTester’s inbox placement tester to confirm messages arrive in inboxes, not spam folders. Test your sending setup end-to-end.

SPF, DKIM, and DMARC are industry-standard trust mechanisms. Properly configured, they reduce false positives, improve sender reputation, and support high delivery rates. Use MailTester’s bulk verification or API to clean up old lists and avoid sending to invalid addresses that harm your reputation.

How long does DNS propagation take after setup?

After setting up DNS records for AWS SES, propagation typically takes 5 to 15 minutes. Some registrars may take up to 30 minutes or longer, especially if they cache records aggressively. Always wait at least 10 minutes before assuming the setup failed—DNS changes don’t happen instantly, but they usually resolve fast.

What affects DNS propagation speed?

Propagation speed depends on your domain registrar and how their nameservers handle TTL (Time to Live) values. Most providers honor low TTLs and update quickly, but older or less-responsive ones might delay changes. The global DNS system doesn’t synchronize in real time—you’re relying on recursive resolvers across the internet to fetch your new records.

For example, the Internet Engineering Task Force (IETF) specifies that DNS TTLs are meant to help control how often resolvers refresh their cache, and many modern systems enforce this behavior strictly (RFC 1034, Section 3.5). If you set a low TTL (like 300 seconds) before making changes, you’re giving resolvers more incentive to check sooner. That said, your registrar or DNS host might still override this.

How to verify your setup without guessing

Don’t rush to restart the process if it doesn’t work right away. Let it sit for at least 10 minutes. Then, use a reliable tool to check if your DNS records are live. Tools like MXToolbox or DNSChecker.org let you test from multiple locations to confirm visibility worldwide.

Even after DNS is propagated, your email may still face delays in reaching inboxes. That’s because ISPs and email providers run additional checks—like domain reputation and sending history—that aren’t DNS-related. You can test deliverability independently by sending a message through your verified domain and checking whether it lands in the inbox or spam folder. MailTester’s inbox placement test gives a real-world view of how your message performs across major email clients.

Once propagation is confirmed, you can move on to testing actual sends—whether through AWS SES or a third-party integration like Mailchimp or HubSpot. If you’re cleaning a large list before sending, use a verified service to avoid invalid or risky addresses. Bulk list verification can help identify bad addresses before they hurt your sender reputation.

How to verify DNS records are working correctly

After setting up SPF, DKIM, and DMARC in your DNS, verify they’re live and correct by querying your domain with tools like MxToolbox or dig. Check that each record appears exactly as configured—no typos, no extra spaces, no duplicates. A single misconfigured SPF record can break deliverability. Use DNS lookup tools to confirm alignment between your ‘from’ domain and DKIM signature.

Check that your DNS records are properly published

Use MxToolbox or run dig TXT yourdomain.com in your terminal to fetch your DNS TXT records.
Compare the output exactly to what you entered in your DNS provider. Even a missing space or extra quote breaks validation.
Ensure you have only one SPF record per domain. Multiple SPF records are invalid—combine all mechanisms into a single record using include: clauses.
Verify that your DKIM selector (e.g., s=mail) matches the one AWS SES generated and that the key is correctly formatted as a TXT record.
Check that DMARC is published at _dmarc.yourdomain.com with a valid policy like v=DMARC1; p=none;.
Test alignment by sending a test message via AWS SES and inspecting the headers. The From: domain must match the domain used in the DKIM signature.
If you use a subdomain (e.g. mail.yourdomain.com), ensure the SPF and DKIM records are set for that specific domain or use include: to include the parent.
Wait up to 72 hours after DNS changes for global propagation—some providers or resolvers cache records longer.

Use real-world validation to catch hidden issues

Send a test email to a mailbox like Gmail or Outlook and view the full headers. Look for Authentication-Results to confirm SPF and DKIM pass.
Check for warnings like “SPF record not found” or “DKIM signature failed”—these indicate configuration issues.
Naturally, some ISPs (like AOL, Yahoo) are stricter than others. A record that passes in one inbox won’t always pass in another.
Use a tool like RFC 7208 (SPF specification) to cross-check your record syntax.
Before sending to a large list, verify each address with a real-time tool like MailTester’s email verification API to catch outdated, invalid, or role-based addresses.
For high-volume sends, run inbox placement tests via MailTester’s inbox tester to ensure your emails land in the inbox, not spam.
Keep records updated if you switch email services, add new senders, or change your domain setup.

Even one incorrect character in a DNS record can cause emails to be rejected. Verification is not optional—it’s mandatory for delivery.

Common DNS mistakes that break AWS SES sending

You’re likely failing to send with AWS SES because of a single DNS error—like having multiple SPF records or misplacing DKIM. These are common, fixable issues that block deliverability. Let’s walk through the most frequent ones, with exact solutions. No guessing. No fluff.

SPF and DKIM: One record, one place, one rule

Only one SPF TXT record is allowed per domain. If you have multiple, DNS ignores all but the first. Use a single record with all your senders listed—your domain, AWS SES, and any other services. Check with RFC 7208 for syntax.
For AWS SES, you must include include:amazonses.com in your SPF. Omitting this means AWS won’t be authorized to send on your domain. Double-check syntax: v=spf1 include:amazonses.com ~all.
DKIM must be placed under mail._domainkey.yourdomain.com. If you put it at _domainkey.yourdomain.com or dkim.yourdomain.com, it won’t work. AWS gives you the exact value—use it as-is.

DMARC and propagation: the silent killers

DMARC is required for reputation tracking. A missing or malformed DMARC record (e.g., DMARC=none or invalid tags) causes receivers to treat your mail as unauthenticated. Use v=DMARC1; p=none; rua=mailto:[email protected] as a start.
After updating DNS, wait 24–48 hours for propagation. Testing immediately with inbox placement will fail even if you did everything right. Use MXToolbox to verify propagation before sending.
Never use an SPF record that includes both include:amazonses.com and include:_spf.google.com on the same domain unless you combine them in one record. More than one SPF record breaks validation.

Even a minor DNS misstep can result in your messages being blocked or marked as spam. Fix one, you’re good; ignore the rest, and deliverability breaks.

Before sending, verify your setup using real email checks. Spot bad addresses before they hurt your sender reputation. Bulk verify your list or use our real-time verification API to catch errors early. Your inbox placement depends on it.

How to test if your DNS records enable successful email delivery

You can verify your AWS SES DNS setup by sending a test message to a verified email address, then checking whether it arrives in the inbox, spam folder, or fails entirely. Use real inboxes—like Gmail or Outlook—not just internal tools. Then confirm delivery and placement with third-party tools that assess spam filters and sender reputation.

Send a test message through AWS SES

After setting up your SPF, DKIM, and verified identities in AWS SES, use the service’s built-in "Test Email" feature. This sends a message directly from SES to a verified address you control. It’s the fastest way to confirm that your DNS records are correctly configured and accepted by AWS’s infrastructure.

Let’s say you verified [email protected]. If the message shows as "sent" in the SES console, the SMTP or API handshake worked. But that doesn’t mean it reached the inbox. The real test is how it lands in a live mailbox.

Check delivery, placement, and spam detection

Send a test campaign from your verified AWS SES identity to a personal Gmail or Outlook account. Wait 10–15 minutes, then check the inbox, spam folder, and junk mail folder. If it’s in spam, your sender reputation, content, or DNS setup might still be misconfigured.

Tools like MailTester’s inbox-placement test simulate how your email lands across real mail providers. They check not just delivery, but how aggressively spam filters treat your message. This feedback helps you tweak your sending practices before scaling.

Also, check your sender reputation with services like MxToolbox or Spamhaus. These tools track blacklists, feedback loops, and historical abuse patterns. A poor reputation—even with correct DNS—can still block delivery, even if your records are valid.

Finally, ensure your email content follows basic sending hygiene: avoid spam trigger words, include a clear unsubscribe link, and don’t send to invalid or unengaged addresses. These signals matter just as much as DNS correctness.

Delivery starts with DNS. But inbox placement depends on reputation, content, and consistency.

By combining AWS SES’s test features with third-party inbox testing and reputation checks, you turn a technical setup into a reliable, deliverable email stream.

Why checking your email list’s health matters with AWS SES

You can’t send emails with AWS SES without verifying your domain or email address, but even that doesn’t guarantee your messages reach inboxes. Invalid, role-based, or disposable email addresses waste your sending quota, increase bounce rates, and hurt your sender reputation—leading to throttling or blacklisting. Cleaning your list before sending protects your deliverability and ensures you’re not just burning through credits on non-deliverable addresses.

How bad addresses drain your AWS SES limits

Every email you send counts against your daily sending quota in AWS SES. If you’re sending to invalid or nonexistent addresses, you’re burning quota on messages that never land in a real inbox. Role accounts like admin@ or info@ often reject messages, and disposable domains are frequently flagged by major providers. These send failures don’t just cost you capacity—they directly contribute to bounce rates, which AWS SES tracks closely.

Keep deliverability strong with list hygiene

High bounce rates are a red flag in email deliverability. ISPs and email providers monitor sender reputation metrics like bounce rate, complaint rate, and engagement. Consistently high bounces trigger automatic throttling or even blacklisting, especially when your volume is large. According to data from Return Path, senders with bounce rates over 5% often see inbox placement drop significantly.

Use MailTester’s bulk verification to clean your list before pushing to AWS SES. It checks for invalid, role, and disposable addresses, flagging catch-all domains that may accept messages but are poor for engagement. Catch-alls can lead to high open rates on paper, but with no real human interaction, they signal low quality to inboxes and degrade sender reputation.

Some addresses might be valid but risky—common in low-engagement segments. Identifying and suppressing these helps you maintain a strong reputation. MailTester’s 98.9% accuracy rate comes from combining real-time SMTP checks, MX validation, and pattern recognition for role addresses or temporary domains.

Let’s be clear: no tool can guarantee inbox delivery. But validating your list before sending removes the preventable failure points. You’re not just saving credits—you’re building a sustainable sending practice.

How MailTester helps verify your setup and list quality

You can catch sending problems early by verifying individual addresses, cleaning your list, and testing inbox placement before sending with AWS SES. MailTester’s real-time API lets you check addresses on the fly, bulk verification removes invalid, role, and disposable emails, and inbox testing shows how your messages land in Gmail, Yahoo, and Outlook. With AI-assisted insights, you get clear fixes when delivery fails.

Verify individual addresses and clean your list

Use MailTester’s real-time API to validate each address before every send — perfect for dynamic list growth or one-off verifications.
Run bulk list verification on your full subscriber list to flag invalid, catch-all, role-based, and disposable emails. This reduces bounce rates and protects your sender reputation.
Discover why a recipient is flagged: invalid means the address doesn’t exist, catch-all means it accepts all mail, role means it’s admin@ or sales@, and disposable means it’s from a throwaway domain.

Test inbox placement and fix delivery issues

Test how your messages land in real inboxes using MailTester’s inbox placement tool. Simulate sends across Gmail, Yahoo, Outlook, and other major providers to see delivery, spam marking, and inbox placement rates.
If your email isn’t landing in the inbox, use the in-app AI assistant to decode results. It reads bounce codes, parse header logs, and suggests specific fixes — like adjusting DKIM alignment or lowering sending volume.
MailTester integrates with your existing tools (Mailchimp, Klaviyo, SendGrid) via real-time sync, so verification becomes part of your normal workflow without manual steps.

Deliverability isn’t just about sending — it’s about ensuring your messages reach real inboxes, not spam folders. According to Spamhaus, about 20% of legitimate emails are blocked or marked as spam due to poor list hygiene. A single invalid address can harm sender reputation. With MailTester, you validate at scale, test before sending, and act on insights — not guesses. Accuracy is high: the system catches 98.9% of invalid addresses. You get real results, not marketing fluff.

What to do after successful DNS setup with AWS SES

Once your DNS records are live and AWS SES confirms delivery readiness, begin sending at a low volume. Start with a few hundred emails per day to establish a positive sender reputation with ISPs.

Warm up your domain gradually

Increase your sending volume over several days, not hours. A slow ramp-up reduces the risk of triggering spam filters that flag sudden spikes in sending volume.

Monitor performance and refine over time

Check bounce and complaint rates in the AWS SES console daily. High bounce rates signal invalid addresses; high complaints suggest content or targeting issues. Use these metrics to clean your list and improve email content.

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can I use AWS SES without setting up DNS records?

No. DNS records (SPF, DKIM, DMARC) are required to verify your domain and enable sending. Without them, emails will be blocked or marked as spam.

How many SPF records can I have on one domain?

Only one SPF record is allowed per domain. Multiple records cause SPF failures. If you have existing SPF, include AWS SES using the include:amazonses.com mechanism.

Does AWS SES support sending from subdomains?

Yes. You can verify a subdomain (e.g. mail.yourcompany.com) and set up SPF and DKIM records for it, then send from that subdomain.

Why does AWS SES require DKIM signing?

DKIM proves the email was sent from your domain and wasn’t altered in transit. It improves inbox placement and reduces spoofing risk.

What if my DNS records are correct but emails still don’t send?

Check the AWS SES sending quota, verify your account is out of the sandbox, and confirm your domain is fully verified in the SES console.

Can I use MailTester to check my DNS configuration?

Not directly, but you can use MailTester’s email verification to test whether messages to valid addresses actually arrive in inbox or spam folders.

How do I prevent my AWS SES domain from being blacklisted?

Avoid high bounce and complaint rates. Regularly clean your list using tools like MailTester, and ensure SPF, DKIM, and DMARC are correctly configured.

What happens if I delete a DKIM record after setup?

Emails will lose their cryptographic signature, leading to delivery failure or spam marking. Re-add the original record to restore signing.

Is DMARC required for AWS SES?

Not required, but strongly recommended. It tells receivers how to handle failed SPF or DKIM checks and improves email authentication trust.

How do I know my domain is fully verified in AWS SES?

In the AWS SES console, check that your domain shows 'Verified' and that both SPF and DKIM are marked as 'Verified'.

What’s the difference between SPF and DKIM?

SPF authorizes IP addresses to send mail from your domain. DKIM adds a digital signature to verify the message wasn’t altered and that it originated from your domain.

Can I send emails from multiple domains with one AWS SES account?

Yes. You can verify multiple domains or subdomains in AWS SES and configure DNS records for each one individually.