Resolve account ownership before DNS
This guide concerns sender domains in Elastic Email Marketing and Email API, not receiving mail through its Inbox product. Begin with the intended account, sending domain, application owner and authoritative DNS administrator. Confirm which account currently owns the domain before generating a new deployment plan.
Elastic Email's domain-verification guide says a sender domain can be associated with only one Email Marketing or Email API account at a time. If another account holds it, resolve that ownership first. An administrator should not delete a production domain from an old account without identifying the applications that still send through it. Where access is unavailable or the account cannot remove it, follow the provider's support and ownership-verification process.
Use the account's verification workflow
The documented path is Settings > Domains > Manage Domains > Start Verification. Select domain verification, enter the domain you own, publish the presented records and use Verify record. In the domain details, inspect individual record statuses rather than treating the overall list entry as proof that every optional feature works.
For SPF, the provider identifies include:_spf.elasticemail.com. Integrate the necessary authorization into the existing applicable SPF TXT policy instead of creating a second one. Review the whole policy, including other authorized services and DNS lookup cost. Do not copy broad a or mx mechanisms from an example unless they match the domain's intended authorization.
For DKIM, use the Name and Value shown in the account's current DKIM section. Elastic Email generates the keypair and publishes the public component through your DNS TXT record. An old tutorial's selector or public key is not a substitute. If the service reports that valid DKIM is not found, compare the authoritative answer with the current account value before changing unrelated records.
Treat default-sender behavior as a policy choice
The provider describes fallback branding based on whether a default sender domain exists and notes that subaccounts can inherit use of the main account's default verified sender domain. Record which default is selected and whether that inheritance is appropriate for the applications using the account. Domain verification and application authorization are not the same administrative decision.
Do not rely on fallback behavior to make an unapproved From domain acceptable. Require each production application to use its approved identity and test what is actually delivered. A platform can successfully send a message using an unexpected domain, which is operationally different from completing the intended custom-domain setup.
Separate tracking and mail routing from signing
The domain details also expose tracking, MX and DMARC status. Review each record's purpose before publication. A tracking CNAME concerns link behavior; a sender-domain MX instruction is not blanket permission to replace the organization's inbox routing. Preserve the current domain-wide DMARC policy unless its owner approves a deliberate change based on all legitimate senders.
Original test design: use a harmless application message and, where relevant, one subaccount test. Record the requested From identity, selected account/default, actual received From, envelope sender, DKIM domain and selector, and receiver authentication results. DMARC requires a passing SPF or DKIM result aligned with the visible From. Compare the intended identity with the received identity before deciding whether fallback is acceptable.
Diagnose and recover at the failing layer
Illustrative scenario: DNS exactly matches the new account's key, but a legacy application still submits through a different account. Replacing the same public key repeatedly will not fix that routing mismatch. Confirm the application's account and domain association, then choose an approved migration or restoration path.
Save prior settings and records. Pause the affected application during an unresolved ownership or identity problem and restore the last approved configuration where feasible. Recheck after account migration, default-domain changes or key replacement. Documentation was reviewed on 8 November 2026; no account, DNS record or received message was tested here.
Decide the account move before regenerating keys
Written case EE-01 assumes receipts@example.com belongs to an active receipt application in account Old, while a new team tries to verify example.com in account New. The new account reports an ownership conflict; current DNS and message results are unknown. The application owner must inventory Old before approving a coordinated transfer. Removing the domain only to clear New’s warning risks the existing route. The operator should resolve access or follow the provider’s ownership-verification support process, preserving the exact current configuration and a recovery decision. No account removal, support contact or DNS change occurred here. After an approved transfer, require a controlled receipt with the intended From and actual signing identity, not merely a verified-domain badge.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.