Why DMARC is essential for modern email deliverability

You send emails that are authenticated with SPF and DKIM—but are still being flagged as spam or blocked. Why? Because without DMARC, those technical safeguards don’t enforce anything at scale.

DMARC is your domain’s enforcement layer. It tells receiving mail servers what to do when an email claims to come from your domain but fails SPF or DKIM checks. Without it, attackers can spoof your domain freely—even if your legitimate messages are properly authenticated.

Configuring DMARC with both p=quarantine and sp=quarantine isn’t just about security—it’s about protecting inbox placement, sender reputation, and deliverability. This guide walks you through how to set it up correctly, avoid common pitfalls, and prevent email loss.

Key takeaways

  • DMARC with p=quarantine and sp=quarantine ensures failed authentication attempts are actively blocked, reducing spoofing and improving deliverability.
  • Using p=none or p=reject prematurely breaks email flow—start with monitoring and gradually enforce policy based on reporting data.
  • Without DMARC, even correct SPF/DKIM configurations leave your domain vulnerable to abuse, harming sender reputation and inbox placement.

What does p=quarantine and sp=quarantine actually mean?

Setting p=quarantine tells receiving mail servers to treat unauthenticated emails from your domain as suspicious—usually moving them to spam folders. Using sp=quarantine applies the same rule to all subdomains, like newsletter.yourcompany.com, helping block spoofed messages across your entire domain structure. This balances security and deliverability by reducing abuse without immediately rejecting legitimate mail.

How DMARC policies work in practice

When you set p=quarantine, you’re not blocking mail—it’s still accepted, but treated with suspicion. Mail servers that enforce DMARC, like Gmail or Outlook, may put those messages in spam or downgrade their priority. This protects your brand reputation by stopping impostors from sending phishing or spam emails that appear to come from your domain.

Using sp=quarantine extends that protection to all subdomains. If someone sends spam from [email protected] without proper authentication, the message gets quarantined just like one from your main domain. This is crucial for large organizations with multiple subdomains and third-party tools (like marketing platforms or help desks) that send email on your behalf.

Let’s be clear: this isn’t an instant fix. It’s a step. You’re not enforcing strict rejection yet—no emails are outright bounced. That makes p=quarantine a safer move than p=reject, especially if you have outdated or misconfigured senders still in use. It still provides meaningful protection while giving you time to clean up. Many enterprises use this phase during DMARC implementation.

Why this approach is often the right middle ground

Unlike p=none, which only monitors traffic and tells you nothing, p=quarantine forces action. It actively helps improve inbox placement for legitimate senders by reducing how much spam gets mistaken for your brand. But it’s not as disruptive as p=reject, which can break sending if authentication is flawed—even for valid messages.

It’s a common industry practice to start with p=quarantine before moving to p=reject once you’re confident all senders are properly authenticated. The DMARC standard (RFC 7483) explicitly supports this phased rollout, and organizations like Google and Microsoft recommend it for real-world deployment.

If you're setting up DMARC and want to test how your domain performs in real mailboxes, you can evaluate inbox placement with a service like our inbox tester. Use it to verify messages from your domain and subdomains are landing in inboxes, not spam, before stepping up to full enforcement. With correct SPF, DKIM, and DMARC alignment, you’re building trust that actual recipients will see your mail—and know it’s real.

The danger of jumping straight to p=reject

Setting p=reject immediately without a monitoring phase risks blocking legitimate emails—especially from third-party services like Klaviyo or SendGrid—because alignment issues often go undetected. If your SPF or DKIM isn’t correctly configured across all sending platforms, you'll silently fail delivery to customers. Always start with p=quarantine to observe behavior before enforcing rejection.

Why the default rush to p=reject fails

Many organizations skip the reporting phase, assuming they’ve got everything aligned. But without rua (reporting address) and ruf (forensic reporting) set up, you’re flying blind. DMARC reports show exactly where emails are failing—whether due to misconfigured senders, broken DKIM signatures, or improper SPF inclusion. Without them, you’re guessing.

Let’s say you run a campaign via Klaviyo. If your domain isn’t properly aligned in their system, the DMARC check fails. You’ll see a “fail” in reports, but if you’re already using p=reject, the mail gets dropped before you even notice. That’s why you can’t jump straight to enforcement.

According to RFC 7483, DMARC’s effectiveness depends on accurate reporting and iterative tuning. Organizations that rush to p=reject without a testing window often see delivery drops of 10–30% from known channels.

Third-party services need alignment visibility

Services like HubSpot, SendGrid, or Mailchimp often send on your behalf—but they don’t always align with your domain in SPF or DKIM. If your DMARC policy is reject-based, these messages are blocked even if they’re legitimate. This is especially common with transactional emails and marketing platforms.

One way to prevent this is to run a real-time inbox placement test before changing policies. Use MailTester’s inbox placement tool to simulate sending through your setup and see if your messages land in inboxes—or get quarantined.

Once you’ve confirmed that all sending sources pass authentication and alignment checks, only then should you consider moving to p=reject. Until then, stick with p=quarantine and monitor reports daily. It’s not a delay—it’s a safeguard. Even then, never disable reporting; keep collecting data to maintain baseline health.

How to safely begin DMARC enforcement with p=quarantine

You start with p=none to collect authentication data from receivers without impacting delivery. Once you confirm SPF and DKIM are properly aligned across all legitimate sources—including third-party vendors and subdomains—you can transition to p=quarantine. Wait at least 7–14 days after enforcement to monitor for unintended delivery issues before moving to p=reject. This gradual rollout prevents accidental blocking of real mail.

Step-by-step: Roll out DMARC policy safely

  1. Begin with p=none. Publish a DMARC record with p=none and include a reporting email address. This lets receivers send forensic and aggregate reports to help you map out all valid sending sources, including internal systems, marketing platforms, and partners. Use a dedicated inbox to avoid message clutter.
  2. Collect and analyze reports. Use a DMARC monitoring tool to parse reports. Look for patterns in failures: are certain email addresses failing due to misconfigured SPF, DKIM, or lack of subdomain alignment? Many large senders see 10–30% of outbound emails fail authentication initially—this is normal during setup.
  3. Fix misconfigurations before tightening policy. Ensure every legitimate sender (e.g., CRM, support tools, transactional systems) has properly aligned SPF and DKIM. Use tools like RFC 7483 or MxToolbox to test alignment and DNS records. For new or unauthenticated sources, update your configuration.
  4. Move to p=quarantine. Once you’ve validated all sending sources and seen consistent success in reports, update your DMARC record to p=quarantine. This signals receivers to treat unauthenticated messages as suspicious but not blocked outright. It’s a lower-impact test than p=reject.
  5. Wait 7–14 days before moving to p=reject. During this window, actively monitor delivery—especially time-sensitive campaigns or transactional emails. Check spam folders and inbox placement using tools like inbox placement tests to confirm legitimate emails are reaching inboxes.
  6. Verify alignment and coverage. Before enforcing p=reject, double-check all subdomains and partners. Even small misalignments (e.g., a subdomain sending without proper DKIM) can result in quarantining. Use a tool like MailTester’s email checker to validate individual addresses and identify risks before they reach real inboxes.
DMARC enforcement isn’t about perfection on day one—it’s about continuous improvement. A measured rollout prevents service disruptions while building sender trust.

Why sp=quarantine is necessary even if you own only one subdomain

You need sp=quarantine even with a single subdomain because attackers often target unmonitored subdomains like blog.yourcompany.com to spoof your brand. Without sp=quarantine, any subdomain—no matter how rarely used—can be exploited for phishing, even if it doesn’t currently send mail. It ensures all subdomains, future or forgotten, follow your domain-wide security policy.

Subdomains aren’t inherently secure—just less monitored

Let’s be clear: a single subdomain like blog.yourcompany.com isn’t a security blind spot by default. But it’s rarely treated with the same scrutiny as your main domain. Many teams assume “if we’re not sending from it, it’s fine.” That’s risky. In fact, subdomains are commonly repurposed by attackers as trusted endpoints because they’re often excluded from strict authentication policies.

Even if you don’t use the subdomain to send email today, an attacker could register a fake version (like blog.yourcompany.com) and use it to send phishing messages. The email might appear to come from your root domain, especially if your SPF, DKIM, or DMARC records don’t cover subdomains properly.

sp=quarantine closes the gap in policy enforcement

Your DMARC policy on the root domain (p=quarantine) only applies to messages sent from your main domain. Without sp=quarantine, subdomains aren’t bound by the same rules—even if they share the same domain name. This creates a loophole.

By setting sp=quarantine, you apply the same policy to all subdomains, regardless of whether they’re actively sending email. It’s not about sending mail—it’s about preventing abuse. This is an industry-standard approach. The RFC 7483 explicitly defines sp=quarantine as the correct mechanism for extending protection beyond the root domain.

Think of it this way: you wouldn’t leave a back door unlocked just because you don’t use it. sp=quarantine ensures no subdomain, old, new, or unused, becomes a backdoor for attackers. It’s proactive. It’s simple. And it’s essential.

If you’re verifying mail server configurations, you can test your DMARC alignment using real-time tools like inbox placement testing, which simulates how receivers like Gmail and Outlook handle your messages. You’ll see whether your policy is enforced consistently across all domains and subdomains.

Common misconfigurations that break DMARC enforcement

DMARC won’t protect you if your SPF and DKIM aren’t properly aligned with your sending domain. Even with p=quarantine and sp=quarantine set, broken SPF records, misaligned DKIM signatures, or unchecked subdomain validation can cause legitimate emails to fail. You’re not enforcing DMARC—you’re disabling it. Let’s fix that.

SPF alignment failures

  • Don’t assume include:spf.sendgrid.net automatically makes your domain valid. If you're sending from a subdomain like newsletter.company.com, you must explicitly add include:spf.sendgrid.net to that subdomain’s SPF record—just having it in the root domain won’t help.
  • Using all ~all or all -all without verifying the full chain of includes or mechanisms breaks SPF. A single missing or invalid include makes the entire record fail.
  • SPF records are limited to 10 DNS lookups. Each include counts toward that limit—exceeding it results in a permanent failure, even with correct syntax.

DKIM and alignment issues

  • DKIM signing with a key from mail.sendgrid.net doesn’t help if the d= tag doesn’t match your sending domain. Even with perfect signature validation, a mismatch in the d= value fails alignment and triggers DMARC failure.
  • Using multiple DKIM keys without managing their alignment in DMARC policies can confuse authentication. Each key must align with either the envelope-from or the header-from domain.
  • Some tools don’t enforce subdomain alignment. You can use an existing DKIM key from a third-party, but if the signing domain doesn’t match the sending domain or its subdomain, DMARC will still reject the email.

It’s not enough to just add DMARC. You must validate that SPF and DKIM are both correctly set up and aligned. A single misstep in any part of the chain—especially with includes or subdomain records—breaks the entire verification system.

“Misconfiguration is the leading cause of DMARC failure, not technical flaws in the protocol itself.” — ICANN

Before sending bulk campaigns, verify your domain’s authentication setup with real email addresses. Use MailTester’s email checker to test individual addresses and ensure they pass authentication checks. Or use the bulk verification tool to clean your list before sending—catch invalid or misconfigured senders early. Even perfect DMARC policies can’t save you if your SPF or DKIM is broken. Check it all.

How to verify your DMARC policy before deploying it

Before enforcing p=quarantine and sp=quarantine in your DMARC record, test your sending infrastructure with real email verification. Confirm SPF and DKIM alignment for your outbound addresses, scan your list for misconfigured or invalid recipients, and simulate inbox delivery under quarantine conditions to catch issues before they trigger widespread blocking. This reduces the risk of legitimate mail being lost or marked as spam.

Check SPF and DKIM alignment with real-time verification

Let’s start with your sending domains. Even if your SPF and DKIM records are set up correctly, individual email addresses may not align due to forwarded or misconfigured senders. Use a real-time verification API—like MailTester’s email verification API—to test a sample of your transactional or marketing addresses. The API checks whether the sending domain matches the SPF sender and whether the DKIM signature passes validation. This reveals if authentication is failing at the envelope or header level.

If the test returns 'invalid' or 'risky' for a significant number of addresses, your DMARC policy will likely cause delivery issues. You’ll need to fix misaligned sends, update SPF mechanisms, or reconfigure DKIM signing. Without this check, enforcing p=quarantine may block valid mail you didn’t expect to fail.

Test delivery under quarantine conditions

Once SPF and DKIM alignment is confirmed, simulate how your messages will behave when DMARC enforcement is active. Use inbox-placement testing tools—such as MailTester’s inbox placement tester—to send test emails to major providers like Gmail, Outlook, and Yahoo. These tools apply DMARC policies in real time, allowing you to see whether messages land in the inbox or are quarantined, even if authentication checks pass.

The key is spotting unexpected drops in inbox placement when p=quarantine is enforced. If you see a sudden shift in delivery patterns—say, 30% fewer inboxes for a campaign—it signals a gap in your setup. Common culprits include misaligned third-party senders, missing DMARC subdomain policies (sp=quarantine), or outdated SPF include mechanisms. The Internet Society’s RFC 7483 notes this is especially critical for organizations using multiple senders or external platforms.

Monitoring DMARC reports: what to actually look for

You need to scan DMARC reports for failure reason codes like SPF fail, DKIM fail, alignment issues, or unauthorized domain usage. Focus on which sending sources—especially third-party services—are failing, and watch for spikes after infrastructure changes to catch misconfigurations before they hurt deliverability. Use real reports to validate your p=quarantine and sp=quarantine policies are working as intended.

Check the failure reason codes directly

  • Look for reason=spf to identify SPF alignment failures—common when a sender uses an IP not listed in your SPF record.
  • Track reason=dkim when signed emails fail cryptographic validation; this often points to poor key management or misconfigured signing.
  • Watch for reason=alignment—a frequent issue when subdomains or email forwards don’t align with the domain in the From field.
  • Flag reason=unauthorized for domains used in From fields without authorization; this signals spoofing or misconfigured services.

Correlate failures with sending sources

  • Map each failure to an IP address or service provider—especially non-internal ones like CRM tools, marketing platforms, or helpdesk systems.
  • Identify if a third-party sender (e.g. a newsletter service) is using your domain without proper SPF/DKIM configuration. These often appear as “unknown” or “external” sources.
  • Monitor for sudden spikes in failures after onboarding a new sending service or switching email providers—this is often where configuration slips happen.
  • Use the DMARC spec (RFC 7483) to validate how reason codes are defined and ensure your parser handles them correctly.

Let’s be clear: DMARC reports are not just alerts—they’re diagnostic maps. When you see multiple failures from one IP, don’t assume the sender is malicious. First, confirm they’re a legitimate send source and then check whether their authentication setup aligns with your p=quarantine policy. A single misconfigured API client can sink your reputation if left unchecked.

DMARC reports are only useful if you act on them—especially when reason codes point to alignment or SPF issues, which are the most common root causes of delivery failures.

Use your DMARC data not to react, but to prevent. If you’re sending in bulk, run a pre-sending validation step via MailTester's bulk verification to catch invalid or risky addresses before they trigger false alarms in your DMARC reports.

Using MailTester to validate your DMARC-ready email list

You can use MailTester to validate your email list before enforcing DMARC policies with p=quarantine and sp=quarantine. First, run your list through bulk verification to filter out invalid, catch-all, or risky addresses that could trigger spam filters or harm sender reputation. Then, integrate the real-time API to pre-validate each outbound email, ensuring only authenticated, deliverable addresses are sent. Finally, test inbox placement across Gmail, Outlook, and Apple Mail to confirm your messages aren’t being quarantined prematurely.

Run your list through bulk verification

If you’re enforcing strict DMARC policies, every email you send must reach a real inbox. Sending to invalid or catch-all addresses increases the risk of bounces, spam complaints, and reputation damage. MailTester’s bulk verification checks each address against SMTP servers, DNS records, and role account patterns to flag problematic emails before they’re sent.

Addresses flagged as catch-all or risky can still receive mail but are often associated with low engagement or high bounce rates. You don’t need to remove them entirely, but they should be handled cautiously—especially if you’re enforcing p=quarantine. Regular verification helps keep your list clean and reduces the chances of being marked as a spam source.

Use the real-time API for ongoing validation

Even after cleaning your list, new sign-ups or data imports introduce risk. The real-time verification API lets you check each address as it’s added to your system. This ensures you’re not sending to an unauthenticated or invalid domain, especially during automated workflows like onboarding or transactional messaging.

When combined with SPF, DKIM, and DMARC, pre-validating addresses reduces the chance of deliverability loss. As a sender, you’re accountable for every email sent—MailTester’s API helps you meet that standard.

Test inbox placement before enforcing DMARC

Before enforcing p=quarantine or sp=quarantine, confirm your messages land in inboxes—not spam or quarantine folders. MailTester’s inbox placement test sends real messages to Gmail, Outlook, and Apple Mail accounts, giving you insight into how they evaluate your emails.

You can run this test after making changes to authentication settings or adjusting message content. If your message lands in a quarantine folder, it may be due to poor sender reputation, poor content hygiene, or incorrect headers—not just DMARC. Fixing these issues before enforcement avoids unexpected drops in delivery rates.

For more details on DMARC policies and their impact, refer to the official IETF DMARC specification (RFC 7483). If you're building out your email infrastructure, explore MailTester’s bulk verification tools for large-scale list cleansing.

When to move from p=quarantine to p=reject

You can safely move from p=quarantine to p=reject only after confirming no legitimate email fails over 14 consecutive days under quarantine, that all third-party providers authenticate correctly, and inbox placement remains stable. A premature shift to reject risks blocking valid messages. Let’s walk through the guardrails.

Confirm minimal failure rates

  • Run p=quarantine for at least 14 days, tracking reports via DMARC aggregate (RUA) and forensic (RUF) feeds.
  • Check that failure rates stay consistently below 1% — this includes both alignment and authentication mismatches.
  • Use a tool like Dmarcanalyzer to parse your DMARC reports and identify failed sources.

Verify third-party compliance

  • Review all outbound email services (e.g. Klaviyo, HubSpot, SendGrid) to confirm they're using your domain's SPF records and have DKIM set up correctly.
  • Check their documentation: most providers publish their SPF mechanisms and DKIM selectors. Look up their published records via DNS lookup tools like MxToolbox to verify alignment.
  • Test your own sends through these systems using an inbox placement tool — for example, verify delivery with MailTester’s inbox placement tester.

Validate inbox delivery stability

  • Monitor delivery of transactional and marketing emails from trusted senders during the quarantine phase.
  • If no bounces, delays, or inbox placement drops occur, the environment is stable enough for stricter enforcement.
  • Use real-time delivery checks — not just logs — to ensure messages reach inboxes, not spam folders.
  • Consider testing with a small sample of verified addresses via MailTester’s email checker to validate individual inbox receipt before expanding.

When all three criteria align — low failure rates, proven third-party compliance, and steady inbox delivery — you can safely update your DMARC policy to p=reject with confidence. This move blocks more spoofed mail without disrupting real traffic.

Final recommendations for long-term DMARC maintenance

Keep p=quarantine as your default policy unless you have verified every legitimate sender in your ecosystem. Enforcing p=reject without complete visibility risks blocking valid messages.

Monitor and act on reports consistently

Review DMARC aggregate reports at least weekly, especially in finance, healthcare, or e-commerce, where spoofing attempts are frequent. Look for new sources, unexpected domains, or sudden spikes in failures.

Maintain sender reputation through list hygiene

Even with proper DMARC alignment, poor list quality harms deliverability. Use a tool like MailTester to verify emails before sending—this reduces bounces, protects sender reputation, and improves inbox placement.

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 happens if I set DMARC to p=quarantine without SPF and DKIM?

Messages from your domain will fail authentication and be treated as suspicious by receiving servers. This typically means they’ll go to spam or be blocked, even if the address is valid.

Can p=quarantine still cause emails to be delivered to spam?

Yes. p=quarantine does not block emails but instructs receivers to treat them as potentially suspicious, which can result in delivery to spam folders.

Should I enable sp=quarantine for all subdomains?

Yes. Subdomains are often less secured and commonly targeted by attackers. Enforcing consistency with sp=quarantine reduces risk across your entire domain structure.

How long should I wait with p=quarantine before moving to p=reject?

Wait at least 14 days after deployment, monitoring reports for anomalies. Ensure all legitimate sources are properly authenticated before enforcing rejection.

Can DMARC help with email deliverability to Gmail and Outlook?

Yes. Major providers use DMARC to assess sender legitimacy. A properly enforced policy improves inbox placement and reduces the chance of being flagged as spam.

What’s the difference between policy and reporting in DMARC?

The policy (p=none, p=quarantine, p=reject) defines how receivers handle unauthenticated messages. Reporting (rua, ruf) defines where failure reports are sent for monitoring.

Why do some emails still get marked as spam even with p=quarantine?

Emails can be flagged by spam filters beyond DMARC, due to content, sender history, or recipient behavior. DMARC only governs authentication alignment.

How often do I need to review my DMARC policy?

Review at least weekly during initial rollout, then monthly. Update the policy if new senders or services are added to your infrastructure.

Can I use MailTester to test DMARC reports?

MailTester doesn’t parse DMARC reports directly, but it can validate the underlying email infrastructure by checking SPF, DKIM, and deliverability through real-time verification and inbox placement testing.

What percentage of emails should fail under p=quarantine?

Failures should be below 1% for legitimate mail. Any significant deviation indicates misconfiguration or unauthorized use of your domain.