DMARC

The Hidden Revenue in DMARC Reports: Unauthorized Senders Your Clients Never Knew They Had

November 5, 2026

Rodney Hall, COO— AI-assisted and reviewed prior to publication.

Every DMARC aggregate report an MSP pulls for a client tells two stories at once. One is the story of attackers trying to spoof the domain. The other, quieter story is about the client's own vendors, SaaS tools, and departments sending mail that nobody ever documented. Most technicians read the first story and skip the second, closing tickets the moment obvious spoofing drops off. That habit leaves real, billable remediation work sitting untouched inside a report the client already paid to generate.

The core issue is simple to state. When a DMARC aggregate report shows unauthenticated volume, it does not automatically mean an attacker. It frequently means a legitimate, currently-in-use service, a CRM, a help desk tool, a payroll processor, that was turned on by someone in the business without ever being added to the domain's SPF record or given a DKIM key. That gap is a documentation failure, not a security incident, and closing it is exactly the kind of recurring work MSPs are positioned to sell.

What Is Actually Showing Up in These Reports?

A DMARC aggregate report is a daily XML summary that a receiving mail system, Gmail, Microsoft, Yahoo, sends back to the domain owner describing every source IP that sent mail claiming to be from that domain, along with whether it passed or failed SPF and DKIM. The format is defined in RFC 7489, which specifies that the report gives domain owners visibility into message streams relevant to them, including the mail that failed as well as the mail that passed. That failed bucket is where the ambiguity lives, and it is exactly where MSPs tend to stop looking too early.

Inside that failed bucket sit three very different categories of traffic: outright spoofing from unrelated IPs, the client's own mail server misconfigured in some minor way, and a third category that gets far less attention, legitimate third-party services the business actually uses that were never written into DNS. Industry guidance on reading these reports consistently separates genuine spoofing from senders with "legitimate IPs" that simply "aren't properly authenticated," a distinction that determines whether the fix is a security response or a documentation fix. The report's XML does not label which bucket a given source belongs to. Someone has to do that triage, and that someone is usually the MSP, if anyone.

Why Do Legitimate Services Go Undocumented in SPF?

Services get left out of SPF because adding them requires someone to remember, at the moment a new tool is adopted, that email authentication exists as a dependency. In practice, marketing signs up for an email platform, sales turns on a CRM's outbound notifications, or HR enables a benefits portal's automated mail, and none of those purchases route through the person who manages DNS. The SPF record stays frozen at whatever it was when the MSP last touched it.

This is compounded by a hard technical ceiling that most non-technical buyers never learn about. SPF evaluation is capped under RFC 7208 at ten DNS-querying mechanisms per check, counting every nested lookup inside an include statement. A client who has added five or six SaaS platforms over several years without pruning old ones can hit that ceiling, at which point receivers return a permanent error and treat SPF as failed for everyone, including services that were correctly authorized. A guide aimed specifically at MSPs managing this problem across client domains notes that nested includes within third-party records consume lookups that are easy to miss during a manual review, which means the ceiling can be breached invisibly, one client-side SaaS signup at a time.

The pressure to close these gaps has also grown sharper because the receivers themselves have raised the bar. Google's own sender guidelines now state plainly that bulk senders must set up SPF, DKIM, and DMARC, with alignment required between the From header and at least one of the authenticated domains, and Gmail began enforcing that requirement against rate limits and rejections after February 2024. A client who does not know their invoicing platform or help desk tool is failing SPF is also, often without realizing it, degrading deliverability for every department that relies on that tool.

The Revenue MSPs Leave on the Table

Treating a DMARC report as a pure security artifact, scan for spoofing, close the ticket, misses the recurring diagnostic and remediation work hiding in the "legitimate but unauthenticated" category. Each undocumented sender identified in aggregate data represents a discrete, explainable piece of work: confirm the service is legitimate, obtain its SPF include or DKIM selector from the vendor, add it to DNS, and verify the next report shows a pass. That is a billable engagement with a clear before-and-after, not an open-ended security retainer that is hard to scope.

The pattern tends to repeat across a client base in predictable ways:

• A help desk or ticketing platform sends outbound notification mail that was never added to SPF when the subscription started.
• A payroll or HR system emails employees directly from a vendor-hosted mail server outside the client's own infrastructure.
• A marketing platform or transactional email API (invoicing, e-signature, appointment reminders) sends on the client's behalf without an aligned DKIM signature.
• An old vendor relationship ended, but its SPF include was never removed, quietly consuming part of the ten-lookup budget for nothing.

Each of these produces a distinct signature in the aggregate data, and each one maps to a different, scopeable fix.

This table is not exhaustive, but it illustrates the point: unauthenticated volume is not a single problem with a single fix. It is several distinct problems, each billable on its own terms, bundled together inside one XML file that most technicians skim rather than parse.

Turning Aggregate Report Noise Into a Billable Workflow

The practical obstacle is volume, not insight. A client with several active sending sources can generate reports from a dozen or more receiving providers daily, each one a separate compressed XML file with its own schema quirks. Reading them by hand does not scale across an MSP's client base, which is exactly why this category of work gets skipped rather than sold.

A structured scanning workflow changes that calculus. Instead of manually opening XML attachments, an MSP can run continuous aggregate report parsing that groups failures by source, flags which ones are recurring from the same legitimate-looking infrastructure, and surfaces the undocumented senders as a discrete punch list per client. ActiScan's own getting-started guide walks through connecting a domain's DMARC reporting address so this grouping happens automatically rather than through manual review of each provider's report format.

Once that punch list exists, the conversation with the client stops being abstract. It becomes a line-item: this vendor, this volume, this fix, billed once to resolve and then monitored going forward to catch the next undocumented service before it silently degrades deliverability. MSPs evaluating how to price that ongoing monitoring against one-time remediation work can review the tiering on the pricing page, since the economics differ meaningfully between a single SPF cleanup and a retained watch across a growing client roster.

Where This Fits Into Ongoing DMARC Operations

None of this replaces the underlying security value of DMARC, moving a client toward p=quarantine or p=reject still depends on first getting SPF and DKIM correct for every legitimate sender, which is the stated purpose of DMARC under RFC 7489 in the first place. The point is that the path to enforcement and the discovery of unbilled legitimate senders are the same process, run against the same report data. Separating them into "security work" and "ignored documentation gap" is an artificial split that costs MSPs revenue they already have the data to claim.

For MSPs that have not yet built aggregate report review into a standing client workflow, the fastest way to see what is actually hiding in a client's mail stream is to start pulling and parsing the reports rather than estimating from memory. ActiScan's signup page sets up that reporting pipeline directly, turning what used to be an occasional manual XML review into a running, groupable record of every sender, authorized or not, claiming to use a client's domain.

The unauthenticated volume sitting in those reports was never really invisible. It was just unprofitable to find by hand.

Further Reading

• wander.science
• en.wikipedia.org