Pacific Debt: p=none to p=quarantine in 90 Days

The Customer: Pacific Debt Relief

Pacific Debt Relief is a 180-person debt settlement company. Three domains. Hundreds of thousands of customer-facing emails per year. The kind of organization that depends on email reaching the inbox — one missed payment notification or settlement update can cost a customer their progress.

Like most mid-market organizations, Pacific Debt Relief had published DMARC records years ago. Like most, they were still at p=none.

For four years.

The Problem: Stuck at p=none

The team at Pacific Debt Relief understood DMARC. They had a tool. They had reports coming in. They knew which senders were failing alignment.

What they didn’t have was a way to do anything about it.

Their previous DMARC platform showed them dashboards full of data. Authentication failures, IP addresses, source breakdowns — all the standard reporting. To resolve a failure, the security team would identify the vendor, schedule a Zoom meeting with the vendor’s support team, and screen-share the dashboard during the call.

The meetings ran 30 to 60 minutes. The vendor’s support engineer would look at the screen. They’d say “I don’t know what I’m looking at” or “I’ll need to check with engineering” or “Can you send me a screenshot?”

Most meetings ended without a fix.

Pacific Debt Relief tried this for four years. The DMARC reports kept arriving. The senders kept failing alignment. The policy stayed at p=none. Spoofers continued to have an open lane to use their domain.

This isn’t a story about technical limitations. The team knew exactly what needed to happen. The problem was coordination — getting vendors to take action on issues that lived inside their support teams’ workflow.

That’s the pattern Verkh was built to solve.

Week 1-2: Onboarding and Sender Inventory

Pacific Debt Relief signed with Verkh after a demo of the APEX link feature. The single deciding factor: the prospect of replacing the meeting-and-screen-share pattern with something a vendor could resolve asynchronously.

The first two weeks were about visibility. Verkh’s AI-powered source analysis processed the incoming DMARC reports and classified every sender:

• Legitimate, configured correctly — pass through
• Legitimate, misconfigured — generates remediation tasks
• Suspicious or unknown — flags for review
• Likely spoofing — escalates immediately

The Pacific Debt Relief team finally had a clear list. Not just IP addresses, but identified services. Microsoft 365 traffic, Salesforce campaigns, payroll system notifications, several marketing automation tools. And an inventory of what each one needed to fix.

Week 3: Catching a Live Spoofing Attempt

This is where the case study turns into a real story.

In Week 3, the security team shared an APEX link with their system administrator covering one of their domains. The link showed live authentication data scoped to specific sources. Anyone with the URL could see the data without logging into Verkh.

The system administrator opened the link and noticed something off. An unfamiliar IP range was sending email from the Pacific Debt Relief domain. The volume was low but persistent. The pattern didn’t match any of the legitimate senders the team had identified.

The IPs didn’t belong to Microsoft. They didn’t belong to Salesforce. They didn’t belong to any vendor the team had a relationship with.

The sysadmin flagged it immediately. Investigation confirmed it: someone was actively spoofing Pacific Debt Relief’s domain, targeting their O365 environment.

Because the team was still at p=none, the attempts had been getting through. After four years of monitoring without enforcement, an attack had been running unnoticed in the data they were already collecting — but never reviewing in a way that surfaced anomalies.

The discovery alone justified the platform switch. It also accelerated the urgency to advance enforcement.

Week 4-8: Vendor Coordination via APEX Links

With the inventory complete and the spoofing attempt confirmed, the team began the methodical work of fixing authentication failures across legitimate senders.

The Verkh platform generated remediation tasks for each failing source: which DNS record needed to change, which DKIM key needed signing, which SPF include was missing. Each task included an effort estimate and a link to vendor-specific documentation.

For tasks that required vendor action, the security team shared APEX links instead of scheduling Zoom calls.

Here’s how the difference played out in practice:

Old workflow: Email vendor support. Wait for reply. Schedule a meeting. Wait for the meeting time. Screen-share the dashboard. Walk through the failure. Vendor doesn’t understand what they’re seeing. Promise a follow-up. Wait a week. Repeat.

New workflow: Send the vendor an APEX link. The vendor opens the link at their convenience and sees the live authentication data scoped to their service. The data updates as they make changes. The security team sees view analytics — when the link was opened, from what device, how often.

Some vendors fixed issues within hours of receiving the link. Others took days. None required a meeting.

By Week 8, the major senders were aligned. Pass rates climbed from below 70% to above 95%.

Week 9-12: Policy Progression to p=quarantine

With pass rates stable, the team began advancing the policy.

Verkh’s risk simulation showed exactly what would happen if the policy moved to p=quarantine: how many messages would be affected, which senders were still at risk, what the impact would be on legitimate traffic.

The progression went in stages:

1. p=quarantine; pct=10 — Quarantine 10% of failing messages. Monitor for unexpected impact.
2. p=quarantine; pct=25 — Increase to 25%. Confirm pass rates remain above 99%.
3. p=quarantine; pct=50 — Halfway there. Review remaining failures.
4. p=quarantine; pct=100 — Full quarantine enforcement.

Each step took a few days of monitoring. By Day 90, Pacific Debt Relief was at full p=quarantine enforcement across all three domains.

After four years stuck at p=none, the policy had advanced in 90 days.

Results and What Comes Next

The hard numbers from Pacific Debt Relief’s first 90 days on Verkh:

• Time to enforcement: 90 days vs. 4 years stuck at p=none
• Active spoofing attempt detected: 1 (the O365 attack found in Week 3)
• Vendor coordination meetings required: 0 (replaced by APEX links)
• Final policy: p=quarantine, 100% rollout, all 3 domains

The team is now working toward p=reject. The remaining work involves a handful of low-volume legitimate senders that weren’t identified during the previous four years at p=none — vendors who only send a few messages per quarter and didn’t appear prominently in the old reports. Once those final edge cases are aligned, they’ll advance to full enforcement.

The Pattern: It Was Never About Data

Pacific Debt Relief’s previous DMARC tool wasn’t broken. It collected reports. It surfaced failures. It showed which senders were misaligned. The team understood the data.

The problem was the gap between knowing and doing. Resolving an authentication failure required getting a vendor’s support engineer to take action on something they didn’t fully understand, in a meeting that interrupted their day, while looking at a dashboard that wasn’t built for them.

That’s not a data problem. It’s a coordination problem.

When Pacific Debt Relief’s security team summarized the difference, they put it simply: the value of Verkh is the ease of coordination and visibility. Their vendors saw the same data they saw, in real time, without a meeting. Their security team caught a spoofing attempt because the right person — the system administrator — had the right view at the right moment.

Four years of being stuck dissolved in 90 days because the platform changed what was possible to coordinate, not what was possible to see.

Could Your Organization Be Stuck on the Same Pattern?

If you’ve had a DMARC record for more than 12 months and you’re still at p=none, the question isn’t whether you have visibility. You probably do.

The question is what stops you from acting on it.

If the answer involves scheduling vendor meetings, screen-sharing dashboards, or waiting on support tickets that go nowhere, you’re stuck on the same pattern that held Pacific Debt Relief at p=none for four years.

Start your enforcement journey free at verkh.io. One domain, no credit card. See your senders, generate remediation tasks, share APEX links with the vendors who need them.

Most of the work is already in your data. The bottleneck is everything that happens between the data and the fix.

That’s what Verkh closes.