The correct SPF include for Amazon SES is include:amazonses.com - one global include that covers every AWS region (AWS, 2026). For most senders, though, the cleaner path is not to touch your root SPF record at all and instead set up a custom MAIL FROM domain. That moves SPF onto a subdomain you control, lets SES publish its own SPF there, and gives you the alignment Gmail and Yahoo bulk-sender rules require for DMARC. This guide walks through both routes, the RFC 7208 10-lookup ceiling, multi-provider scenarios, and the mistakes that quietly break SPF without anyone noticing.
What SPF Actually Validates for SES
SPF authorises the envelope-from (Return-Path) sender, not the visible From: header. By default, Amazon SES uses a subdomain of amazonses.com as the MAIL FROM, so SPF validates against AWS's own published record and passes without you doing anything (AWS, 2026). Your domain's SPF record is irrelevant in that default state - because your domain isn't the envelope sender, it's just the From: header.
This is the part that confuses most people. They publish include:amazonses.com on their root SPF, send a test message, see SPF=pass in Gmail's "show original" view, and assume DMARC alignment is sorted. It isn't. The SPF check that passed was against amazonses.com, not against the domain in the From: header. DMARC requires the domain that SPF authenticates to match (or share an organisational domain with) the From: domain. With default SES MAIL FROM, those domains don't match, and DMARC's SPF leg fails alignment regardless of how clean your SPF record is.
The fix is either to publish include:amazonses.com on the same domain you put in From: (works, but verbose) or to use a custom MAIL FROM domain (cleaner, and what AWS recommends).
The Correct SPF Record for SES
If you do want to publish SPF on your sending domain, the canonical SES record is exactly this:
example.com. IN TXT "v=spf1 include:amazonses.com ~all"
That's the entire record. include:amazonses.com is a single global include - AWS publishes one SPF tree under amazonses.com that authorises every SES sending IP in every region, so you do not need include:us-east-1.amazonses.com or any regional variant (AWS, 2026). If you've seen advice to add per-region includes, it was wrong or extremely outdated.
The qualifier on all matters. Use ~all (softfail) while you're still adding senders or verifying setup - receivers will accept unauthorized mail but mark it suspicious, giving you DMARC visibility without immediate blocking. Move to -all (hardfail) once two weeks of DMARC reports show no surprising sources. -all instructs receivers to reject unauthorized mail outright; that's the goal state for any production newsletter domain.
One more thing about syntax: a domain can only publish one SPF TXT record. Publishing two creates a permerror and SPF fails everywhere. If you're already using include:_spf.google.com for Workspace mail, you merge into one record - not add a second.
Custom MAIL FROM Domain: The Better Path for DMARC
The custom MAIL FROM approach is what AWS recommends and what every Gmail/Yahoo bulk-sender-compliant SES setup uses (AWS, 2026). Instead of authorising SES on your root domain, you delegate a subdomain (typically bounce.example.com or mail.example.com) as your envelope sender. SES then auto-publishes SPF on that subdomain, bounce and complaint addresses live under your domain, and DMARC's SPF leg aligns naturally because the envelope domain and From: domain share an organisational root.
Setup is two DNS records on the subdomain - the SES console hands you the exact values:
bounce.example.com. IN MX 10 feedback-smtp.us-east-1.amazonses.com.
bounce.example.com. IN TXT "v=spf1 include:amazonses.com ~all"
The MX record receives bounces and complaints; the TXT record is the SPF for that subdomain. The region in the MX value (us-east-1 above) is the AWS region you verified the identity in - this is the only place a region appears, and only on the MX, not the SPF. Full step-by-step instructions, including the console flow and Route 53 one-click publish, live in our Amazon SES custom MAIL FROM domain setup guide.
Once the custom MAIL FROM is live, your root domain SPF can stay untouched (or empty), because SES never uses it. You only need root-domain SPF if you also send mail directly from example.com via another provider.
The 10 DNS Lookup Limit - And How to Stay Under It
RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS lookups per record. Every include, a, mx, exists, ptr, and redirect mechanism counts as one lookup, and nested includes count their own lookups recursively. Exceed 10 and the receiver returns a permerror - SPF fails for the entire message, regardless of which mechanism was the eleventh. This is the single most common cause of "we have SPF but it stopped working" tickets.
A bare SES SPF record is generous on budget:
v=spf1 include:amazonses.com ~all
That's roughly 2 lookups (the include itself plus what amazonses.com resolves internally). You have eight in reserve. Trouble starts when you add Google Workspace, Mailchimp, a CRM, and a transactional sender all on the same root record - each include: brings its own subtree:
| Include | Approximate lookups (you + nested) |
|---|---|
include:amazonses.com | ~2 |
include:_spf.google.com | ~4 |
include:servers.mcsv.net (Mailchimp) | ~2 |
include:_spf.salesforce.com | ~5 |
include:spf.protection.outlook.com | ~3 |
Add four of those and you're already over budget. Run dig +short txt example.com and count, or use mxtoolbox's SPF lookup tool which renders the full nested tree and gives you a live count.
When you're past 10, three fixes work, in order of preference: drop providers you no longer use (audit honestly - that legacy Mailchimp account from 2022 is still in your SPF), switch a provider onto a subdomain instead of the root (e.g. mailchimp.example.com SPF, with senders configured to use that subdomain), or flatten the record by resolving includes to IP ranges manually (brittle - those IPs change, so you need automation to re-flatten weekly).
Multi-Provider SPF (SES + Google Workspace + Mailchimp)
The real-world scenario most SES users hit is mixed sending. Marketing emails go via SES (your campaign tool sitting on top of it), transactional notifications might still go via SES too, employee mail goes via Google Workspace, and an old Mailchimp account hasn't quite been retired. All of those want to send From: anything@example.com, so all of them need authorisation on a single root SPF record:
example.com. IN TXT "v=spf1 include:amazonses.com include:_spf.google.com include:servers.mcsv.net ~all"
Lookup budget: roughly 2 + 4 + 2 = 8 lookups. That leaves two in the tank. Add one more major provider and you're at the edge; add two and you'll start seeing intermittent permerrors as nested DNS varies.
If you've gone the custom MAIL FROM route for SES specifically, your root SPF can drop include:amazonses.com entirely - SES uses the subdomain SPF, not the root - which frees up two lookups for Google and others:
example.com. IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net ~all"
bounce.example.com. IN TXT "v=spf1 include:amazonses.com ~all"
This is the configuration we recommend for any domain sending through three or more providers. It also makes per-provider rotation easier - you can swap SES for another provider on bounce.example.com without touching the SPF that Workspace depends on.
For senders running SES across several regions or several sender identities (transactional vs marketing on separate subdomains), the same logic applies - put each sender on its own subdomain. The multiple SES domain identities guide covers that layout in more depth.
| Approach | What you publish | DMARC SPF alignment | Maintenance |
|---|---|---|---|
| Default MAIL FROM, no SPF on your domain | Nothing | ✗ Fails alignment | Zero |
| Default MAIL FROM, `include:amazonses.com` on your root SPF | Root TXT with SES include | Authorises SES but no envelope alignment | Low - watch lookup count |
| Custom MAIL FROM subdomain (recommended) | MX + TXT on subdomain; root SPF untouched | ✓ Aligns via organisational domain | One-time setup per identity |
Common Mistakes
A handful of SPF errors recur every week in support tickets across the SES community. None require deep DNS knowledge to avoid - just awareness.
Two SPF TXT records on the same domain. RFC 7208 explicitly forbids multiple SPF records; receivers see the configuration as a permerror and fail SPF entirely. This typically happens when someone publishes a second TXT containing v=spf1 ... instead of merging into the existing one. Audit with dig +short txt example.com - if you see two strings starting with v=spf1, merge them into a single record.
Mixing ~all and -all across nested includes. The all qualifier in an include: is ignored - the included record contributes its mechanisms but its all does not terminate evaluation. Only the all qualifier on the outermost record decides the final action. People sometimes set -all on the root and assume an included ~all softens it; it doesn't. Decide once at the root.
Forgetting subdomain SPF. SPF is per-domain and not inherited from the parent. If you send from newsletter.example.com and only example.com has SPF, newsletter.example.com has no SPF at all - receivers will return none, and DMARC will fall back to the DKIM leg. Either publish SPF on every sending subdomain, or use SPF macros / redirect (advanced - usually not worth it).
Publishing SPF as the wrong record type. SPF lives in a TXT record. There was historically an SPF record type (RFC 4408); it was deprecated by RFC 7208 in 2014 and most resolvers do not query it. If your DNS provider offers an "SPF" record type, ignore it and use TXT.
Using a custom MAIL FROM but also putting include:amazonses.com on root. Harmless but pointless. SES isn't using your root SPF when a custom MAIL FROM is active - the include just consumes part of your 10-lookup budget for nothing.
For the broader picture of how SPF interacts with DKIM and DMARC alignment - and why fixing SPF in isolation rarely solves a deliverability problem - see our SPF, DKIM, and DMARC explained primer.
How Mailblast Handles SPF on Your SES
Mailblast operates on your own Amazon SES account (BYO-SES), so SPF lives entirely in your DNS - we don't (and can't) modify your TXT records. What Mailblast provides is the onboarding wizard that tells you which records to publish: when you connect SES, we read your verified-identity configuration via the SES API and surface the exact MAIL FROM, SPF, and DKIM records SES is expecting, with a copy button per row.
If you pick the custom MAIL FROM path (which we recommend), Mailblast shows the MX and SPF TXT for your chosen subdomain. If you stick with the default MAIL FROM and want include:amazonses.com on your root SPF, we'll surface that too, with a warning if your root SPF already has 9+ lookups. We never insert Mailblast-specific SPF includes - your sent mail authenticates as your domain via SES, end of story. There's no "Sent with Mailblast" footer either.
FAQ
What is the correct SPF include for Amazon SES?
The correct SPF include for Amazon SES is include:amazonses.com - a single global include that covers every AWS region (AWS, 2026). A minimum-viable SES SPF record looks like v=spf1 include:amazonses.com ~all. You do not need per-region includes; AWS publishes all SES sending IPs under the same amazonses.com SPF tree.
Do I need an SPF record if I use Amazon SES?
Only if you send under your own domain via a custom MAIL FROM domain. If you use the default amazonses.com MAIL FROM, AWS publishes SPF on its own subdomain and SPF passes implicitly. For DMARC alignment - which Gmail and Yahoo bulk-sender rules require - you need a custom MAIL FROM domain with its own SPF TXT record (AWS, 2026).
What is the SPF 10 DNS lookup limit?
RFC 7208 caps SPF evaluation at 10 DNS lookups per record. Every include, a, mx, exists, and redirect mechanism counts; nested includes count their own lookups too. Exceeding 10 produces a permerror and SPF fails entirely (RFC 7208 §4.6.4). Tools like mxtoolbox or dmarcian show your live lookup count.
Should I use ~all or -all in my SES SPF record?
Start with ~all (softfail) while you verify all legitimate senders are listed, then move to -all (hardfail) once your DMARC reports show no missing sources. ~all tells receivers to accept-but-flag unauthorized senders; -all tells them to reject. Production newsletters with stable infrastructure should land on -all (AWS, 2026).
Do I need both include:amazonses.com and a custom MAIL FROM domain?
Pick one approach per identity. If you publish include:amazonses.com on your root domain SPF and keep the default amazonses.com MAIL FROM, that authorises SES but does not align with DMARC. The custom MAIL FROM path moves SPF onto your own subdomain (e.g. bounce.example.com) where SES auto-publishes its SPF, achieving DMARC SPF alignment.
Disclosure: Mailblast is a hosted management layer for your own Amazon SES account. SPF records, MAIL FROM subdomains, and DNS configuration live entirely in the customer's DNS and AWS account; Mailblast surfaces the exact records SES expects but never publishes or modifies them on your behalf.