Amazon SES and SPF: where include:amazonses.com actually goes

A client's developer says "we send through SES, add their SPF include," and the instinct is to drop include:amazonses.com into the apex record next to Microsoft 365. Amazon's documentation describes something different. By default you don't need to touch the client's SPF record for SES at all. When you do publish include:amazonses.com, it belongs on a dedicated subdomain that SES uses as the envelope sender. This guide walks through both cases and how each one affects DMARC.

The default: SPF passes, but for Amazon's domain

Amazon's SES developer guide says messages sent through SES "automatically use a subdomain of amazonses.com as the default MAIL FROM domain," so SPF is "implicitly set up for you." The MAIL FROM (also called the envelope sender or Return-Path) is the address SPF actually checks under RFC 7208. It isn't the From: address the recipient sees.

That means a default SES message passes SPF, but the pass belongs to an amazonses.com subdomain. Under DMARC (RFC 9989), an SPF pass only counts if the SPF-authenticated domain aligns with the From: domain, meaning it shares the same Organizational Domain (relaxed alignment) or is identical to it (strict). An amazonses.com subdomain will never align with client.com. So with the default MAIL FROM, a message from billing@client.com relies on DKIM to pass DMARC.

Adding include:amazonses.com to the client's apex record doesn't change this. The envelope sender is still Amazon's domain, so the apex record is never consulted for SPF. It just spends a DNS lookup.

The custom MAIL FROM domain: where the include belongs

If you want SPF to align, SES supports a custom MAIL FROM domain. This is a subdomain of the client's domain, such as bounce.client.com, that SES uses as the envelope sender. Amazon's setup guide lists the records you publish on that subdomain:

<region> is the AWS Region the client sends from, and the SES console shows the exact value. The MX record is required because bounce and complaint notifications come back to this domain, and the TXT record is the SPF record for the subdomain only. The apex SPF record stays as it is.

Amazon sets three conditions on the subdomain:

• It has to be a subdomain of the parent domain of a verified identity.
• It shouldn't be a subdomain you also send email from.
• It shouldn't be a subdomain you receive email on.

In practice, pick a name that exists only for this purpose. Don't reuse mail. if that's already an MX host for something else.

When you configure it, SES asks how to behave on MX failure. Use default MAIL FROM domain falls back to the amazonses.com subdomain, so mail keeps flowing but SPF stops aligning. Reject message makes SES refuse to send, with a MailFromDomainNotVerified error. For most client setups the fallback is the safer default, as long as someone monitors DMARC reports to catch it.

How this gets you DMARC alignment

Amazon's DMARC guidance lists two routes:

1. Through SPF. Messages need a custom MAIL FROM domain with a valid SPF record, and the From: domain must be the same as the MAIL FROM domain or a parent of it. Amazon notes that SPF alignment with SES requires that the DMARC record not use strict SPF alignment (aspf=s). Relaxed is the default in both DMARC and SES.
2. Through DKIM. With Easy DKIM, SES signs every message from that identity with a 2048-bit key by default, under the client's domain. If the DKIM domain aligns with From:, DMARC passes regardless of SPF.

DKIM is the more robust of the two because it survives forwarding, and RFC 9989 warns that a reject policy shouldn't rely on SPF alone. Set up Easy DKIM first. Add the custom MAIL FROM domain if the client wants SPF alignment too, or if a receiver or an auditor specifically asks for an aligned SPF pass.

Lookup cost

On Oct 13, 2026, a live DNS check of amazonses.com showed only ip4 ranges with no nested lookups. That means include:amazonses.com costs one lookup toward the RFC 7208 limit of 10, and on a dedicated MAIL FROM subdomain it's the only lookup there. This is an observation, not a documented guarantee. Amazon can change the record.

A client checklist

• Confirm which From: addresses and domains send through SES. Ask the developer, or check the SES identities.
• Turn on Easy DKIM for each domain identity and confirm the CNAMEs resolve.
• If you want SPF alignment, set up a custom MAIL FROM subdomain, publish the MX and TXT records above on it, and choose the MX-failure behavior.
• Leave include:amazonses.com out of the apex record unless you have a specific reason, such as the apex itself being configured as the custom MAIL FROM domain, which conflicts with Amazon's advice above.
• Check the client's DMARC record for aspf=s. If it's there, SES mail can't align on SPF.
• Watch the DMARC aggregate reports for SES traffic that shows an amazonses.com envelope domain, which means the fallback kicked in.

Check the client's SPF now

Run the free SPF checker →

It walks the include tree, counts DNS lookups against the RFC 7208 limit of 10, names common senders such as Amazon SES, and flags duplicate records and dangerous +all or ?all endings. Run it on the apex and on the MAIL FROM subdomain.

Founding Partner: $1,999, one time. See every client's SPF, DKIM, and DMARC, including the domains developers wired to SES without telling you. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →