Does Amazon SES require SPF at the root domain?

No. Amazon SES passes SPF with its default amazonses.com MAIL FROM domain. For DMARC SPF domain alignment, configure a custom MAIL FROM subdomain and publish the SES-provided SPF record there. Do not add include:amazonses.com to the root SPF record solely because SES sends mail for the domain.

Can Amazon SES pass DMARC without custom MAIL FROM?

Yes. Easy DKIM can make DMARC pass when dkim=pass and the DKIM signing domain has domain alignment with the visible From domain. The default amazonses.com Return-Path passes SPF but does not supply SPF domain alignment for example.com.

Which platform uses smtp-out.amazonses.com rDNS?

Amazon SES commonly uses Region-specific hostnames ending in smtp-out.amazonses.com for outbound server rDNS. Treat the suffix as a source clue, then confirm the message through its source IP, DKIM signing domain, Return-Path, and DMARC report data.

Which email platform uses include:amazonses.com in SPF?

Amazon SES uses include:amazonses.com in the SPF record generated for a custom MAIL FROM domain. Seeing that include indicates an Amazon SES relationship, but it does not prove that the hostname is the recommended place for a new record. Publish only the records shown by SES for the configured identity.

How long does Amazon SES domain verification take?

Amazon SES can keep identity, DKIM, or custom MAIL FROM verification pending for up to 72 hours while DNS propagates. If it remains pending, check the active AWS Region, duplicated zone names, missing CNAMEs, and the requirement for exactly one MX record on the custom MAIL FROM subdomain.

Learn

DMARC

How to set up DMARC/DKIM/SPF for Amazon SES

Matthew Whittaker

Co-founder & CTO, Suped

Published 6 Aug 2026

Updated 6 Aug 2026

14 min read

Summarize with

Amazon SES email authentication setup with SPF, DKIM, and DMARC

Verify the sending domain as an Amazon SES identity in every AWS Region you use, publish the three Easy DKIM CNAME records, configure a custom MAIL FROM subdomain with the SES-provided MX and SPF TXT records, then publish one DMARC TXT record at _dmarc.example.com. I use Easy DKIM as the primary DMARC pass path and custom MAIL FROM as a second aligned path.

Amazon SES already passes SPF when it uses its default amazonses.com MAIL FROM domain, but that domain differs from the visible From domain. SPF therefore does not satisfy DMARC domain alignment in the default setup. Easy DKIM can still make DMARC pass. A custom MAIL FROM such as mail.example.com adds SPF domain alignment because Amazon SES supports a Return-Path under the verified domain.

Add your domain

An Amazon SES identity belongs to one AWS Region. I create and verify the same domain identity separately in every Region that sends mail, and I keep the application endpoint in the same Region as the verified identity.

Select the Region. Open the Amazon SES console and choose the AWS Region used by the application or SMTP credentials.
Open identities. Choose Configuration, Verified identities, then Create identity.
Enter the domain. Choose Domain and enter the visible From domain, such as example.com, without a scheme or path.
Choose Easy DKIM. Leave DKIM signing enabled and use the default 2048-bit key length unless an existing DNS limit requires 1024-bit keys.
Create the identity. Copy all DNS records Amazon SES displays. If DNS is hosted in the same account through Route 53, use the console's publish action. Otherwise, add them at the authoritative DNS provider.

Amazon SES Create identity form for example.com with Easy DKIM enabled

The Verified identities table should change to Verified after Amazon SES detects the DNS records. Detection can take up to 72 hours, although it often completes sooner. Do not continue to production sending while the identity status is Pending or Failed.

Identity success criteria

Identity status. The domain shows Verified in the active sending Region.
DKIM status. The identity's Authentication tab shows DKIM configuration Successful.
Application source. The visible From address uses the verified domain or an allowed subdomain identity.
Production access. The account has left the SES sandbox in each sending Region when external recipients are required.

Set up SPF

SPF is implicit when Amazon SES uses its default amazonses.com MAIL FROM domain. I configure a custom MAIL FROM subdomain when I want SPF to satisfy DMARC domain alignment as well. This step is optional when aligned Easy DKIM passes consistently, but it gives legitimate mail a second DMARC pass path.

Default MAIL FROM

Amazon SES uses an amazonses.com Return-Path and manages SPF.

SPF result. SPF passes for amazonses.com.
DMARC result. SPF lacks domain alignment with example.com.
Required path. Easy DKIM must pass with the visible From domain.

Custom MAIL FROM

Amazon SES uses a dedicated subdomain such as mail.example.com.

SPF result. SPF passes through include:amazonses.com.
DMARC result. Relaxed SPF domain alignment passes for the subdomain.
DNS requirement. Publish one SES MX record and one SPF TXT record.

Use a MAIL FROM subdomain that is not used for visible From addresses or normal inbound mail. The examples below use mail.example.com, but the AWS Region in the MX target must match the identity's sending Region.

Open the identity. In Amazon SES, choose Configuration, Verified identities, then select the verified domain.
Edit MAIL FROM. On the Authentication tab, find Custom MAIL FROM domain and choose Edit.
Enter the subdomain. Select Use a custom MAIL FROM domain and enter mail.example.com.
Choose failure behavior. Use Reject message when authentication consistency matters more than fallback delivery. Use the default MAIL FROM fallback during an initial migration only if temporary SPF domain alignment loss is acceptable.
Publish both records. Copy the MX and TXT values generated by Amazon SES exactly. Publish only one MX record at the MAIL FROM subdomain.

Amazon SES custom MAIL FROM settings for mail.example.com

Amazon SES displays Region-specific values after saving. For us-east-1, the records follow this shape. Copy the console output rather than assuming the Region or target.

Custom MAIL FROM DNS recordsDNS

mail.example.com. 300 MX 10 feedback-smtp.us-east-1.amazonses.com.
mail.example.com. 300 TXT "v=spf1 include:amazonses.com ~all"

The SPF TXT record belongs on the custom MAIL FROM subdomain, not automatically on the root domain. Amazon's SES SPF guidance confirms that the default MAIL FROM already passes SPF and that a custom MAIL FROM needs its own SPF and MX records.

SPF checker

Find SPF syntax issues, lookup limits, and weak records.

?/16tests passed

Run the SPF checker against mail.example.com after DNS propagation. A good result returns one SPF record, resolves include:amazonses.com, stays within the ten-lookup SPF limit, and ends with the mechanism Amazon SES generated. The identity's Custom MAIL FROM status should also show Successful.

Do not merge the wrong SPF records

A domain can have only one SPF record at a given hostname. Keep the Amazon SES SPF record at the custom MAIL FROM subdomain. Do not add include:amazonses.com to the root SPF record solely because Amazon SES sends mail for the domain.

Set up DKIM

Easy DKIM is the cleanest Amazon SES authentication path because SES creates the signature and hosts the public keys. I publish every CNAME shown for the identity, keep DKIM signing enabled, and verify the identity separately in each sending Region.

Open DKIM settings. Select the domain identity, open Authentication, and find DomainKeys Identified Mail.
Copy all CNAMEs. Publish each generated selector name and target exactly as displayed. Easy DKIM normally provides three records.
Disable DNS proxying. The CNAMEs must return DNS data directly. Any provider option that masks or rewrites the CNAME target must remain off.
Confirm success. Wait until DKIM configuration shows Successful and DKIM signing shows Enabled.

Amazon SES Easy DKIM panel with three CNAME records

Your selectors will be long random tokens. These shorter names show the DNS structure only. Some DNS control panels append the zone name automatically, so check that the final public hostname contains example.com once, not twice.

Easy DKIM CNAME patternDNS

token1._domainkey.example.com. CNAME token1.dkim.amazonses.com.
token2._domainkey.example.com. CNAME token2.dkim.amazonses.com.
token3._domainkey.example.com. CNAME token3.dkim.amazonses.com.

Send a test message only after the status is Successful. The DKIM signature should use example.com in the d= value when the visible From address is user@example.com. A signature using amazonses.com can pass DKIM cryptographically but will not give the visible From domain DMARC domain alignment.

DKIM checks that matter

Selector lookup. Each selector resolves through CNAME to the SES-hosted public key.
Signature result. A delivered message reports dkim=pass.
Signing domain. The header.d domain matches the visible From domain under the DMARC policy's domain matching mode.
Regional coverage. Every sending Region has a verified identity and active signing configuration.

Set up DMARC

DMARC is published in DNS for the visible From domain, not configured inside Amazon SES. I start a domain without enforcement at p=none so reports expose every legitimate sender before filtering begins. If the domain already uses p=quarantine or p=reject, keep that stronger policy and fix Amazon SES authentication without lowering it.

Check for an existing record. Query TXT at _dmarc.example.com. Edit the existing record instead of publishing a second one.
Choose a report mailbox. Use an address that can receive and process aggregate XML reports. Replace dmarc@example.com before publishing when it is only a placeholder.
Build the record. Use the DMARC record generator to create one valid TXT value and preserve any existing policy.
Publish one TXT record. Set the host to _dmarc.example.com, or only _dmarc when the DNS provider appends the zone.
Keep relaxed matching. Omit aspf and adkim during initial setup unless strict matching is intentional. Their defaults permit subdomain domain alignment.

Recommended monitoring DMARC recordDNS

Name: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com

A message passes DMARC when either SPF or DKIM passes and the passing identifier has domain alignment with the visible From domain. The Amazon SES DMARC guidance confirms that Easy DKIM supplies the DKIM path and a custom MAIL FROM supplies the SPF path.

DMARC checker

Look up a domain's DMARC record and catch policy issues.

?/7tests passed

Run the DMARC checker against example.com. The result should find exactly one record, parse version DMARC1, show policy none for a new deployment, and show the intended aggregate report address. A duplicate record makes DMARC invalid even when both records look correct.

Amazon SES identity with successful DKIM and custom MAIL FROM status

The Amazon SES page validates its own identity, DKIM, and custom MAIL FROM state. It does not prove that the domain has one valid DMARC record, so the DNS check remains necessary after SES shows green statuses.

p=none does not block impersonation

The monitoring policy requests reports but tells receivers to take no enforcement action. Use it to find every legitimate source, then move to quarantine and reject after the data confirms that valid mail passes.

Verify and troubleshoot

Console status and DNS lookup results are necessary, but the final proof is a message sent by the same application path used in production. I test the API or SMTP route, configuration set, From domain, and AWS Region that production will use.

Send a real test. Send through the production application to a mailbox outside the sending domain.
Open the raw headers. Find Authentication-Results, Return-Path, DKIM-Signature, and the visible From header.
Confirm SPF. Expect spf=pass. With custom MAIL FROM, smtp.mailfrom should use mail.example.com.
Confirm DKIM. Expect dkim=pass and header.d=example.com, or a valid subdomain accepted by the DMARC matching mode.
Confirm DMARC. Expect dmarc=pass and header.from=example.com. Test each application and sending Region separately.

Expected authentication resulttext

Authentication-Results: mx.example;
 spf=pass smtp.mailfrom=mail.example.com;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com

Treat each failure according to the identifier that failed. An SPF pass for amazonses.com is normal with the default MAIL FROM, but DMARC then depends on aligned DKIM. A DKIM pass with the wrong header.d value also fails to supply DMARC domain alignment.

Symptom	Likely cause	Action
Identity pending	CNAME missing	Publish all three
MAIL FROM failed	MX wrong	Use one SES MX
SPF pass, DMARC fail	Return-Path differs	Use custom MAIL FROM
DKIM pass, DMARC fail	Signing domain differs	Match the identity
DNS name missing	Zone added twice	Use a relative host

Compact Amazon SES authentication fault map

Header inspection is easy to misread when a receiver adds several Authentication-Results fields. The field added by the final receiving system is the useful one. It evaluates the SMTP connection that system actually accepted.

Email tester

Send a real email to this address. Suped shows a results button when the test is ready.

?/43tests passed

Send the test address a message through the production Amazon SES path. The report should show SPF, DKIM, and DMARC results together with the identifiers used for each check. This catches cases where every DNS record exists but the application sends through another Region, identity, or Return-Path configuration.

Fast diagnosis order

Identity. Confirm Verified in the Region used by the sender.
DKIM. Confirm Successful, Enabled, dkim=pass, and the expected header.d.
MAIL FROM. Confirm Successful, one MX record, and one SPF record.
DMARC. Confirm one valid policy and a pass through at least one domain-matched identifier.

Get alerted when it breaks

DNS records drift, SES identities get recreated in another Region, and applications change their From or Return-Path behavior. I do not treat a one-time pass as permanent. Aggregate DMARC reports provide the continuing evidence, but the raw XML needs source grouping and alert thresholds to become operational.

Route reports. Replace the placeholder rua mailbox with an address that processes aggregate reports automatically.
Verify the source. Label expected Amazon SES traffic by domain, Region, sending account, and authentication identifiers.
Alert on change. Trigger alerts when failure volume rises, a new source appears, or DKIM and SPF domain alignment drops.
Watch reputation. Correlate authentication changes with deliverability and blocklist (blacklist) status for the sending domain and IPs.

Suped's product is the best overall practical DMARC platform for most teams here because its DMARC monitoring groups Amazon SES traffic, detects new authentication issues, and supplies steps to fix them. Real-time alerts and weekly summaries reduce the gap between a DNS or application change and investigation.

Routine monitoring

Source review. Confirm Amazon SES volume stays within the expected baseline.
Pass rate. Track domain-matched DKIM and SPF results over time.
DNS state. Watch the DMARC policy and authentication records for drift.

Incident response

Identify scope. Separate one Region or application path from domain-wide failure.
Inspect identifiers. Compare header.d, Return-Path, source IP, and visible From domain.
Verify the fix. Send another production-path test and watch the next report cycle.

Suped also brings DMARC, SPF, DKIM, hosted policy management, blocklist monitoring, and deliverability signals into one workflow. Agencies and managed service providers can review multiple client domains from one multi-tenant dashboard instead of handling each domain as a separate report stream.

Minimum useful alerts

Failure spike. Alert when legitimate Amazon SES traffic loses DMARC.
Unknown source. Alert when a new IP or sending service claims the domain.
Record change. Alert when DMARC, SPF, or DKIM DNS no longer matches the approved state.
Policy regression. Alert when quarantine or reject is weakened or removed.

Secure your domain with p=reject

Move to p=reject only after reports show that every legitimate Amazon SES stream and every other approved sender passes DMARC. I use DKIM as the required path for Amazon SES and keep custom MAIL FROM SPF as a second path. Enforcement should never depend on an unverified inventory.

Inventory all sources. Map every approved source IP, DKIM signing domain, Return-Path, subdomain, AWS account, and SES Region seen in reports.
Fix legitimate failures. Require Easy DKIM to pass with the correct signing domain. Repair custom MAIL FROM when SPF is intended as a second path.
Observe normal cycles. Cover billing runs, password resets, low-volume applications, scheduled campaigns, and regional failover before enforcement.
Stage quarantine. Start with p=quarantine and a limited pct value. Increase coverage only when legitimate failure volume stays at zero or has an explained forwarding pattern.
Move to reject. Set p=reject and pct=100 after quarantine data confirms readiness. Keep aggregate reporting active.

Ready for reject

Known sources. Every legitimate source in reports has an owner.
Passing mail. Normal application paths pass DMARC consistently.
Active alerts. Authentication regressions reach an accountable owner quickly.

Hold enforcement

Unknown traffic. Unassigned sources still send meaningful volume.
Intermittent failures. A Region or application path still loses DKIM.
Missing ownership. No person owns alerts, fixes, or rollback decisions.

A staged record limits initial exposure while quarantine data is reviewed. The final record asks receivers to reject unauthenticated mail. Use the report address assigned to the production monitoring workflow.

Staged DMARC enforcement recordsDNS

Value: v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com
Value: v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com

Suped's Hosted DMARC workflow is the strongest practical way to stage this change for most teams. It combines policy controls with source verification, issue detection, guided fixes, and continuing alerts, so each increase in enforcement is based on observed traffic rather than a DNS guess.

Do not weaken an existing policy

If example.com already uses p=quarantine or p=reject, keep that policy. Repair the Amazon SES identity, Easy DKIM, or custom MAIL FROM configuration instead. Lowering enforcement exposes the entire domain, not only Amazon SES mail.