How do I properly set up a DMARC record on Wix and when should I change the policy?
Updated on 9 Oct 2026: We clarified Wix's CNAME-based DMARC setup and the checks needed before changing your policy.
For a manual Wix DMARC setup, add a TXT record with Host Name _dmarc and a value that starts with v=DMARC1. If you put v=DMARC1; p=none; at the root domain, it is published at the wrong DNS name. A blank host denotes the root in Wix; DMARC receivers query _dmarc.example.com. Check for an existing TXT record or CNAME delegation at that host before adding anything.
Start at p=none and collect aggregate reports with rua. Move to p=quarantine when every authorized sender passes DMARC through SPF or DKIM with the required domain alignment. Consider p=reject only after quarantine has run cleanly and mailing-list use has been assessed.
Add a DMARC TXT record in Wix
For manual setup when Wix hosts your authoritative DNS, the DMARC record belongs under TXT records for the domain. The Host Name must be _dmarc. The Value must be the DMARC policy string. The full DNS name created by Wix will be _dmarc.example.com, not example.com. Wix appends your domain, so enter only _dmarc in this field.
The Wix path is Domains, then Domain Actions beside your domain, then Manage DNS records, then TXT (Text), then + Add Record. Enter the Host Name and Value, leave TTL at its default, click Save, and confirm Save Changes. These steps follow Wix's DNS instructions. The Wix deliverability note says high-volume senders need SPF and DKIM plus DMARC. DMARC uses their results and checks domain alignment; it does not replace either authentication method.
|
|
|
|---|---|---|
Type | TXT | Text DNS record |
Host Name | _dmarc | DMARC subdomain |
Value | Policy string | Starts with v=DMARC1 |
TTL | Default value | How long DNS answers are cached |
Use the Value field for the full DMARC policy string, not the Host Name field.
Starter Wix DMARC TXT recordtext
Host Name: _dmarc Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r
Replace example.com with your domain and dmarc-reports@example.com with a real reporting mailbox or the exact reporting address supplied by Suped. Do not add the surrounding quotation marks shown in DNS lookup results to Wix's Value field.
Do not stop at v=DMARC1; p=none; with no reporting address. That record can satisfy a surface-level check, but it gives you no aggregate reports and no practical path to enforcement.
Check Wix Email Marketing authentication before adding DMARC
Wix Email Marketing has a custom domain authentication workflow. Wix's authentication instructions say CNAME 5 automatically sets up DMARC. Domains purchased through Wix or connected to Wix nameservers normally start authentication automatically; Wix's troubleshooting instructions cover cases where that process fails.
- Open Email Marketing in your site dashboard, then Manage Senders under Sender Details. Confirm the sender email address if prompted, then choose Authenticate this domain or View DNS records.
- Inspect existing DNS records before copying Wix's CNAME records into your authoritative DNS host. Use the exact host and target values supplied for your domain.
- If _dmarc is a CNAME, inspect the TXT policy at its target. To manage your own policy and reporting address, plan the replacement with the DNS owner and verify Wix sender authentication afterwards.
- Recheck Domain status in Sender Details after propagation and send a campaign test. Verify dmarc=pass in the receiving server's Authentication-Results header before enforcement.
A CNAME and TXT record cannot coexist at the same DNS name under RFC 2181. If Wix reports 'Hostname already in use' for _dmarc, inspect both record types before proceeding. DMARC policy delegation is separate from Wix's DKIM CNAME records; keep the DKIM records needed to authenticate campaigns.
Why no DMARC record is found
A common Wix mistake is putting the DMARC TXT record at the root. Leaving Host Name blank publishes at the apex, which other DNS providers often label @. DMARC receivers query _dmarc.example.com, so a root TXT record does not supply the policy.
Wix DNS TXT editor showing _dmarc in the Host Name field.
Another common issue is editing DNS in the wrong place. If the domain is connected to Wix by pointing, Wix hosts the website but another provider controls DNS. Check the authoritative nameservers first, then edit TXT records wherever those nameservers are managed, as Wix's DNS instructions explain.
Wrong placement
- Leaving Host Name blank publishes the record at the root domain.
- DMARC checks look under _dmarc, so they report missing.
- Mailbox providers ignore the misplaced root TXT value.
Correct placement
- Use _dmarc exactly in the Wix Host Name field.
- The published name becomes _dmarc plus your domain.
- Receivers can read the policy and send aggregate reports.
After saving the record, allow DNS caches to refresh and check the exact DMARC name. Wix's propagation guidance allows up to 48 hours for DNS changes. Suped's DMARC checker parses the resolved record and identifies malformed tags.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Build the record before enforcing it
A useful DMARC policy record puts the version tag first and includes an explicit policy tag. RFC 9989 treats a missing p tag as p=none, but keeping the policy explicit avoids ambiguity and supports older receivers. For a real domain, include aggregate reporting so the monitoring stage identifies legitimate senders before receivers are asked to filter failures.
Monitoring policydns
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r
Each DMARC host has one policy record even when several services send mail using the same From domain. Do not add a second _dmarc record for Wix forms or another sender. Keep the single domain-wide policy, then configure each authorized service to pass SPF or DKIM with alignment to the visible From domain.
DMARC alignment compares the visible From domain with the SPF-authenticated Return-Path domain or the DKIM signing domain in d=. With relaxed alignment, they must share the same organizational domain, such as example.com and mail.example.com. Strict alignment requires an exact match. A matching Reply-to address does not establish DMARC alignment.
For mail sent with a subdomain in From, such as news.example.com, a separate policy belongs at _dmarc.news in Wix. Without its own policy, an applicable parent policy is inherited. Review subdomain senders before changing the parent policy.
Use a dedicated address that can receive XML reports, with a parser or reporting platform to make them readable. Reports are generally sent daily, but not every receiver sends them. Missing reports alone do not prove that no mail is being sent. RFC 9990 defines aggregate reporting.
- Use v=DMARC1 as the first tag; the DMARC1 value is case-sensitive.
- Start with p=none while you collect data.
- Add rua so receivers can send aggregate DMARC data.
- Relaxed SPF and DKIM alignment is the default and the safer starting point.
For a clean starter value, use Suped's DMARC record generator and paste the generated TXT value into the Wix Value field. Keep the host as _dmarc.
If the reporting destination has a different organizational domain, it must authorize reports in its own DNS. Confirm this with the reporting provider rather than adding authorization under your Wix domain. For example, reports for example.com sent to reports@example.net require an authorization TXT record at example.com._report._dmarc.example.net containing v=DMARC1; the provider can also use a wildcard authorization.
When to change the policy
After saving in Wix, validate the finished record before making a policy decision. Confirm that the record exists at the DMARC name, the syntax is readable, and the report address is present. DNS publication alone is not enough because a record can exist and still have a weak or unusable policy.
Check authoritative nameservers and the resolved DMARC policybash
dig NS example.com +short dig CNAME _dmarc.example.com +short dig TXT _dmarc.example.com +short
- Confirm the record is returned for the _dmarc host.
- Confirm the value starts with v=DMARC1 and has one policy tag.
- Confirm rua points to the intended reporting destination and reports actually arrive.
- Confirm the intended value is none, quarantine, or reject.
If no policy resolves after DNS caches refresh, check the host, authoritative DNS provider, and any CNAME target. A TXT lookup can return the CNAME followed by its target policy; that is not a duplicate. If it returns multiple distinct DMARC TXT records, consolidate them into one. Quoted chunks within one TXT record are also not duplicate records.
Keep p=none until reports show that authorized mail passes DMARC. For a small Wix business site, review mailbox traffic, form notifications, invoicing, bookings, CRM mail, and newsletters. For domains considering reject whose users post to mailing lists, RFC 9989 recommends at least one month at p=none followed by at least an equally long quarantine stage. Review every normal send cycle, including infrequent business mail. Judge readiness by authorized senders, not the overall pass percentage, which also includes unauthorized traffic. Investigate unknown sources before classifying them as unauthorized.
DMARC policy readiness stages
Qualitative readiness checks for authorized mail, rather than a fixed pass-rate threshold.
Discovery
p=none
Reports are missing or less than one complete send cycle exists.
Almost ready
p=none
Known senders pass, but low-frequency or indirect mail still needs review.
Quarantine enforcement
p=quarantine
Authorized senders pass and remaining failures have been investigated.
Full enforcement
p=reject
Quarantine is stable and indirect-mail risks are controlled.
Move to p=quarantine when authorized senders are accounted for and failures are not legitimate business mail. Quarantine requests suspicious handling, often spam placement; receivers use local filtering rules to decide the outcome. When a general-purpose user domain is considering reject, keep quarantine for at least another month and compare report dispositions before proceeding.
Full quarantine policydns
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
RFC 9989 made pct historic because percentage sampling was inconsistent. Avoid pct=25. Its test tag t=y requests one policy level lower: quarantine becomes none, and reject becomes quarantine. Older receivers ignore this tag and can apply the full declared policy. Keep p=none during discovery rather than relying on test mode for protection.
For transactional or other tightly controlled domains, move to p=reject after quarantine has run cleanly and the remaining failures are unauthorized. The safe transition plan helps when a domain has several senders or multiple business owners.
Full enforcement policydns
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r
For a domain that never sends mail, publish a restrictive SPF record such as v=spf1 -all and move DMARC to p=reject promptly; DKIM is unnecessary when no mail is sent. Confirm first that the domain and any subdomains covered by this policy send no mailbox, form, or automated mail. An active business domain needs reports first; enforcement risks delivery when legitimate messages pass neither SPF nor DKIM with DMARC alignment.
Check mailing-list use before reject
Forwarding commonly breaks SPF, and mailing lists can modify a message in ways that invalidate DKIM. Legitimate mail can then fail DMARC even when the original sender was authorized. A p=reject policy on a domain used for routine person-to-person mail can disrupt mailing-list participation.
- Ask whether users post to Internet mailing lists with addresses on the domain.
- Review aggregate-report policy overrides and forwarded sources during both monitoring stages.
- Keep p=quarantine when reject would disrupt legitimate mailing-list use, and work with affected senders and recipients to reduce disruption. Quarantine can still put legitimate messages in spam.
- Reserve p=reject for tightly controlled or no-send domains after authorized sources are accounted for.
RFC 9989 advises general-purpose email domains against p=reject when users might post to Internet mailing lists. If reject is still required, document the user impact and keep aggregate reports active.
How Suped fits the workflow
Suped is our DMARC reporting and email authentication platform. Its DMARC monitoring connects Wix DNS setup with sender-level report data, authentication issues, alerts, and steps to fix each source. That is useful on Wix domains because the website host, DNS host, and mail sender can be different.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Use the reports to answer one question before changing policy: which authorized sources still fail DMARC, and why? Suped's issue view turns that answer into actions such as adding missing DKIM, correcting SPF, removing an obsolete sender, or holding the DMARC policy at its current stage.
Manual process
- XML files land in an inbox and need manual parsing.
- Compare reported sources with your inventory of authorized senders.
- Record each policy change and review the next reporting period.
- Multiple Wix domains need repeated DNS reviews.
Suped process
- Aggregate data becomes sender-level DMARC visibility.
- Sender categories help review authorized and unrecognized mail; confirm ownership before enforcement.
- Alerts show when authentication breaks after setup.
- Multi-domain views keep each Wix domain separate.
Suped's Hosted DMARC supports policy changes without repeated Wix DNS edits. Publish the CNAME supplied by Suped at _dmarc as a replacement for the existing DMARC TXT record or delegation, then adjust policy in Suped after reviewing reports. Keep one delegation at that host and account for DNS caching when verifying changes.
Common Wix mistakes to fix first
Before changing policy, fix the problems that create false confidence. A 'DMARC record found' result is not enough. The policy needs the right host, one resolved DMARC TXT record, valid syntax, and reliable reports.
Flowchart for checking DNS host, adding DMARC, validating, reading reports, and enforcing policy.
- Move the TXT value from the blank host to _dmarc.
- Keep one resolved DMARC policy at each host. If _dmarc is a CNAME, do not add a TXT record alongside it.
- Add rua so you can see who sends mail for the domain.
- Edit records where the authoritative nameservers are managed.
- Do not reject active mail until authorized senders and mailing-list risks are reviewed.
A warning that says DMARC policy is not enabled usually means the record exists but uses p=none. The record is valid but does not request DMARC enforcement. Treat it as the monitoring stage and move beyond none when reports support the change.
Frequently asked questions
Enter _dmarc. Do not leave it blank and do not use @. Wix uses a blank Host Name for root-domain records; DMARC belongs at the _dmarc host. Inspect existing TXT and CNAME records first.
Yes, for the first monitoring stage. It is not enforcement. Add rua reporting, review the sources, then move to quarantine when authorized senders pass.
The record is usually at the wrong DNS name, often the root domain instead of _dmarc. Other causes include editing Wix when DNS is managed elsewhere, stale DNS caches, or a CNAME target without a valid DMARC policy.
No. Keep one domain-wide _dmarc record for senders using the same From domain. Configure each sender to pass SPF or DKIM with DMARC alignment. Sending subdomains can have their own policies.
For a tightly controlled domain, switch after quarantine is stable and remaining failures are unauthorized. RFC 9989 advises against reject for domains whose users post to Internet mailing lists. Domains still considering reject should review reports at none and quarantine for at least one month each before assessing the user impact.
Set up both where your senders support them, but each message needs a pass from SPF or DKIM with DMARC domain alignment. DMARC does not create SPF or DKIM records. Verify received test messages and fix any authorized sender that passes neither before enforcement.
