Table of Contents
- What DNS Records Does Amazon SES DKIM Require?
- What belongs in the DNS fields?
- How do Easy DKIM and BYODKIM differ?
- How to verify it
- How Do You Enable Easy DKIM and Publish the CNAMEs?
- What is the publishing procedure?
- What do the verification statuses mean?
- How do you confirm the CNAMEs reached DNS?
- How Do Custom MAIL FROM and DMARC Make Amazon SES Mail Align?
- Which records support custom MAIL FROM?
- What do the record checks confirm?
- How Do You Verify Amazon SES DKIM Is Signing?
- What should the DNS check show?
- Reading the DKIM-Signature header in a test message
- Which sending paths still need their own test?
- Why Does Amazon SES DKIM Stay Pending or Fail?
- Which common mistakes produce these symptoms?
- Why can only part of the traffic fail?
- How to verify it
- What Must Be True Before Production Mail Uses Amazon SES DKIM?
- Can one Easy DKIM setup cover every Region?
- Should a new domain use Easy DKIM or BYODKIM?
- Does DKIM replace SPF?
- How long can status stay Pending?
- How can agents verify the same setup?
Do not index
Do not index
Amazon SES Easy DKIM requires three CNAME records, each named token._domainkey and typically pointing to token.dkim.amazonses.com; Bring Your Own DKIM uses a single TXT record as the alternative. Publishing those records isn't proof that every sending path is authenticated, because Amazon SES DKIM settings belong to a particular AWS Region, AWS account, and identity.
The familiar advice to add the records and wait misses the important distinction: DNS publication, identity verification, and message signing are separate checks. A domain can have working DKIM records while an application sends unsigned messages through a different identity.
Table of Contents
What DNS Records Does Amazon SES DKIM Require?What belongs in the DNS fields?How do Easy DKIM and BYODKIM differ?How to verify itHow Do You Enable Easy DKIM and Publish the CNAMEs?What is the publishing procedure?What do the verification statuses mean?How do you confirm the CNAMEs reached DNS?How Do Custom MAIL FROM and DMARC Make Amazon SES Mail Align?Which records support custom MAIL FROM?What do the record checks confirm?How Do You Verify Amazon SES DKIM Is Signing?What should the DNS check show?Reading the DKIM-Signature header in a test messageWhich sending paths still need their own test?Why Does Amazon SES DKIM Stay Pending or Fail?Which common mistakes produce these symptoms?Why can only part of the traffic fail?How to verify itWhat Must Be True Before Production Mail Uses Amazon SES DKIM?Can one Easy DKIM setup cover every Region?Should a new domain use Easy DKIM or BYODKIM?Does DKIM replace SPF?How long can status stay Pending?How can agents verify the same setup?
What DNS Records Does Amazon SES DKIM Require?
DomainKeys Identified Mail (DKIM) lets a receiving mail server verify a message's cryptographic signature using a public key published through DNS. Amazon Simple Email Service (Amazon SES) offers Easy DKIM to manage the signing keys, or Bring Your Own DKIM (BYODKIM) for teams that need to supply their own.
The Amazon SES identity documentation specifies three CNAME records for Easy DKIM, rather than the TXT record used by BYODKIM. Amazon SES keeps the Easy DKIM private key and uses it to sign messages; the CNAME records direct public-key lookups to Amazon-hosted signing material.
What belongs in the DNS fields?
The following example.com examples are patterns, not deployable selectors. The actual tokens and targets must come from the identity's Amazon SES console.
The selector is the token before
._domainkey. A receiving server reads that selector from the message's signature and looks up the corresponding DNS name.The target shown above is a common pattern, not a hostname to construct manually. Region-specific targets can differ, so the console-generated value takes precedence over any example.
For a plain-language definition of the underlying mechanism, DKIM explained by Grou provides additional terminology context.
How do Easy DKIM and BYODKIM differ?
The AWS Easy DKIM guide documents RSA_2048_BIT as the default, with RSA_1024_BIT available for compatibility, and specifies supported BYODKIM key formatting and size requirements.
BYODKIM doesn't mean publishing the private key. The private key goes to Amazon SES; DNS contains the public key.
How to verify it
A selector-specific mailX DKIM check should locate the published public key through the SES-generated CNAME. The exact SES selector matters: failure to discover an automatically generated selector through common-selector guessing doesn't prove that the record is missing.
A missing name, unexpected record type, or target that differs from the console indicates a publication problem. Creating an identity in Amazon SES alone doesn't establish that its DNS records are reachable.
How Do You Enable Easy DKIM and Publish the CNAMEs?
Start in the sending Region: open Amazon SES in the account and Region your application uses. DKIM is configured per AWS account and per Region, so records published for one Region's identity do nothing for mail sent through another.
What is the publishing procedure?
- Select the sending environment. Open Amazon SES in the AWS account and Region the application sends through, then create or select the domain identity. For an example.com deployment, the identity is
example.com, matching the domain in the From address, rather than the application's website hostname unless that hostname is deliberately the sending domain.
- Enable Easy DKIM. Turn on Easy DKIM with signing enabled for the identity. The default key setting is appropriate unless a documented DNS-host compatibility problem requires the supported fallback.
- Copy every generated CNAME row. Both the record name and target come from Amazon SES. Replacing the token with a memorable selector, copying records from another identity, or changing the record type prevents the intended lookup.
- Publish at the authoritative DNS provider. A DNS control panel may expect a relative host rather than a fully qualified name. The provider's field behavior determines which form belongs in the host box.
- Disable DNS proxying. When Cloudflare or another DNS host offers proxying, these CNAME records need DNS-only behavior so Amazon SES can retrieve the actual DNS target.
- Read the identity's DKIM status. The status in Amazon SES shows whether the service has observed and accepted the publication. A saved record in a DNS panel is only an input until SES confirms it.
For example.com, the host-field distinction looks like this:
The AWS verification troubleshooting guide identifies malformed DNS names as a verification problem and notes that Amazon SES can take up to 72 hours to observe records in rare cases.
What do the verification statuses mean?
Verification status and signing-enabled state are distinct. A verified identity with signing disabled still needs a configuration change before it produces the intended signatures.
How do you confirm the CNAMEs reached DNS?
A mailX CNAME Lookup against each generated selector should return the console's exact target. Querying the authoritative nameserver gives an additional confirmation that the records exist at the DNS source, rather than only in a dashboard or a resolver cache.
Three passing lookups confirm publication for that one identity. They say nothing about mail sent through a different Region or a different AWS account, and a separately verified email-address identity can keep its own DKIM settings, so each sending path needs its own check.
How Do Custom MAIL FROM and DMARC Make Amazon SES Mail Align?
DMARC passes when one authenticated domain matches the visible From domain. DKIM authenticates a signing domain, SPF authenticates the envelope sender's domain, and Domain-based Message Authentication, Reporting, and Conformance (DMARC) compares those authenticated domains with the address the recipient sees.
With the default Amazon SES MAIL FROM domain, SPF can pass for an
amazonses.com domain without aligning with the organization's visible From address. Easy DKIM can still provide the aligned authentication that DMARC needs.
Which records support custom MAIL FROM?
A custom MAIL FROM subdomain gives SPF a domain under the organization's control. For example.com,
mail.example.com is an illustrative choice, separate from the visible From address.The AWS custom MAIL FROM documentation provides the Region-specific MX target and required DNS settings. Its MX example uses priority 10; the hostname must match the identity's sending Region and should be copied from the current console configuration.
These are example.com examples. The literal
region label is a placeholder, and the reporting mailbox must exist before reports can be received.The DMARC monitoring policy requests reports without requesting quarantine or rejection. DKIM alignment comes from the relationship between the signature's authenticated domain and the visible From domain, so publishing this record changes reporting behavior rather than the alignment result.
A custom MAIL FROM subdomain generally supports relaxed SPF alignment with its parent domain. Strict SPF alignment requires an exact domain match, so a subdomain MAIL FROM and parent-domain From address don't satisfy that stricter comparison.
Alignment applies per sending path. Because Amazon SES configures DKIM per Region and per AWS account, an aligned result under one identity covers that identity only; an identity in another Region needs its own records checked before an operator can claim alignment for it.
The Gmail and Yahoo sender requirements overview from Purple Engage provides broader sender-policy context. For Amazon SES configuration, the immediate task remains matching the actual authenticated domains to the visible From domain.
What do the record checks confirm?
For the MAIL FROM subdomain, the SPF policy lives in the TXT record published at
mail.example.com, and the MX record should answer with the console's feedback-smtp target for the sending Region. A good configuration exposes a single SPF policy authorizing Amazon SES; an actual message's SPF pass still depends on the connecting sender and the evaluated envelope domain.For DMARC, the policy record lives at
_dmarc.example.com. The mailX DMARC checker can check DMARC alignment prerequisites by returning the domain's live policy: for an interface expecting a domain, the input is example.com, and the published record sits under the underscore-prefixed name.A received message supplies the final alignment evidence. A valid policy lookup establishes that a policy exists; the message headers establish whether DMARC passed for that particular send.
How Do You Verify Amazon SES DKIM Is Signing?
Three resolving CNAMEs are evidence of publication, not of signing. A message can travel a path where the identity is unverified, DKIM is disabled, or a separate email-address identity keeps its own settings, and none of that appears in the DNS answer.
The Amazon SES DKIM attributes reference identifies the supported Easy DKIM choices as RSA_2048_BIT and RSA_1024_BIT. The retrieved public key should match the identity's configured choice, rather than an assumed setting.
What should the DNS check show?
The operator can use mailX to verify your DKIM record by supplying the domain and the exact selector from Amazon SES. The check should be repeated for every generated selector, because checking a single valid record can miss an incomplete publication.
A TXT public key at the end of a CNAME chain is expected. The error is substituting a TXT record at the Easy DKIM selector name instead of publishing the required CNAME.
When a selector looks wrong, a selector-level CNAME lookup isolates the alias from the rest of the authentication checks.
Reading the DKIM-Signature header in a test message
Send through the actual application path, then open the received message's raw headers. The
DKIM-Signature header identifies the signing domain in d= and the selector in s=.For an example.com domain identity, the intended result is a signing domain matching the visible From domain and a selector matching the identity's published records. The receiver's trusted
Authentication-Results header should report dkim=pass alongside the intended DMARC result.A signature header by itself isn't proof of successful authentication. A receiver can find the header but reject the signature because the key lookup fails or the signed content no longer matches.
Which sending paths still need their own test?
A complete verification combines three things: the identity verified and enabled in the sending Region, each selector returning its published key, and a received message that passes signature validation. The order matters less than the coverage.
Coverage is where Amazon SES trips up careful operators. DKIM configuration is set per Region and per AWS account, so a domain verified and signing in one Region says nothing about the same identity in another Region or under a second account. A separately verified email-address identity also keeps its own DKIM settings even on a domain that already passes. Each production route needs its own test message, including failover routes and individually configured addresses.
The email authentication guide explains how the receiver combines DKIM, SPF, and DMARC results into a final verdict.
Why Does Amazon SES DKIM Stay Pending or Fail?
A proxied CNAME and a doubled hostname are direct DNS failures worth checking before waiting. The former hides the required lookup behavior; the latter publishes the record somewhere Amazon SES isn't querying.
Identity mismatches require a different investigation. The AWS DKIM troubleshooting guide explains that DKIM configuration is Region-specific and account-specific, and that separately verified email addresses can have their own settings.
Which common mistakes produce these symptoms?
The example.com hostname in the table is illustrative. Duplicate SPF policies cause permerror, rather than giving receivers a choice of authorization records.
The SPF lookup limit applies to evaluated DNS-querying terms, including nested includes. It isn't a simple count of TXT records visible in the domain's DNS panel.
Why can only part of the traffic fail?
Production, staging, failover, and separate AWS accounts can share a visible From domain while using different identities. A passing public lookup doesn't reveal which identity an application selected or whether signing was enabled there.
The diagnostic inventory should record:
- Sending account and Region. These identify the Amazon SES environment responsible for the message.
- Identity type. A domain identity and an individually verified address aren't interchangeable configuration checks.
- Published selector and target. These connect the console configuration to DNS.
- Received authentication result. This establishes what the recipient verified.
Old CNAME records shouldn't be deleted just because a newer deployment works. Another account or Region may still depend on them.
How to verify it
After a fix, the operator should rerun the affected mailX check and send a new message through the failing route. An old message can't demonstrate that a configuration change worked.
Key-length changes deserve a separate review of current AWS restrictions and DNS-provider compatibility. A shorter supported key is a compatibility fallback, not a substitute for correcting the selector or target.
SMTP connection errors also belong outside DKIM DNS diagnosis. A wrong port/encryption pair or missing authentication credential can stop submission before any message is signed; changing DKIM records won't fix that failure.
What Must Be True Before Production Mail Uses Amazon SES DKIM?
Production readiness is a go or no-go decision for each sending path, not a domain-wide badge. A working staging account does not establish that production or failover traffic uses the same authenticated configuration, because signing is configured per Region, per AWS account, and per identity. A verified email-address identity can even keep its own DKIM settings apart from the domain identity that shares its domain.
The go decision rests on four conditions:
- Identity ready. The intended account and Region show successful DKIM verification with signing enabled, including any individually verified sending addresses.
- DNS reachable. Every required selector resolves from the authoritative nameservers to the expected signing material.
- Message authenticated. A received test message carries the intended signing domain and a passing DKIM result.
- DMARC supported. Passing DKIM or custom MAIL FROM SPF aligns with the visible From domain.
A final check should validate your SPF record at the actual MAIL FROM domain. Teams seeking to keep nurture emails reaching prospects still need this authentication evidence before treating DNS setup as complete.
Can one Easy DKIM setup cover every Region?
One Easy DKIM setup covers only the account and Region where it was configured. Every other sending Region and AWS account needs its applicable identity configuration checked on its own, because existing DNS records do not establish that another environment has enabled signing or selected the intended identity. This matters most where an application can switch between primary and failover environments, since each environment holds its own identity verification state.
Should a new domain use Easy DKIM or BYODKIM?
The earlier section on DNS records already covered this tradeoff: Easy DKIM for a team that wants Amazon SES to generate and manage signing material, BYODKIM for a requirement to control the signing key along with its generation, supported private-key formatting, upload, and public-key publication.
Does DKIM replace SPF?
They answer different questions. DKIM authenticates a message signature, while SPF authorizes the sending server for the envelope sender's domain. Passing aligned DKIM can satisfy DMARC without aligned SPF. A custom MAIL FROM domain provides an SPF alignment path, subject to the DMARC alignment mode and the relationship between the envelope and visible From domains.
How long can status stay Pending?
The AWS documentation on Easy DKIM, cited in the setup steps, allows up to 72 hours for Amazon SES to observe correctly published records. Waiting is appropriate only after the authoritative DNS answers are correct. A doubled hostname, wrong selector, incorrect target, or proxied CNAME will not repair itself with time, so DNS inspection should come before another waiting period.
How can agents verify the same setup?
The
dkim-check endpoint accepts a domain and can try common selectors when none is supplied. Amazon SES's generated selectors should be supplied explicitly. The mailX API accepts JSON request bodies and returns JSON responses, with no API key or signup required; MCP supports agent-driven checks as well.mailX offers free, no-signup live authentication checks with plain-English explanations and fixes. Visit mailX to check the exact Amazon SES DKIM selectors, custom MAIL FROM SPF, and DMARC policy, or run the same checks through MCP from ChatGPT, Claude, or Cursor. DNS that answers correctly is half the evidence; the signature on a message from the actual production path is the other half.