The DMARC alignment gap most SES senders never notice
Most teams setting up Amazon SES follow the same checklist: verify the domain, enable Easy DKIM, publish a DMARC record, and watch the green lights appear. DKIM passes. DMARC shows a pass. Everything looks fine. The problem is that a passing DMARC result driven solely by DKIM alignment is structurally incomplete, and for a meaningful share of messages it can fail silently in ways that are invisible until something goes wrong.
The root cause is a default SES behaviour that almost nobody changes: Amazon uses a subdomain of amazonses.com as the envelope sender for every message you send, which means SPF authenticates against Amazon's domain rather than yours. This article explains precisely why that matters, how to fix it, and how to verify that the fix has actually worked.
Header From address versus envelope sender
Every email carries two distinct "from" concepts. The header From address is the friendly address your recipient sees in their mail client. The envelope sender, also called the MAIL FROM address or Return-Path, is the address used during the SMTP transaction itself. It is not normally visible to recipients, but it is the address to which bounce and complaint notifications are returned, and it is the domain that SPF evaluates.
SPF checks whether the server that delivered the message is authorised to send on behalf of the envelope sender domain. DKIM checks whether the message carries a valid cryptographic signature from a domain specified in the DKIM d= tag. Neither check involves the header From address directly. DMARC closes that gap: it requires that at least one of those authenticated domains aligns with the header From domain. For SPF-based DMARC alignment, the envelope sender domain must match the header From domain, either exactly under strict alignment or as a subdomain under relaxed alignment. For DKIM-based DMARC alignment, the d= domain in the DKIM signature must match the header From domain under the same rules.
Why SES uses amazonses.com as the envelope sender by default
When you send through Amazon SES without any additional configuration, SES automatically uses a subdomain of amazonses.com as the MAIL FROM domain. SPF authentication passes on those messages because Amazon's servers are genuinely authorised to send for amazonses.com. The problem is alignment: SPF passes against amazonses.com, not against your domain, so DMARC cannot pass via the SPF path.
SES uses its own domain by default for a practical reason. The MAIL FROM address is where receiving servers send bounce and complaint notifications. SES needs to process those notifications to track your sending reputation and feed data back into your account. By owning the envelope sender domain, SES routes all of that feedback internally. The side effect is that your domain never appears in the envelope, so SPF alignment with your header From domain is impossible without an explicit configuration change.
SPF passes but is not aligned: what that means for DMARC
This is the crux of the confusion. When SES sends a message on your behalf, the receiving server runs an SPF check against the MAIL FROM domain, which is a subdomain of amazonses.com. That check passes, because Amazon's sending infrastructure is authorised for its own domain. The receiving server then runs the DMARC alignment check: does the SPF-authenticated domain match the header From domain? The answer is no. amazonses.com does not match yourcompany.com, so SPF alignment fails for DMARC regardless of the fact that SPF itself passed.
If you have added include:amazonses.com to your root domain's SPF record, that does not fix the problem. That record authorises SES to send on behalf of your apex domain, but SES is not using your apex domain as the envelope sender. The SPF check evaluates against the amazonses.com subdomain, so your root SPF record is never consulted during DMARC alignment. The include directive only becomes relevant if SES were using your apex domain as its MAIL FROM, which it does not do by default.
DKIM alignment works reliably, until it does not
Easy DKIM is Amazon's built-in DKIM signing feature. When enabled, SES signs every outgoing message with a DKIM signature tied to your domain and generates three CNAME records that you publish to DNS. This gives you DKIM alignment for DMARC, and for the majority of directly delivered messages it works reliably. DKIM alignment also handles forwarding better than SPF alignment: because DKIM signatures are attached to the message header and body rather than to the SMTP envelope, a forwarding server that relays a message without modifying its content will leave the DKIM signature intact, and DMARC can pass via the DKIM path even though SPF alignment has broken.
However, DKIM has its own failure modes. Forwarding servers that append footers, modify subject lines, or re-wrap MIME parts can invalidate the DKIM signature, leaving both SPF and DKIM alignment failed simultaneously. Mailing list servers regularly modify message content in ways that break DKIM signatures. If a message reaches that state, DMARC fails entirely. There is also the question of operational resilience: if a misconfiguration causes DKIM signing to silently stop working, perhaps because CNAME records were accidentally deleted or a third-party tool sends without signing, your only remaining DMARC path collapses. Relying solely on DKIM means you have no fallback.
The case for dual-path DMARC alignment
A message passes DMARC if at least one of SPF or DKIM alignment succeeds. A message fails DMARC only if both fail. Configuring both aligned SPF and aligned DKIM means that a single failure, whether a forwarding hop breaks SPF or a content modification breaks DKIM, does not in itself produce a DMARC failure. Each path acts as a backstop for the other. AWS itself recommends configuring a custom MAIL FROM domain as best practice, noting that both SPF and DKIM alignment together give your sending programme the strongest possible authentication posture. For any domain operating at p=quarantine or p=reject, dual-path alignment is not optional: it is the configuration that gives legitimate mail the best chance of surviving the edge cases that every sending programme eventually encounters.
Configuring a custom MAIL FROM subdomain in the AWS console
The custom MAIL FROM feature is configured per identity in the SES console. Navigate to the Amazon SES console and choose Verified identities in the left-hand navigation. Select the domain identity you want to configure, open the Authentication tab, find the Custom MAIL FROM domain section, and choose Edit.
In the MAIL FROM domain field, enter a subdomain of your verified sending domain. Common choices are mail.yourdomain.com or bounce.yourdomain.com. The subdomain must sit under the same parent domain as your From address: if you send from yourdomain.com, the custom MAIL FROM must be something like mail.yourdomain.com, not a different parent domain entirely. Because custom MAIL FROM domains are always subdomains of the parent domain, your DMARC policy must use relaxed SPF alignment (aspf=r) rather than strict, since a subdomain satisfies relaxed alignment but not strict. Once you have entered the subdomain and saved your changes, SES will display the DNS records you need to publish before it can verify the configuration.
DNS records required for the custom MAIL FROM subdomain
Two DNS records are required on the custom MAIL FROM subdomain itself, not on your apex domain. The first is an MX record. SES uses this record to route bounce and complaint notifications back to its own infrastructure. Publish it with a priority of 10 and a value of feedback-smtp.{region}.amazonses.com, where {region} is the AWS region from which you are sending, for example feedback-smtp.eu-west-1.amazonses.com for the Ireland region. You must publish exactly one MX record on the subdomain: multiple MX records on the same subdomain will cause SES to fail verification of the custom MAIL FROM configuration.
The second record is an SPF TXT record, also on the subdomain. The value is: v=spf1 include:amazonses.com ~all. This authorises Amazon's sending infrastructure to send mail using your subdomain as the envelope sender. It is a record on the subdomain and does not need to mirror or replace anything on your apex domain. Once both records are published and DNS has propagated, SES will poll your DNS, typically within minutes but potentially up to 72 hours, and update the identity status to Successful.
The MX failure behaviour setting
When configuring the custom MAIL FROM domain, SES asks you to choose what happens if the custom MAIL FROM domain's MX record is missing or incorrect at send time. The two options are "Use default MAIL FROM domain" and "Reject message". If you choose the default fallback, SES will silently revert to using amazonses.com as the envelope sender whenever it cannot locate your MX record. Your SPF alignment will break without any obvious error, and messages will continue to be delivered but without aligned SPF. If you choose "Reject message", SES returns a MailFromDomainNotVerified error and refuses to send, producing a visible failure rather than silent misalignment.
For production sending, the reject option is the more defensible choice. Silent fallback means you can lose SPF alignment without noticing, particularly after a DNS migration or an accidental record deletion. A hard failure is immediately visible in your sending logs, whereas misaligned SPF may not surface until you examine DMARC aggregate reports days later. If you are setting up DNS records for the first time and want to avoid disrupting live sending during propagation, the fallback option can serve as a temporary measure, but switch to Reject message once the records are confirmed as verified.
The per-region, per-identity gotcha
SES identities are scoped to an AWS region. A custom MAIL FROM configuration applied to an identity in eu-west-1 does not carry over to the same domain identity in us-east-1. If you send from multiple regions, whether for failover or latency reasons, you must repeat the custom MAIL FROM setup in each region separately. This includes configuring the subdomain against the identity in each regional console and ensuring the MX record target uses the correct region-specific feedback-smtp endpoint. Using the wrong region's endpoint in the MX record will cause SES to fail verification in that region. It is a common oversight to configure everything correctly in a primary region and then discover that traffic routed through a secondary region has been sending with an amazonses.com envelope sender all along.
The same per-identity logic applies to Easy DKIM. If you send from multiple regions, DKIM signing must be enabled and the three CNAME records must be published for each regional identity. The DMARC alignment benefits of both custom MAIL FROM and Easy DKIM only apply to mail sent from identities where those features are active.
Verifying that alignment is working
Once your DNS records have propagated and SES shows the custom MAIL FROM status as Successful, send a real test message and inspect the full email headers at the recipient. Look for two specific results. The spf= result in the Authentication-Results header should show spf=pass with smtp.mailfrom equal to your custom MAIL FROM subdomain, for example mail.yourdomain.com. The dmarc= result should show dmarc=pass. If you see spf=pass but dmarc=fail, the MAIL FROM domain is either not properly aligned with your From domain or your DMARC record is using strict SPF alignment (aspf=s) while your MAIL FROM is on a subdomain.
Tools such as mail-tester.com provide a simple one-shot report showing SPF, DKIM, and DMARC results for a single test message. For an ongoing view, your DMARC RUA aggregate reports are the authoritative source. These XML reports, sent daily by receiving mail servers to the address specified in your rua= tag, show alignment results broken down by sending source and authentication outcome. Reviewing them regularly lets you confirm that SES traffic is producing aligned SPF and aligned DKIM, and allows you to spot any sending sources that have drifted outside your authentication setup.
Continuous monitoring with SES Monitor
A correctly configured custom MAIL FROM domain and Easy DKIM setup is not a one-time task. DNS records can be accidentally deleted during migrations. CNAME records for DKIM can be overwritten. New AWS regions can be added to your infrastructure without the MAIL FROM configuration being repeated. A third-party integration may begin sending through SES without going through your standard authentication setup. Any of these events can silently break SPF or DKIM alignment, and without active monitoring you may not find out until a deliverability problem surfaces or a DMARC aggregate report flags failures that have already accumulated over days.
SES Monitor continuously tracks your bounce rates, complaint rates, and sending reputation metrics across your SES account, alerting you when key thresholds are crossed or when account-level warnings appear. Sudden increases in bounce or complaint rates are often the first practical signal that something in your authentication chain has broken and that messages are being rejected or sent to spam at a higher rate than expected. Combining that alerting layer with regular review of your DMARC aggregate reports gives you the earliest possible warning when a DNS change or configuration drift has undermined the alignment setup you have worked to build.
Setup checklist
To achieve dual-path DMARC alignment for Amazon SES, work through the following steps in order. First, configure a custom MAIL FROM subdomain under your verified domain identity in the SES console and set the MX failure behaviour to Reject message. Second, publish an MX record on that subdomain pointing to feedback-smtp.{region}.amazonses.com with a priority of 10. Third, publish an SPF TXT record on the subdomain with the value v=spf1 include:amazonses.com ~all. Fourth, confirm that Easy DKIM is enabled for the identity and that all three CNAME records are published and showing as verified. Fifth, ensure your DMARC TXT record at _dmarc.yourdomain.com includes an rua= tag pointing to an address where you will receive aggregate reports, and that SPF alignment is set to relaxed (aspf=r). Sixth, repeat the custom MAIL FROM and DKIM configuration for every AWS region from which you send. Finally, send a test message, inspect the Authentication-Results header to confirm both spf=pass and dmarc=pass, and put ongoing monitoring in place so that any future configuration drift surfaces quickly rather than silently.