Why does my SES mail pass SPF but fail DMARC?

Because by default SES sends with a MAIL FROM domain under amazonses.com. AWS's own documentation states the problem exactly: customers must use a custom MAIL FROM domain if they want SPF=PASS to result in DMARC=PASS. Default SPF passes the 'authorized server' test but the MAIL FROM domain does not match your From domain, so SPF cannot align. DKIM (Easy DKIM's three CNAME records) aligns independently — which is why SES mail often passes DMARC on the DKIM leg while SPF alignment silently fails until you configure the custom MAIL FROM domain.

What DNS records does a custom MAIL FROM domain need in SES?

Two records on the MAIL FROM subdomain (commonly a subdomain like mail.yourdomain): an MX record, priority 10, pointing to feedback-smtp. .amazonses.com — SES setup FAILS if the domain has multiple MX records, so it must be exactly one — and a TXT record with the SPF value v=spf1 include:amazonses.com ~all. AWS continuously re-checks the MX after setup succeeds; if it later breaks, the state can move through TemporaryFailure to Failed, at which point SES stops checking and you must restart the MAIL FROM setup in the console. You also choose the send-time behaviour for MX failure: fall back to the default amazonses.com MAIL FROM, or reject the message.

What are the Amazon SES sandbox limits?

Per AWS's documentation, an account in the sandbox (which is set per Region) can send only to verified email addresses/domains or the SES mailbox simulator, up to 200 messages per 24 hours and at most 1 message per second; suppression-list bulk operations are also disabled. Requesting production access removes the recipient restrictions, but From identities must remain verified permanently. AWS Support's documented initial response time for the request is within 96 hours — the 'approved in 24 hours' figure in most tutorials is not AWS's number.

Amazon SES · Identity · MAIL FROM

Amazon SES domain identity: DKIM carries one leg, MAIL FROM carries the other

First published 20 October 2026 · Every procedure, record and number below is from AWS's SES Developer Guide and API documentation, read for this guide — including the two places AWS's own pages disagree, flagged where they matter.

THREE LAYERS Identity+DKIM → DKIM alignment · Custom MAIL FROM → SPF alignment · Your _dmarc → policy

Most SES setups finish layer one and stop — and their mail passes DMARC on DKIM alone, with SPF alignment quietly failing forever. AWS's documentation says why, in its own words: “customers must use a custom MAIL FROM domain if they want ‘SPF=PASS’ to result in a ‘DMARC=PASS’.”

Easy DKIM: 3 CNAMEs, 2048-bitDefault MAIL FROM = amazonses.com = no SPF alignment

The setup ladder

Pick your Region first — identities are per-Region; the region is even baked into the MAIL FROM MX target later.
SES console → Verified identities → Create identity → Domain. Choose Easy DKIM (2048-bit is the documented current default; BYODKIM exists if you must bring your own keypair).
Publish the 3 DKIM CNAMEs the console shows (<token>._domainkey → <token>.dkim.amazonses.com) at your DNS host. Publish exactly what your console shows — older tutorials describe a TXT-token verification flow the current documentation no longer centres.
Wait for Verified (AWS allows a detection window — up to 72 hours stated for MAIL FROM; DKIM verification flips when the CNAMEs resolve).
Test-send and read headers: DKIM pass with your domain. Layer 1 done.
Custom MAIL FROM: on the identity, set a MAIL FROM subdomain (e.g. mail.) and publish its two records (next section).
Choose “Behavior on MX failure” deliberately (below) and watch the state reach Success.
Your DMARC record at _dmarc, starting p=none with reports — AWS's best-practice text prescribes the phased start (its example record elsewhere jumps to quarantine; follow the best-practice text, and our rollout guide).
Request production access when ready to send for real (sandbox numbers below).

The MAIL FROM records — with AWS's sharpest rule

Record	Value
MX at the MAIL FROM subdomain	`10 feedback-smtp.<region>.amazonses.com` — and exactly one MX record may exist. AWS verbatim in substance: if the MAIL FROM domain has multiple MX records, the custom MAIL FROM setup will fail. (A subdomain you also receive mail on is therefore the wrong subdomain.)
TXT (SPF) at the same subdomain	`v=spf1 include:amazonses.com ~all` — on the subdomain only; your root SPF is never edited in this flow.

The lifecycle nobody warns you about: SES continuously re-checks that MX after success. Break it later (a DNS cleanup, a host migration) and the state degrades — TemporaryFailure, then Failed, after which SES stops checking entirely and the fix is to restart the MAIL FROM setup in the console, not merely to repair the record. And the behavior choice matters: fall back to the amazonses.com MAIL FROM quietly forfeits SPF alignment during the outage; Reject message (MailFromDomainNotVerified) protects alignment and bounces mail. Choose knowing which failure you'd rather explain.

Alignment truth table

Configuration	SPF	DKIM	DMARC
Email identity only (one verified address)	A testing convenience — not a domain identity, no alignment story. Verify the domain.
Domain identity, no DKIM	Pass, unaligned (amazonses.com)	—	Fail
+ Easy DKIM	Pass, unaligned	Pass, aligned	Pass (DKIM leg)
+ Custom MAIL FROM done right	Pass, aligned	Pass, aligned	Pass (both legs) — forwarding-resilient via DKIM

The sandbox, in AWS's numbers

Per Region: recipients must be verified addresses/domains (or the mailbox simulator), 200 messages per 24 hours, 1 per second, suppression-list bulk actions disabled, and delegate senders equally restricted. Production access removes recipient limits; verified-identity requirements for From/Source are permanent. AWS Support's documented initial response: within 96 hours — plan launches on 96, celebrate if it's 24. Post-production quotas are per-account in your dashboard; the “50k/day” in tutorials is a common default, not an AWS-published constant, and this guide won't print it as one.

Traps

Trap	Reality
Verifying in the wrong Region	The identity simply doesn't exist where your app sends. Region first, always.
Adding a second MX “for backup”	The single-MX rule above — the setup fails by design.
Deleting the “amazonses” CNAMEs in a cleanup	They're the identity. Same inventory law as our other guides: never delete a record you can't explain.
Assuming Failed MAIL FROM heals itself	It doesn't — SES stops checking at Failed. Restart the setup in the console after repairing DNS.
Cloudflare proxy on the CNAMEs	Practice, labelled: DNS-only is the operational consensus; AWS's docs don't mention proxying either way. DNS lookups are the arbiter.

FAQ

Do I need the custom MAIL FROM if DKIM already passes DMARC?

Strictly, DMARC needs one aligned leg — DKIM alone passes. MAIL FROM earns its keep in resilience (SPF-aligned mail survives more forwarding/edge cases) and in bounce handling on your own subdomain. AWS built it because SPF=PASS should mean DMARC=PASS; finish the job.

Can the MAIL FROM subdomain be my root?

No — it must be a subdomain you control, and one whose MX can be exactly-one SES. mail. or bounce. are the conventional shapes.

BYODKIM vs Easy DKIM?

Easy DKIM (AWS-held keys, CNAME delegation, 2048-bit) is the documented default path and the right choice absent a compliance requirement to hold your own keys.

Sources

AWS — Amazon SES Developer Guide (domain identities & Easy DKIM, custom MAIL FROM incl. the DNS records table and failure states, sandbox & production access, DMARC with SES incl. its best-practices section) · AWS — SES API Reference (MAIL FROM behavior values).

Verification note: records, the single-MX rule, failure lifecycle and sandbox numbers were confirmed from AWS documentation on 20 October 2026. Where AWS's own pages disagree (the DMARC example vs its best-practice text; legacy 1024-bit material), this guide follows the current best-practice text and says so.

Did this guide work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.