Every email carries two sender addresses, and only one of them is visible. The From header is what shows up in an inbox. The MAIL FROM address, also called the envelope sender or the Return-Path, is what mail servers use to route the message and to send it back if delivery fails. Amazon SES points that second address at a subdomain of amazonses.com unless you configure your own. That means SPF authenticates Amazon’s domain on every message you send, not yours, and bounces are addressed to Amazon’s mail server instead of one on your domain.
Key Takeaways
- The From header and the MAIL FROM address (also the envelope sender, or Return-Path) are different fields. SPF checks MAIL FROM, not From.
- SES defaults MAIL FROM to a subdomain of
amazonses.com, which is why SPF passes for Amazon by default, not for your domain.- A custom MAIL FROM domain needs one MX record and one SPF TXT record, both at a subdomain you don’t send or receive regular mail on.
- DKIM alone can already satisfy DMARC if it’s signed as your domain. A custom MAIL FROM domain gives DMARC a second, independent way to pass.
The two addresses on every message
RFC 5321 defines the SMTP envelope, the machine-to-machine conversation that delivers a message, and the MAIL FROM command in that conversation carries the address a receiving server will use if it needs to bounce the message back. RFC 5322 defines the header block a mail client renders, and the From: line in it is what a person reads. Nothing requires the two to match, and on most marketing email they don’t. A sending platform typically puts its own domain in the envelope so bounces come back to its own infrastructure, while your brand’s domain stays in the From header the recipient sees.
SPF, defined in RFC 7208, only ever checks the envelope address. A message can carry a From header of news@example.com and still pass SPF against a completely different domain, because SPF was never looking at the From header in the first place. That gap between what SPF checks and what a reader sees is exactly what a MAIL FROM domain closes, and it’s the same gap SPF, DKIM and DMARC without the acronym soup covers from the DKIM side.
What SES uses if you don’t set one up
Amazon SES gives every account a working MAIL FROM domain with nothing to configure: a subdomain of amazonses.com, varying by AWS region. Mail sent this way passes SPF cleanly, because Amazon’s own SPF record authorizes Amazon’s own sending infrastructure. AWS says so directly: “Sender Policy Framework (SPF) authentication successfully validates these messages because the default MAIL FROM domain matches the application that sent the email, in this case, SES.”
That default is fine for delivery. What it costs you is alignment. SPF authenticates amazonses.com, not your domain, so it contributes nothing toward DMARC alignment for your From address. AWS describes the MX record a custom MAIL FROM domain requires as what lets your domain receive the bounce and complaint notifications that email providers send.
What a custom MAIL FROM domain changes
Setting up your own MAIL FROM domain, a subdomain you own, does two things at once.
SPF now authenticates your domain. Once your MAIL FROM subdomain publishes its own SPF record authorizing SES, a passing SPF check is a pass for your domain. It can now align with the domain in your From header under DMARC.
The bounce address becomes yours. A receiving server that needs to bounce a message looks up MX for the MAIL FROM domain, which is now your subdomain. The record you publish points that lookup at feedback-smtp.<region>.amazonses.com, so SES still takes delivery and still reports the bounce back to you. What changes is the domain on the envelope, not the machine that catches it.
Neither change touches how the message is delivered or how it looks to a recipient. Nobody reading the message sees the MAIL FROM address at all under normal use; it only surfaces in the raw source or in a bounce.
The DNS records it needs
A custom MAIL FROM domain needs exactly two records, published at the subdomain you choose, for example mail.example.com:
mail.example.com. MX 10 feedback-smtp.us-east-1.amazonses.com.
mail.example.com. TXT "v=spf1 include:amazonses.com ~all"That’s Amazon’s own documented pattern: the MX record routes bounce and complaint traffic to SES, and the TXT record is the SPF record authorizing SES to send as that subdomain. The region in the MX target matches whichever AWS region you’re sending from. AWS requires exactly one MX record on the subdomain; a second one fails the setup outright.
AWS sets three rules for the subdomain:
- It has to be a subdomain of the parent domain of a verified SES identity.
- It shouldn’t be a subdomain you also send email from.
- It shouldn’t be a subdomain you use to receive email.
The last two rule out the obvious shortcut of pointing MAIL FROM at your root domain or at whatever subdomain already runs your inbox. mail.example.com or bounces.example.com, used for nothing else, is the usual choice.
Once published, SES can take up to 72 hours to detect the MX record. The domain shows Pending, then Success once found, or Failed if it never turns up. A Behavior on MX failure setting decides what happens to your sending in the meantime: “Use default MAIL FROM domain” falls back to the amazonses.com default so mail keeps going out, and “Reject message” refuses the send instead. Publish DNS records at your domain provider shows the exact host fields for the other five records an EmailFig sending domain needs, and your DNS records, one at a time walks through publishing each kind with dig to check it.
Why bother, if DKIM alone can already pass DMARC
DMARC, defined in RFC 7489, passes a message if either SPF or DKIM produces an aligned result. It doesn’t require both. If your DKIM key signs as your own domain, which is how SES’s own DKIM setup works, DKIM alone already gives DMARC an aligned pass, with no custom MAIL FROM domain in the picture at all. AWS’s own documentation frames the custom MAIL FROM domain as exactly this kind of option, not a requirement: it gives you “the flexibility to use SPF, DKIM, or both to achieve DMARC validation.”
Alignment itself comes in two strengths, and the default matters here. RFC 7489 section 3.1 defines relaxed alignment as a match on the organizational domain, so a MAIL FROM of bounces.example.com aligns with a From address of news@example.com. Strict alignment requires an exact match instead. Relaxed is the default for both SPF and DKIM, and it’s forgiving enough that a MAIL FROM subdomain does the job without matching your From address exactly. Whether that alignment is actually holding for your real traffic is what a DMARC aggregate report shows, row by row, not something you can assume from the DNS record alone.
Given that, a working DKIM setup is enough to pass DMARC by itself. What a custom MAIL FROM domain buys on top of that is redundancy. DKIM validates a signature over the message, and that signature breaks if a gateway rewrites the subject or adds a footer. SPF doesn’t look at the message content, so that kind of change doesn’t affect it. (Forwarding is the reverse case: it often breaks SPF and leaves DKIM intact.) With a custom MAIL FROM domain, a broken DKIM signature still leaves an aligned SPF pass behind it, and DMARC only needs one. With the SES default, that fallback authenticates Amazon, not you, and doesn’t count.
The MX record is not a second benefit on top of that. SES requires it so the MAIL FROM domain can take delivery of bounce and complaint traffic at all, which is the condition of using your own domain on the envelope in the first place.
Frequently asked questions
What’s the difference between the From header and the MAIL FROM address?
The From header is what a recipient sees in their inbox. The MAIL FROM address, also called the envelope sender or Return-Path, is what mail servers use to route the message and to send a bounce if delivery fails, and it’s normally invisible unless you view a message’s raw source or look at a bounce. SPF only ever checks the MAIL FROM address, not the From header.
What is Amazon SES’s default MAIL FROM domain?
Amazon SES points every message’s MAIL FROM address at a subdomain of amazonses.com unless you configure your own. SPF passes cleanly on that default because Amazon’s own SPF record authorizes Amazon’s own sending infrastructure, but that pass authenticates Amazon, not your domain.
How long does Amazon SES take to verify a custom MAIL FROM domain?
Amazon SES can take up to 72 hours to detect the MX record, depending on your DNS provider (AWS’s MAIL FROM documentation). The domain shows as Pending until SES finds the record, then moves to Success, or to Failed if 72 hours pass without it.
Can I use my root domain as my Amazon SES MAIL FROM domain?
No. AWS requires a MAIL FROM domain to be a subdomain of a verified identity’s domain, and it shouldn’t be one you also send or receive email on. mail.example.com or bounces.example.com, used for nothing else, is the usual choice.
Do I need a custom MAIL FROM domain if my DKIM signature already passes DMARC?
Not strictly. DMARC passes if either SPF or DKIM produces an aligned result, so a DKIM key that signs as your own domain already gives DMARC a pass on its own. What a custom MAIL FROM domain adds is redundancy: DKIM’s signature breaks if a gateway alters the message, and SPF doesn’t look at the content, so an aligned SPF pass survives that kind of change.
If you send through EmailFig
EmailFig sets up a custom MAIL FROM subdomain (emfigmail) for every sending domain, so you never choose one. It gives you the MX and SPF records for it, alongside three DKIM CNAME records, a DMARC record and a tracking CNAME. The values differ from the generic AWS sample above, so copy them from EmailFig. You publish the records once at your DNS provider, and EmailFig marks the domain Verified when every record is live. Add a sending domain walks through that flow from the start.
A custom MAIL FROM domain is one piece of what a sending domain needs before it’s ready for real volume. Bounces, complaints and suppression in SES covers what happens once a message you’ve sent actually bounces, and reading a bounce covers what the bounce itself is telling you.