DMARC

The p=reject Finish Line Is Costing MSPs a Recurring Revenue Line

October 22, 2026

Ric Hall, CRO— AI-assisted and reviewed prior to publication.

Most MSPs treat DMARC the way they treat a firewall migration: scope it, build it, bill it, close the ticket. A client's domain climbs from p=none to p=quarantine to p=reject, the project folder gets archived, and the account moves on to the next fire. That instinct is understandable, but it leaves money on the table every single month, because the DNS record that just got hardened doesn't stay hardened on its own.

Here is the core problem in one sentence: MSPs that bundle DMARC enforcement into a one-time project, then stop billing once p=reject is live, are giving away the exact monitoring work that protects that enforcement, work that a new SaaS tool, a marketing platform switch, or a single misconfigured sender can undo within weeks.

Why does p=reject feel like a finish line?

It feels final because the policy tag itself reads like an endpoint: reject means reject, full stop. But DMARC was never designed as a one-time setting. The specification built reporting into the protocol permanently, not just for the ramp-up period, because the feedback loop is how domain owners stay aware of what's sending on their behalf.

Under RFC 7489, mail receivers generate aggregate feedback reports on a recurring schedule for as long as the DMARC record exists, not only while a domain is in monitor mode. The protocol's visibility mechanism was built to run continuously, which means a domain owner who stops reading those reports after reaching p=reject is simply choosing not to use a feature that is still actively being delivered to them.

What actually breaks after the project closes?

Plenty, and most of it has nothing to do with DMARC itself. New senders get added constantly: a sales team signs up for an email outreach tool, HR starts using a benefits platform that sends on the client's domain, a marketing agency rotates ESPs. Each of those events can introduce an unauthenticated sender that now fails under an enforced policy, silently dropping legitimate mail instead of stopping an attacker.

A few of the most common post-enforcement failure points include:

• A new marketing or HR SaaS tool begins sending from the domain without being added to SPF or given a DKIM selector.
• A client's IT staff edits the SPF record directly and breaks the include chain or exceeds the 10-lookup limit.
• A forwarding rule or mailing list rewrites headers in a way that breaks alignment for an otherwise legitimate sender.
• A domain acquired in a merger or rebrand gets added to the mail environment without a DMARC record at all.

None of these are hypothetical edge cases. They are the normal churn of a growing business, and every one of them produces data in the aggregate reports that only someone actually watching the dashboard will catch before it becomes a help desk ticket or a missed invoice email.

Regulators and mailbox providers already treat this as ongoing work

This isn't just an internal MSP opinion. The federal government's own directive on the subject frames DMARC reporting as a standing capability, not a project milestone. CISA's Binding Operational Directive 18-01, which still governs federal civilian domains, notes that DMARC reports provide a mechanism for an agency to be made aware of the source of an apparent forgery, information agencies would not otherwise receive. That mechanism only has value if someone keeps reading it after the initial deadline passes.

NIST's guidance points the same direction. NIST SP 800-177 gives recommendations and guidelines for enhancing trust in email, aimed at the people who actually administer mail systems day to day, not a one-time implementation checklist. The mailbox providers have reinforced this too: Google defines a bulk sender as any email sender that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period, a threshold clients can cross or fall below as their business changes, which shifts their authentication obligations without anyone touching the DMARC record itself. Microsoft has since followed Google and Yahoo in requiring DMARC for large senders sending 5,000 or more emails per day across its consumer mail services, which means a client's compliance posture can change based on mailbox provider policy updates that have nothing to do with the MSP's original project scope.

How much revenue is actually being left on the table?

Enough that it changes the shape of an MSP's security practice. Industry pricing data on DMARC services shows the managed cybersecurity services market growing at roughly 18% annually, outpacing overall MSP growth of 14%, with DMARC positioned as one of the more reliable recurring lines inside that growth. The project fee for getting a domain to p=reject is a single transaction. The monitoring that keeps it there is a subscription, and subscriptions compound across a client base in a way that one-time implementation fees never do.

The left column is the same work regardless of who does it. The only question is whether the MSP gets paid for it or does it for free as an unspoken part of "we handle your IT."

Packaging monitoring as its own line item

The fix isn't complicated, but it does require treating DMARC monitoring as a distinct SKU rather than a feature baked into a managed services bundle. A standalone monitoring line, billed per domain per month, makes the ongoing work visible to the client instead of invisible inside a flat MSP retainer.

A few practical steps make this easier to sell:

• Separate the enforcement project (scoped, time-boxed, priced as a fixed fee) from the monitoring retainer (recurring, billed monthly, tied to report review and sender governance).
• Show the client their own aggregate report data as part of the pitch. A domain that has already reached p=reject usually still has new or unverified senders showing up, which makes the ongoing need concrete rather than theoretical.
• Build the monitoring tier around specific deliverables: monthly summary, new-sender alerts, and a documented escalation path when authentication starts failing.

Tooling matters here too. An MSP running this manually across dozens of client domains will burn the margin that makes the line worth selling in the first place, which is why platforms built for multi-tenant report processing exist. A platform's getting-started guide is usually the fastest way to see whether a given tool's monitoring workflow actually scales to a real client book before committing to it. Pricing structures vary widely by vendor, so it is worth comparing a pricing page against the per-domain monitoring rate an MSP plans to charge, since the margin on this line only holds up if the platform cost stays well under the client rate.

Closing the gap

DMARC enforcement is a milestone, not a maintenance plan. A client at p=reject has crossed a real threshold, but the DNS record doesn't defend itself against a new unauthorized sender, a DNS typo, or a provider policy change six months later. MSPs that keep billing only for the implementation project are effectively donating the highest-margin part of the service.

Separating monitoring into its own recurring line doesn't require new technical skill. It requires a packaging decision and a willingness to show clients the ongoing report data that justifies the fee. For MSPs ready to formalize that offering, starting from a signup page for a monitoring platform built around multi-tenant reporting is a faster path than retrofitting spreadsheets and manual report parsing into something billable.

The domains that reach p=reject this year will still be sending mail next year, next quarter, and next month. The only question is whether the MSP gets paid for watching them.