Amazon SES MAIL FROM Domain Setup for SPF and DMARC Alignment

The Amazon SES default MAIL FROM domain is a subdomain of amazonses.com - which means messages you send through SES will not produce SPF alignment for DMARC, even when DMARC is otherwise correctly configured. A custom MAIL FROM domain fixes that gap with two DNS records (one MX, one TXT) and a single change in the SES console. Total work is roughly ten minutes; AWS detection can take up to 72 hours.

This is a reference walkthrough for the bounce-address subdomain pattern (e.g. bounce.example.com), the DNS records SES will demand, and the failure modes that catch teams off guard.

What MAIL FROM is and why SES needs a custom one

Every SMTP message carries two sender addresses: the From: header that recipients see in their inbox, and the envelope MAIL FROM (also called Return-Path or bounce address) that the receiving mail server uses to deliver non-delivery reports. According to AWS's MAIL FROM documentation, Amazon SES automatically sets that envelope address to a subdomain of amazonses.com unless you configure your own - so your bounce traffic flows to AWS, not your domain, and the MAIL FROM domain visible to receivers is amazonses.com.

That default is fine for raw SPF, because the IP is genuinely an SES IP. The problem is DMARC. DMARC requires alignment: the domain the receiver authenticates against has to match the domain in the From: header that the recipient sees. With the default MAIL FROM, SPF authenticates amazonses.com, but your From: header is you@example.com - the two do not align, and SPF cannot contribute to a DMARC pass. The fix is to authenticate SPF against a subdomain you own.

How DMARC alignment requires DKIM or aligned SPF

DMARC passes when at least one of SPF or DKIM authenticates and aligns with the From: header domain - so configuring both is the textbook recommendation. The relationship between the two is straightforward and worth visualizing before you touch any DNS.

Without a custom MAIL FROM, only the DKIM path is available - and DKIM signatures can be invalidated by forwarders that rewrite the body or strip headers. The custom MAIL FROM gives you a second, independent path to alignment.

For a refresher on how the three protocols fit together, see SPF, DKIM, and DMARC explained.

Setting up a custom MAIL FROM in the SES console

The AWS console flow takes about two minutes once you have a verified domain identity. Per AWS's setup procedure, the steps are:

1. Open the SES console and choose Configuration → Identities in the left navigation.
2. Select the verified domain identity (status must be Verified) - if you have not verified the domain yet, follow our walkthrough on how to set up Amazon SES first.
3. Scroll to the Custom MAIL FROM domain pane and choose Edit.
4. Tick Use a custom MAIL FROM domain and enter your subdomain - the convention is bounce.example.com or mail.example.com. AWS requires that this subdomain is not used to send mail from a different system and not used to receive mail.
5. Choose a Behavior on MX failure option (covered below).
6. Save changes. SES will display the exact MX and TXT records you need to publish.

If your domain uses Route 53 in the same AWS account, the console offers a one-click Publish Records Using Route 53 button that creates both records for you. Every other DNS provider requires manual publication.

The DNS records you need

SES needs exactly two records on the MAIL FROM subdomain: one MX record so bounce notifications can be routed back, and one TXT record that authorizes SES IPs to send on behalf of that subdomain. For a MAIL FROM of bounce.example.com in us-east-1, the records look like this:

Record	Host / Name	Type	Value	Purpose
Bounce routing	bounce.example.com	MX	10 feedback-smtp.us-east-1.amazonses.com	Routes bounces and complaints back to SES so events appear in the SES dashboard and SNS topics.
SPF authorization	bounce.example.com	TXT	"v=spf1 include:amazonses.com ~all"	Tells receivers that Amazon SES is authorized to send mail with this subdomain as the envelope sender.

A few exact-format details that catch people:

• The 10 in the MX value is the preference number. Most DNS providers split this into its own field; do not paste it into the hostname.
• The MX target host is Region-specific. eu-west-1 becomes feedback-smtp.eu-west-1.amazonses.com, ap-southeast-2 becomes feedback-smtp.ap-southeast-2.amazonses.com, and so on. Using the wrong Region will leave the identity stuck in Pending indefinitely.
• The TXT record value must include the surrounding quotation marks in most DNS GUIs (Route 53 strips them automatically; many others do not).
• Publish exactly one MX record. AWS explicitly states that multiple MX records on the MAIL FROM subdomain will cause the setup to fail.

In zone-file syntax the records look like this:

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

Verifying the configuration

After you publish the records, SES enters a Pending state and starts polling DNS. AWS will email the account's notification address when the state changes. The four possible states map to clear sending behaviors:

• Pending - SES is still looking. Mail uses the fallback (default MAIL FROM or rejection, depending on your choice). Detection runs for up to 72 hours.
• Success - SES detected the records and is now using your custom MAIL FROM on the envelope. SES keeps polling so it can downgrade you if the records disappear.
• TemporaryFailure - SES saw the records once but now cannot. Mail reverts to the fallback while SES retries.
• Failed - SES never detected the records inside the 72-hour window. You have to restart the setup in the console.

To verify outside the AWS UI:

dig +short MX bounce.example.com
# expect: 10 feedback-smtp.us-east-1.amazonses.com.

dig +short TXT bounce.example.com
# expect: "v=spf1 include:amazonses.com ~all"

Then send a test message and inspect the raw headers in the recipient inbox. You should see Return-Path: <something@bounce.example.com> (instead of an amazonses.com address) and an Authentication-Results header showing spf=pass together with dmarc=pass on example.com.

Common failure modes

Four problems account for nearly every stuck setup:

• Wrong Region in the MX target. Teams copy a value from an eu-west-1 runbook into a us-east-1 account and never see the state leave Pending. Always pull the MX target from the SES console - it is generated for the Region you are configured in.
• An A record on the MAIL FROM subdomain. If bounce.example.com already resolves to a website (because the subdomain was previously used for something else), the SPF check itself still works, but the MX record fights with the existing infrastructure and bounces can be misrouted. Use a dedicated subdomain with nothing else on it.
• Multiple MX records. Some DNS providers auto-create a fallback MX. AWS requires exactly one MX on the MAIL FROM subdomain - any extra MX record causes setup to fail outright.
• Propagation lag. DNS TTLs on a brand-new zone often default to 24-48 hours. If you see Pending for longer than a few hours, run dig against 8.8.8.8 and your registrar's authoritative server; a mismatch tells you propagation has not finished.

MAIL FROM for subdomains and multi-domain accounts

If you send from multiple domains through the same SES account (a common pattern in agencies and multi-tenant SaaS), each domain identity gets its own MAIL FROM. You cannot share bounce.example.com across example.com and example.net - AWS enforces that the MAIL FROM is a subdomain of the parent of the verified identity. The standard pattern is:

• For example.com, use bounce.example.com.
• For client-domain.com, use bounce.client-domain.com.
• For a subdomain identity like notifications.example.com, use bounce.notifications.example.com.

You can also script the entire flow with the SetIdentityMailFromDomain API, which is what most management layers do when they provision domains on behalf of customers - including the way Mailblast handles its hosted onboarding for BYO-SES tenants.

FAQ

What MAIL FROM domain does Amazon SES use by default?

Amazon SES uses a subdomain of amazonses.com as the envelope MAIL FROM whenever you have not configured a custom one. The exact subdomain varies by AWS Region. SPF still passes because the message genuinely originated from SES infrastructure, but the MAIL FROM domain will not match your From: header domain, so SPF alignment fails for DMARC.

Do I still need DKIM if I set up a custom MAIL FROM domain?

Yes. DKIM and a custom MAIL FROM solve different problems. DKIM signs the message body with a key on your domain. A custom MAIL FROM aligns the envelope sender with your From: header so SPF satisfies DMARC. AWS recommends configuring both because either one passing is enough for DMARC, and redundancy protects you when a forwarding hop strips one signal.

Can I reuse my main domain as the MAIL FROM domain?

No. AWS requires the MAIL FROM to be a subdomain of the verified parent domain, and it must not be a subdomain you use to send or receive mail from. A dedicated bounce subdomain like bounce.example.com or mail.example.com keeps the SPF record narrow and prevents conflicts with your inbound MX records.

How long does Amazon SES take to detect the DNS records?

AWS polls for the MX record continuously and will email you when the status changes to Success. The detection window stays open for 72 hours. If the records have not propagated by then the identity moves to a Failed state and you have to restart the setup from the SES console.

What happens if my MAIL FROM MX record breaks later?

The behavior depends on the fallback you chose during setup. Use default MAIL FROM domain reverts SES to the amazonses.com subdomain so mail keeps flowing, at the cost of DMARC alignment. Reject message tells SES to return MailFromDomainNotVerified and drop the send. Pick Use default for production unless you have monitoring that will catch the regression immediately.

How Mailblast Fits with Custom MAIL FROM

Mailblast operates on your own Amazon SES account (BYO-SES), so the MAIL FROM identity, the DNS records, and the per-Region configuration all stay in your AWS account and your DNS zone. Mailblast reads the verified identity and sends through it, which means a custom MAIL FROM you set in the SES console takes effect for Mailblast traffic the moment SES flips the identity to Success. You do not configure MAIL FROM inside Mailblast; you configure it once on the SES identity and it applies to every campaign Mailblast pushes through that identity.

For multi-brand and agency setups where you send from several verified domains in one SES account, follow the per-domain MAIL FROM pattern above and Mailblast will route each campaign through the matching identity.

---

Disclosure: Mailblast is a hosted management layer for your own Amazon SES account. The MAIL FROM identity, DNS records, and Region selection belong to your AWS account; Mailblast does not pool sending across customers or wrap SES centrally.