DMARC p=quarantine Setup for

Q: Where should I send DMARC reports?

Use a dedicated email address (e.g., postmaster@yourdomain.com) for aggregate reports, and abuse@yourdomain.com for forensic reports. These help identify misused or forged senders.

Why DMARC p=quarantine matters for inbox placement and MailTester results

You just sent a campaign to 10,000 contacts. The open rate is low. The inbox placement tool says “unauthorized.” You check your SPF and DKIM—both are set. But MailTester still fails your domain. Why?

Because even with technical authentication in place, a weak or missing DMARC policy undermines trust. DMARC’s p=quarantine setting is not a nice-to-have—it’s a signal to inbox providers that your domain takes email security seriously.

MailTester doesn’t just validate syntax. It checks sender reputation, alignment, and enforcement across the full email flow. A properly configured DMARC policy with p=quarantine reduces the risk of spoofing, confirms your domain’s intent, and helps your messages land in inboxes—not spam folders.

Key takeaways

DMARC p=quarantine tells receiving servers to treat unauthenticated messages from your domain as suspicious, improving inbox placement over time.
MailTester verifies domain-level authentication, reputation, and policy enforcement—p=quarantine is a required signal for a passing result.
Without p=quarantine or p=reject, even technically correct SPF/DKIM setups may fail MailTester due to weak trust signals at scale.

How MailTester verifies DMARC alignment and policy strength

You must have a valid DMARC record with a policy of p=quarantine or p=reject to pass MailTester’s verification. We validate alignment by checking if your SPF and DKIM records consistently align with your sender domain using real inbox placement tests. We also analyze your domain’s reputation, past sending patterns, and authentication consistency to detect long-term risks that could hurt deliverability.

Real-world testing behind the scenes

MailTester doesn’t just scan DNS records — we simulate actual sending to real domains and monitor how they respond. This includes testing whether receivers enforce your DMARC policy (like marking messages as spam or rejecting them) based on alignment. If your policy says p=quarantine but messages still pass through untouched, it’s a red flag. We catch that.

For example, SPF and DKIM must align with the domain in the “From” header. If your SPF validates a sending IP but the DKIM signature fails to tie back to the sender domain, or if the domain in the From field doesn’t match the one in DKIM, MailTester flags it as alignment failure — regardless of whether the SPF or DKIM record is technically valid.

How reputation and consistency affect policy strength

Even with a strong DMARC policy, a domain with a history of poor authentication or frequent bounces will still raise red flags. MailTester cross-references your domain’s past behavior: sudden shifts in sending volume, inconsistent SPF/DKIM setup, or patterns seen in compromised or abusive domains can lower your trust score.

We use this context to determine whether a p=quarantine policy is meaningful. A weak or inconsistent record, even with the right policy value, may still result in failure if the system detects risk indicators like inconsistent alignment or a poor historical reputation. It’s not just about what the record says — it’s about whether it holds up at scale and across real-world testing.

For teams relying on email lists, catching alignment and policy flaws early can prevent months of deliverability issues. You can test your domain’s full authentication setup with a real inbox placement check — not just a DNS scan. See how your messages land for real recipients: test inbox placement.

What p=quarantine means and why it’s a necessary step toward deliverability

Setting DMARC's p=quarantine tells receivers to treat unauthenticated emails from your domain as suspicious—risky messages get flagged and sent to spam, not the inbox. It’s a safer, more controlled way to enforce authentication than doing nothing (p=none) or outright rejecting mail (p=reject), especially during transitions. This step reduces the risk of legitimate emails being lost while building sender reputation.

How p=quarantine works in practice

When you set p=quarantine, mail servers that check your DMARC record will look at SPF and DKIM results. If both pass, the message goes to the inbox. If either fails—or if no authentication is present—the server may still deliver the message, but it marks it as suspicious. Recipients usually see it in spam or junk folders, not the primary inbox.

Let’s say you’re sending transactional emails through one system, marketing emails through another, and some third-party tools send on your behalf. Without DMARC enforcement, spoofed or misconfigured sources could send mail that looks like it comes from you. p=quarantine gives you a buffer—legitimate mail still arrives, but unauthorized or poorly configured sources get filtered.

Why it’s a necessary step—especially during rollout

Going directly to p=reject can break workflows. If a team accidentally sends without proper SPF, or a new service forgets to sign, email delivery fails. That’s why p=quarantine is a common middle ground during setup.

It’s often recommended by industry players like the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), which promotes DMARC adoption as a core email security practice. You can review their stance in broader discussions on email authentication standards.

Using p=quarantine also aligns with how major providers like Gmail and Microsoft treat unauthenticated messages. It's not about blocking—but being transparent. You’re saying: “We care about security, and if an email lacks proper checks, treat it with caution.”

If you’re preparing a list for outreach, use MailTester’s email checker to validate addresses before sending. If you’re automating verification at scale, our bulk verification tool helps catch invalid or risky addresses early. These steps support your DMARC goals—clean data, proper authentication, and inbox placement.

In short: p=quarantine is not the final step, but it’s the right one to take when building trust with receiving systems. It’s the foundation of a secure, deliverable sending strategy.

Step-by-step: How to configure a DMARC record with p=quarantine

You can configure a DMARC record with p=quarantine by creating a TXT record at _dmarc.yourdomain.com with the value v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r. Ensure SPF and DKIM are properly set up and aligned with your sending sources. After publishing, wait 48 hours for DNS propagation, then verify the record using tools like MXToolbox or DMARCian.

Setting up your DMARC record

Log into your DNS provider’s dashboard—Cloudflare, AWS Route 53, GoDaddy, or another provider. You’ll need access to manage TXT records at the root domain level.
Create a new TXT record with the name _dmarc. This points to the subdomain _dmarc.yourdomain.com and is where DMARC policies are published.
Set the record value to: v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r. This tells receiving mail servers to quarantine messages that fail your authentication policies.
Double-check that your SPF and DKIM records are published and correctly aligned. A DMARC policy only applies if SPF and DKIM pass. Misaligned authentication can cause legitimate mail to be rejected.

Validating and waiting for propagation

Save your changes. DNS updates can take up to 48 hours to propagate across global resolvers, though changes often appear within a few hours. Be patient—your record won’t work immediately.
After waiting, verify your published DMARC record using a free DNS lookup tool. MXToolbox lets you query any TXT record, including DMARC. Enter _dmarc.yourdomain.com to confirm the syntax and policy.
For ongoing monitoring, use DMARCian's DMARC report dashboard. It parses aggregate reports sent to your rua address and helps you understand how your domain is being used.

DMARC is a key piece of email infrastructure. When aligned with proper SPF and DKIM, it improves your sender reputation and reduces the risk of spoofing. Tools like MailTester can help validate your email list against real-world delivery conditions—before you send. See how your messages fare in actual inboxes with our inbox placement test.

The 4 steps described in “Setting up your DMARC record”, in order.

Common DMARC setup issues that block MailTester verification

You can't pass MailTester verification with a p=quarantine DMARC policy if your record is misformatted, SPF or DKIM alignment fails, reporting isn’t set up, or you’re using p=none without monitoring. These are the top four pitfalls that break deliverability checks. Let’s walk through each with real fixes.

Record formatting errors

Double-check that your DMARC record starts with v=DMARC1;—missing or incorrect tags invalidate the entire record.
Don’t add extra spaces or line breaks inside the DNS record; even a single spurious space can render it unreadable to DNS resolvers.
Use a standard DNS TXT record format—no quotes or brackets around the value unless required by your DNS provider.
Validate your record using tools like MXToolbox’s DMARC checker or RFC 7483 to ensure you’re following official syntax.

SPF and DKIM misalignment

DMARC requires SPF and DKIM alignment with your domain. If your SPF fails to authorize your sending server, DMARC fails too.
Check that your DKIM signature uses the correct selector and domain—misconfigurations here often go unnoticed until deliverability drops.
Use MailTester’s email checker to validate domain alignment before sending at scale.
Remember: a p=quarantine policy only works when both SPF and DKIM pass with alignment. One failure breaks the policy.
Set a valid rua=mailto:[email protected] address to receive aggregate reports. Without it, MailTester sees no monitoring—this triggers a warning during verification.
Use a dedicated domain for reporting (e.g., [email protected])—not a personal email or a shared mailbox.
Even with p=none, you need reporting if you’re using MailTester for inbox placement testing—no monitoring means no trust signal.
If your p=none policy has no reporting, it’s a red flag. It implies you’re not tracking issues, which harms sender reputation.

DMARC isn’t about locking down the mailbox—it’s about proving you’re who you claim to be, consistently and transparently.

Never use p=none without reporting if you’re testing deliverability with MailTester. It fails due diligence checks.
For high-volume senders, p=quarantine or p=reject must be paired with monitoring to avoid being flagged as a weak sender.
Use MailTester’s inbox placement tool to test how your p=quarantine policy performs in real inboxes.
Test changes using a staging environment or low-volume test campaign. Never apply DMARC policy changes live at scale without validation.

DMARC, SPF, and DKIM: The triad that determines MailTester pass/fail

You can’t pass MailTester verification with a p=quarantine DMARC policy unless SPF and DKIM are correctly configured and aligned. MailTester checks all three protocols together: if any one fails, the entire verification fails. This is how email providers like Gmail and Outlook determine trust — and why ignoring any part of the triad breaks delivery.

How each protocol works in practice

SPF checks if the sending server’s IP is authorized in your domain’s DNS records. If the IP isn’t listed, the message fails SPF. DKIM adds a digital signature to the email header, which receivers verify against a public key in your DNS. This ensures the content hasn’t been altered in transit.

DMARC sits on top of both. It tells receivers what to do when SPF or DKIM fails — like quarantining the message. Setting p=quarantine means bad emails get flagged, not delivered to the inbox. But DMARC only works if SPF and DKIM are actually enforced and properly aligned.

Why MailTester tests them as a group

MailTester doesn’t verify SPF, DKIM, and DMARC in isolation. It simulates real-world delivery and checks the full chain: does the sending IP pass SPF? Does the DKIM signature match? Is DMARC enforcing the policy as expected? If not, the test fails — even if two are correct.

For example, a message can pass SPF but fail DKIM due to a broken signing setup. Even with p=quarantine in place, MailTester will mark it as a failure because the integrity check failed. This mirrors how real email systems like Gmail or Yahoo evaluate senders.

DMARC reporting (via ruf/rua) helps track abuse, but MailTester doesn’t test reporting — it tests enforcement. It’s not enough to have a policy; the policy must be effective across all sending sources.

Let’s be clear: setting a DMARC policy without verified SPF and DKIM is a risk. The protocol can’t protect you if the foundation is broken. For best results, verify your sending setup with a tool like MailTester’s inbox placement tester, which checks how your messages land in real inboxes.

The three protocols — SPF, DKIM, and DMARC — aren’t optional checkboxes. They’re a single, interdependent system. The DMARC specification defines how the stack should behave, and real email gateways follow it strictly. A single misstep in alignment, configuration, or signing breaks the chain.

Use MailTester to check your whole stack before you send. If you’re setting p=quarantine, the results will reflect the full health of your email authentication, not just the policy you’ve declared.

What your DMARC policy should not do to pass MailTester

You must not set p=none without actively monitoring reports—MailTester flags it as unenforced, meaning no protection. Avoid p=reject too early if you haven’t validated all your senders. Never use automated tools that omit critical tags like fo=1, adkim=r, or aspf=r, as they invalidate the policy. And never ignore DMARC reports—unattended abuse can poison your sender reputation, even if your email technically passes verification.

Common DMARC missteps that block verification

Setting p=none without a monitoring setup: This policy is treated as inactive by MailTester and many email providers. It signals no enforcement, which undermines your deliverability posture.
Using p=reject prematurely: If you haven’t confirmed all legitimate sending sources (including partners or platforms), you’ll block legitimate mail. MailTester tests for real-world delivery, not just policy syntax.
Letting auto-generators skip essential tags: A complete DMARC record should include fo=1 (report on failure of any alignment), adkim=r (relaxed alignment for DKIM), aspf=r (relaxed alignment for SPF). Missing any of these undermines integrity.
Ignoring DMARC reports: These reports highlight unauthorized senders and phishing attempts. Without review, malicious actors can exploit your domain, leading to blacklisting and lower inbox placement.

How to validate your setup before testing

Use your existing infrastructure to test alignment before relying on the DMARC policy itself. Confirm all senders—your CRM, transactional platform, newsletter tool—are properly authenticated with SPF and DKIM. A policy without validated sources will fail not only MailTester but real email providers.

When you're ready, test inbox placement with MailTester’s inbox placement tool. It checks real inboxes (Gmail, Outlook, Yahoo) to simulate how your messages arrive under different DMARC policies.

For ongoing validation, integrate with your existing tools via MailTester’s integrations with SendGrid, HubSpot, and Klaviyo. This lets you verify sender reputation and alignment directly in your workflow.

DMARC is not a one-time fix. It’s a monitoring and enforcement system. Without careful setup and ongoing review, even a valid policy can fail verification due to misalignment or abuse.

How to validate your DMARC config before relying on MailTester

You can’t trust MailTester’s deliverability results if your DMARC policy isn’t properly configured. Start by confirming your record syntax with a free tool like dmarcian.com, then send test emails from legitimate sources and check if they land in inboxes using a real inbox placement test. Monitor DMARC aggregate reports to spot misaligned senders, and never rely on tools that don’t simulate how real email providers actually receive messages.

Step-by-step validation process

Validate your DMARC record syntax
Use dmarcian.com to check that your DMARC DNS record parses correctly. A malformed record can cause deliverability issues even if the policy is set to p=quarantine. This tool parses the full record and flags issues like incorrect tags, missing tags, or invalid values.
Send test emails from verified sources
Send messages from your official sending domains using real email clients or SMTP servers. Avoid testing from unverified sources or throwaway accounts. This ensures the alignment checks (SPF and DKIM) are evaluated under conditions that match real delivery.
Run a real inbox placement test
Use MailTester’s inbox placement test to see how your messages land across multiple inboxes. This simulates real-world receipt behavior—something many free tools skip. It checks delivery, inbox placement, spam filtering, and rendering, not just syntax.
Check DMARC aggregate reports
Set up a reporting URI (e.g., ruf=mailto:[email protected]) and monitor reports via dmarcian.com or other DMARC reporting services. These reports show which senders are passing alignment, which are failing, and whether unauthorized sources are impersonating your domain.
Avoid tools that simulate, not verify
Many tools claim to "validate" DMARC but only check DNS syntax. These don’t test how real inbox providers receive and process mail. You need tools that simulate actual receipt behavior, not just parsing.

Why simulation matters

Even if your DMARC record is technically correct, poor alignment, weak authentication, or improper email content can still result in delivery failures or spam filtering. Testing your setup in the wild—using actual messages sent from approved sources to real inbox environments—is the only way to know if your p=quarantine policy is working as intended.

DMARC is only effective when enforced across your entire sending ecosystem. Misaligned senders (like marketing platforms or third-party tools) may still be allowed through by some providers if they’re not caught early. That’s why ongoing monitoring through real reports and testing is essential.

After confirmation, run your full list through MailTester’s bulk verification tool to clean your database and ensure only deliverable, aligned addresses remain—reducing bounces and protecting sender reputation.

MailTester’s role in testing DMARC and sender reputation in practice

You can’t assume a DMARC policy set to p=quarantine automatically passes deliverability checks. MailTester simulates real inbox delivery across major providers—Gmail, Outlook, Yahoo—validating not just policy presence, but whether it’s actively enforced, properly configured, and aligned with your sender reputation. It checks if your authentication chain (SPF, DKIM, DMARC) is intact and whether past behaviors like bounces, spam complaints, or blocklist entries are dragging down your score. A technically correct policy alone won’t suffice if historical performance is poor.

How MailTester evaluates policy enforcement beyond setup

DMARC reports alone don’t tell you if your policy is working. MailTester goes further by testing actual delivery conditions: it sends test emails across different domains and observes how each inbox handles them based on your DMARC alignment. For a p=quarantine policy to pass, the receiving server must act on the policy, not just read it. MailTester checks if the alignment between the From header and the sender’s domain matches SPF or DKIM results. If either fails, the message should be quarantined—but if it still lands in the inbox, your setup is ineffective.

A correct DMARC policy doesn’t override bad sending habits. MailTester aggregates data on your send history: how many recipients reported your emails as spam, whether you’ve been flagged by major blocklists, or if your list has high bounce rates. These factors combine into a sender reputation score. For example, a single domain with a strong DMARC policy but frequent hard bounces will still fail if the sender reputation is poor. This aligns with industry-standard practices outlined in the DMARC specification, which explicitly states that policy enforcement should reflect real email behavior.

Reputation and authentication must work together

Think of DMARC as a fence: it’s only useful if your delivery track record hasn’t broken through it repeatedly. MailTester doesn’t just check if you’ve built the fence—it tests whether it’s holding. If your emails keep hitting spam filters or being rejected despite correct DMARC, you’re likely dealing with a sender reputation issue. The system flags this by combining real-world inbox placement results with historical behavior, including past deliveries to MailTester’s network of test domains across major providers.

Let’s say you’ve set p=quarantine and pass all technical checks. But MailTester’s inbox placement test shows your emails consistently ending up in spam folders. That’s a red flag. It means your reputation is harming delivery, regardless of protocol correctness. Real-world testing like this helps catch mismatches before you send to thousands. To validate your full send stack—including DMARC, SPF, DKIM, and sender reputation—use MailTester’s inbox placement tester to catch issues before they cost you engagement.

Why MailTester’s 98.9% accuracy matters when validating DMARC setup

MailTester’s 98.9% accuracy isn’t just a number—it’s the difference between trusting a theoretical DNS check and knowing your DMARC p=quarantine policy will actually stop spammers while letting legitimate mail through. Unlike tools that only scan DNS records, MailTester tests real delivery behavior, uncovering hidden flaws like misaligned DKIM, broken SPF, or spoofed domains that could still cause your emails to be quarantined—even with proper DMARC set up.

Real-world testing beats static DNS checks

Many tools tell you that your DMARC record looks correct on paper. But a record that passes a DNS validator can still fail in practice. MailTester goes beyond configuration—running full SMTP sessions and simulating inbox placement to see how your emails behave in real mail servers. If your DKIM signature doesn’t align with the From domain, or SPF fails due to incorrect inclusion of third-party senders, MailTester flags it before you send.

Let’s say you've set p=quarantine and think you’re protected. But if your SPF includes a deprecated IP range or your DKIM is signed with an outdated key, receivers may still reject your mail. MailTester catches these issues because it mimics how actual mail servers evaluate authentication during delivery, not just during setup.

Accuracy reduces false positives, builds trust in your data

False positives—flagging valid emails as invalid—are a major pain point. They waste time, hurt sender reputation, and can lead to blocking. MailTester’s high accuracy means you're less likely to misclassify good addresses as risky or invalid. This confidence comes from testing across actual infrastructure, not just matching patterns against known rules.

Industry-standard practices like those defined in RFC 7483 (the DMARC specification) are enforced here, but MailTester goes further—validating not just policy existence, but whether the policy works in real conditions. That’s why you can check an email address before sending, or use the inbox placement tool to see how your messages land in real inboxes. You're not just checking a record—you're simulating delivery.

Because MailTester doesn’t rely on outdated databases or speculative modeling, your verification results reflect actual behavior. You can trust it because you’re not guessing—you’re seeing test outcomes that mirror what happens with real email providers.

Conclusion: DMARC p=quarantine is not optional—it’s a deliverability requirement

Configuring DMARC with p=quarantine is not a formality. It’s a proven step after validating SPF and DKIM, directly improving inbox placement for legitimate mail.

MailTester doesn’t rely on DNS checks alone. It runs real delivery tests to confirm your policy is active, enforced, and consistently applied across all sending sources.

Use the steps outlined to implement, test, and validate your policy. Monitor DMARC reports to maintain alignment and trust, ensuring long-term deliverability.

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 is p=quarantine in DMARC?

It tells receiving email servers to treat unauthenticated messages as suspicious, typically moving them to spam rather than the inbox. This protects recipients while allowing legitimate mail to pass.

Can I use p=quarantine instead of p=reject?

Yes. p=quarantine is a safer transition policy than p=reject, especially if you're still validating all sending sources. It reduces risk of blocking legitimate mail during setup.

How long does it take for DMARC changes to affect MailTester verification?

After DNS propagation (usually 48 hours), MailTester can retest the domain. Real-time changes may take time to reflect in inbox placement results.

Does MailTester verify DMARC reports?

It evaluates the policy enforcement and alignment, but not the content of individual reports. It does, however, use the strength of the policy to assess overall deliverability risk.

What happens if my DMARC policy is missing or set to p=none?

MailTester will flag the domain as having weak or no policy enforcement. This often leads to a failed verification, especially if other authentication signals are inconsistent.

Can I test DMARC config with MailTester before going live?

Yes. Use MailTester’s inbox placement and deliverability testing to simulate how your domain performs with the new policy in place.

Does DMARC affect cold email deliverability?

Yes. If your domain lacks DMARC policy enforcement, cold emails are more likely to be blocked or quarantined, even if SPF/DKIM are in place.

Why does my domain pass SPF and DKIM but still fail MailTester?

Because MailTester checks policy enforcement (via DMARC), reputation history, and delivery behavior. A weak or missing DMARC policy can override passing SPF/DKIM.

What’s the difference between adkim=r and adkim=s?

adkim=r checks the domain in the From header; adkim=s checks the From header domain only. Use r for broader alignment with modern sending practices.

Where should I send DMARC reports?

Use a dedicated email address (e.g., [email protected]) for aggregate reports, and [email protected] for forensic reports. These help identify misused or forged senders.

Do I need to remove p=quarantine after MailTester passes?

No. Keeping p=quarantine is recommended unless you're confident in full authentication coverage. Many senders keep it permanently for security.

Can MailTester help me fix a failed DMARC policy?

It identifies failures and provides context on why a domain fails verification. Use the AI assistant in-app to explore root causes, but fixes must be made in DNS.