skip to content

If you never configure a custom MAIL FROM domain in Amazon SES, which domain does SPF authenticate for your outbound mail, and why does that matter for DMARC alignment?

level: seniorimportance: should knowfreq 45%

answer

  1. envelope sender is not the header From
  2. default Return-Path lands on amazonses.com
  3. SPF authenticates the envelope domain
  4. MX to feedback-smtp plus an SPF TXT
  5. fallback or reject on MX failure

basics

~20 s

SES uses a subdomain of amazonses.com as the envelope MAIL FROM, so SPF authenticates amazonses.com rather than your From domain. That leaves DKIM as the only mechanism that can align with your domain, until you configure a custom MAIL FROM subdomain.

solid answer

~50 s

By default SES sets the envelope sender — the MAIL FROM, which is also the Return-Path that bounces come back to — to a subdomain of `amazonses.com`. SPF is evaluated against that envelope domain, not the header `From`, so SPF passes for Amazon's domain while your own domain is not the one authenticated. DMARC only counts an authentication result that **aligns** with the header `From` domain, so on a default setup your alignment rests entirely on DKIM. The fix is a custom MAIL FROM subdomain, say `mail.example.com`: you publish an MX record pointing at `feedback-smtp.<region>.amazonses.com` with priority 10 so bounces route back, plus a TXT SPF record that includes `amazonses.com`. You also choose `BehaviorOnMxFailure` — reject the message, or fall back to the default `amazonses.com` MAIL FROM — which decides whether a broken MX record stops your mail or silently un-aligns it.

code

bash · 8 lines
bash
aws sesv2 put-email-identity-mail-from-attributes \
  --email-identity example.com \
  --mail-from-domain mail.example.com \
  --behavior-on-mx-failure REJECT_MESSAGE

# Confirm SES actually switched over (status must be SUCCESS)
aws sesv2 get-email-identity --email-identity example.com \
  --query 'MailFromAttributes'

go deeper

for a junior

Know that the address bounces return to is not the same as the From address a recipient sees, and that SES uses an amazonses.com address for it until you configure your own.

for a middle

Explain the two DNS records a custom MAIL FROM subdomain needs — an MX pointing at the regional feedback-smtp host and an SPF TXT including amazonses.com — and why the MX one keeps bounce events working.

for a senior

Demonstrate the diagnosis: read Return-Path and Authentication-Results from a raw test message, and argue the BehaviorOnMxFailure choice for the specific mail stream rather than picking a default.

for a principal

Own domain-wide authentication strategy: which subdomains send which streams, how many aligned mechanisms each stream must have before you tighten enforcement, and who is accountable for those DNS records long term.

## Two different "from" addresses Every SMTP message carries two senders. The **envelope sender** is given in the `MAIL FROM` command during the SMTP conversation and becomes the `Return-Path` header; it is where bounces go, and it is what receiving servers see at the protocol level. The **header From** is what the recipient's mail client displays. They do not have to match, and in SES, by default, they do not. This distinction is the entire question. SPF is evaluated against the *envelope* domain. DMARC, on the other hand, only cares about results that line up with the *header From* domain — the property usually called alignment. The precise alignment and policy rules belong to the DMARC specification and are covered in their own right; the AWS-side fact you must know is simply which domain SES puts in the envelope. ## What SES does by default With no custom MAIL FROM configured, SES sets the envelope sender to an address under a regional subdomain of `amazonses.com`. Consequences: - SPF is evaluated for `amazonses.com`, and it passes — Amazon publishes correct SPF records for its own sending infrastructure. - That pass is for Amazon's domain, not yours, so it does not align with a header `From` of `[email protected]`. - Bounces are returned to Amazon's infrastructure, which is how SES generates bounce events for you in the first place. So your mail is authenticated, but only DKIM can be the *aligned* mechanism, because your Easy DKIM or BYODKIM signature carries `d=example.com`. A DMARC evaluation passes when at least one aligned mechanism authenticates, so a correctly DKIM-signed SES setup does pass DMARC. It just passes on one leg. ## Why one leg is not enough Single-leg authentication is fragile in exactly the cases that matter: - **Forwarding and mailing lists.** Some intermediaries rewrite headers or add footers in a way that invalidates the DKIM signature. If DKIM was your only aligned result, the message now fails DMARC outright. - **DNS accidents.** A dropped `_domainkey` record silently disables signing, and DKIM-only alignment becomes no alignment. - **Report legibility.** Aggregate DMARC reports show SPF failing alignment on every SES message. Teams chasing that noise waste days, and the noise hides real spoofing. A senior answer says the plain thing: you want both SPF and DKIM aligned so either can carry the message, and configuring a custom MAIL FROM is how you get the SPF leg. ## Configuring a custom MAIL FROM in SES You pick a subdomain you do not use for receiving normal mail — `mail.example.com` or `bounce.example.com` — and publish two records: ``` mail.example.com. MX 10 feedback-smtp.<region>.amazonses.com. mail.example.com. TXT "v=spf1 include:amazonses.com ~all" ``` The MX record is what keeps bounce processing working: bounces now come back to your subdomain and must be routed into SES's feedback infrastructure, which is what `feedback-smtp.<region>.amazonses.com` is for. The TXT record is what makes SPF pass for your subdomain, by authorising Amazon's sending hosts. Use a **subdomain**, not the apex. Adding an MX record at `example.com` would fight with wherever your real inbound mail is delivered. Two further details matter operationally. The feedback host is **region-specific**, so a multi-region SES setup needs the right host per region — or a separate MAIL FROM subdomain per region. And SES will not begin using the custom MAIL FROM until it has verified the records; until then it keeps using the `amazonses.com` default. ## BehaviorOnMxFailure — the decision people skip When you set the MAIL FROM attributes you choose what SES does if the MX record for your custom domain is missing or unresolvable at send time: - `USE_DEFAULT_VALUE` — silently fall back to the `amazonses.com` MAIL FROM. Mail keeps flowing; SPF alignment quietly disappears. - `REJECT_MESSAGE` — SES refuses the send. There is no universally right answer, and that is why it is an interview-grade question. For transactional mail whose delivery is a business function — password resets, receipts — falling back is usually correct, because unaligned mail that still DKIM-aligns beats no mail at all. For a domain under strict DMARC enforcement where an unaligned stream would be rejected anyway, or for bulk marketing where reputation is the asset, rejecting is the honest choice: it makes the misconfiguration loud instead of letting it rot. ## Diagnosing it Send a test message to a mailbox you control and read the raw headers. Compare `Return-Path` with `From`: if `Return-Path` ends in `amazonses.com`, the custom MAIL FROM is not in effect — either it was never configured, verification has not completed, or `USE_DEFAULT_VALUE` fell back because the MX record is gone. Then check the `Authentication-Results` header, which reports each mechanism and the domain it authenticated, and confirm SPF now names your subdomain rather than Amazon's.

  • Why does SES require an MX record on the custom MAIL FROM subdomain rather than just an SPF record?
    Because the MAIL FROM domain is also the Return-Path, so bounces are delivered to it. The MX record points that subdomain at `feedback-smtp.<region>.amazonses.com` so returned messages reach SES's feedback infrastructure and still become bounce events you can act on. Without it, SPF might align but your bounce reporting would break — the worse of the two failures.
  • Would you pick USE_DEFAULT_VALUE or REJECT_MESSAGE for BehaviorOnMxFailure on password-reset email?
    USE_DEFAULT_VALUE, usually. If the MX record breaks, falling back to the `amazonses.com` MAIL FROM keeps resets flowing and DKIM still aligns, so most receivers still pass the message. Pair it with an alarm on the MailFromAttributes status, because the fallback is silent — that is its one real danger.
  • You run SES in two regions. What breaks if both use the same custom MAIL FROM subdomain?
    The bounce-feedback host is region-specific, so one subdomain can carry the MX record for only one region's `feedback-smtp` endpoint. The usual answer is a distinct MAIL FROM subdomain per region — `mail-use1` and `mail-euw1`, for instance — each with its own MX and SPF TXT record, so both regions align and both route bounces correctly.

saying these in an interview costs you the question

  • Believing SPF is checked against the visible From header
  • Adding the MX record at the apex domain instead of a subdomain
  • Assuming SES uses the custom MAIL FROM before verification completes
  • Thinking DKIM alignment alone makes SPF alignment unnecessary
  • Reusing one MAIL FROM subdomain across SES regions

context

resolving links…