Amazon SES custom MAIL FROM domain: SPF alignment for DMARC

What it means

Every email has two sender addresses. The From address is what people see. The MAIL FROM (also called envelope sender, Return-Path or bounce address) is used by servers to send back bounces. SPF checks the MAIL FROM domain, not the From domain.

By default, Amazon SES uses a subdomain of amazonses.com as MAIL FROM. SPF passes, but for amazonses.com, not for your domain. DMARC needs SPF or DKIM to pass for a domain aligned with your From domain. So with the default settings, SPF never counts for DMARC. In a report it looks like this:

spf=pass smtp.mailfrom=0100018abc...@us-east-1.amazonses.com
dkim=pass header.d=yourdomain.com
dmarc=pass header.from=yourdomain.com

DMARC still passes here thanks to DKIM. But you depend on DKIM alone: if a forwarder or a footer added by a gateway breaks the signature, DMARC fails. A custom MAIL FROM domain gives you a second, aligned pass. The general idea is explained in Return-Path, envelope sender and From.

Why it happens

• No custom MAIL FROM domain is configured on the identity (the default).
• A custom MAIL FROM domain is configured but its status is Pending, TemporaryFailure or Failed. With the fallback option Use default MAIL FROM domain, SES silently goes back to amazonses.com.
• The MAIL FROM subdomain has two MX records, or none, or a wrong Region in the MX value.
• Your DMARC record uses strict SPF alignment (aspf=s). A subdomain like mail.yourdomain.com only aligns in relaxed mode, the default.

How to check

Send an email through SES to the unique address on the Delivmail home page and open the report. Look at the domain checked by SPF and whether the DMARC section shows SPF as aligned. If you see amazonses.com, the custom MAIL FROM is not active. In the SES console, open Identities, your domain, and the Custom MAIL FROM domain pane to see its status. From a terminal:

dig +short MX mail.yourdomain.com
dig +short TXT mail.yourdomain.com
dig +short TXT _dmarc.yourdomain.com

How to fix it

1. Pick a dedicated subdomain, for example mail.yourdomain.com or bounce.yourdomain.com. AWS requires it to be a subdomain of a verified identity, not used to send From and not used to receive email. Do not reuse a subdomain that already has MX records for a mailbox.
2. In the console: Identities, your domain, Custom MAIL FROM domain, Edit. Tick Use a custom MAIL FROM domain, enter the subdomain, and choose the Behavior on MX failure. Use default MAIL FROM domain keeps sending if DNS breaks; Reject message stops sending with a MailFromDomainNotVerified error.
3. Publish the two records shown by SES, replacing the Region by yours:

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

There must be exactly one MX record on that subdomain, otherwise the setup fails. The SPF record goes on the subdomain, not on your main domain, so it does not use any of the 10 DNS lookups of your main SPF record. If the subdomain already has a CNAME, remove it first: a CNAME cannot coexist with MX or TXT records (see CNAME conflicts with MX and TXT records).

With the CLI, the same setting is:

aws sesv2 put-email-identity-mail-from-attributes \
  --email-identity yourdomain.com \
  --mail-from-domain mail.yourdomain.com \
  --behavior-on-mx-failure USE_DEFAULT_VALUE

SES checks for the MX record for up to 72 hours. If it does not find it, the status becomes Failed and you must start the setup again. Repeat this for each Region where the identity is used.

Keep relaxed alignment in DMARC (no aspf=s), or the subdomain will not align. If other services also send for your domain, check how they fit together in several email services on one domain. For DMARC basics, see DMARC fails: SPF and DKIM do not match your domain.

Check that it is fixed

Wait for the status Success in the console (SES also emails the account owner). Send a new Delivmail test: SPF should now pass for mail.yourdomain.com, and DMARC should show both SPF and DKIM aligned. Then resend to the recipient whose server rejected or filtered your message. DNS changes can take some time to reach every resolver, depending on the TTL.