Amazon SES messages can authenticate successfully while using identities that do not align with the domain displayed in From. A DMARC setup therefore needs the SES identity configuration and the actual application's received-message results.
Use the correct AWS account, Region and identity. Obtain generated values from that configuration rather than copying another account's selector targets or assuming a setup elsewhere covers the current sending route.
Establish the identity and signing model
Record the visible From domain, the application and the SES configuration it uses. Confirm whether DKIM is provided through Easy DKIM, a bring-your-own-key arrangement or another supported identity configuration.
Before changing a working setup, save its current state and check who owns DNS and signing changes. A new guide is not a reason to regenerate a working identity blindly.
Domain verification and DKIM signing state should both be checked in the actual service. A public key or delegation alone does not prove that the application sends with the intended passing signature.
Configure DKIM from the selected identity
For a verified domain identity using Easy DKIM, AWS documents the identity's Authentication settings, Easy DKIM choice and signing enablement. It generates the DNS verification configuration that must be completed with the DNS provider.
Use the full supplied record set and verify its authoritative answers. Confirm the resulting service status, then send a representative application message to an independent recipient.
AWS’s Easy DKIM guidance also documents a migration risk when moving from BYODKIM to Easy DKIM: messages may be unsigned while the new configuration is pending. Follow its supported migration guidance and plan for critical traffic instead of assuming the switch is seamless.
Inspect the MAIL FROM domain separately
SES uses an amazonses.com subdomain as the default MAIL FROM identity. A passing SPF result for that identity does not, by itself, establish alignment with your own visible From domain.
An aligned passing DKIM signature can provide the DMARC passing path. A supported custom MAIL FROM setup can also establish an SPF identity under an appropriate domain relationship.
Choose a dedicated subdomain under the parent domain of a verified SES identity. AWS says it must not be used for other purposes, including ordinary sending or receiving mail. The custom MAIL FROM name needs exactly one MX record; multiple MX records make SES setup fail. Follow AWS’s custom MAIL FROM requirements and use the selected identity’s generated MX and SPF values. This receiving function supports bounce and complaint handling; do not confuse it with moving the organisation's normal mailbox MX records.
Choose MX-failure behaviour deliberately
AWS documents two custom MAIL FROM failure behaviours. The service can fall back to its default MAIL FROM domain or reject the send when the custom domain's required MX configuration is not verified.
The fallback can change the SPF identity and its alignment relationship. It does not necessarily mean DMARC fails, because an aligned passing DKIM path may remain.
In a synthetic case, a billing message has From at example.com and aligned passing DKIM, but its custom MAIL FROM fails validation and the permitted fallback uses the SES domain. The SPF-alignment expectation has changed while DKIM can still provide the passing path.
Document the selected behaviour and its implications for critical application mail. Do not leave that decision as an unexplained default.
For a verified domain identity, AWS documents this console sequence:
- Open SES in the intended Region, choose Configuration → Identities, then select the verified domain.
- In Custom MAIL FROM domain, choose Edit. Enable Use a custom MAIL FROM domain, enter the dedicated subdomain and choose Behavior on MX failure.
- Save changes, then copy the MX and SPF TXT values from Publish DNS records to the authoritative DNS provider. Keep unrelated mailbox MX records unchanged.
Check the resulting custom MAIL FROM status in SES, the authoritative DNS answers, and a received application message as separate evidence. The AWS procedure is the reference if console labels change; this sequence is not a claim that these steps have been executed.
Publish the intended DMARC policy
Assess the existing policy, reporting destination and the domain's legitimate sending population. Preserve an existing stronger approved policy while investigating a separate SES configuration issue.
Use the record workflow for publication and collection checks. Policy selection should fit the domain's actual use and current interoperability guidance, rather than a universal instruction to publish reject.
Verify the final application route
Send from the application users depend on, not only a console or isolated test tool. Inspect the original message at the recipient and retain From, the SPF-evaluated domain, every relevant DKIM signature and trusted DMARC results.
Repeat for material Regions, identities or routes actually in use. If an outbound intermediary changes the message, verify the result after that route. Keep provider status, DNS observations and received-message evidence as separate acceptance records.
Monitor subsequent failures and changes to custom MAIL FROM configuration. The useful outcome is a supported, owned SES sending route with verified alignment and understood failure behaviour.