Amazon SES SPF setup: custom MAIL FROM domain for DMARC alignment

Amazon SES SPF “just works” against amazonses.com, and that is exactly the trap. The default envelope sender is a subdomain of amazonses.com, so SPF passes. But it does not align with your From domain, so DMARC fails through the SPF path.

The fix is a custom MAIL FROM domain. This guide walks through the exact records you need.

If you are new to SPF, start with the SPF overview.

Why SES SPF passes but DMARC fails

RFC 7208 evaluates SPF against the MAIL FROM (envelope) domain. RFC 9989 requires that domain to align with the From header for DMARC to pass via the SPF path.

Out of the box, SES uses a subdomain of amazonses.com as the MAIL FROM. SPF passes against amazonses.com. But your From header is [email protected], and amazonses.com does not align with example.com, so DMARC will not pass through SPF. For background, see our deeper DMARC alignment article and the alignment fundamentals page.

DKIM signed with d=example.com can still align and let DMARC pass. SPF alignment requires a custom MAIL FROM.

The fix: a custom MAIL FROM subdomain

AWS requires the MAIL FROM domain to be:

• A subdomain of the verified parent domain (for example mail.example.com for a verified example.com).
• Not a subdomain you also use to send From mail.
• Not a subdomain you use to receive mail.
• Backed by exactly one MX record. Multiple MX records make SES setup fail.

Step 1: pick a MAIL FROM subdomain

A common convention is mail.example.com or bounce.example.com. Pick a label that is unused today and reserve it for SES bounces.

Step 2: configure it in the SES console

In the SES console, open Configuration > Identities, choose your verified domain, and at the bottom of the page open Custom MAIL FROM domain > Edit.

• Tick Use a custom MAIL FROM domain.
• Enter the subdomain.
• Choose Behavior on MX failure: Use default MAIL FROM domain falls back to amazonses.com if the records are missing or wrong; Reject message returns MailFromDomainNotVerified and refuses to send. Pick Reject if you would rather see a hard failure than ship unaligned mail.

If you provision SES through Terraform or the AWS CLI, the equivalent API is SetIdentityMailFromDomain.

Step 3: publish the MX and TXT records

SES will display two records to add at the MAIL FROM subdomain. They look like this for us-east-1:

mail.example.com.   MX   10 feedback-smtp.us-east-1.amazonses.com
mail.example.com.   TXT  "v=spf1 include:amazonses.com ~all"

Three things to watch:

• Region. The MX target is feedback-smtp.{region}.amazonses.com. Use the region you actually send from (us-east-1, us-west-2, eu-west-1, and so on). The wrong region silently fails.
• Priority. The 10 is the MX priority and goes in a separate field in most DNS UIs.
• Quotes. AWS publishes the TXT value with surrounding quotation marks. Some DNS providers want them, some strip them. Check the saved record before moving on. If you build SPF strings by hand, our SPF generator will validate the syntax.

The SPF value is exactly v=spf1 include:amazonses.com ~all. It is a per-MAIL-FROM record and does not need to mirror what is on your apex domain.

Step 4: wait for SES to detect the records

SES polls DNS and flips the identity from Pending to Success. Most providers propagate in minutes; AWS will wait up to 72 hours before giving up and marking the state Failed. While you are pending, the Behavior on MX failure setting controls whether SES sends with the fallback envelope or refuses.

Step 5: verify SPF and DMARC alignment

Send a real test message and inspect the headers. You want to see:

• Received-SPF: pass (or spf=pass in the Authentication-Results header) with smtp.mailfrom=mail.example.com.
• dmarc=pass with the SPF aligned identifier matching your From domain.

Then run your domain through DMARCTrust’s domain checker for a clean syntax review of SPF, DKIM, and DMARC. Once your real reports start flowing, SES should appear as an authorized source with both SPF and DKIM passing.

Common mistakes

Assuming default SES SPF is enough for DMARC. It passes the SPF check, but it does not align. Without a custom MAIL FROM you must rely entirely on DKIM for DMARC.

Reusing a subdomain that already has DNS records. If mail.example.com already has an MX (because it receives mail) or an A/CNAME (because it serves something else), SES will refuse to verify or you will break the existing service. Use a fresh label.

Pointing at the wrong region. feedback-smtp.us-east-1.amazonses.com is not interchangeable with the eu-west-1 host. If you call the SES API in multiple regions, each region needs its own custom MAIL FROM identity.

Adding a second SPF record at the MAIL FROM subdomain. Only one v=spf1 TXT record is permitted per name. If you ever need to authorize another sender from the same MAIL FROM subdomain, merge the includes into one record. SES plus several other providers at your apex can also push you toward the 10-DNS-lookup limit. If you start hitting it, our SPF flattening explainer covers the fix.

Forgetting that SES is per-region. A custom MAIL FROM domain is configured against an identity, and SES identities are scoped to a region. If you fail over from us-east-1 to us-west-2, set up the same MAIL FROM in both.

What about DKIM?

For most SES customers, DKIM is the more reliable DMARC path: SPF breaks on forwarding, DKIM survives. DKIM also lets a single signed identity pass DMARC even when the envelope sender is an opaque AWS host.

The companion guide is Amazon SES DKIM setup. It covers Easy DKIM, BYODKIM, DEED, and the per-region signing trap.

FAQ

Does SES need an SPF record on my From domain?

No. SES SPF lives on the MAIL FROM subdomain, not on your apex From domain. Your apex SPF only needs to authorize the senders that actually use the apex as their MAIL FROM (typically Google Workspace or Microsoft 365 for business mail).

Can I just put include:amazonses.com in my apex SPF and skip custom MAIL FROM?

That authorizes SES to send, but it does not produce DMARC alignment. SES still uses an amazonses.com envelope sender, so the SPF check evaluates against amazonses.com, not your domain. The apex include only matters if SES is somehow configured to use your apex as MAIL FROM, which is not the default.

Why does SES require exactly one MX record?

SES uses the MX record to route bounce and complaint notifications back to itself. Multiple MX records would let mail flow elsewhere, so the SES verifier rejects the setup.

What does the MailFromDomainNotVerified error mean?

It means SES tried to send a message using your custom MAIL FROM subdomain, could not confirm the required MX record on that subdomain, and you have Behavior on MX failure set to Reject message. Either fix the MX record (priority 10, value feedback-smtp.{region}.amazonses.com for the region you send from) or temporarily flip the failure behavior to Use default MAIL FROM domain until the record propagates.