< back to blog

Why DMARC p=reject Saves MSPs From Blame

June 18, 2025
DMARC Protocol
MSP

"Why are our emails broken? What did you change?"

Every Managed Service Provider (MSP) has been there. Your client hired a web developer who decided to send emails from their domain without telling anyone. Now the customer is missing sales leads, and somehow it's your fault.

Here's why DMARC p=reject policies actually protect you from these situations better than p=quarantine - and make your life easier when shadow IT inevitably happens.

The Quarantine Problem: You Get Blamed Anyway

Some DMARC guides tell you to use p=quarantine because it's "safer". But when a web developer or marketing consultant starts sending unauthenticated emails from your client's domain, those emails end up in junk folders.

What happens next:

  • Client calls angry about vague "email deliverability issues"
  • You spend hours investigating
  • Customer complaints pile up about missing communications
  • Client assumes you broke something with the email setup
  • You're troubleshooting phantom problems while the real culprit sends more mail
  • The real problem: p=quarantine creates ambiguity. Is it a configuration issue with legitimate senders? A deliverability problem? Or unauthorised sending? You can't tell without deep analysis.

    p=reject: Clean Failures, Clear Accountability

    With p=reject, unauthorised senders fail immediately and completely. No emails delivered, no junk folders, no confusion.

    When that web developer tries sending from your client's domain:

  • Emails bounce immediately with clear error messages
  • The conversation becomes "why is your email being rejected?" not "why are some emails going to junk?"
  • You're not troubleshooting delivery issues for systems you didn't configure
  • Real-World Example: The Marketing Agency Surprise

    The setup: Professional services client with Microsoft 365, properly configured DMARC p=quarantine policy.

    What happened: Client's web developer set up a new contact form on their website sending sales leads from their domain through a third-party platform—without telling anyone.

    p=quarantine result:

    • Web sales leads went unattended in junk folders
    • Client found them one day
    • Client called MSP angry about missing sales leads
    • MSP spent hours investigating
    • Eventually discovered these were unauthenticated from their website contact form
    • Still had to explain why some emails worked and others didn't

    What p=reject would have done:

    • Contact form submissions would have bounced immediately
    • Web developer would have contacted client about email failures
    • Client would have engaged MSP to resolve

    The Shadow IT Reality Check

    MSPs deal with shadow IT constantly:

  • Web developers sending contact form emails
  • Consultants using domain for email campaigns
  • Staff signing up for SaaS tools that send notifications
  • Accounting software configured by bookkeepers
  • HR platforms set up without IT involvement
  • With p=quarantine: Shadow IT mail may be festering in junk folders.

    With p=reject: Shadow IT senders fail fast and contact the client to fix authentication.

    New Sender Compliance Report Makes p=reject Practical

    The traditional argument against p=reject was "you might block legitimate senders by accident". But with tools like VerifyDMARC's Sender Compliance Report, you can see all senders and their overall compliance across all domains.

    Instead of clicking through individual domain reports:

  • See every sender's compliance status in one view
  • Identify authentication gaps across your entire client base
  • Apply proven configurations from similar setups
  • Monitor p=reject confidently knowing all legitimate senders are covered
  • Use No DKIM Senders Report

    Correctly configured DKIM is important with p=reject policies as some types of mail cannot pass SPF checks. VerifyDMARC's No DKIM Senders report makes it easy to identify legitimate senders that have passed SPF checks but do not have DKIM correctly enabled.

    The Business Case: Fewer Support Tickets

    p=quarantine support flow:

    1. Client reports delivery issues
    2. You investigate legitimate email systems
    3. You check spam folder placement across providers
    4. You analyse DMARC reports for anomalies
    5. You discover unauthorised sender
    6. You explain complex authentication concepts to client
    7. You coordinate with client to fix third-party authentication

    p=reject support flow:

    1. Third-party contacts client about bounced emails
    2. Client forwards bounce message asking for help
    3. You see "authentication failed" error immediately
    4. You provide SPF/DKIM setup instructions
    5. Problem solved in one email exchange

    The Bottom Line

    p=reject doesn't just provide better security—it provides better business protection for MSPs. When unauthorised senders fail cleanly, you're not the first person clients call about email problems.

    Your clients get clear outcomes: email either works perfectly or fails with obvious error messages. No gray areas, no spam folder investigations, no lengthy troubleshooting sessions for problems you didn't create.

    Ready to stop getting blamed for shadow IT email problems?

    VerifyDMARC's Sender Compliance Report gives you the visibility to deploy p=reject policies safely across all client domains. See every sender's authentication status in one place and implement policies that protect both your clients and your sanity.

    Start your 30-day free trial and experience how p=reject actually makes client management easier.

    START FREE TRIAL
    DMARC Implementation Guide for Microsoft 365

    DMARC Implementation Guide for Microsoft 365

    A practical guide for MSPs and SMEs to implement DMARC, SPF and DKIM protection for Microsoft 365, Office 365 and Exchange Online email services.

    DMARC Protocol
    Mail Providers
    Fixing "550; 5.7.15 Access denied" from Microsoft

    Fixing "550; 5.7.15 Access denied" from Microsoft

    To fix "does not meet the required authentication level" from Microsoft, you need a DMARC record, SPF and DKIM passing, plus SPF or DKIM alignment.

    DMARC Protocol
    Mail Providers
    Is DANE Right for Your Inbound Email Security?

    Is DANE Right for Your Inbound Email Security?

    Explore inbound email security for SMEs: Compare MTA-STS and DANE with practical guidance on enhancing security using TLS reporting and MTA-STS.

    Security
    TLS Reporting