Map accounts to the sending domain
Emma authentication combines domain-level DNS with an account-specific verification step. Start by listing each account or subaccount that will send from the domain, its owner and intended default sender email. The same domain appearing in two campaign accounts does not make their verification tokens interchangeable.
The provider's DKIM setup guide directs users to make the default sender email match the domain being authenticated. Confirm that setting before DNS work. Otherwise, the administrator can configure one domain successfully while the campaign owner continues to send with another identity.
Publish the domain records and account proof
Emma documents three DKIM CNAME records, using the e2ma-k1, e2ma-k2 and e2ma-k3 selectors under _domainkey and corresponding targets under dkim.e2ma.net. Retrieve the current values from the provider instructions when implementing and use the DNS host's correct owner-name syntax. This guide does not supply a private account configuration or assert that existing records have been tested.
The workflow also requires a TXT value beginning e2ma-verification= with the account's own validation hash. Find that hash in Account > Deliverability for the correct account context. Emma states that each account or subaccount has a unique hash and that tiered accounts require separate TXT verification records for the relevant subaccounts. Do not replace another active account's verification record simply because it shares the domain.
Unlike SPF, where multiple candidate policies at one owner cause an error, unrelated domain-verification TXT values can coexist. Keep the purpose of each TXT record explicit so a cleanup operation does not remove proof needed by another campaign account. Never infer that any TXT value beginning with a different service's token is an obsolete SPF record.
Verify names without damaging existing selectors
Before publication, inspect the actual authoritative DNS service and existing record owners. A registrar login may not control the live zone. At each selector, compare the existing record type and destination with the approved change. A CNAME cannot be combined with ordinary competing data at that same owner, so resolve a collision rather than forcing two providers onto one selector name.
After saving, check the complete public owner and target. Relative-label editors and fully qualified input formats differ; a duplicated domain suffix can make a visually plausible record useless. Complete Emma's final validation in the correct account and keep the status for each subaccount separately. The source describes the workflow, but it does not establish that your own DNS or account has passed it.
Exercise the actual campaign identity
Original verification worksheet: one row per account/subaccount, with default sender domain, token owner, selector answers, final validation status and controlled-message evidence. Send a harmless campaign to a controlled mailbox through each materially different account path. Avoid customer addresses and production audiences during testing.
Capture the receiver's DKIM result, signing domain and selector alongside the visible From domain and envelope sender. A valid signature proves verification under its signing domain; DMARC additionally requires alignment with From for that authentication path. The TXT ownership token is not the key used to verify the message signature, and checking it alone cannot settle alignment.
Illustrative scenario: a parent account validates successfully, while a subaccount still has the parent's hash entered as its own verification proof. The correct next step is to retrieve the subaccount's distinct value and validate that account, not regenerate all three domain CNAMEs without evidence of a DNS defect.
Retain a recoverable account inventory
Save pre-change settings and records. If validation fails, pause the affected campaign and identify whether the default sender, account token or public selector is wrong. Restore only the affected configuration after checking dependencies. Keep other accounts' valid tokens and selectors intact.
Recheck when adding a subaccount, changing the default sender or migrating DNS. Documentation was reviewed on 8 November 2026. The worksheet and scenario are original examples; no Emma account, public record or delivered campaign was tested here.
Use a two-account completion ledger
Written case EM-01 assumes Parent and Events both intend From news@example.com. Parent has its own verification token and completed final validation. Events mistakenly references Parent’s token; its own token and final validation remain missing. The three domain CNAMEs are stipulated correct in this example, not queried. Keep Parent’s working token, retrieve Events’ account-specific value and complete validation in Events. Do not regenerate shared selectors to repair a missing account proof. Message authentication for Events remains unknown until a controlled campaign is inspected. No token was collected or published and no campaign was sent.
The current provider guide limits each account or subaccount to one authenticated domain. If Events instead needs news@other.example, record that separate identity and account choice before replacing a working setup. A parent account’s domain success does not remove this product limit.
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.