Wix Email Marketing SPF, DKIM and DMARC setup, step by step

To authenticate Wix Email Marketing, confirm your sender address, open the domain-authentication instructions, and publish the CNAME records generated for that sender. Preserve your existing mail records: this workflow does not justify adding a guessed SPF include or replacing a working DMARC policy. Completion requires both Wix's domain status and a newly delivered message with the intended authenticated identities.

This guide covers the Email Marketing service associated with Ascend by Wix. It does not configure Google Workspace mailboxes purchased through Wix, every Wix transactional notification, or an unrelated sender whose DNS happens to be hosted at Wix. Wix's Ascend product overview lists Email Marketing as one component; Wix's email-type documentation distinguishes campaigns and automations from business-transactional messages.

On this page: Before you start · SPF and identity · Setup · Existing DMARC · Validation · Troubleshooting · FAQs

Before you start

Have access to the correct site's Email Marketing dashboard, the sender mailbox, and the authoritative DNS zone. Save the current DNS configuration before editing it. Inventory your other senders, such as employee mail, invoices and support notifications, especially if they share the same From domain.

Determine who actually hosts DNS:

Automatic setup can need attention if the sender was configured before the domain was connected. Wix's recovery path is Email Marketing → Manage Senders → View DNS records. For Wix-hosted DNS, use Domains → Domain Actions → Manage DNS records, add a record, and save before entering the next one. Do not move nameservers merely to authenticate email. Wix's authentication troubleshooting instructions.

What SPF and DKIM authenticate

Three identities matter independently:

The Reply-To address routes replies. It is not the SPF identity, and matching it to your brand does not establish DMARC alignment. SPF evaluates the SMTP identity, not simply the visible From address. SPF specification, RFC 7208.

Is there a universal Wix SPF record?

Do not build one from this guide. The documented Email Marketing setup uses account-generated authentication CNAMEs. Wix also describes campaign infrastructure involving sendgrid.net and ascendbywix.com; those names are context, not instructions to invent an include: or copy someone else's targets. Wix's campaign deliverability documentation.

For an existing SPF policy, retain authorization for legitimate non-Wix senders. Do not create a second v=spf1 TXT record at the same owner. An SPF record at example.com does not automatically authorize mail using bounce.example.com as its envelope domain. Likewise, an apex change cannot turn a provider-owned envelope identity into your own domain.

The public Wix setup instructions do not establish one fixed Return-Path for every account and campaign. Verify the actual envelope and signing domain after setup rather than promise aligned SPF before seeing a message.

Authenticate the Wix sender domain

1. Open Email Marketing in the site's dashboard, then Sender Details → Manage Senders. Use the edit option for an existing sender.
2. Supply the sender name and custom-domain reply-to address, then save.
3. Retrieve the confirmation code from that mailbox and confirm the address.
4. For a domain showing Not authenticated, select Authenticate this domain.
5. Keep the generated CNAME list available. Review existing records, including the DMARC collision check below, before publishing each host/target pair at authoritative DNS.
6. Allow propagation, then refresh Sender Details and inspect Domain status. Wix advises allowing up to 24 hours.

Mailbox confirmation and domain authentication are separate checks. The code does not install DNS records. Wix's current custom-domain authentication instructions.

Enter CNAME owners accurately

Use the record type and paired target from the current account. Do not substitute a TXT public key for a requested CNAME. A DKIM CNAME delegates key lookup; Wix's destination supplies the verification data.

Suppose the dashboard supplies a DKIM owner shaped like selector._domainkey.news.example.com. This is an illustrative name, not a Wix value:

An editor accepting fully qualified names may instead accept the complete owner. Inspect the saved name; it must not end in example.com.example.com. Preserve underscores, selector spelling and target pairing.

Authentication CNAMEs need ordinary DNS answers. Keep them DNS-only where an HTTP proxy is offered. Check zone-wide CNAME flattening as well as the individual record setting: a proxy or flattening option can hide the CNAME the verifier expects. A CNAME owner cannot also hold ordinary TXT, MX or another conflicting record. Resolve collisions with the current record's owner rather than deleting an entry that may serve another system. DNS alias constraints, RFC 2181 section 10.1.

Handle the fifth CNAME without weakening DMARC

Wix identifies CNAME 5 as the record that automatically sets up DMARC. Treat it as a policy-management decision, not merely another DKIM selector. Its destination can determine the effective policy and reporting configuration. Do not assume its policy, reporting addresses or enforcement strength from its row number.

Before adding it:

• Look up both TXT and CNAME at _dmarc under the intended From domain.
• Inspect any existing delegated target and its effective TXT policy.
• If the sender is a subdomain, inspect the applicable inherited policy as well. No local record does not necessarily mean no DMARC protection.
• Record the existing enforcement and reporting arrangement, including alignment settings and subdomain policy.

If an existing DMARC TXT or another DMARC CNAME conflicts, stop that change. Do not publish both, silently remove the current policy, or replace quarantine/reject protection with monitoring just to satisfy a setup screen. Have the domain's mail/security owner and Wix resolve the supported configuration. A new dedicated sending subdomain can be considered, but it is not automatically exempt from its parent's policy.

DMARC passes when at least one successful SPF or DKIM result aligns with the visible From domain. Relaxed alignment uses the same organizational domain; strict alignment requires identical domains. A passing provider-domain signature can therefore be insufficient for your branded From address. Current policy discovery and alignment are defined by RFC 9989.

For aggregate reporting, use a mailbox or reporting service your organization has authorized. An external reporting destination may need a DNS authorization record controlled by that destination. Merely inserting a rua address does not establish that permission. DMARC aggregate reporting and external-destination authorization, RFC 9990.

Review reports across all legitimate sending systems before changing enforcement. Authentication is not a delivery guarantee, and p=none does not guarantee acceptance.

Verify DNS, Wix status and a delivered campaign

1. Check the published owners

Replace these illustrative names with the actual dashboard owners. These are read-only queries, not records to publish:

dig +short NS example.com
dig +short CNAME selector._domainkey.news.example.com
dig +short TXT selector._domainkey.news.example.com
dig +short CNAME _dmarc.news.example.com
dig +short TXT _dmarc.news.example.com
dig +short TXT _dmarc.example.com

Query each generated CNAME, not only the first DKIM row. Compare an authoritative answer with a recursive/public resolver when troubleshooting cached results. Follow each target to its final data; an alias existing without a usable destination is not enough. If the sending subdomain is delegated, use that zone's nameservers.

2. Confirm Wix recognizes the same domain

Refresh the sender view. Verify that the authenticated domain belongs to the sender and site you intend to use. A screenshot from another account, a previous sender or an old configuration is not acceptance evidence.

3. Inspect a new delivered message

After authorization to send a test, send through the actual Wix Email Marketing campaign path to a mailbox you control. Inspect the original message at the receiving service. If a preview/test path uses different identities, also validate the intended production campaign path with an authorized limited send.

Use the receiver's own trusted Authentication-Results, not an arbitrary earlier header that a sender could have inserted. RFC 8601 explains that trust boundary.

Record:

• The delivered From domain. Confirm it is the intended brand, not a fallback domain.
• spf=pass and the actual smtp.mailfrom. Determine its alignment separately.
• A successful DKIM signature with header.d/d= aligned to the intended From domain, plus its s= selector.
• dmarc=pass for the intended header.from, and the mechanism that supplied alignment.

A useful acceptance result is an authenticated Wix domain, all required DNS answers matching, and a fresh campaign with the intended aligned DKIM signature and DMARC pass. If SPF passes for a non-aligned provider envelope, document that accurately instead of claiming both mechanisms align. Follow-up aggregate reports should corroborate the production route over time.

Troubleshooting

Distinguish SPF errors from a non-aligned pass

An SPF pass for a provider envelope can be valid but unaligned with your From domain. That differs from an SPF failure:

• fail or softfail: the evaluated policy did not authorize the observed outbound IP. Check the actual envelope domain and route, not just your root-domain TXT.
• none: no usable SPF policy was found for the evaluated identity.
• permerror: inspect invalid syntax, multiple SPF records and excessive DNS-lookup-causing terms.
• temperror: investigate temporary DNS failures and retry the check after the underlying service recovers.

Where you control the evaluated SPF policy, keep it to one record and at most ten DNS-lookup-causing terms across the evaluation, including nested includes. For a Wix/provider-owned envelope or delegated provider target, take the failing identity, source IP, timestamp and receiver result to Wix; adding an apex include is not the repair. RFC 7208 SPF processing limits.

Documentation review and testing boundary

This is a documentary setup guide. No signed-in Wix account, customer-specific CNAME values, DNS changes or test campaigns were used to validate an implementation. Use current account-generated values and perform the acceptance checks before relying on the setup.