For Amazon SES, configure DKIM on the identity that actually sends your application mail. If you also need SPF alignment, configure a custom MAIL FROM subdomain and publish its SES-issued MX and SPF records. Finally, verify the visible From domain’s DMARC policy and an externally delivered message. SES’s default MAIL FROM can pass SPF without aligning with your brand. AWS SPF guidance.
This guide covers outbound Amazon Simple Email Service mail, including API and SMTP application routes. It does not configure Amazon WorkMail or employee mail sent directly through another provider. Keep the AWS account, Region, identity, and application together throughout the change.
Establish the account, Region and domain before editing
Write down the application’s actual SES endpoint, sending Region, domain shown in From, verified identity, and DNS host. Include any disaster-recovery Region or secondary application. Save the current DKIM mode, signing status, custom MAIL FROM setting, MX-failure behavior, and relevant DNS records.
Identity verification, sandbox status, and sending limits can differ by Region. A domain working in one Region is not proof that another is ready to send. Treat regional sending permission separately from authentication DNS. AWS Regions and SES.
If another team owns the application, request a recent sample message and confirm the configured endpoint rather than inferring it from the console tab open in your browser. Export the DNS records you intend to change and identify a rollback owner. Do not delete employee-mail MX records or another sender’s DKIM selectors during this task.
Choose the right DKIM mode
AWS supports Easy DKIM, Deterministic Easy DKIM (DEED), BYODKIM, and manual message signing. Easy DKIM lets SES manage signing keys; BYODKIM uses a key pair you supply. Manual signing is an application-level option, not the same setup as copying generated CNAMEs. New Easy DKIM identities default to 2048-bit keys. AWS DKIM overview.
Use the existing mode as your starting point. Do not switch a working BYODKIM identity just to follow this article: AWS warns that moving to Easy DKIM can leave messages without that DKIM signature while verification is pending. Schedule a controlled migration if a mode change is genuinely required. AWS Easy DKIM migration warning.
For a multi-Region design, DEED creates replica identities that inherit an Easy DKIM parent’s configuration and reuse its DNS records. It requires an actual replica setup, not simply sending through another Region after configuring the first. Record the parent and replica Regions and validate each live application route. AWS DEED documentation.
Configure Easy DKIM and publish the issued records
In the correct Region’s SES console, open Configuration → Identities, select the domain, and open Authentication. Edit DKIM, choose Easy DKIM if appropriate, retain the preferred 2048-bit setting, enable signatures, and save. This procedure assumes you have the necessary identity-management and DNS access. AWS Easy DKIM setup.
Under Publish DNS records, copy all three generated CNAME records or download the record set. Use their complete names and destinations. AWS documents that hosted-zone suffixes vary by Region and identity; API-based tooling should use the returned DkimAttributes.SigningHostedZone, not a hardcoded suffix. AWS identity verification instructions.
For every record, check:
- The owner name includes the full issued selector and
_domainkeycomponent. - The DNS host has not appended the domain twice.
- The destination matches the selected identity’s output exactly.
- An existing record at that name has a known owner before replacement.
- All three records are present, even when one test message uses only one selector.
No reusable selectors or destinations are provided here. They must come from your account. Wait for public DNS visibility and the expected SES verification/signing state, then test actual mail. Save both observations rather than treating the console label alone as completion.
Apply the following name mapping to the actual SES-generated record set for the chosen identity and Region, not to a guessed selector. For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.
For the Easy DKIM CNAME records, resolve conflicting ordinary data at the same owner with its owner before publication; do not remove another service’s records blindly. This does not turn a BYODKIM TXT key into a CNAME. Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.
Understand SPF before adding an SES include
With the default SES MAIL FROM, SPF is already configured for the provider-owned envelope domain. Adding include:amazonses.com at your root domain does not change the envelope sender used by SES. To use your own envelope domain, configure custom MAIL FROM and publish its required records. AWS SPF behavior.
SPF checks the SMTP envelope identity, not the visible From address. At any evaluated DNS name, publish one SPF policy, not several competing v=spf1 records. Keep the full evaluation within the ten DNS-querying-term limit, including nested processing. SPF specification, RFC 7208.
This distinction matters during migrations. A root-domain SPF change may affect employee mail without fixing SES alignment. Locate the actual envelope domain in a delivered message before deciding where an SPF change belongs.
Configure a dedicated custom MAIL FROM subdomain
Choose a dedicated subdomain of the verified identity’s parent domain, not one used for ordinary sending or receiving. In the selected identity’s Custom MAIL FROM settings, enable the feature, enter that subdomain, choose MX-failure behavior, and save. Copy the displayed DNS records. AWS custom MAIL FROM setup.
For a conventional AWS Region, the documented shape is:
- Owner: your chosen custom MAIL FROM subdomain.
- MX: priority
10, destinationfeedback-smtp.REGION.amazonses.com. - TXT:
v=spf1 include:amazonses.com ~all.
REGION is a placeholder. Publish the exact generated endpoint for the selected Region, not this template unchanged. SES requires exactly one MX record at the custom MAIL FROM name. Do not reuse that name as a mailbox domain or add several regional feedback MX records. AWS custom MAIL FROM DNS requirements.
For multi-Region sending, plan separate dedicated MAIL FROM names as needed so each configuration can retain its required feedback endpoint. Record the mapping explicitly. DEED’s shared DKIM configuration should not be mistaken for proof that custom MAIL FROM is ready in every Region.
Decide what should happen if the MX check fails
UseDefaultValue lets SES fall back to an amazonses.com envelope domain. RejectMessage prevents sending and returns MailFromDomainNotVerified. The configured action applies to Pending, Failed, and TemporaryFailure custom MAIL FROM states. AWS MAIL FROM API behavior.
Choose intentionally. Fallback favors continued sending but can remove the SPF alignment you expected; an aligned valid DKIM signature may still satisfy DMARC. Rejection makes an unavailable custom MAIL FROM configuration a sending failure your application must handle. Record the business decision and alert owner, rather than silently accepting the console default.
Preserve or publish the DMARC policy safely
Inspect TXT at _dmarc.YOUR-FROM-DOMAIN, including whether an inherited policy applies when no exact-domain record exists. Keep existing enforcement and approved report destinations unchanged unless a separate policy change is intended. SES authentication setup does not justify weakening an established policy. AWS places DMARC in your domain’s public DNS. AWS DMARC setup.
Publish one DMARC policy as a TXT record at _dmarc of the exact visible From domain. Use the DNS host’s relative-name or fully qualified-name convention, without duplicating the domain. If a record already exists, edit only the approved policy rather than adding a second.
For a domain with no existing applicable policy, an initial monitoring template is v=DMARC1; p=none; rua=mailto:APPROVED-REPORT-ADDRESS. Replace the address with an authorized destination before publication. Monitoring does not request quarantine or rejection. DMARC needs at least one passing SPF or DKIM identity aligned with the visible From domain. Current DMARC specification.
For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.
SES custom MAIL FROM normally uses a different subdomain from the visible From domain, so its SPF alignment depends on relaxed alignment. Do not remove an existing aspf=s policy automatically: an appropriately aligned DKIM signature can supply the DMARC pass instead. Strict DKIM alignment requires an exact signing-domain match. AWS SES alignment guidance.
Authorize who receives aggregate reports and verify any external reporting authorization required by the receiving service. Reports disclose sending activity, so access and retention deserve deliberate choices. DMARC aggregate reporting, RFC 9990.
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.
Validate public DNS and real application mail
Run public lookups using your actual values, replacing every example:
dig CNAME ISSUED-SELECTOR._domainkey.example.com
dig MX MAIL-FROM.example.com
dig TXT MAIL-FROM.example.com
dig TXT _dmarc.example.com
Repeat the DKIM lookup for all issued selectors. Compare results against SES output and retain resolver and timestamp information. Check the authoritative answer when cached results disagree before editing again.
For each Easy DKIM CNAME, verify both the literal issued alias and that its target resolves to a usable public DKIM key. Alias presence alone is not key-resolution acceptance. Compare the key lookup with the intended signature’s actual s= and d=; the delivered-message test must then verify that signature successfully. For BYODKIM, check the issued public TXT key at its own owner instead of inventing an Easy DKIM alias. DKIM public-key discovery.
Send a fresh message through the real application to an external mailbox you control. Record the receiving system’s SPF result and envelope domain, DKIM result and d=/s= values, visible From domain, and DMARC result. For DKIM, verification uses the signature’s selector and signing domain to locate the public key. DKIM specification.
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.
Repeat this acceptance test per Region and important route. A console-generated test is useful but does not prove that production selects the same identity or preserves the same content. Save unresolved exceptions with an owner, especially fallback events and gateways that modify signed messages.
Accept the branded DKIM setup only when the intended SES signature has trusted dkim=pass, its actual d= aligns with the intended visible From under the current adkim mode, and the trusted receiver reports dmarc=pass for that From domain. An SPF-only DMARC pass or an unrelated provider-domain signature does not satisfy this DKIM acceptance check. Diagnose SPF fail, softfail, temperror and permerror independently even when aligned DKIM supplies DMARC: inspect the actual envelope domain, connecting IP, DNS policy and delivery path. AWS SES DKIM and alignment, SPF result meanings.
For employee mail sent separately through Gmail, use the Google Workspace authentication guide. An SES test does not validate that mailbox route.