How do I properly set up a DMARC record on Wix and when should I change the policy?
Michael Ko
Co-founder & CEO, Suped
Published 17 Apr 2025
Updated 17 Aug 2025
7 min read
Establishing a strong email sending reputation is crucial for anyone using email for business, especially when your website and domain are hosted on platforms like Wix. One of the most effective ways to protect your domain from spoofing and phishing, and to ensure your emails reach recipients' inboxes, is by implementing a DMARC record. While the concept might seem technical, setting up DMARC on Wix is manageable if you know the correct steps and understand how to manage your DNS records.
Many users, including those on Wix, sometimes encounter challenges where their newly added DMARC record isn't recognized. A common reason for this is often a small but critical detail: the hostname used when adding the record. I've seen situations where, despite adding the correct DMARC policy string, the record still appears missing after a week of propagation time.
This guide will walk you through the proper setup of a DMARC record on Wix, addressing common pitfalls and explaining when and how you should consider advancing your DMARC policy for optimal email security and deliverability.
DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, is an email authentication protocol that helps protect your domain from unauthorized use, such as spoofing and phishing attacks. It builds upon two existing email authentication standards: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). For a more in-depth understanding, you can refer to our simple guide to DMARC, SPF, and DKIM.
When an email server receives an email claiming to be from your domain, it checks your DMARC record, along with your SPF and DKIM records, to verify its authenticity. This verification process ensures that only legitimate emails from your domain reach their intended recipients, helping to reduce spam and improve your email deliverability. Without DMARC, your domain remains vulnerable to abuse, potentially impacting your brand's reputation and leading to your emails being marked as spam or blocked outright.
DMARC records are published as TXT records in your domain's DNS. While some older information might suggest Wix doesn't support DMARC, this is incorrect. Wix provides the functionality to manage DNS records, including adding TXT records. The key is knowing the specific format and location required for DMARC.
The importance of DMARC
Anti-Spoofing: It prevents unauthorized entities from sending emails using your domain, safeguarding your brand's reputation.
Deliverability: Email providers trust domains with DMARC, leading to better inbox placement and fewer emails landing in spam folders.
Visibility: DMARC reports provide insights into who is sending email on behalf of your domain, helping you identify legitimate and fraudulent sources.
How to add your DMARC record on Wix
The process of adding a DMARC record to your Wix domain involves logging into your Wix account and navigating to the DNS settings. From there, you will add a new TXT record. The most crucial part of this step is ensuring the correct hostname (or name/host field) is entered for your DMARC record. Many users initially make the mistake of leaving this field blank or entering an '@' symbol, which is incorrect for DMARC records.
A DMARC record must be published under the specific hostname _dmarc. This prefix tells receiving email servers that the TXT record contains DMARC policy information for your domain. If you've been troubleshooting a "No DMARC Record found" error, double-checking this specific entry is often the solution, as highlighted by multiple DMARC setup guides for Wix.
Once you've entered _dmarc in the host field and your DMARC policy string (e.g., v=DMARC1; p=none; rua=mailto:your_email@yourdomain.com;) in the value field, save the record. DNS changes can take some time to propagate globally, typically from a few minutes to several hours, but sometimes up to 48 hours. After propagation, you can use online DMARC checkers to verify your record's presence and correctness.
Once your DMARC record with p=none is successfully published and you're receiving DMARC reports, you'll need to decide when to change your policy. The p=none policy is a monitoring-only policy, meaning it instructs receiving servers not to take any action on emails that fail DMARC checks, but to send reports. This phase is crucial for gathering data and ensuring all legitimate sending sources for your domain are properly authenticated with SPF and DKIM. You can learn more about DMARC policy options.
Policy transition
P=none: Monitor mode, no impact on email delivery, provides visibility into email sources.
P=quarantine: Emails failing DMARC checks are moved to spam or quarantined by receiving servers.
P=reject: Emails failing DMARC checks are outright rejected and not delivered.
I recommend moving to p=quarantine or p=reject only after you are confident that all your legitimate email streams are passing DMARC authentication. This often means reviewing your reports for a few weeks to a few months, identifying any legitimate sending services (like email marketing platforms or transactional email providers), and ensuring they are correctly configured with SPF and DKIM. Rushing this step can lead to your own legitimate emails being sent to spam folders or rejected, causing deliverability issues. For guidance, explore our guide on safely transitioning your DMARC policy.
Monitoring DMARC reports and maintaining your policy
DMARC reporting is vital for a successful implementation. By including rua (aggregate reports) and optionally ruf (forensic reports) tags in your DMARC record, you receive XML-formatted reports that detail how email servers are processing emails from your domain. These reports, while complex, provide critical insights into your email ecosystem.
These reports will show you which emails are passing or failing SPF and DKIM authentication and how they are aligning with your DMARC policy. Analyzing these reports is key to identifying legitimate senders that need to be authenticated and detecting any unauthorized (spoofing) activity. You'll need a DMARC reporting service to parse these XML reports into an understandable format. There are many reporting tools available, which you can find listed at sites like dmarcvendors.com. Proper DMARC reports setup is essential.
As mailbox providers like Gmail and Yahoo increasingly enforce stricter email authentication requirements, having a DMARC policy stronger than p=none will become a de facto requirement for maintaining high deliverability rates. This transition is not about rushing, but about a phased approach, ensuring your legitimate emails are always delivered. You can refer to our guide on understanding and troubleshooting DMARC reports.
Views from the trenches
Best practices
Always start with DMARC p=none and rua tag to monitor email traffic and get full visibility into legitimate and fraudulent sending sources.
Ensure all legitimate email sending services (marketing platforms, transactional mailers) are correctly configured with SPF and DKIM for your domain.
Utilize a DMARC reporting tool to parse XML reports into an easily digestible format for analysis.
Gradually move from p=none to p=quarantine, and then to p=reject only after confirming all legitimate emails pass authentication consistently.
Regularly review your DMARC reports to detect new sending sources or potential spoofing attempts and adjust your DNS records as needed.
Common pitfalls
Failing to include the '_dmarc' subdomain prefix when adding the DMARC record to your DNS settings on Wix or other providers.
Not configuring reporting (rua and ruf tags), which leaves you blind to how your emails are being authenticated and handled.
Jumping directly to a p=quarantine or p=reject policy without sufficient monitoring, leading to legitimate emails being blocked or sent to spam.
Forgetting to update SPF or DKIM records when adding new email sending services, causing DMARC authentication failures.
Not understanding DMARC alignment and assuming SPF or DKIM pass means DMARC will also pass, leading to unexpected failures.
Expert tips
Consider setting a low percentage (pct) tag when moving to quarantine or reject for a gradual rollout, minimizing impact on deliverability.
Implement subdomain DMARC policies using the 'sp' tag, especially for domains that should not send email.
Regularly audit your DNS records (SPF, DKIM, DMARC) to ensure they are up-to-date and compliant with current best practices.
Leverage DMARC forensic reports (ruf) for detailed insights into failed emails, aiding in quicker troubleshooting of authentication issues.
Be aware of DMARC-related changes from major mailbox providers; they frequently update their requirements, which can affect your policy.
Expert view
Expert from Email Geeks says the lack of a DMARC record could be due to not adding `_dmarc` as the host. The DMARC record needs to be a TXT record for `_dmarc.yourdomain.com`.
2024-09-03 - Email Geeks
Expert view
Expert from Email Geeks says a `p=none` DMARC policy without reporting is largely ineffective because it doesn't provide the necessary feedback to improve email authentication.
2024-09-04 - Email Geeks
Securing your email with DMARC on Wix
Setting up a DMARC record on your Wix domain is a fundamental step towards modern email security and deliverability. While the initial setup requires attention to detail, particularly the _dmarc hostname, the benefits in terms of anti-spoofing protection and inbox placement are significant. The shift towards stricter authentication by major mailbox providers means that DMARC is no longer optional for serious senders.
By following a phased approach, starting with p=none and utilizing DMARC reports, you can confidently transition to stronger policies like p=quarantine or p=reject. This proactive stance will secure your domain, protect your brand, and help ensure your emails consistently reach their intended audience.