Configure sp=quarantine

Why sp=quarantine is essential for DMARC security in 2025

Imagine an attacker sending phishing emails that appear to come from your company's support@ or marketing@ subdomains—emails that bypass your main domain’s SPF and DKIM checks. Without sp=quarantine, these messages might still reach inboxes, silently eroding trust and inviting compromises.

DMARC policies with p=quarantine act as a gatekeeper. When properly configured, they automatically isolate messages that fail authentication, even if they come from a subdomain. The key? Setting sp=quarantine to enforce security across all subdomains, not just the root domain.

In 2025, attackers are no longer just targeting your primary domain—they’re exploiting weak subdomain policies. A single unsecured subdomain can become a backdoor for spoofing. Without sp=quarantine, your DMARC policy is half-armed.

Key takeaways

sp=quarantine ensures unauthenticated mail from any subdomain of your domain is treated as suspicious and quarantined
Failure to configure sp=quarantine leaves subdomains vulnerable to spoofing, even if your root domain policy is strict
sp=quarantine complements p=quarantine by applying the same protection level to subdomains, closing a major gap in DMARC enforcement

What does sp=quarantine actually do in a DMARC record?

Setting sp=quarantine in your DMARC record tells receiving mail servers to treat unauthenticated messages from your subdomains as suspicious, not outright rejected—they’ll land in spam folders instead. This reduces the risk of malicious or misconfigured subdomains delivering phishing or spam emails while still allowing legitimate traffic to flow, helping protect your brand’s reputation. It’s a balanced step toward tighter email security without breaking valid sends.

How sp=quarantine works in practice

When you set p=quarantine for your main domain and sp=quarantine for subdomains, any email sent from a subdomain like newsletter.yourcompany.com or login.yourcompany.com that fails SPF or DKIM checks won’t be blocked—it’ll be flagged as potentially suspicious and sent to spam. This gives you breathing room to detect and fix issues, whether it’s a rogue app, misconfigured tool, or a compromised account, without interrupting legitimate workflows.

For example, if a developer deploys a test script from dev.yourcompany.com without proper authentication, the email won’t reach the inbox—but it also won’t be delivered to your recipients’ inboxes, where it could look like phishing. Instead, it lands in the spam folder, where it’s much less likely to cause harm or damage your brand’s trust.

Why it's a smarter default than rejection for subdomains

Rejecting all unauthenticated subdomain emails (with sp=reject) can backfire. Subdomains often host services with variable or incomplete email setup—internal tools, third-party platforms, or legacy systems that don't yet authenticate properly. Sending them to spam instead of blocking them entirely helps you detect problems early without disrupting operations.

It’s a widely supported approach: the DMARC specification defines sp=quarantine as a recommended, less aggressive alternative to outright rejection for subdomains, especially during rollout or migration. This makes it ideal for organizations scaling their email infrastructure while maintaining security.

While setting sp=quarantine isn’t a complete fix for all email threats, it’s a critical layer in protecting your domain from unauthorized use—especially by subdomains that may be overlooked in day-to-day monitoring.

Before you deploy or adjust your DMARC policy, verify that your sending sources are properly authenticated. A good way to check for misconfigured or risky addresses is using a real-time verification tool. You can test domains, subdomains, or individual addresses with MailTester’s email checker to catch potential issues before they hit the inbox.

How sp=quarantine differs from p=quarantine in DMARC

You can use both p=quarantine and sp=quarantine in your DMARC policy to protect your domain and its subdomains from spoofing. While p=quarantine applies to emails sent from your base domain (like example.com), sp=quarantine extends that protection to subdomains (like mail.example.com or blog.example.com), especially when third parties manage them. Using both ensures that even unverified or poorly managed subdomains can’t bypass authentication checks.

Base domain protection with p=quarantine

p=quarantine sets the policy for messages sent from your primary domain. If an email claiming to come from example.com fails SPF or DKIM checks, it must be treated as suspicious—typically sent to spam, not rejected outright. This helps reduce the risk of spoofed emails reaching inboxes while allowing legitimate failures (like those from temporary misconfigurations) to be reviewed rather than blocked.

It’s important to note that enforcing p=quarantine without testing first can cause unintended delivery issues. The policy only applies when you have a DMARC record published, and it’s active in a “reporting-only” mode for at least a few weeks to gather data. You can validate your full authentication chain using tools like MailTester’s email checker, which tests if a single address is valid and properly authenticated before sending.

Subdomain protection with sp=quarantine

Subdomains often fall outside your direct control. For instance, mail.example.com might be managed by a third-party email service, blog.example.com by a CMS, or even login.example.com by a SaaS provider. Without sp=quarantine, these could be exploited to spoof your brand—even if the main domain is secured.

sp=quarantine ensures that any email claiming to come from any subdomain of your domain is treated with the same suspicion. This prevents attackers from impersonating a subdomain that’s not properly authenticated. It's especially valuable in enterprise environments where multiple teams or vendors handle different parts of your domain infrastructure.

According to the DMARC specification, subdomain policies are meant to provide layered protection. While p=quarantine secures the root domain, sp=quarantine closes gaps in subdomains that might otherwise slip through without oversight. Together, they create a stronger chain of authentication, reducing the risk of brand impersonation across your entire domain hierarchy.

Step-by-step: How to configure sp=quarantine in your DMARC record

You can strengthen your email security by setting sp=quarantine in your DMARC record, ensuring that unauthenticated mail from your domain’s subdomains is treated as suspicious—even if the main domain passes checks. Start by accessing your DNS provider’s interface, locate your existing _dmarc TXT record, update it with sp=quarantine, validate syntax using a free tool, and wait up to 48 hours for global propagation.

Access and edit your DNS records

Log in to your domain provider’s DNS management interface (like Cloudflare, GoDaddy, or AWS Route 53).
Look for a TXT record with the name _dmarc.example.com (replace with your actual domain).
Editing this record directly allows you to apply DMARC policies across your domain and subdomains consistently.

Update the DMARC policy and validate

Change your DMARC policy from p=none or p=reject to p=quarantine and add sp=quarantine to apply the same handling to subdomain-sourced messages.
Example: v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:[email protected]; — include a valid feedback email address.
Use an open-source validator like DMARCian's DMARC Record Checker to verify your record’s syntax before saving.
After saving, wait up to 48 hours for DNS propagation across global mail providers—this includes major services like Gmail, Outlook, and Yahoo.

Why this matters: p=quarantine tells receivers to treat unauthenticated mail from your domain as suspicious, reducing phishing and spoofing risk without blocking legitimate messages. Setting sp=quarantine extends that protection to subdomains, which are often weaker targets.

The 3 steps described in “Access and edit your DNS records”, in order.

Once configured, monitor your DMARC reports via the rua address. You’ll see detailed data on failed attempts, helping you adjust SPF and DKIM records for better alignment. These checks are foundational to email trust and deliverability.

When building or validating your email lists, use MailTester’s bulk verification tool to ensure sender reputation stays strong—valid addresses improve your domain’s trust score over time.

Common mistakes to avoid when setting sp=quarantine

You risk leaving subdomains vulnerable if you set p=none or p=reject without configuring sp=quarantine. Without it, attackers can spoof subdomains like login.company.com with no consequences. Always monitor your DMARC reports via the rua tag to catch misconfigurations and detect abuse early. Without this, you’re flying blind.

Ignoring subdomain protection is a common oversight

Setting p=none or p=reject only applies to your main domain — it doesn’t extend to subdomains unless you explicitly define sp=quarantine or sp=reject.
If sp=none, malicious actors can send emails from [email protected] without any action taken, even if your main domain is secured.
Using sp=none essentially disables all subdomain enforcement — this is equivalent to having no DMARC policy for subdomains, leaving your brand open to impersonation.

DMARC reports (sent to the rua email address) are your only way to understand which emails are being quarantined due to policy violations.
If you don’t monitor these reports, you won’t know if your policy is blocking legitimate mail or if attackers are actively spoofing your domains.
Regularly reviewing rua reports helps you spot new threats, correct misconfigurations, and refine your policy over time — a standard practice recommended by the DMARC specification (RFC 7483).
Use tools like MailTester’s inbox placement test to simulate how your emails perform across inboxes, helping you verify that DMARC enforcement isn’t blocking real messages.

Let’s be clear: a strong DMARC policy isn’t just about setting p=quarantine. It’s about ensuring subdomain protection with sp=quarantine, and then actively watching the reports that tell you whether your policy is working — or failing silently.

How to test your DMARC configuration works after sp=quarantine is set

After setting sp=quarantine, test your DMARC policy by sending real emails through different mail servers—especially those mimicking misaligned SPF or DKIM—then check aggregate reports (RUA) to confirm quarantined messages from unapproved senders are being tracked. Use a trusted DMARC analysis tool to observe how inbounds from your domain or subdomains behave under enforced policies.

Send test emails with varying alignment levels

Let’s simulate real-world delivery conditions. Send test emails from your domain or a subdomain using mail servers that either pass or fail SPF and DKIM alignment. Some legitimate senders might not align perfectly, especially with older infrastructure or third-party tools. Tools like MXToolbox’s DMARC tester can help verify how your policy treats these cases.

Pay attention to whether messages that misalign with SPF or DKIM are marked as quarantined in the recipient’s inbox. This confirms your sp=quarantine directive is being enforced. Failure to see quarantining could mean your policy is too permissive or not published correctly.

Verify DMARC reports (RUA) are receiving data

Ensure your DMARC aggregate reports (RUA) are being sent to a valid email address. These reports collect daily summaries of email traffic using your domain. Check them regularly to see if messages from subdomains—especially those with known misconfigurations—are flagged as fails.

Messages from unauthorized senders should appear in the report with a result=fail and indicate alignment issues. If subdomain traffic isn’t showing up, double-check your RUA tag and DNS records. RFC 7483 defines the expected format for these reports, so refer to it for validation if needed.

You can also use real-time email verification tools before sending to reduce the risk of sending from misconfigured systems. For example, check individual addresses and pre-process lists in bulk to reduce delivery risks tied to invalid or suspicious senders. Keeping your outbound traffic clean supports stronger policy enforcement.

How MailTester helps validate your DMARC-safe email list

You can’t enforce DMARC protection with p=quarantine if your list includes fake, invalid, or high-risk addresses. MailTester’s bulk verification checks every email for validity, catch-all status, and spam trap risk—clearing out addresses that could trigger false positives in DMARC reports or damage your sender reputation before you send. This clean list ensures only legitimate recipients receive your messages, reducing complaints and improving inbox placement.

Remove risky addresses before they harm your DMARC score

Many DMARC reports show spikes in failures not from malicious actors, but from sending to fake or misconfigured accounts. MailTester identifies these early—flagging catch-all domains, disposable emails, and role accounts you might not know are on your list. By filtering these out, you avoid accidental bounces and complaints that could lead to IP or domain reputation damage.

According to the Spamhaus Project, misconfigured or non-existent addresses are a common source of sender reputation harm, especially when large volumes are sent to them. A clean list reduces that risk—making your DMARC policy enforcement more reliable.

Improve DMARC report accuracy and inbox placement

When you send to lists with high invalid rates, DMARC reports can show false positives—indicating issues where none exist. This confuses your analysis and makes it harder to detect real policy violations. MailTester helps eliminate noise by verifying each address in bulk, ensuring your DMARC reports reflect actual threats, not technical glitches.

By using MailTester’s bulk email verification, you catch invalid and risky addresses before they trigger bounces or complaints. This improves your sender reputation, supports a tighter p=quarantine policy, and ensures that only legitimate recipients receive your messages—making your DMARC enforcement effective and sustainable.

Why email verification complements DMARC security

DMARC with p=quarantine guards your domain against spoofing, but it only works if your email volume comes from real, deliverable addresses. A list full of invalid or risky emails increases bounces and spam complaints—both of which damage sender reputation. Poor reputation can weaken DMARC enforcement, even if policies are correctly set. MailTester’s 98.9% accurate verification ensures only valid, deliverable addresses are used, keeping your bounce rate low and reputation strong—making DMARC more effective.

Bounces and spam warnings erode sender reputation

Every undeliverable email you send increases bounce rate. High bounce rates trigger sender reputation warnings with ISPs like Gmail and Outlook. Even one spam complaint can flag your domain. If your reputation drops, DMARC enforcement can be downgraded or ignored by receivers, especially if they’re unsure whether your messages are legitimate.

Valid addresses mean lower risk, stronger DMARC trust

With MailTester, you verify your list before sending. Its 98.9% accuracy identifies invalid, role, or disposable email addresses before they ever touch your campaign. Fewer bounces mean fewer red flags. Fewer spam complaints preserve your domain’s trust score. This stability lets DMARC remain effective—your p=quarantine setting stays enforced, not bypassed.

For a real-time check, use the email checker on individual addresses. For large lists, run a bulk verification to clean them upfront. If you're building an automated system, integrate the real-time verification API into your workflow. All of these reduce the risk that your outbound emails trigger spam filters, even when you already have p=quarantine configured.

Spam filters don’t just look at SPF and DKIM. They look at sending behavior, volume, and engagement. A clean list of real users supports better inbox placement, which strengthens the full security stack—including DMARC. As outlined in RFC 7483, policy enforcement assumes consistent, legitimate sending. If your sending behavior is inconsistent or high-risk, receivers may not follow your DMARC policy. Verification keeps your sending behavior within expected norms, so your policies are actually enforced.

Monitoring and refining your DMARC policy over time

You should review your DMARC aggregate reports monthly to spot sources of failed authentication, then use inbox-placement testing to confirm whether quarantined emails are actually landing in spam — only after validating real-world delivery and engagement results should you adjust sp=quarantine or p=quarantine. This ensures stronger protection without breaking legitimate sender workflows.

Track authentication failures with aggregate reports

DMARC aggregate reports (RUA) deliver daily summaries of how your domains perform across the internet. Each report shows which sending sources pass or fail SPF, DKIM, and DMARC checks. By scanning these monthly, you’ll identify unexpected senders — like misconfigured third-party tools or internal systems — that might be sending as your domain without proper authentication.

Use tools like dmarc.org or open-source parsers to analyze the XML data. Look for patterns: repeated failures from a single IP, new domains showing up with failed signatures, or spikes during campaign launches. These clues help you isolate and fix weak links before attackers hijack them.

Test real-world inbox placement before tightening policy

Just because an email fails DMARC doesn’t mean it’s blocked — it may just be quarantined. But quarantined messages often end up in spam folders, which harms engagement. Let’s be clear: DMARC policy enforcement is only as strong as your actual inbox placement.

This is where inbox-placement testing helps. Run tests through a service like MailTester’s inbox tester to simulate real delivery across Gmail, Outlook, Apple Mail, and others. If quarantined messages land in spam despite proper authentication, you may need to adjust your reporting or sender reputation — not the policy itself.

Only after observing consistent delivery patterns and stable engagement rates (open rates, click-throughs) should you consider shifting sp=quarantine to p=reject. Rushing this step risks losing valid traffic. DMARC is a defense mechanism; it should protect without punishing legitimate users.

Start small. Monitor. Adjust. Repeat.

Final checklist: Ensure your DMARC setup is secure

You’re protecting your domain. Set p=quarantine on your base domain to mark unauthorized emails as suspicious. Set sp=quarantine for subdomains to cover all branches. Send reports to a monitored address via rua so you can track enforcement and detect threats early. Validate your syntax and alignment using a trusted DMARC validator. And always clean your email list—remove invalid, disposable, and role-based addresses with a tool like MailTester before sending.

Check your DMARC policy parameters

Set p=quarantine for your base domain. This tells receiving servers to treat unauthenticated messages as suspicious, reducing inbox placement risk.
Set sp=quarantine for subdomains. Without this, attackers can exploit email sent from subdomains like login.yourcompany.com or support.yourcompany.com.
Use rua to send aggregate reports to a monitored email address. This helps detect spoofing attempts and verify that your policy is working as intended.

Verify configuration and list quality

Test your DMARC record syntax and alignment with a reputable validator like DMARCian's DMARC Record Checker or MXToolbox. Invalid syntax breaks enforcement.
Confirm SPF and DKIM alignment. A DMARC policy only applies when both SPF and DKIM pass verification. Use MailTester’s email checker to validate single addresses before sending.
Clear your list of invalid, disposable, and role addresses. These degrade sender reputation and increase the risk of being flagged as spam. Use MailTester’s bulk verification to validate entire lists at scale.
Monitor inbox placement over time with inbox placement testing. A drop in delivery rates may signal a misconfiguration or sender reputation issue.

Even with perfect DMARC, a poor-quality list can still harm deliverability. Clean data is the foundation of a secure, trusted email program.

Conclusion: sp=quarantine is not optional for modern email security

Setting sp=quarantine is not a minor configuration tweak—it’s a necessary layer in defending your domain. Without it, subdomains become attack vectors, and malicious actors can exploit weak policies to launch phishing campaigns under your brand.

When combined with DMARC’s p=quarantine policy, sp=quarantine ensures that even unauthorized emails sent from subdomains are flagged or isolated. This protects your sender reputation, reduces bounce rates, and improves inbox placement across major providers.

Strong email security starts with clean data. Use MailTester to verify your list—98.9% accurate verification ensures only valid, deliverable addresses remain. Your domain’s trust and deliverability reach their full potential when policy meets precision.

Sources

Only 22.9% of top domains enforce DMARC with p=quarantine or p=reject, while 29.2% remain in monitoring-only p=none mode that blocks nothing. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What happens if I don’t set sp=quarantine?

Without sp=quarantine, subdomains of your domain can be exploited by attackers to send spoofed or malicious emails without being quarantined. This harms your domain’s reputation and increases the risk of being flagged as spam.

Can I use sp=quarantine with p=none?

Yes, but only temporarily during DMARC rollout. Using sp=none with p=none gives you visibility without enforcement. Transition to p=quarantine and sp=quarantine once you understand your traffic patterns.

How long does it take for sp=quarantine to take effect?

DNS propagation typically takes 2 to 48 hours. After that, mail servers begin applying the policy based on their DMARC implementation.

Does sp=quarantine affect legitimate business emails?

Only if those emails fail SPF or DKIM checks. When properly configured, legitimate emails should pass authentication and avoid quarantining.

How do I monitor whether sp=quarantine is working?

Check your DMARC aggregate reports (via rua) to see if unauthenticated subdomain emails are being flagged. Use MailTester to verify your sending list remains clean.

Can MailTester help test my DMARC settings?

MailTester doesn’t validate DMARC records directly, but it helps by ensuring your email list is high-quality—reducing bounce rates and spam complaints that can harm your DMARC performance.

What’s the difference between p=quarantine and sp=quarantine?

p=quarantine applies to your main domain; sp=quarantine applies to subdomains. Using both ensures full domain coverage against spoofing.

Is sp=quarantine required for DMARC compliance?

No, it’s not required, but it’s strongly recommended. A full policy with both p=quarantine and sp=quarantine significantly reduces email fraud and improves deliverability.

What if my ESP doesn’t support sp=quarantine?

Most modern ESPs (SendGrid, Mailchimp, Klaviyo) support DMARC policies. If yours doesn’t, ensure your sending infrastructure aligns with SPF and DKIM to reduce risks.

Should I switch from p=none to p=quarantine?

Yes, once you’ve validated your infrastructure and reviewed DMARC reports. Start with p=quarantine, then gradually roll out full enforcement to minimize disruptions.