Prepare an Amazon SES sending identity

Before an application sends through Amazon SES, establish which AWS account and Region own its sending identity. Verify the domain in that Region, confirm account sending access, and give the application only the permissions it needs. Domain verification alone is not production access or proof of inbox placement.

Choose a Region and application domain

SES identities and account settings are regional. Select a Region supported by your application, and use that same Region in the console, CLI, SDK, and event configuration. If receiving is part of the design, check SES receiving availability separately; not every sending Region supports receiving.

Use a domain you control, often an application subdomain, and record who can change its DNS. Sending through SES does not require replacing the MX records that deliver employee mail to Exchange or Gmail.

Verify the identity and DKIM

In the SES console, open Identities → Create identity → Domain. Enter your sending domain, select the appropriate DKIM setup, and publish the exact records SES supplies. With Easy DKIM, use the names and values from the identity’s current DNS instructions rather than inventing tokens or assuming a regional hosted-zone suffix.

Do not confuse three DNS jobs:

A custom MAIL FROM subdomain is not a replacement for a user’s mailbox MX. Also plan DMARC alignment; do not create multiple conflicting SPF records at the same name.

Inspect readiness without sending mail

The following commands require AWS CLI credentials authorized for the read operations shown. Set AWS_REGION and SES_DOMAIN to your selected Region and actual sending domain; neither value is a secret.

aws sesv2 get-email-identity \
  --region "$AWS_REGION" \
  --email-identity "$SES_DOMAIN" \
  --query '{Ready:VerifiedForSendingStatus,DKIM:DkimAttributes.Status}'

aws sesv2 get-account \
  --region "$AWS_REGION" \
  --query '{Production:ProductionAccessEnabled,Sending:SendingEnabled}'

A verified identity should report readiness and successful DKIM once DNS has propagated. If identity lookup fails, check account, Region, domain spelling, and IAM access before changing DNS again.

Resolve sandbox and application permissions

When an account is in the SES sandbox, recipient restrictions and reduced sending limits apply. Use approved verified recipients or the AWS mailbox simulator for development, and follow AWS’s production-access procedure before sending to general recipients. Production access is an account/Region decision; it does not remove sender-verification requirements.

Run the application with an IAM role where possible. Scope its sending permission to the intended identity and allowed behavior. A sending process does not need account administration, arbitrary S3 access, or receipt-rule management. AWS API credentials and SES SMTP credentials are different credential types; do not interchange them.

Define the handoff to MailKite

Choose one transport for each message. To send directly through AWS, continue to send with the SES SDK. For an independent managed application path, use the MailKite sending SDK with its own verified domain and API key. SES identity verification does not verify the domain in MailKite automatically.

Before production, document who handles delivery events, bounces, complaints, suppression, and quota alarms. The next guide sends a controlled message; it does not replace those responsibilities.

References

• Creating and verifying SES identities
• Requesting production access