Does p=quarantine fully protect your subdomains?

You’ve set p=quarantine on your domain. Good move. But if a subdomain like help.yourcompany.com is sending email, is it really safe? Not unless you also set sp=quarantine on that subdomain’s SPF record.

Here’s the reality: p=quarantine only guards the domain itself. It doesn’t extend to subdomains by default. Without sp=quarantine on the subdomain, an attacker can still spoof it—even if your main domain is protected. The protection gap is real, and it’s often missed.

Why does this matter? Because attackers target subdomains regularly. They’re trusted, often poorly monitored, and commonly used in phishing. A single unsecured subdomain can expose your whole brand.

Key takeaways

  • p=quarantine on the parent domain does not protect subdomains unless sp=quarantine is explicitly set on the subdomain’s SPF record.
  • Without sp=quarantine, subdomains remain vulnerable to email spoofing despite valid p=quarantine at the parent level.
  • Always audit subdomain SPF records—not just the root domain—to close spoofing gaps in your email security posture.

How SPF record handling works across domains and subdomains

You can’t rely on a parent domain’s SPF setting to protect its subdomains—unless you explicitly configure SPF records for each subdomain. SPF records are evaluated per domain, not inherited across parent-child hierarchies. If a subdomain sends email, it needs its own SPF record with sp=quarantine or sp=reject to enforce policies. Without it, the subdomain's mail isn’t protected, even if the parent domain has strong SPF.

SPF is domain-specific, not inheritance-based

SPF records are tied to the domain they’re published under. That means example.com’s SPF doesn’t enforce rules for mail sent from blog.example.com unless explicitly told to. The DNS system treats each domain or subdomain as a separate entity. This is how you prevent unauthorized senders from using any subdomain in your ecosystem.

Let’s say your marketing team sends emails from newsletter.example.com. If that subdomain lacks an SPF record, or if it includes only the parent domain’s SPF (without the proper include or all mechanisms), mail from it could be silently accepted or rejected based on the parent record’s settings—often without proper enforcement.

Why subdomains need independent SPF setup

Even if your main domain uses p=quarantine, that only applies to messages sent from @example.com. Subdomains like [email protected] or [email protected] must have their own records to enforce policy. Otherwise, they’re vulnerable to spoofing and deliverability issues.

Some organizations use automated systems to generate subdomain SPF policies—but it’s easy to miss one. That’s why sending teams should validate SPF across all domains in their ecosystem. Tools like our email checker can confirm if a specific address is sending from a valid, properly configured domain.

The RFC 7208 specification confirms this behavior: SPF results are evaluated per domain name lookup. No parent-child inheritance occurs by default. This design prevents accidental exposure but also requires active management. As the IETF document notes, “SPF policies apply to the sender domain as reported in the Message-Id header and the From domain.”

For organizations sending from multiple domains or subdomains, this means proactive SPF auditing. A single missing record can break deliverability for a key service. Use bulk verification to test all email addresses across your domains and catch SPF misconfigurations before they hit the inbox.

The role of sp=quarantine in SPF alignment

Without sp=quarantine, subdomains that fail SPF authentication receive no explicit instruction from the receiving server on how to handle the message—meaning they may be delivered with no warning, even if suspicious. This leaves email systems vulnerable to spoofing on branded subdomains. Setting sp=quarantine ensures that incoming mail from subdomains failing SPF is treated with caution, reducing the chance of malicious messages bypassing filters.

How sp=quarantine protects subdomains

When you set p=quarantine in your SPF record, you're telling receivers: "If the sender’s domain fails SPF, treat the message like spam." But that only applies to the base domain. Subdomains—like mail.yourcompany.com—are separate unless explicitly addressed.

That’s where sp=quarantine comes in. It’s the subdomain-specific counterpart to p=quarantine. If a message arrives from a subdomain and its SPF record fails, sp=quarantine tells the receiving server: "Don’t deliver it outright—quarantine it." Without this, the subdomain's failure goes unnoticed, and the message might land in the inbox.

It’s a common misstep to assume that setting p=quarantine covers all subdomains. It doesn’t. If subdomains have their own SPF records that fail, or if they rely on the parent’s SPF without alignment, they’re exposed. This is why sp=quarantine is essential for organizations with complex email infrastructures.

For example, if your marketing team uses newsletter.yourcompany.com and the SPF check fails there, sp=quarantine ensures the message gets flagged—not allowed through. Without it, the sender’s reputation could be eroded without warning.

Best practices for SPF alignment

Use both p=quarantine and sp=quarantine. It’s not optional if you control multiple subdomains. Many enterprise systems rely on subdomain-specific policies, and skipping sp=quarantine weakens your entire email defense. It’s an industry-standard practice to align authentication policies across all levels of domain hierarchy.

Consider checking your SPF record’s alignment using tools that verify your full configuration. You can test individual addresses or entire lists to ensure they pass SPF, DKIM, and DMARC checks. Real-world testing helps uncover issues before your messages hit inboxes.

For teams sending bulk communications, it's worth verifying your entire email list. You can clean out bad addresses before sending, saving reputation and inbox placement. The MailTester bulk verification tool helps identify invalid, catch-all, or risky addresses that could trigger filters—even if they’re technically “valid.”

Why relying on p=quarantine alone leaves a gap

You can’t fully protect subdomains with p=quarantine alone because it only applies to the main domain’s SPF policy. If a subdomain lacks SPF, has a malformed record, or uses a misconfigured policy, DMARC has no way to enforce it — letting attackers send from those subdomains without penalty. The result? Spoofing risks remain unblocked, even if your core domain is secure.

SPF enforcement gaps on subdomains

Let’s be clear: a subdomain’s SPF record is independent of the parent domain’s policy. If a subdomain doesn’t have an SPF record, or has one that’s invalid or misconfigured, DMARC doesn’t flag it when p=quarantine is set. You’re relying on a policy that only covers what the parent domain defines — not what subdomains do.

That means spammers can target subdomains with outdated configurations or no SPF at all. They send messages that pass DMARC checks (because the policy doesn’t apply), and land in inboxes anyway. No quarantine. No warning. No enforcement.

Why this exposes your brand

When attackers abuse subdomains, especially those that look like they belong to you, it damages your sender reputation. Even if the subdomain isn’t yours, users may think it is — especially if it uses a similar name or looks official. Each such message increases the risk of being marked as spam.

DMARC with p=quarantine stops abuse on your main domain, but it doesn’t stop subdomain spoofing. That’s why a complete email security strategy needs to ensure every subdomain has its own valid SPF record — and that those are checked regularly. If you’re relying only on p=quarantine, you’re missing the real attack surface.

Tools like Bulk Email List Verification can test your sending infrastructure for SPF and DMARC consistency across all domains and subdomains, helping you spot weaknesses before attackers exploit them.

For deeper email validation, you can also use the real-time email verification API to check sender domains and subdomains at scale. It’s not just about sending — it’s about ensuring the entire email path is secure and compliant.

As outlined in RFC 7672 and confirmed by industry analysis from organizations like Spamhaus, domain alignment and strict policy enforcement are critical to reducing spoofing. But policies like p=quarantine are incomplete unless they’re backed by solid SPF records across all subdomains.

What happens when a subdomain has no sp=quarantine?

If a subdomain lacks an sp=quarantine policy in its SPF record, the receiving server sees a failed SPF check but has no clear instruction on how to handle it. It may accept the message, reject it outright, or quarantine it—depending on the server’s local rules. This inconsistency means the same email can end up in the inbox, spam folder, or bounce based solely on the recipient’s configuration, not the sender’s intent.

Why policy clarity matters for subdomains

SPF is designed to let senders define how their domains (and subdomains) should be handled if a message fails validation. Without sp=quarantine defined, you’re leaving the decision to the receiving server. Some systems default to acceptance, others to rejection, and some to quarantine—this lack of uniformity harms deliverability.

For example, a major email provider may treat a failed SPF check as a soft bounce if there’s no policy, while another may flag the message as spam. This inconsistency means your emails may land in spam folders even if your main domain is trusted. It also increases the risk of hard bounces when the recipient’s server chooses to reject the message outright.

Real-world impact on email performance

Subdomains without sp=quarantine often see higher spam rates or delivery failures, especially when used for transactional or marketing campaigns. Without a clear signal to the receiving server, there's no consistent expectation of how to treat non-compliant mail.

According to the SPF specification (RFC 7208), it’s not mandatory to include sp=quarantine—but leaving it out means you’re not guiding recipients on how to respond to subdomain failures. This is a gap in alignment, not a technical error, but the effect is real: unreliable delivery.

Let’s say you send emails from newsletter.yourcompany.com. If that subdomain has no SPF policy, and the email fails SPF validation, the receiving server may not know whether to accept it, mark it as spam, or bounce it. The outcome is unpredictable—and that unpredictability hurts sender reputation, especially at scale.

Using tools like MailTester’s bulk verification helps catch these issues early. You can test whether subdomains are properly configured, identify invalid or unverifiable addresses, and audit your email infrastructure for SPF, DKIM, and DMARC alignment—before sending to thousands.

A real-world example: unsecured subdomain abuse

SPF’s p=quarantine on the root domain doesn’t protect subdomains unless sp=quarantine is set there too. Without it, attackers can spoof emails from subdomains like newsletter.company.com—especially if those subdomains lack SPF records entirely—because SPF only checks the sending domain at the domain level. Even with strong policies on the parent domain, unsecured subdomains remain a blind spot.

How the attack works

  1. Malicious sender uses newsletter.company.com A threat actor sends spam or phishing emails from newsletter.company.com. The domain is valid, but no SPF record exists on the subdomain. SPF doesn't validate the subdomain by default, only the root domain.
  2. Root domain has p=quarantine, but sp=quarantine is missing The parent domain company.com includes an SPF record with p=quarantine, meaning emails from the root domain that fail SPF checks get quarantined. However, the subdomain newsletter.company.com has no SPF record, so SPF doesn’t even evaluate it. No policy means no enforcement.
  3. No SPF check means no rejection or quarantine Since the subdomain has no SPF record, the receiving server skips SPF validation entirely. The message passes unchecked. SPF only applies when a record exists, so empty or missing records are ignored. The sender’s origin isn’t verified.
  4. Attack continues undetected The malicious email appears to come from a legitimate source. Recipients see newsletter.company.com in the From field. Because the root domain’s policy doesn't apply to subdomains without explicit sp=quarantine, the email bypasses protection completely.
  5. Aftermath: branding damage, reputation loss If the attack succeeds, recipients report the email as spam. ISPs may flag the entire company.com domain for poor sender reputation—even though the subdomain is misused. This damages future deliverability for all legitimate emails.

How to fix it

Set sp=quarantine on subdomains that send email. If you use newsletter.company.com, create an SPF record there: v=spf1 include:_spf.company.com ~all with sp=quarantine. Without it, SPF is blind to abuse.

Use tools to test your subdomain configurations. MailTester’s email checker can verify whether a specific address passes SPF checks in real time. Combine this with bulk verification to audit entire lists before sending. It’s not just about the root domain—every sending subdomain must be secured.

How to fix SPF misconfigurations that expose subdomains

If your SPF record uses p=quarantine at the parent domain level but doesn’t declare sp=quarantine for individual subdomains, those subdomains can still be exploited by attackers or misconfigured senders—because SPF evaluates each domain independently. The sp= policy only applies if explicitly set for that subdomain. Without it, a subdomain’s SPF is effectively unprotected even if the parent domain is secured.

Check SPF across your full domain hierarchy

  • Use a tool that scans every subdomain in your ecosystem—like MailTester’s bulk verification tool—to identify which ones lack proper SPF policies.
  • Many organizations assume the parent SPF covers subdomains, but RFC 7208 clearly states SPF policies are domain-specific and must be explicitly defined for each subdomain if you want consistent protection.
  • Look for missing, malformed, or overly permissive SPF records on subdomains you control (e.g., mail.yoursite.com, newsletter.yoursite.com).

Align subdomain SPF policies with parent domain intent

  • For every sending subdomain, make sure sp=quarantine is included in its SPF record—especially if the parent policy uses p=quarantine.
  • The sp= mechanism is specifically designed to allow subdomain-specific enforcement, so relying on the parent policy alone leaves a gap.
  • If your parent domain uses p=none or p=reject, ensure all subdomains follow the same intent: if you want rejection, use sp=reject; if quarantine, use sp=quarantine.
  • Use MailTester’s real-time verification API to test SPF outcomes before sending—this helps catch misconfigurations before they trigger a delivery failure or abuse risk.
  • After updating SPF records, verify their propagation and effectiveness using tools like MXToolbox or DNS lookups—don’t assume changes were applied correctly.
Even small misconfigurations in SPF can allow attackers to spoof your subdomains. A single missing sp=quarantine can undo the security of your entire email ecosystem.

DMARC enforcement and the importance of sp=quarantine

DMARC won’t enforce your policy across subdomains unless you set sp=quarantine. Without it, failed SPF checks on subdomains don’t trigger any action—meaning attackers can exploit them without consequences. This weakens your overall DMARC coverage and hurts sender reputation, even if your main domain is secure.

How DMARC uses SPF and DKIM to decide what to do

DMARC decisions are based entirely on SPF and DKIM results. If a message passes both, DMARC allows delivery. If it fails SPF but passes DKIM, DMARC applies the policy defined in the rua and ruf reports—but only if an enforcement action is set.

Let’s say you have a subdomain like newsletter.example.com. If it sends mail with a forged sender but a valid DKIM signature, and your DMARC policy is p=quarantine but sp=none, no quarantine happens. The message lands in the inbox anyway—despite failing SPF.

Why sp=quarantine is critical for subdomain protection

Setting sp=quarantine ensures that even if a subdomain fails SPF, DMARC will apply the same safeguard. Without it, your policy only applies to the main domain, leaving subdomains wide open to abuse. According to the DMARC specification, this inconsistency undermines the goal of consistent enforcement across your entire domain infrastructure.

Attackers increasingly target subdomains because they’re often misconfigured or overlooked. If SPF fails there and sp=none, DMARC does nothing. That means malicious emails—using your brand—can still reach inboxes, eroding trust and hurting deliverability.

You don’t need to enforce sp=quarantine on every subdomain if they’re not sending mail, but for any that do, it’s a simple but vital step. It ensures your policy acts consistently whether the message comes from example.com or accounting.example.com.

Use tools like MailTester’s email checker to validate your sender setup, including SPF records and DMARC alignment, before sending to your full list. It helps ensure your domain policies are properly structured and applied, protecting both your main domain and any subdomains that send mail.

A comparison of SPF policies across domains and subdomains

You might think setting p=quarantine on your domain stops bad emails, but it only applies to the main domain—it doesn’t protect subdomains. Without sp=quarantine, your subdomains can be exploited even if your primary domain is secure. SPF doesn’t automatically extend to subdomains unless explicitly configured.

Why the Base Domain Policy Isn’t Enough

Most organizations manage their email authentication at the root domain level. But SPF’s p=quarantine policy only governs the domain named in the record. Subdomains like newsletter.yourcompany.com or support.yourcompany.com are untouched unless they have their own SPF record or inherit the policy via sp=quarantine.

Let’s say your marketing team sends emails from campaigns.yourcompany.com using an external service. If that subdomain lacks proper SPF alignment, attackers can spoof it—even if your main domain is protected. This gap is a common entry point for phishing and spoofing campaigns.

The Full Protection: Alignment with sp=quarantine

To close this loophole, you must include sp=quarantine in your SPF record. This tells receiving servers to apply the same policy to subdomains. RFC 7208 (the SPF standard) specifies that sp= controls subdomain policy, just as p= governs the base domain.

The full, secure configuration looks like:

Policy Effect on Base Domain Effect on Subdomains Recommended?
p=quarantine Mark unauthorized senders as suspicious Does not apply No — creates a blind spot
sp=quarantine Not set Applies quarantine to subdomains only Only if base domain is also secured
p=quarantine sp=quarantine Full protection for domain Full protection for subdomains Yes — recommended for complete alignment

Without sp=quarantine, your subdomains remain vulnerable even if the root domain is properly authenticated. This is a real gap—verified by DMARC reports from organizations that missed the sp parameter. The SPF specification makes this explicit: sp= exists for a reason.

Use a trusted verification tool to check your SPF setup across domains and subdomains. You can test your full email infrastructure at MailTester’s bulk verification tool, which checks SPF, DKIM, and DMARC alignment in real-time.

How MailTester helps catch domain configuration flaws

SPF’s p=quarantine only applies to the domain itself, not subdomains unless sp=quarantine is explicitly set. Without it, subdomains inherit the default policy (usually p=none), allowing unauthorized senders to abuse them. MailTester checks both the domain and subdomain alignment across SPF, DKIM, and DMARC, flagging missing sp=quarantine settings and other misconfigurations that leave your branding exposed.

Spot issues before they trigger blocks

  • Run bulk verification on your email list to identify addresses that fail validation due to flawed domain policies — including those under subdomains misconfigured with p=quarantine but missing sp=quarantine.
  • Use the inbox-placement tester to simulate sending under your current SPF/DKIM/DMARC setup and see whether emails land in inboxes or get quarantined — even if your authentication passes on paper.
  • Verify individual addresses via the real-time email checker to test whether a message to a subdomain recipient actually delivers or is silently dropped due to policy gaps.
  • Integrate MailTester with SendGrid, Mailchimp, HubSpot, or Klaviyo to validate sender configurations in real time before sending to large lists.
  • Use the in-app AI assistant to parse complex SPF, DKIM, or DMARC results and provide plain-English explanations — including why sp=quarantine is needed for subdomains.

Fix what standard tools miss

Many tools only validate the root domain policy. MailTester goes deeper: it checks whether your subdomains — especially those used for newsletters, support, or marketing — are protected from spoofing via proper SPF sp=quarantine configuration. This is especially relevant when using cloud-based email services or shared sending platforms.

DMARC reports from major ISPs like Gmail or Yahoo often show alignment failures that stem from subdomain misconfigurations. While RFC 7208 defines DMARC behavior, enforcement varies — and only consistent, thorough checks catch these drifts. The DMARC specification explicitly separates domain and subdomain policies, making sp=quarantine mandatory for full protection.

With MailTester, you’re not just testing if an address is valid — you’re testing whether your full sending environment is secure. For teams sending at scale, this means fewer bounces, lower blocklist risk, and better inbox placement.

Start with free, risk-free testing: verify 100 emails at no cost at MailTester’s bulk verification tool.

Final takeaway: protect subdomains with sp=quarantine

p=quarantine alone does not protect subdomains. Without an explicit sp=quarantine directive in each subdomain’s SPF record, mail receivers treat those subdomains as untrusted sources, even if your main domain has a strict DMARC policy.

Each sending subdomain must include sp=quarantine in its SPF record to inherit the same protection. Failing to do so exposes your domain’s reputation — a single misconfigured subdomain can undermine hours of deliverability work.

How to enforce compliance

  • Review SPF records across your entire domain estate using automated tools.
  • Verify that every sending subdomain explicitly includes sp=quarantine.
  • Test configurations with real-world deliverability checks to catch failures early.

Sources

Keep reading

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

Frequently asked questions

What does p=quarantine do?

It instructs receiving servers to quarantine emails from the domain if SPF fails, rather than reject or accept them.

Does p=quarantine apply to subdomains?

No — p=quarantine only applies to the domain where it is set. Subdomains need their own sp=quarantine policy.

Is sp=quarantine required for SPF to work?

No — but it’s required to protect subdomains. SPF still functions without it, but security is incomplete.

Can a missing sp=quarantine cause email delivery issues?

It doesn’t directly block delivery, but it creates a security gap that increases the risk of spoofing and DMARC failures.

How can I check if my subdomains have sp=quarantine?

Use DNS tools like MxToolbox or MailTester’s verification API to inspect SPF records for subdomains.

Does MailTester check SPF records for subdomains?

Yes — its real-time API validates individual emails and can detect SPF misconfigurations across sending domains and subdomains.

Why is sp=quarantine not included in most SPF records?

It’s often overlooked in configuration, especially when subdomains are managed separately from the parent domain.

Can I use DNS-based verification instead of email verification?

DNS checks confirm policy presence but don’t validate real email delivery. MailTester tests both.

What happens if I set p=quarantine but not sp=quarantine?

The parent domain is protected, but subdomains remain unsecured. Senders can still abuse them without consequence.

How accurate is MailTester’s email verification?

MailTester achieves 98.9% accuracy in verifying email addresses and detecting delivery issues, including SPF and DMARC risks.

Do Email verification services like MailTester require technical setup?

No — it offers bulk checks, real-time API, and integrations with Mailchimp, HubSpot, Klaviyo, and SendGrid.

Do purchased credits on MailTester expire?

No — once bought, credits never expire, allowing teams to maintain consistent verification workflows.