DMARC Quarantine Policy
Your domain uses p=quarantine — moderate DMARC protection that sends
failing emails to spam. This is a good intermediate step, but upgrading to
p=reject will provide the strongest defense against domain spoofing.
What p=quarantine means
The p=quarantine policy tells receiving mail servers to treat emails
that fail DMARC authentication as suspicious. In practice, this
typically means the email is moved to the recipient's spam or junk folder instead
of their inbox.
v=DMARC1; p=quarantine; rua=mailto:[email protected]
This is a reasonable middle ground — spoofed emails are flagged as suspicious, but legitimate emails that might be misconfigured aren't completely blocked. However, it's intended to be a transitional policy, not a permanent one.
No action taken. Spoofed emails delivered normally. Only useful for initial monitoring.
Failing emails sent to spam/junk folder. Moderate protection — spoofed emails still reach recipients.
Failing emails blocked entirely. Maximum protection — spoofed emails never delivered.
Why quarantine is weaker than reject
While p=quarantine provides some protection, it has important limitations
compared to p=reject:
Emails still reach recipients
Quarantined emails land in the spam folder, where users can still find and open them. Some users regularly check their spam folder and may interact with spoofed emails.
Mobile clients may show them
Some mobile email clients display spam folder notifications or show quarantined emails more prominently, increasing the risk that a user opens a spoofed message.
Inconsistent handling
Not all mail servers handle quarantine identically. Some may deliver to spam, others may add a warning banner, and some may treat it more leniently than intended.
Incomplete brand protection
Your domain reputation isn't fully protected because spoofed emails still technically reach inboxes. With reject, attackers get no value from spoofing your domain.
Before upgrading: check your reports
Before changing from p=quarantine to p=reject, you need
to verify that all your legitimate email sources pass DMARC authentication. Upgrading
without checking could block legitimate emails from services you use.
Verify you have DMARC reporting enabled
Check that your DMARC record includes a rua tag pointing to a valid email address or reporting service. If not, add one and wait 2–4 weeks to collect data.
v=DMARC1; p=quarantine; rua=mailto:[email protected]
Review aggregate reports
Look at your DMARC reports for any legitimate sources that are failing authentication. Common culprits include marketing platforms (Mailchimp, HubSpot), CRM systems (Salesforce), and helpdesk tools (Zendesk, Freshdesk).
Confirm all sources pass
Wait another 1–2 weeks after fixing sources. Review reports again to confirm that all legitimate email now passes DMARC authentication. Only then proceed to upgrade.
p=reject is forgotten third-party
services that weren't properly configured for SPF/DKIM alignment. Take the time
to audit your reports thoroughly.
Step-by-step upgrade to reject
Once you've verified all legitimate sources pass DMARC, follow these steps to
safely upgrade to p=reject:
Start with a partial reject rollout
Use the pct tag to apply the reject policy to only a percentage of failing emails. Start with 10–25%.
v=DMARC1; p=reject; pct=10; rua=mailto:[email protected]
Monitor for 1–2 weeks
Watch your DMARC reports and check for any delivery complaints from users. If legitimate emails are being rejected, fix their SPF/DKIM configuration before continuing.
Increase the percentage gradually
If no problems appear, increase the percentage. A common progression is 10% → 25% → 50% → 75% → 100%, with 1–2 weeks at each level.
v=DMARC1; p=reject; pct=50; rua=mailto:[email protected]
Remove the pct tag for full enforcement
Once you're at 100% with no issues, you can remove the pct tag entirely (it defaults to 100). Your final record should look like this:
v=DMARC1; p=reject; rua=mailto:[email protected]
Before and after
| Stage | DNS record |
|---|---|
| Current (quarantine) | v=DMARC1; p=quarantine; rua=mailto:[email protected] |
| Transition (partial reject) | v=DMARC1; p=reject; pct=25; rua=mailto:[email protected] |
| Final (full reject) | v=DMARC1; p=reject; rua=mailto:[email protected] |
Provider-specific notes
How to update your DMARC record depends on where your domain's DNS is hosted.
The DMARC record is a TXT record at _dmarc.yourdomain.com.
Cloudflare
Go to DNS → Records. Find the TXT record for _dmarc. Click Edit and change p=quarantine to p=reject. Save. Changes propagate quickly.
GoDaddy
Go to DNS Management. Find the TXT record for _dmarc. Edit the value to change the policy. Save. DNS propagation can take up to 48 hours.
Google Domains / Squarespace
Navigate to DNS settings. Locate the _dmarc TXT record. Update the value. Google Domains typically propagates changes within minutes.
AWS Route 53
Go to Hosted Zones → select your domain. Find the _dmarc TXT record set. Edit the value and save. Changes propagate based on the record's TTL.
Troubleshooting
Legitimate emails being quarantined
If users report that legitimate emails are going to spam, check your DMARC reports to identify the failing source. The most common fix is adding the service's sending servers to your SPF record or configuring DKIM signing with your domain.
Fix: Identify the source IP in DMARC reports, determine which service it belongs to, and configure SPF/DKIM for that service.
Forwarded emails failing
Email forwarding (e.g., university alumni addresses, mailing lists) breaks SPF because the forwarding server's IP isn't in your SPF record. This is expected behavior and one reason DKIM is important — DKIM signatures survive forwarding.
Fix: Ensure DKIM is properly configured for all your sending sources. With DKIM alignment, forwarded emails will still pass DMARC even when SPF fails.
Not sure which services send email as your domain
If you're unsure which services are sending email on your behalf, don't guess. Your DMARC aggregate reports contain a complete list of all servers that sent email using your domain, along with their authentication results.
Fix: Use a DMARC reporting service to analyze your aggregate reports. They'll show you every source, whether it passed or failed, and help you identify legitimate vs. unauthorized senders.
Upgrade your domain's protection
Domain Guarddog monitors your DMARC policy and alerts you when it's safe to upgrade from quarantine to reject.
Get Started Free