Configure Elastic Email v4 domain and access scopes

Elastic Email’s current REST reference documents API v4 and operation-specific access levels. Match the client, credentials, and request model to that version rather than copying a v2 example from an old comparison page.

Establish the application context

1. Verify the sending domain and publish the authentication records supplied for the account.
2. Create an API key limited to the required sending operations. Reading events or managing routes may require different access.
3. If using SMTP, create the separate SMTP credential instead of guessing that an API key is interchangeable.
4. Store production/development secrets separately and document the intended sender identity.

The v4 reference lists domain verification, security, transactional sending, inbound routes, events, and webhooks. API availability in the reference does not establish a particular account’s enabled plan/permissions.

Verify in stages

Confirm the domain’s verified status, then send to one controlled recipient and inspect account activity. Resolve domain, access-level, and account-capability errors at their actual boundary.

Do not change mailbox MX records merely to authenticate an outbound sender. Inbound routing is a separate setup and the third guide covers it explicitly.

MailKite credentials and verification are independent; moving a workload means deliberately choosing the transport and mapping feedback/suppression behavior, not replacing the key in an unchanged Elastic Email request.