Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Authenticate the exact Omnisend sender domain
In Omnisend, begin with the exact domain or subdomain that will appear in the sender address. A verified root domain and a separately configured sending subdomain are not interchangeable account entries. Record the store or brand, intended sender address and the message classes that will use it. The current setup guide distinguishes **Email Campaigns, Email Automations and Double opt-in** in domain usage. Omnisend sender-domain setup.
This guide covers sender-domain authentication. A link domain for tracked URLs, a connected ecommerce store and an SMS identity are separate configurations. Their successful setup does not establish that a campaign has aligned email authentication. Keep the scope narrow enough to test: one store, one sender domain and identified workflows.
Before changing the domain, inventory active campaigns and automations. Determine whether a welcome sequence, abandoned-cart message or confirmation flow could send while verification or assignment changes are underway. Select controlled test recipients and avoid triggering purchases, customer notices or subscription changes merely to obtain a message sample. Record the current domain assignments and approved rollback plan.
The provider documentation describes shared-domain sending before a custom sender domain is verified. Do not infer the exact identities of a particular account from that general description. Capture a baseline original message and document what the account actually sends today. Tenant settings, live DNS and received-message behavior have not been inspected for this article.
Generate the account records and review the intended change
The documented setup begins in Store settings → Domains with an email-domain addition. Enter the exact sender domain, identify the DNS provider and obtain the account's SPF, DKIM and DMARC instructions. Preserve the record names, types, values and generation date. Do not turn a provider example into a universal DNS template.
If Omnisend reports that the domain is connected to another account, brand or previous service configuration, use the supported ownership-resolution process. Establish which active account owns the existing use before proceeding. A DNS ownership proof may demonstrate control of a domain, but it does not by itself establish that taking over a live configuration is an approved business change. Record the owner, dependencies and migration decision.
Review the DNS zone before publishing. Identify the authoritative nameservers, existing sender permissions, DKIM selectors and DMARC policy. The organization may already have a stronger domain policy than an onboarding example. Do not replace that policy with a weaker one simply to make a setup screen look consistent. Likewise, do not add a second DMARC policy at the same owner or create another SPF record alongside the existing one.
Treat automatic DNS authorization, if offered by the actual setup flow, as a separate access decision. Review the requested permissions and proposed changes through the organization's normal approval process. Manual instructions still require exact name handling: a DNS editor may append the zone automatically, so compare the final fully qualified owner rather than copying a displayed hostname blindly.
Publish SPF and DKIM without disturbing other senders
For SPF, use the account-provided authorization at the exact owner required for the selected route. If a policy already exists, preserve still-needed services within one valid policy. Omnisend's troubleshooting guide identifies duplicate SPF policies and excessive lookup use as verification failures. It can propose a merge in some cases, but that proposed text still needs review against the real zone and legitimate dependencies. Omnisend SPF troubleshooting.
Evaluate the complete SPF path, including nested includes and other DNS-querying terms. The limit is not a simple count of records shown in a control panel, and a short top-level policy can still exceed it. Do not remove a service solely to make the number smaller until its owner confirms that it no longer sends using this identity. Do not add or copy MX records as a generic cure for SPF lookup exhaustion; MX controls mail routing and must have a separately verified purpose. RFC 7208, DNS lookup limits.
For DKIM, copy only the current account's public record instructions. Preserve the supplied selector, record type and value, and check for a conflicting record at the owner. The provider's guidance calls out DNS-editor differences, including domain suffix duplication. Verify the final authoritative hostname and value before repeatedly requesting verification. If the value is a public key, keep it intact; a private key must never be published or placed in the review bundle.
Once the expected public records are visible, return to Omnisend's verification flow. The provider can show which required record failed and why. A waiting status is not evidence that the setup is correct, and elapsed time alone is not a diagnosis. Check the authoritative answer, the name and the intended domain level before assuming propagation is the only problem. Omnisend authentication guidance.
Reconcile DMARC policy and finish domain verification
Review the applicable DMARC policy with the mail-security owner. Preserve approved reporting destinations and enforcement intent. Determine whether the exact sender domain has its own policy or relies on applicable organizational-domain policy, then reconcile that with Omnisend's current verification requirement. If the setup requests a record that conflicts with the existing design, resolve the conflict rather than silently overwriting it.
Omnisend's detailed setup guide says the domain cannot be selected for sending when any required authentication record fails validation. Use the actual record-specific status in the tenant as the operational requirement. Do not interpret ambiguous shorthand elsewhere as permission to leave an explicitly required record unverified.
The protocol acceptance test remains distinct from the provider's setup status. DMARC requires a passing SPF or DKIM identity that aligns with the visible From domain under the applicable alignment mode. It does not require both paths to align, and a passing policy check does not guarantee inbox placement. RFC 9989, identifier alignment and evaluation.
Record the provider verification outcome and a separate received-message result. That distinction helps when the account shows Verified but a workflow still uses another domain, or when a receiver reports a valid aligned signature but the account has a missing administrative setup requirement.
Assign and test campaigns automations and double opt in
Verification and usage are separate decisions. Omnisend's setup guide says selected message classes can receive the new domain automatically after verification; if selection was skipped, the domain must be assigned under Domain usage. Plan that timing carefully because an active automation may begin using the new identity as soon as assignment takes effect. Omnisend domain usage.
Confirm the sender email address for each class and ensure it matches the authenticated domain entry. Omnisend explicitly states that test emails always use its shared domain and cannot be assigned a custom domain. The product’s test-email feature therefore cannot validate custom-domain assignment or alignment. Omnisend sender-domain setup.
To validate the custom domain, use a representative actual campaign, automation and double opt-in workflow where each is in scope. Use controlled recipients and genuine workflow triggers only where safe and authorized. Preserve the received originals and record whether the expected domain was actually used; label test-email samples separately so their shared-domain identity is not mistaken for a production assignment failure.
Keep authentication acceptance separate from volume ramp-up. The provider recommends warming a newly assigned domain before high-volume sending. Plan a gradual, approved rollout and monitor engagement and delivery separately. DNS verification does not erase a poor list, complaints or a sudden change in sending volume, and it cannot promise a particular inbox tab or folder.
Complete the Omnisend store worksheet
This worksheet is a proposed procedure, not evidence of completed testing.
- Store and domain: account or brand, exact domain entry, intended sender addresses and active workflow owners.
- Existing state: current campaign, automation and double-opt-in assignments; existing DNS; and any domain ownership conflict.
- Record plan: account-generated owner/type/value for SPF, DKIM and DMARC, purpose, authoritative zone and saved prior configuration.
- DNS review: single SPF policy, complete lookup evaluation, selector conflicts, suffix handling and preserved DMARC intent.
- Verification: status and explanation for each required record, verification time and remaining provider errors.
- Workflow samples: one controlled message per selected class, UTC time, message identifier and observed delivery outcome.
- Authentication: visible From, envelope domain, every DKIM d and s pair, trusted receiver results and the passing aligned path.
- Release: domain assignments confirmed, rollout limits, rollback owner, unresolved tests and human approval.
DKIM verification must relate to the actual received message. A domain lookup shows the public key or delegation; the receiver's signature result establishes whether that message verified. Record both pieces without treating either as a substitute for the other. RFC 6376, DKIM verification.
Diagnose a fictional automation that retained the old domain
**Fictional illustration only. No Omnisend store, DNS zone or message was tested.** A store verifies news@maplemarket.example's sender domain and assigns it to campaigns. Its imagined campaign has a passing aligned DKIM signature. An active welcome automation still uses a different domain because its usage assignment was not updated.
The campaign's success does not prove the automation uses the new route. First compare domain usage and the automation's sender address with the received original. If the automation's old identity authenticates successfully, the issue may be incomplete assignment rather than broken DNS. If it uses the intended From domain but signs only with an unrelated domain, inspect the actual domain configuration and signing route.
Adding another SPF record would not address an assignment error and could create a new failure. Correct the approved assignment, trigger a new controlled automation and inspect its identities. The example domains are fictional and establish no facts about Omnisend's actual envelope or signing infrastructure.
Recover the affected workflows and retain the evidence
If verification fails, leave the rollout pending while correcting the specific record problem. If a new assignment causes an operational issue, use the approved previous verified assignment where it remains available, or pause the affected workflow through its owner. Do not delete the old configuration until active dependencies and queued messages have been considered.
Keep the completed worksheet, sanitized message evidence and change approval together. This manuscript remains unpublished, with tenant inspection, authoritative DNS validation, actual message tests, visual review and human subject-matter approval pending. Release only the message classes whose assignments and aligned authentication have been demonstrated; untested automations and double-opt-in flows remain explicit exceptions.