To verify a domain in Amazon SES, create a domain identity in the AWS Region you will send from, publish the three Easy DKIM CNAME records SES gives you, and wait until the identity status is Verified. Verification is per Region, can take up to 72 hours, and does not take the account out of the sandbox. Custom MAIL FROM is optional but required if you want SPF alignment on your own bounce subdomain.
What SES domain verification actually proves
Amazon SES treats a domain as an identity. Until that identity is verified in a Region, you cannot send from addresses on that domain in that Region. Easy DKIM is the default path: SES generates the keys and asks you to publish three CNAMEs. BYODKIM is the exception, used when you must control the key pair yourself.
Three separate jobs often get mixed together:
- Identity verification proves you control the domain and enables DKIM signing in that Region.
- Sandbox exit is a different request. A verified domain in sandbox still cannot mail unverified recipients. See how to move Amazon SES out of the sandbox.
- Inbox placement still depends on reputation, content, and bounce handling. Quotas after approval are covered in Amazon SES sending limits and quotas.
Easy DKIM vs BYODKIM
| Path | Who holds the key | DNS records | When to use it |
|---|---|---|---|
| Easy DKIM (default) | SES manages rotation | Three CNAMEs to a *.dkim.amazonses.com hosted zone | Almost every SaaS and product team |
| BYODKIM | You supply a 1024–2048-bit key | One TXT at {selector}._domainkey.{domain} with a p= public key | Compliance or multi-vendor DKIM reuse |
Use Easy DKIM unless you have a written reason to own the private key. Default signing length is 2048-bit; 1024-bit remains available but is the weaker option.
How to verify a domain with Easy DKIM
1. Open Amazon SES in the sending Region
Switch the AWS console to the Region your application will call. Identities, DKIM tokens, sandbox status, and sending quotas are all Region-specific. An identity verified in us-east-1 does not authorize sending from eu-west-1.
2. Create a domain identity
Choose Create identity, select Domain, and enter the domain you will use in the From header. For most product mail that is the root domain (example.com) or a dedicated send host (mail.example.com). Verifying the root does not automatically verify every subdomain as a separate identity in every workflow, so create the identity that matches the From domain you will actually use.
Under Advanced DKIM settings, keep Easy DKIM and RSA_2048_BIT unless you have a documented constraint.
3. Publish the three CNAME records
SES shows three CNAME names and values. The name pattern is:
{token}._domainkey.example.com → {token}.dkim.amazonses.comSome Regions use a hosted-zone value that includes the Region, for example {token}.a31d.dkim.us-west-2.amazonses.com. Copy the values SES displays for that identity. Do not invent tokens.
If the zone is in Route 53, SES can publish the records for you. Every other DNS host needs a manual paste.
Cloudflare warning: create the records as DNS-only (grey cloud), not proxied. Do not flatten the CNAME into an A record. In the Cloudflare name field, enter only the host SES shows if the UI already appends the zone. A doubled name such as token._domainkey.example.com.example.com is a common reason the identity stays Pending.
4. Wait for SES to see the records
DNS can take up to 72 hours. SES marks DKIM Successful and the identity Verified when all three CNAMEs resolve. Refresh the identity page rather than creating a second identity in the same Region.
Optional: set a custom MAIL FROM domain
Without a custom MAIL FROM, SES uses an amazonses.com bounce address. That can pass SPF at Amazon’s domain while leaving your From domain unaligned. For SPF alignment you want a subdomain you control, such as bounce.example.com.
- On the verified identity, enable custom MAIL FROM and enter a subdomain of that domain—not the same hostname you send from.
- Publish an MX on that subdomain pointing at the SES feedback host shown in the console for your Region.
- Publish a TXT SPF record on the same subdomain, typically
v=spf1 include:amazonses.com ~allunless SES shows a more specific value. - Choose fallback behavior if the MAIL FROM domain is not verified yet: use the default Amazon MAIL FROM, or reject the send with
MailFromDomainNotVerified.
Custom MAIL FROM is how Return-Path and SPF line up with the domain your customers see. For header roles, see From, Reply-To, and Return-Path. For alignment itself, see SPF, DKIM, and DMARC explained.
BYODKIM, if you must bring your own key
Choose Provide DKIM authentication token (BYODKIM). Paste a base64-encoded private key between 1024 and 2048 bits with PEM headers and line breaks stripped. Publish a TXT at {selector}._domainkey.example.com whose value is the matching public key, also stripped of PEM headers, prefixed with p=.
Common BYODKIM failures are leftover -----BEGIN PUBLIC KEY----- wrappers, wrapped lines, a missing p=, or a selector that does not match the DNS name.
Why the identity is still Pending
- Wrong Region. The app sends in one Region; the identity lives in another.
- Zone name appended twice. The DNS host added
example.comonto a name that already included it. - Name and value swapped. The token host was pasted into the value field.
- Cloudflare proxy or CNAME flattening. Mail CNAMEs must stay CNAMEs and must not be orange-clouded.
- Extra underscore. Correct:
abc123._domainkey.example.com. Incorrect:_abc123._domainkey.example.com. - Underscore-unfriendly DNS host. Some panels reject
_domainkeynames. Use a host that accepts them, or move the zone. - Propagation still in flight. Recheck with a public lookup from ArawaMail email tools before assuming SES is stuck.
SES allows up to 10,000 identities per Region. Creating duplicates to “force” verification usually makes the DNS picture worse.
Root domain, send subdomain, or both?
Verify the domain that appears in the From address. If receipts come from [email protected], verify example.com. If they come from [email protected], verify mail.example.com. Teams that later add staff mailboxes on the same company domain should treat that as a product decision, not a second SES checkbox—see keeping inboxes and product email on one domain.
What verification does not do
- It does not grant production access.
- It does not raise sending quotas.
- It does not create an employee inbox. SES remains send infrastructure.
- It does not replace DMARC policy or report analysis. Use how to read a DMARC report after mail starts flowing.
How this compares with ArawaMail DNS
ArawaMail onboarding is Cloudflare-only. You authorize the zone, activate receiving (MX; existing MX is warned before replace), then activate sending (DKIM CNAMEs plus custom MAIL FROM MX and SPF). Sending cannot be enabled until receiving is active. If SES was chosen only because “DNS looked hard,” ArawaMail publishes the same record classes automatically—after the zone lives on Cloudflare. The commercial tradeoff is on ArawaMail vs Amazon SES.
How we analyzed this
This walkthrough follows AWS’s current “Creating and verifying identities in Amazon SES” documentation, including Easy DKIM defaults, BYODKIM formatting, custom MAIL FROM behavior, the 72-hour DNS window, and the 10,000-identity-per-Region cap. Console labels can move; the record classes do not. ArawaMail receiving and sending docs were checked separately so the closing contrast does not invent ArawaMail hostnames or SES-style Mail Manager features.
Frequently asked questions
Does verifying a domain take Amazon SES out of the sandbox?
No. Domain verification and production access are separate. You can have a Verified identity and still be limited to 200 recipients per 24 hours and verified destinations only.
How long does Amazon SES Easy DKIM verification take?
Often minutes once DNS is correct. AWS documents up to 72 hours for propagation. If the status is still Pending after that, the records are usually wrong, proxied, or created in a different Region.
Should a SaaS team use Easy DKIM or BYODKIM?
Easy DKIM. Use BYODKIM only when you must reuse an existing selector or keep the private key outside AWS.
Do I need a custom MAIL FROM domain?
It is optional for verification. It is recommended for SPF alignment so the bounce domain belongs to you instead of amazonses.com.
Can I verify a domain once and send from every AWS Region?
No. Create and verify the identity in each Region you send from, unless you are using a documented multi-Region identity feature such as Deterministic Easy DKIM from a parent Region.