An Amazon SES domain identity stays pending or failed because SES has not seen every required Easy DKIM record at the domain's authoritative DNS, or because the identity is a Global replica using Deterministic Easy DKIM (DEED) and does not need new records. Paste the three console CNAMEs exactly, query them on the domain's own name servers, then wait. AWS documents up to 72 hours for DNS visibility. That is an upper bound, not a promise that verification will succeed.
Why SES domain verification stays stuck
The first-time path is already covered in how to verify a domain in Amazon SES. This page is only for an identity that is still Pending, Failed, or Unverified after those records were added. Sandbox limits, sending quotas, and SMTP throttling are different failures. Do not treat them as a DNS verification problem.
Most stuck identities are a name problem. The console shows the records, the DNS host UI shows something similar, and SES still cannot see all three CNAMEs. A smaller set are the wrong identity type: a Global replica created with DEED reuses the parent region's Easy DKIM DNS and should not get a second set of tokens.
How we checked this on 8 October 2026
We re-read the AWS pages for creating identities, Easy DKIM, DEED, and DKIM troubleshooting, plus the Arawa Mail sending guide. Constraints that shape the check order:
- Easy DKIM verification still copies three CNAME records from the Publish DNS records table. Each value is the token plus a region-specific hosted zone, such as
token.dkim.region.amazonses.com. The hosted zone is in the APISigningHostedZonefield. - Key length is still
RSA_2048_BIT(default) orRSA_1024_BIT. The length choice does not replace the three-record requirement. - AWS says DNS changes can take up to 72 hours, and SES marks DKIM successful only after it detects all required records. Waiting 72 hours does not fix a wrong name.
- A Global (replica) identity using DEED does not require additional DNS. The parent identity must already be Easy DKIM. You cannot replicate a BYODKIM identity.
- Custom MAIL FROM is a separate MX and SPF status on a subdomain. Pending MAIL FROM does not mean the domain identity is unverified.
- Arawa Mail does not show SES verification status, SES tokens, or DEED. Activate Sending writes Arawa's own DKIM CNAMEs and a custom MAIL FROM domain through Cloudflare, and only after receiving is active. Do not paste Arawa hostnames into an SES identity.
Check identity type before you touch DNS
Open the identity in the same AWS Region you send from. SES identities are regional. A verified domain in one Region is not verified in another unless you created that identity too.
- If Authentication shows Deterministic Easy DKIM, a parent region, and no new CNAME table, stop. DEED inherits the parent's Easy DKIM records. Missing customer CNAMEs are the wrong diagnosis. Confirm the parent is verified and that DNS for the parent still resolves. Replication can lag; AWS also lists missing
ses:ReplicateEmailIdentityDKIMSigningKeypermission as a verification error. - If the identity is standard Easy DKIM, expect three CNAMEs. BYODKIM uses a TXT public key, not three CNAMEs. Do not mix the two record shapes.
- Confirm the identity name is the apex you meant, such as
example.com, notwww.example.com. AWS says includingwww.makes domain verification fail.
How to tell a doubled hostname from a delay
Copy the three names and targets from the console. Do not retype them. Some DNS hosts append the apex, so a name you entered as token._domainkey.example.com is stored as token._domainkey.example.com.example.com. The host UI can look correct while the authoritative server returns NXDOMAIN for the name SES queries.
Query each CNAME against the domain's own name servers, not only 8.8.8.8 or 1.1.1.1. A public resolver can still be inside the TTL of an older answer. Two of three records resolving is not enough: SES needs all required records. The underscore in _domainkey is required. A provider that strips underscores will not verify.
Another failure mode on the AWS troubleshooting page: the DNS host returns the CNAME, then fails the follow-up TXT query that SES and mailbox providers make. That is a resolver limitation, not a missing paste. Route 53 is the workaround AWS names for that case.
What to do after the names match
If authoritative lookups match the console, including the region-specific dkim target, wait. AWS says detection can take up to 72 hours in rare cases. Do not delete the identity to refresh it while that window is open. Deleting and recreating can issue new tokens, so the records you just proved are no longer the ones SES wants.
After the records are correct and status is Failed or Unverified, use Retry under Authentication. Retry is not a substitute for a wrong name. Changing Easy DKIM key length is limited: you cannot switch to the length already set, and you cannot switch length more than once in 24 hours except the first downgrade to 1024 in that period. A key-length edit is not the first fix for a pending identity.
Moving from BYODKIM to Easy DKIM can leave mail unsigned while Easy DKIM is pending. AWS warns that SES will not use BYODKIM during that gap. That is a signing gap, not proof the identity is permanently stuck.
Statuses that are not a stuck domain
| What you see | What it means |
|---|---|
| DKIM successful, MAIL FROM pending | Domain identity can be verified. MAIL FROM still needs its own MX and SPF on the subdomain. SES can fall back to an amazonses.com MAIL FROM or reject, depending on the failure behavior you set. |
Second DKIM signature with d=amazonses.com | SES adds this for complaint feedback loops. AWS says you can ignore it. It is not a failed verification. Microsoft Enterprise Outlook may validate only one signature; that is a later signing issue, not this checklist. |
| Email address shows Unverified while the domain is Verified | AWS displays inherited addresses as unverified even though they can still send. That display is not a stuck domain. |
If two products send from the same From domain, keep their DKIM selectors separate. See two vendors, one From address. Arawa, Resend, and Postmark publish their own DKIM records. Those hostnames will not verify an SES identity.
How this differs from Arawa Mail
Arawa Mail does not manage SES identities. When you activate sending, after receiving is already active, Arawa creates the outbound identity and writes DKIM CNAMEs plus a custom MAIL FROM domain (MX and SPF) through Cloudflare. There is no SES pending screen and no DEED replica step. Domain onboarding is the Cloudflare path in the Enable Sending guide, not the SES console. For the authentication model those records serve, see SPF, DKIM, and DMARC explained and DKIM key rotation.
A verified SES domain still cannot send freely from a new account until production access exists. That limit is covered in moving SES out of the sandbox. It is not fixed by another CNAME.
FAQ
Why is SES still pending after the CNAMEs look right?
The usual cause is the published name, not the clock. Confirm you are not on a DEED replica, then query all three CNAMEs at the authoritative name servers. A doubled apex or a stripped underscore looks fine in some host UIs and returns NXDOMAIN to SES.
How many Easy DKIM records are required?
Three CNAME records, copied from the SES console. BYODKIM uses a TXT record instead. DEED replicas do not add a new customer record set.
Does custom MAIL FROM pending mean the domain is unverified?
No. MAIL FROM is a separate status. Diagnose the DKIM identity status first.
When is Retry safe?
After the records match and status is Failed or Unverified. Recreating the identity is a last resort because it can change the tokens.
Does a second DKIM signature mean verification failed?
No. The extra d=amazonses.com signature is added by SES for feedback loops. AWS says to ignore it for this check.
Does Arawa Mail verify domains the SES way?
No. Arawa writes its own DKIM and MAIL FROM records through Cloudflare after receiving is active. It does not display SES verification status.