How to Fix 'DMARC Quarantine Policy Not Enforced' Warnings

You can fix dmarc quarantine warning alerts by updating your domain's DNS TXT record to include a properly formatted policy tag (p=quarantine or p=reject) and ensuring your SPF and DKIM signatures are correctly aligned. Email receivers flag this warning when a DMARC policy is either missing, set to none (p=none), or improperly syntaxed, leaving your domain vulnerable to spoofing. Addressing this ensures unauthenticated mail is actively handled rather than just monitored.

Understanding the DMARC Quarantine Warning

When you check your domain's email authentication health using tools or receive aggregate DMARC reports, seeing a warning about an unenforced quarantine policy means your current Domain-based Message Authentication, Reporting, and Conformance configuration is not actively protecting your inbox partners. DMARC relies on two underlying protocols: Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).

If your policy tag is set to p=none, your DMARC record is effectively in "reporting-only" mode. While this is useful for gathering data during initial deployment, email security scanners and compliance auditors will flag this as a warning because unauthorized emails still land in user inboxes instead of being quarantined or rejected. To transition from passive monitoring to active defense, you must elevate your policy level.

Verifying Your Current DMARC Record

Before making changes, you need to inspect your existing DNS records to see what policy is currently deployed. You can query your domain using command-line tools like dig or nslookup to retrieve the TXT record located at _dmarc.example.com.

Run the following command in your terminal:

dig TXT _dmarc.example.com +short

Or using PowerShell on Windows:

Resolve-DnsName -Name _dmarc.example.com -Type TXT

A typical misconfigured or monitoring-only response looks like this:

"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;"

The presence of p=none is the exact trigger for the warning. The receiving mail server sees that you are only collecting data and not instructing it to quarantine failing messages.

Step-by-Step Guide to Fix the Warning

To resolve the warning permanently, you need to generate a robust DMARC record, update your DNS zone, and verify that your mail flow works without disruption. If you want to build a compliant record without manual syntax errors, you can use the DMARC Record Generator to instantly create a valid policy string based on your specific reporting and alignment requirements.

Step 1: Ensure SPF and DKIM are Fully Aligned

Before changing your DMARC policy to quarantine, your legitimate email streams must pass SPF and DKIM checks with strict alignment. If your third-party mailing tools send mail that fails alignment, upgrading to p=quarantine will cause your own legitimate emails to end up in the spam folder.

• SPF Alignment: The domain in the Return-Path address must match the domain in the From header (or have a valid organizational domain match).
• DKIM Alignment: The domain in the d= tag of your DKIM signature must match your From header domain.

Step 2: Construct the New DMARC Record

Modify your DMARC string to change the policy tag from p=none to p=quarantine. You should also include a percentage tag (pct=) if you want to phase in the enforcement gradually, though a full transition is often preferred for smaller domains.

Here is an example of a secure DMARC record set to quarantine:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc-reports@example.com; rfs=mailto:dmarc-reports@example.com;"

Step 3: Publish the Record in Your DNS Provider

Log in to your DNS hosting provider or domain registrar. Navigate to your domain's DNS management console (menu paths vary by provider, typically found under "DNS Manager", "Zone Editor", or "Manage DNS").

1. Locate your existing _dmarc TXT record.
2. Edit the record value to replace p=none with p=quarantine.
3. If no record exists, create a new TXT record with the host name _dmarc (or _dmarc.example.com depending on whether your interface appends the root domain automatically).
4. Save the changes and wait for DNS propagation.

Step 4: Verify the Update

After a few minutes, verify that the new record is globally visible and correctly interpreted by running a lookup again:

dig TXT _dmarc.example.com +short

You should see your updated quarantine policy returned in the output.

Comparison of DMARC Policy Settings

Common Mistakes and How to Fix Them

Even experienced engineers occasionally run into configuration pitfalls when tightening email authentication policies.

• Forgetting Third-Party Senders: If you use customer support platforms, marketing automation tools, or transactional email services (such as those sending from 192.0.2.0/24), make sure they are authorized in your SPF record and have custom DKIM keys configured before moving to p=quarantine. Otherwise, your outbound notifications will be quarantined.
• Syntax Errors in DNS Records: Typos such as missing semicolons, incorrect tag names (e.g., using policy= instead of p=), or invalid email addresses in the rua= tag will cause mail servers to ignore your DMARC record and fall back to default behaviors.
• Subdomain Oversights: By default, a DMARC policy applies to subdomains unless overridden by the sp= tag. If your subdomains send unauthenticated mail, specify sp=quarantine explicitly.

Quick Checklist for DMARC Quarantine Enforcement

• Verify all legitimate sending IPs and services are SPF and DKIM compliant.
• Ensure aggregate reporting addresses (rua=) are active and monitored.
• Update the DNS TXT record at _dmarc.example.com to p=quarantine.
• Test live mail delivery using external diagnostic tools.
• Review incoming DMARC XML reports after 48 hours to confirm zero legitimate mail loss.