Authenticate an Omnisend sender domain by publishing the SPF, DKIM and DMARC configuration shown for that domain, completing verification, and assigning the verified domain to the intended email workflows. The final check must use real campaign, automation or double-opt-in mail: Omnisend's test emails use its shared domain, so a preview test cannot demonstrate custom-domain authentication. Omnisend sender-domain guide.
Plan the domain and the sending workflows
This guide covers Omnisend email, not branded SMS links or mail sent independently by your online store or employee mailbox provider. Domain signing is available without an additional signing fee to all Omnisend users. The documented setup does not publish a universal region-specific record set; your account-generated records govern. Omnisend authentication overview.
Decide which domain each stream should use before opening DNS. For example, a business might plan separate campaigns.example.com and automations.example.com identities, with double opt-in assigned deliberately to one of them. These are planning examples, not prescribed hostnames. Separate names can make reports easier to interpret; they do not automatically isolate every aspect of reputation.
Create a three-row worksheet: campaigns, automations and double opt-in. For each row record the intended domain, From address, owner and controlled recipient for later testing. Include the live automations that could send while setup is in progress. Treat a domain change as a production change, not just a branding preference.
Identify the authoritative DNS host, which may differ from the registrar or store platform. Export existing records, including root-domain SPF, DKIM selectors, DMARC and inbound MX. Keep the export with the proposed changes. Do not delete employee-mail records simply because the marketing platform gives you a fresh setup list.
Obtain the current records in Omnisend
Go to Store settings → Domains → Add domain, choose Email, select your DNS provider and enter the exact domain or subdomain. Open its setup page to obtain the records. Do not reuse selectors, keys or ownership tokens from another brand. Current setup route.
For each generated row, record its purpose, type, full DNS owner and exact value. The SPF row authorizes infrastructure, DKIM publishes public verification material, and DMARC establishes policy for the visible sender domain. They are not interchangeable fields. A private signing key must never be entered in public DNS.
If an existing Omnisend or Mailgun association triggers an ownership-claim flow, review the presented proof record and the existing relationship before proceeding. Proving control is not permission to break another brand's active sending configuration. Coordinate with the account owner rather than repeatedly deleting and re-adding the domain. Domain association warning.
Publish SPF and DKIM without replacing other senders
Follow the type and value shown in the account. Current Omnisend instructions describe TXT-based authentication; an include shown in a third-party article is not a substitute for your current setup screen. Match the exact configured domain level. SPF published at example.com is not automatically the SPF policy for campaigns.example.com. Omnisend record guidance.
If the specified owner already has a TXT record beginning v=spf1, preserve it and incorporate only the required authorization into that single policy. Put new mechanisms before its terminal ~all or -all; do not paste two complete SPF policies together. Preserve every still-authorized sender and review the ten DNS-lookup-term limit, including nested includes. Do not add arbitrary IP addresses or replace the entire policy with a sample from another business. SPF rules.
If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.
A DKIM record belongs at the generated selector owner, not at @. For an illustrative full owner SELECTOR._domainkey.campaigns.example.com, a DNS zone for example.com may require SELECTOR._domainkey.campaigns in its Name field. In a separately delegated campaigns.example.com zone, the relative name would instead be SELECTOR._domainkey. Replace SELECTOR with the exact generated selector and inspect the saved full name.
For that same full owner at an existing delegated _domainkey.campaigns.example.com authority, the relative name is SELECTOR. Use the actual issued selector, preserve existing NS delegation and other selectors, and publish the TXT key at the actual authority. Relative DNS names.
Paste the complete public key. Do not trim punctuation, shorten the key or create separate TXT records for its pieces. Some DNS hosts represent a long TXT value as several quoted strings within one record; that is different from publishing competing records. DKIM verification uses the selector and signing domain to locate the corresponding key. DKIM specification.
Preserve unrelated TXT verification tokens. Where a proposed owner already has a CNAME, stop and resolve the conflict rather than adding TXT alongside it. CNAME owners generally cannot host other record data. DNS alias constraint.
Add DMARC only after checking existing policy
Omnisend requires valid authentication records for domain verification and describes relaxed alignment and a monitoring policy as an onboarding configuration. That does not authorize weakening an established organization-wide policy. Omnisend SPF, DKIM and DMARC guidance.
Before creating anything, inspect TXT at the exact From domain's DMARC owner and applicable parent policy. For news@campaigns.example.com, begin with _dmarc.campaigns.example.com and inspect _dmarc.example.com as part of the policy review. An absent child record does not mean the domain is unprotected. Preserve existing enforcement, alignment settings and reporting recipients unless the security owner approves a specific change.
For a new organizational domain with no established or inherited policy to weaken, the following is an illustrative monitoring record:
- DNS zone:
example.com. - Type:
TXT. - Name:
_dmarc. - Value:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. - TTL: your DNS host's default or an approved change-window value.
Replace the domain and reporting mailbox. The mailbox must exist, be monitored and be approved to receive authentication reports. Keep the semicolon separators and publish only one policy at that owner. For an external report-processing service, use its actual destination and complete its external-destination authorization. DMARC aggregate reporting.
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.
DMARC succeeds through either passing aligned SPF or passing aligned DKIM. Relaxed alignment compares organizational domains; strict alignment requires an exact match. RFC 9989 is the current DMARC standard replacing RFC 7489, and it removes pct. Do not introduce that retired tag as a gradual-enforcement mechanism. Current DMARC standard.
Monitoring gathers evidence rather than protecting the domain through enforcement. Assess all approved senders before later tightening policy. EmailAuth's domain assessment is a related starting point for that broader review, not a replacement for the Omnisend workflow checks below.
Finish verification and inspect domain usage
Return to Omnisend and use Finish verification. Review the campaigns, automations and double-opt-in selections: all three are initially selected, and chosen areas switch when verification completes. Choose Use one address for campaigns and automations or Use different addresses for campaigns and automations, enter the corresponding sender address or addresses, and click Confirm & finish. Later, inspect Store settings → Domains → Domain usage rather than assuming a verified domain is assigned everywhere. Verification and domain usage.
This is the point where the preparation worksheet prevents surprises. If campaigns and automations need different domains, do not leave a broad selection merely to finish onboarding quickly. Review assignments with the owner of active flows and check which messages could be triggered immediately after activation.
Record account status separately from DNS status. A provider verification indicator answers whether its checks accepted the configuration. It does not show which recipient validated a message or whether an old automation still uses a different From address.
Validate public DNS and production-path mail
Use your generated owner names in these read-only command examples. They are not actual results:
dig +short TXT campaigns.example.com
dig +short TXT SELECTOR._domainkey.campaigns.example.com
dig +short TXT _dmarc.campaigns.example.com
dig +short TXT _dmarc.example.com
Expect one SPF policy at the relevant SPF owner and the complete generated key at the DKIM owner. DMARC should show the intended direct policy or a correctly evaluated inherited policy. A missing child response alone is not a DMARC failure. If public and authoritative answers disagree, record their timestamps and TTLs before diagnosing propagation. If both show the wrong name or value, correct the entry rather than waiting blindly.
After verification and assignment, arrange a narrowly scoped real send to controlled recipients for each workflow you use. For double opt-in, use a controlled subscription path without enrolling unrelated people. Do not substitute Omnisend's preview test for this exercise; its shared-domain behavior is explicitly different from custom-domain production sending.
At the recipient, inspect the trusted receiving service's Authentication-Results. Record the visible From domain, smtp.mailfrom, header.d, selector, spf, dkim and dmarc verdicts. For the branded-domain setup, require dkim=pass with the expected branded signing domain aligned to visible From, plus dmarc=pass. Investigate any unexpected SPF or DKIM failure independently; a DMARC pass carried by SPF alone does not prove that branded DKIM is working. Ignore forged or untrusted copies of authentication headers. Receiver authentication-result handling.
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.
Keep campaign and automation evidence separately. A useful acceptance record includes the send identifier, workflow, date, intended domain, observed domain and receiver verdict. This makes a later domain-usage regression distinguishable from a DNS fault.
Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.
Diagnose the failed layer first
- Preview still shows a shared domain: repeat with an authorized real campaign or workflow, not another preview.
- Campaign passes but automation differs: inspect the assignment and sender address for that stream before editing DNS.
- SPF is missing: compare the root/subdomain level and the DNS editor's saved owner; a correct value at the wrong name remains ineffective.
- DKIM is not found: compare the selector and suffix. Check for accidentally repeated domain names or a truncated key.
- SPF passes but DMARC fails: a passing envelope domain may not align with visible From. Inspect DKIM alignment and the applicable policy.
- Verification stalls: compare the account-requested values with public DNS. Omnisend allows up to 48 hours in its guidance, but elapsed time does not prove correct publication. Verification troubleshooting.
Pause only the affected sends while investigating. Do not delete shared DNS records or replace an enforcement policy with monitoring as a universal fix. Preserve evidence before an account reassignment or provider-support escalation.