DMARC Quarantine/Reject Policy Not Enabled: How to Fix It
Fix the 'DMARC quarantine/reject policy not enabled' error. Learn what this message means, why it appears, and how to enable a DMARC enforcement policy step by step.
Last updated: 2026-04-10
If you have run your domain through an email security scanner like MX Toolbox, Google Postmaster Tools, or a deliverability checker, you may have seen the warning "DMARC quarantine/reject policy not enabled." This message means your domain is not actively protecting against email spoofing, and it is one of the most common issues flagged in email security audits.
The good news is that this is straightforward to fix. This guide explains exactly what the error means, why it appears, and how to enable a DMARC enforcement policy step by step.
What This Error Message Means
The "DMARC quarantine/reject policy not enabled" warning tells you that your domain is not instructing receiving mail servers to take action when someone sends a fraudulent email using your domain name. Without an enforcement policy, anyone can forge your From address and those spoofed messages will be delivered normally to recipients' inboxes.
This warning appears in two different situations, and both lead to the same result — no DMARC protection for your domain:
You have no DMARC record at all. If a scanner looks up _dmarc.yourdomain.com and finds nothing, it reports "no DMARC record found" or "DMARC policy not enabled." Without a record, receiving servers have no instructions for handling unauthenticated email from your domain.
Your DMARC record uses p=none. If you do have a DMARC record but the policy is set to none, the scanner will still flag it. The p=none policy tells mail servers to deliver all messages regardless of whether they pass authentication. It is useful for monitoring, but it does not actually block or quarantine spoofed emails. From a security perspective, having p=none offers no more protection than having no DMARC record at all.
Both scenarios — no DMARC record found and a DMARC record with p=none — trigger the same "policy not enabled" warning. The fix for both is to publish a DMARC record with an enforcement policy of either quarantine or reject.
Why This Matters
Without a DMARC quarantine or reject policy, your domain is vulnerable to email spoofing. Attackers can send phishing emails that appear to come from your address, and recipients have no way to tell the difference. This damages your brand reputation, erodes trust with your customers, and can lead to your legitimate emails landing in spam folders as mailbox providers lose confidence in your domain.
Major email providers including Google and Yahoo now require DMARC records for bulk senders. Even if you are not sending high volumes, having no DMARC protection can hurt your deliverability over time as inbox providers tighten their authentication requirements.
How to Fix It
Follow these steps to move your domain from no protection to full DMARC enforcement. If you already have a p=none record, skip to step three.
Check your current DMARC record
Before making any changes, find out what you currently have. Go to dmarcrecordchecker.com and enter your domain. The tool will tell you whether you have a DMARC record and what your current policy is set to. If it reports "no DMARC record found," you need to create one from scratch. If it shows a record with p=none, you need to update it to an enforcement policy.
Create a DMARC record with monitoring
If you have no DMARC record at all, start by creating one with p=none and a reporting address. This lets you collect data about who is sending email as your domain before you start blocking anything. Use our free DMARC record generator below to build a valid record, then add it as a TXT record at _dmarc.yourdomain.com in your DNS provider.
Make sure your SPF record and DKIM signing are properly configured for all services that send email on your behalf. DMARC relies on SPF and DKIM alignment to determine whether a message is legitimate.
Review your DMARC reports
With p=none in place, you will start receiving aggregate reports from mailbox providers within 24 to 48 hours. These reports show every IP address sending email as your domain and whether those messages are passing SPF and DKIM checks. Review these reports for at least two to four weeks to make sure all your legitimate senders — your marketing platform, CRM, transactional email service, helpdesk tool — are passing authentication. For more on reading these reports, see our guide on how to read DMARC reports.
Move to p=quarantine
Once you are confident that all legitimate email is passing authentication, update your DMARC record to p=quarantine. This tells receiving servers to send failing messages to the spam folder instead of the inbox. It is the first real enforcement step and gives you a safety net — if something is misconfigured, affected emails end up in spam rather than being blocked entirely, so recipients can still find them.
You can also use the pct tag to roll out gradually. Setting pct=25 applies the quarantine policy to only 25 percent of failing messages at first. Increase this over a few weeks until you reach pct=100.
Move to p=reject
After running at p=quarantine with no issues for two to four weeks, update your policy to p=reject. This is the strongest protection available. Receiving servers will refuse delivery of any email that fails DMARC alignment, blocking spoofed messages before they reach anyone. For a detailed comparison of how these two enforcement levels work in practice, see DMARC quarantine vs reject.
Create your DMARC record
Use our free DMARC generator to build a valid record for your domain.
Common Mistakes When Enabling Enforcement
Even with the right intentions, there are a few pitfalls that trip people up when moving from p=none to an enforcement policy.
Skipping the monitoring phase. Jumping straight to p=quarantine or p=reject without reviewing your DMARC reports first is the fastest way to break your own email. You may have services sending as your domain that you have forgotten about. The monitoring phase with p=none exists to catch these before enforcement blocks them.
Forgetting about third-party senders. Your main email provider might be properly authenticated, but what about your invoicing tool, your helpdesk software, or the newsletter platform your marketing team signed up for last quarter? Every service that sends email using your domain needs to be included in your SPF record or configured with DKIM signing for your domain.
Not using the pct tag for gradual rollout. Moving from p=none to p=quarantine; pct=100 in one step is risky. Start with a lower percentage and increase it over time. This limits the blast radius if something is wrong.
Publishing the record at the wrong location. Your DMARC record must be a TXT record at _dmarc.yourdomain.com — not dmarc.yourdomain.com and not at the root of your domain. Some DNS providers automatically append your domain name, so you may only need to enter _dmarc in the host field. Check your provider's documentation.
If you manage multiple domains or subdomains, each one needs its own DMARC consideration. A DMARC record on your root domain applies to subdomains by default through the sp tag, but you should verify this is working as expected. See our guide on DMARC for subdomains for details.
What Your Final Record Should Look Like
Once you have completed the enforcement process, your DMARC record should look something like this:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1;
This record tells receiving servers to reject all unauthenticated email, send aggregate reports to your specified address, and generate failure reports when any check fails. You can verify your record is working correctly at any time by checking it with dmarcrecordchecker.com.
For a complete explanation of every tag and value available, see our DMARC policy levels guide.
Related Articles
Monitor Your DMARC Record
You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.
Never miss a DMARC issue
Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.
Start Monitoring