Correct DMARC Syntax for p=quarantine and sp=quarantine Settings

What is the correct DMARC syntax for p=quarantine and sp=quarantine?

You’ve set up SPF and DKIM, but your emails still don’t land in inboxes. Why? One reason: your DMARC record isn’t enforcing what it should. You’re missing a critical piece.

The right DMARC syntax for enforcing quarantine on both aligned and non-aligned messages is simple: v=DMARC1; p=quarantine; sp=quarantine;. This tells mail servers to treat any email failing DMARC checks—whether aligned or not—as suspicious.

It’s not about sending more emails. It’s about sending them correctly. A working DMARC record isn’t optional; it’s how you prove authenticity at scale.

Key takeaways

• The correct DMARC syntax for both p=quarantine and sp=quarantine is v=DMARC1; p=quarantine; sp=quarantine;.
• Setting p=quarantine applies the policy to emails from your domain with aligned authentication; sp=quarantine applies it to subdomains.
• This record must be published as a DNS TXT record under _dmarc.example.com, not in the root zone or as a CNAME.

Why use p=quarantine and sp=quarantine together?

You should use p=quarantine and sp=quarantine together to ensure that any email not aligned with your domain's authentication policies gets flagged as suspicious and routed to the spam folder, not outright blocked. This reduces the risk of accidentally rejecting legitimate emails due to misconfigurations or third-party delivery quirks, while still actively deterring spoofing attacks. It’s the sweet spot for organizations that want strong anti-fraud protection without compromising deliverability during transitional phases.

How it protects without overblocking

Using p=quarantine and sp=quarantine means that only messages failing both SPF and DKIM alignment are moved to spam—no outright rejections. This is critical when you’re onboarding new senders, using third-party platforms that don’t fully align with your domain, or managing a shifting email environment. A hard p=reject policy might block messages from trusted partners during setup or migration, but quarantine gives you breathing room.

For example, if a newsletter is sent via a vendor's system with a non-aligned From header, the email won’t be bounced. Instead, it lands in the spam folder, where users can still access it—no lost communication, but clear warning that the message is suspicious. This approach reflects how most modern email providers (like Gmail and Outlook) evaluate messages in practice.

Industry standards, such as those outlined in RFC 7483, recommend a phased deployment of DMARC policies. Starting with none or quarantine before moving to reject allows you to monitor your domain’s email flow, identify misconfigurations, and fix them without affecting delivery.

Balancing security and reliability

Most organizations that rely on third-party platforms (marketing automation, helpdesk tools, payment processors) can’t guarantee perfect alignment across all systems. sp=quarantine ensures that even messages from untrusted subdomains or non-aligned sources are not delivered to the inbox—but they are not lost either.

This setup is especially useful in mid-to-large enterprises, where email governance spans multiple teams, platforms, and geographies. You’ll catch spoofing attempts, reduce phishing risk, and improve user trust—all while maintaining reliable delivery of real messages.

For teams testing DMARC alignment or validating sender compliance before enforcing strict policies, MailTester’s inbox placement tester helps validate how your messages land across major inboxes under different DMARC settings. That insight is critical when deciding when to escalate to p=reject safely.

How does DMARC alignment work with p=quarantine?

DMARC enforces email authentication by requiring alignment between the From: header and the domain used in SPF or DKIM. When you set p=quarantine, failing alignment means receiving servers may treat the message as spoofed and mark it as suspicious or move it to spam. This protects users by reducing phishing risks but can block legitimate emails if alignment isn’t properly configured.

What does alignment mean for SPF and DKIM?

For SPF, alignment means the domain in the MAIL FROM (envelope-from) must match the domain in the From: header. If your sender domain is example.com but your SPF check uses mail.example.com, alignment fails.

For DKIM, the domain in the signature must exactly match the domain in the From: header. If the signature is signed with dkim.google.com but the From: header says example.com, the email won’t align — even if the DKIM signature is valid.

Why does quarantine matter when alignment fails?

DMARC policies like p=quarantine tell receiving servers: “If the email fails authentication or alignment, don’t deliver it to the inbox. Treat it as potentially fraudulent.” This isn’t a hard rejection — it’s a soft block. The email might land in spam or be held for manual review.

Let’s say you send a newsletter from [email protected], but your SPF record uses send.example.net. The alignment fails. Even if SPF passes, DMARC fails. Receiving servers, especially those using strict enforcement like Gmail or Microsoft, may quarantine the message.

According to RFC 7483, DMARC alignment is not optional. It’s a core component of email authentication. Without it, even correctly signed or authenticated messages can be treated as spoofed. You can check for alignment issues using tools that test email headers — for example, the Spamhaus Lookup can help verify domain reputation, and MxToolbox’s DMARC tool gives real-time reports on policy and alignment status.

Before you send bulk campaigns, verify your setup with a real-time email checker. Use MailTester’s inbox placement tester to simulate how your messages land in major inboxes — even with p=quarantine in effect. If alignment is off, you’re risking deliverability long before the first bounce.

Common syntax errors in DMARC records with quarantine policies

You might be using p=quarantine in your DMARC record, but if the syntax is wrong, your policy won’t enforce. Common mistakes include missing the v=DMARC1 tag, using uppercase letters, forgetting semicolons, or confusing p=quarantine with p=reject. These small errors can leave your domain unprotected. Let’s go over the key ones you should fix now.

The basics you can’t skip

• Always start your DMARC record with v=DMARC1. Without it, DNS resolvers ignore the entire record — no matter what comes after.
• Use lowercase for all tags: v=DMARC1; p=quarantine; sp=quarantine;. While DNS is case-insensitive, some validating tools expect lowercase, and inconsistencies can cause parsing failures.
• End every tag with a semicolon. Omitting even one — such as p=quarantine instead of p=quarantine; — breaks the record. It’s a syntax requirement, not a suggestion.

Mistakes that mislead your email security

• Don’t mix up p=quarantine with p=reject. Quarantine means the email gets marked as suspicious or sent to spam, but still delivered. Reject means the sending server is told the email is invalid and blocked outright. Using reject is stricter; quarantine is safer for testing.
• Test your DMARC record with a tool that checks DNS syntax. The DMARC.org site provides a validator, and RFC 7483 (the DMARC specification) defines the exact format you must follow.
• Double-check all tags. A missing semicolon or typo like P=QUARANTINE may seem harmless, but some tools flag it as invalid. Even minimal errors can prevent enforcement.
• If you're setting default policy for subdomains (sp=quarantine), make sure it’s present. Skipping sp leaves subdomains unprotected unless you explicitly set them.

Getting this right means your domain’s mail policy works as intended. A correctly structured record helps prevent spoofing and improves inbox placement. After validation, test your setup using a real-time inbox-placement tool — MailTester’s inbox placement tester checks how your messages land across major providers, including Gmail and Outlook, so you can verify the full effect of your DMARC policy.

How to test your DMARC record syntax for correctness

Set your DMARC record with p=quarantine and sp=quarantine only after verifying the syntax is correct. Use a tool like MxToolbox or DNS Checker to confirm the TXT record exists and starts with v=DMARC1. Ensure no invalid tags, spaces, or malformed values (like p=invalid) are present. Test across multiple DNS resolvers to rule out caching issues during propagation.

Step-by-step syntax verification

1. Confirm the record starts with v=DMARC1 — this is mandatory. Any deviation, like v=DMARC or missing v=, breaks DMARC validation. Use RFC 7483 as the reference standard for syntax.
2. Check that you’re using only valid tags — p=quarantine, sp=quarantine, rua, ruf, fo, and pct are all standard. Avoid unknown tags like policy=block — they’re ignored or cause parsing failure.
3. Look for extra spaces or quote errors — values must not include leading/trailing whitespace or incorrect quoting. For example, p = quarantine or p="quarantine" are invalid. The correct format is p=quarantine with no quotes.
4. Validate using multiple DNS resolvers — DNS propagation isn't instant. Use tools like MxToolbox or DNS Checker to query your record across geographically diverse servers. This catches caching delays or inconsistent publishing.
5. Verify tag order doesn't affect validity — DMARC records are tag-ordered, but parsers ignore order. Still, keep them readable. Avoid mixing v=DMARC1 with other TXT records under the same name — each domain should have only one DMARC record.

Common mistakes to avoid

• Don’t set p=none if you want enforcement — p=quarantine is only effective once properly published and validated.
• Avoid including multiple DMARC records for the same domain — this causes errors and breaks authentication.
• Ensure rua points to a valid email address for aggregate reports. An invalid or nonexistent address won’t break DMARC but disables reporting.

Once your record is clean, monitor inbox placement. Even with correct syntax, deliverability depends on sender reputation and mailbox provider policies. For a comprehensive check, test real email delivery across inboxes with inbox placement testing.

What happens when a domain has p=quarantine but no SPF or DKIM?

If your domain sets a DMARC policy of p=quarantine but lacks both SPF and DKIM records, every email sent from that domain will fail alignment. Since no authentication is in place, DMARC sees all messages as unverified. As a result, those emails will be marked as suspicious and routed to spam or junk folders, even if they're legitimate. This breaks inbox delivery for all outbound mail.

Alignment is mandatory — and failed without SPF or DKIM

DMARC only works when it can verify that an email passed SPF or DKIM. Without either, the alignment check will fail. Even if you have a strong sender reputation, that doesn’t matter if the core authentication is missing. This is why a p=quarantine policy is dangerous when no baseline authentication exists: it actively harms deliverability.

Let’s be clear: this isn’t a configuration error that just delays delivery. It’s a complete failure to reach inboxes. Even emails sent from your company’s official domains — like your CEO’s address — will get tagged as suspicious if they lack SPF or DKIM. That’s the reality of DMARC enforcement. Major email providers use this rule consistently, and you can’t rely on exceptions.

Fixing this requires action — not more policies

Setting a DMARC policy without SPF or DKIM is like putting a red stop sign at a crosswalk with no traffic lights. The sign means something, but no system is in place to enforce it. You cannot "fix" deliverability by adjusting the p=quarantine setting. The real fix is adding proper SPF and DKIM records that align with your sending sources.

Once you do, DMARC can begin working as intended — giving you visibility and control over unauthorized sending. Without that foundation, your domain is delivering messages into the spam zone by default. It’s a critical failure point that affects every email sent from your domain.

Use tools like inbox placement testing to check how your emails are being received across major providers. You can also use our email checker to validate individual addresses before sending, or bulk list verification to clean outdated or invalid addresses that might trigger spam filters. These tools help you spot misconfigurations early and ensure your sending infrastructure is solid.

For more on how DMARC works, see the specification at RFC 7489. The standard outlines why alignment is required and how policies like p=quarantine are applied based on authentication results.

How DMARC policies differ: p=none, p=quarantine, p=reject

DMARC policies control what happens when an email fails authentication. Use p=none to collect reports without affecting delivery, p=quarantine to flag failures as spam, or p=reject to block them outright. Start with p=quarantine to monitor alignment and reduce spam risk before moving to p=reject only when you're confident all legitimate senders are properly authenticated.

Policy options and practical outcomes

When setting a DMARC record, the p tag defines how receivers should handle authentication failures. Each setting has a different impact on deliverability and security:

According to RFC 7483, DMARC’s core purpose is to allow domain owners to specify how receivers should handle unauthenticated messages. The policy settings reflect evolving levels of enforcement, from passive reporting to active blocking.

Let’s be clear: p=quarantine isn’t a full stop—it’s a warning. It gives you room to audit your email flows and fix misconfigurations without cutting off legitimate senders. You can test this in a real-world scenario by using a service like inbox placement testing to see how your messages land across Gmail, Outlook, and other inboxes under different DMARC settings.

How to validate DMARC compliance with real email traffic

You can validate DMARC compliance with real email traffic by testing your policy in a controlled, incremental way: start with p=none to collect data, verify alignment using inbox placement tools like MailTester’s inbox tester, monitor aggregate reports (RUA), and only move to p=quarantine after confirming no critical emails are failing. Once safe, step to p=reject with confidence. Never apply p=reject without first verifying alignment in live inboxes.

Test the real-world impact of your DMARC policy

• Use inbox placement testing tools — such as MailTester’s inbox tester — to send test emails to real inboxes and observe whether they land in the primary inbox, spam, or are blocked. This reveals the actual impact of your current DMARC policy (e.g., p=none) on deliverability.
• Check your RUA (Reporting URI for Aggregate) reports from receiving domains to spot alignment failures. These reports show which emails are being rejected due to SPF or DKIM misalignment, even when the domain appears valid.
• Ensure every sending source (sender domain, subdomain, email service) is properly aligned with your DMARC policy. Misaligned DMARC is a common reason for false positives; it breaks authentic email streams.

Adopt DMARC policies progressively and safely

• Begin with p=none. This logs issues without affecting delivery. Use this phase to gather data on real email traffic, identify misconfigured or spoofed sources, and fix them.
• After 7–14 days of logging, move to p=quarantine only after confirming no legitimate emails are being marked as suspicious. This step quarantines misaligned messages—no blocking, but they land in spam.
• Test the quarantine policy with real outbound email flows. Tools like MailTester’s inbox placement tester let you simulate high-volume sends and see whether your emails reach inboxes reliably.
• Only then, once you're confident alignment and deliverability are consistent, apply p=reject. This tells receiving servers to reject emails that fail authentication.
• Never skip testing with real traffic. An incorrect policy can disrupt transactional emails, marketing sends, or support workflows — especially if third-party services aren’t aligned.
• Keep your policy active even after reaching p=reject, and continue monitoring RUA reports. DMARC is not a one-time setup; alignment issues can emerge from changed infrastructure or new partners.

DMARC works best when enforced in stages. The IETF's RFC 7483 defines these policy options clearly: p=reject is strong, but only effective when you understand how your emails behave in real-world mail flows. Let data guide you, not timing or hype.

Why verifying your domain's DMARC settings is just the first step

Having correct DMARC syntax for p=quarantine and sp=quarantine is necessary but not enough. A well-formed record doesn’t stop your emails from being quarantined if your sender reputation is weak, your list has high bounce rates, or you’ve triggered spam traps. Deliverability depends on behavior, not just configuration.

DMARC is a gatekeeper, not a deliverability guarantee

DMARC tells receiving servers what to do with emails that fail authentication, but it doesn’t assess the quality of your sending practices. Even with p=quarantine set correctly, an email can land in spam if your domain has a poor sending history, inconsistent volume, or a high ratio of hard bounces.

For example, some domains with correct DMARC alignment still get filtered due to past spam activity or poor list hygiene. According to Return Path’s research, sender reputation accounts for up to 85% of inbox placement decisions, far outweighing DNS record correctness alone.

Prevent delivery failures by cleaning your list

Let’s be clear: even a perfectly configured DMARC record won’t help if you're sending to disposable emails, inactive addresses, or role accounts like admin@, support@, or info@. These accounts rarely open emails and often trigger spam traps or automatic feedback loops.

Use bulk email verification to identify and remove such addresses before sending. Tools like MailTester's bulk list verification help detect invalid, disposable, or high-risk addresses at scale—reducing bounce rates and protecting your sender reputation.

You can also test your deliverability with an inbox placement tool like MailTester's inbox tester to see how your message arrives across major providers. It’s not about setting a single DNS record—it’s about building trust through consistent, clean, and respectful sending behavior.

How MailTester helps validate and improve DMARC effectiveness

You don’t need MailTester to set up DMARC records, but you do need it to test whether your email infrastructure actually enforces them. It checks if your domains comply with DMARC policies like p=quarantine and sp=quarantine by simulating real-world delivery—and revealing whether messages aligned with your DMARC policy actually reach inboxes or get blocked. This is the real test of whether your policy is working.

Testing DMARC enforcement across real inboxes

DMARC is only as strong as its enforcement. A policy like p=quarantine is meaningless if receiving mail servers ignore it. MailTester’s inbox-placement testing sends messages through Gmail, Outlook, Yahoo, and other major providers to see if DMARC-aligned emails land in the inbox—or are flagged as spam. You can’t rely on DNS-only checks; this real delivery simulation shows the actual outcome.

Fixing misaligned addresses before they hurt your sender reputation

Even if your DMARC policy is correctly published, misaligned or invalid email addresses in your sends can still cause DMARC failures. For example, sending to a malformed address or one that doesn’t match your SPF or DKIM alignment breaks DMARC validation. MailTester’s bulk verification identifies these risks before you send, ensuring your list only contains addresses that can pass DMARC checks.

Using the real-time API, you can integrate this validation into your sending workflow—checking every address on the fly. This helps maintain sender reputation, which DMARC relies on. A poor reputation means even correctly aligned emails get quarantined or blocked, undermining your policy’s intent.

With 98.9% accuracy, MailTester gives you confidence that your verification results reflect real-world deliverability conditions. It doesn’t replace DNS configuration, but it tells you whether your infrastructure is ready to enforce DMARC policies like p=quarantine and sp=quarantine effectively. The goal isn’t just compliance—it’s inbox placement. And that’s the difference a reliable verification tool makes.

For organizations using multiple sending platforms, integrations with tools like Mailchimp, Klaviyo, and SendGrid help maintain consistency across email systems. These workflows, when combined with pre-send validation, ensure that every message sent aligns with your DMARC policy—before it's ever delivered.

Learn more about how MailTester helps verify email lists at scale: bulk email verification, or use the real-time API to automate checks. You can also test delivery to real inboxes with inbox-placement testing—a key step in validating DMARC effectiveness.

Conclusion: Use p=quarantine for safer DMARC enforcement

The correct syntax for full quarantine enforcement is v=DMARC1; p=quarantine; sp=quarantine;. This policy instructs receiving servers to quarantine messages that fail DMARC checks, reducing the risk of legitimate emails being blocked outright.

Test before you enforce

Begin with p=none to collect data on email flow and alignment failures. When confident in your setup, transition to p=quarantine for a testing phase. Only after validating deliverability should you move to p=reject for full enforcement.

Pair policy with clean lists

DMARC works best when paired with accurate, up-to-date email lists. Valid addresses reduce alignment failures and lower spam scores, ensuring your policy is effective in practice, not just theory.

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

• Email authentication: SPF, DKIM, DMARC, BIMI and MTA-STS (complete guide)
• DKIM Signature Failure Due to IDN Punycode Misconfiguration in DNS
• DKIM t= Timestamp Must Be in UTC for Email Verification Success
• SPF Authentication Fails with AAAA DNS Records for Email Servers
• Email Verification API Detects SPF A Record Expected but AAAA Returned 2026

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 in a DMARC record?

It tells receiving mail servers to move any email that fails DMARC alignment to the spam or junk folder instead of delivering it to the inbox.

Can I use p=quarantine with sp=none?

Yes, but it's inconsistent. sp=none means non-aligned messages are not quarantined, while p=quarantine applies to aligned ones. Use the same policy for both for predictability.

What happens if I forget the semicolon after p=quarantine?

The record becomes malformed and will be ignored by most mail servers, leaving your domain unprotected against spoofing.

Does p=quarantine prevent all phishing emails?

No. It only applies to emails that fail DMARC alignment. Phishing emails may still bypass DMARC if they use a valid DKIM signature with a trusted domain.

How long does it take for DMARC changes to take effect?

DNS propagation typically takes 1–24 hours, but email servers may cache records for up to 72 hours. Monitor delivery during this window.

Should I use p=reject immediately after setting up DMARC?

No. Use p=none first to collect reports, then p=quarantine to test before moving to p=reject to avoid breaking legitimate email.

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

p=quarantine applies to aligned messages (where the From: domain matches the SPF or DKIM domain). sp=quarantine applies to non-aligned messages.

Can a single DMARC record have both p=quarantine and sp=reject?

No. p=quarantine and sp=quarantine are the only valid values for each policy. Mixing different actions violates the DMARC specification.

How do I know if my DMARC policy is working?

Check aggregate reports (RUA) sent to your email address. They show how many messages passed or failed alignment. Use inbox testing tools to verify real delivery.

Does using MailTester replace the need for a DMARC record?

No. MailTester verifies email addresses and inbox delivery but does not replace DNS-level email authentication. DMARC is required for anti-spoofing.

Can DMARC help with email deliverability?

Yes, by reducing spoofing and increasing trust. But only if combined with a clean list, valid authentication, and sender reputation management.

What’s the minimum required DMARC syntax?

At minimum: v=DMARC1; p=none; — though this offers no enforcement. For action, use v=DMARC1; p=quarantine; sp=quarantine;.