Omnisend SPF and DKIM setup

What you are setting up

Omnisend is an ecommerce email and SMS platform, and until you verify a custom sender domain every campaign and automation leaves on Omnisend's shared domain. Signing your own domain is free on every plan. Omnisend delivers through Mailgun (its help center talks about domains “previously authenticated through Mailgun,” and every SPF example it publishes uses the Mailgun include), so the records you publish are Mailgun-shaped: one SPF TXT, one DKIM TXT with an account-specific selector, and a basic DMARC TXT. Omnisend recommends your store domain for campaigns and a subdomain such as news.yourdomain.com for automations; each one is added and verified on its own.

Publish SPF and DKIM

In Omnisend, go to Store settings > Domains and click + Add domain. Choose Email, pick your DNS provider (or “I don't know”), enter the exact domain or subdomain you will send from, and click Continue. The Domain setup page then lists the SPF, DKIM, and DMARC records with provider-specific instructions. The shape is:

Type:  TXT     (SPF)
Host:  @       (or just the subdomain label, e.g. news)
Value: v=spf1 include:mailgun.org ~all

Type:  TXT     (DKIM)
Host:  <selector>._domainkey      (Omnisend shows the full name, ending in your domain)
Value: (the public key shown on the Domain setup page)

Type:  TXT     (DMARC)
Host:  _dmarc
Value: (the basic record Omnisend generates)

Copy the values from your own Domain setup page rather than from this article; the include above is the one Omnisend's documentation uses in every example, but the DKIM selector is specific to your account and Omnisend does not publish it. If your domain already has an SPF record, do not add a second one. Omnisend generates a merged value for you (it can stop doing so if you already have more than two SPF records or a syntax error), so publish the merged record and delete the old one. Omnisend's verifier names the two SPF failures it sees most, Multiple SPF Records Found and Too Many DNS Lookups, and its suggested escape from the ten-lookup limit is to sign a subdomain for Omnisend instead.

Once the records are in, click Finish verification. Leave Email campaigns and Email automations selected so the domain is applied automatically when it verifies, enter a sender email address on that same domain, and click Confirm & finish. The status moves to In progress and Omnisend emails you when it lands on Verified or Unverified; it usually takes about 30 minutes and can take up to 48 hours. To come back to the records later, go to Store settings > Domains, click the three dots next to the domain, and choose Open DNS records, where a Check verification manually button re-runs the check.

Add DMARC

Omnisend hands you a basic _dmarc record during setup and advises p=none with relaxed alignment, which is the right place to start. If you already have one, keep it; a domain has one DMARC record, and Omnisend only needs it to be valid. Standard shape, nothing Omnisend-specific:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Build it with our DMARC builder and progress past p=none once your reports are clean. Two Omnisend notes: if the DMARC check fails, Omnisend's own fix is to try the host as _dmarc instead of _dmarc.yourdomain.com (some DNS hosts append the domain), and a subdomain such as news.yourdomain.com inherits the root domain's DMARC record, so you do not publish a second one for it.

The Omnisend gotcha

“Verified” is a low bar. Omnisend states that a domain verifies when at least one of SPF, DKIM, or DMARC is valid. That means a domain with only a DMARC record can show as Verified while none of its Omnisend mail is authenticated as you, and under p=none nothing will complain except your DMARC reports. Open the Domain setup page and make sure none of the three records is marked Not Found before you treat the domain as done. Omnisend does not document a custom return-path or bounce domain either, so plan for DKIM (the signature showing d=yourdomain.com) to carry alignment, and check the Return-Path header on a real send rather than assuming SPF aligns.

The sender address must sit on the exact verified domain. Root and subdomain are separate in Omnisend: verify mail.yourdomain.com and your sender email has to be hello@mail.yourdomain.com, not hello@yourdomain.com. A mismatch is what makes Outlook show “on behalf of,” and it is also what keeps your DMARC reports from crediting the domain you authenticated. The sender address lives in Store settings > Email addresses, one screen away from the domain. Two more sources of confusion: test emails always go out on Omnisend's shared domain and cannot be assigned to your custom one, and Omnisend's domain warm-up feature keeps part of your volume on the shared domain until you turn it off. Neither will appear in your DMARC reports as your domain, so a quieter-than-expected Omnisend row is not necessarily a failure.

Confirm it worked

• Check the Domains page. The domain should read Verified, and on the Domain setup page all three of SPF, DKIM, and DMARC should show as found, not just one. Then confirm it is selected under Domain usage for both campaigns and automations.
• Send a real campaign and read the headers. Not a test send, which uses the shared domain. Open the message at the other end and confirm the DKIM signature shows d=yourdomain.com with the selector Omnisend gave you, and the result is dmarc=pass. Our header analyzer reads it back plainly.
• Watch the reports. Omnisend should appear as an aligned, passing source in your DMARC aggregate reports, delivered from Mailgun infrastructure and labeled as a known sender in trustyourinbox. If it shows as passing SPF only for a domain that is not yours, the sender address and the verified domain do not match.