DMARC

The Ghost Sender Problem: Why Outbound DMARC Compliance Doesn't Mean Internal Visibility

October 1, 2026

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

A managed service provider can report a client's DMARC policy sitting at p=reject, SPF passing, DKIM signed, and still be wrong about what is actually happening on that domain. Policy enforcement and sender inventory are two different jobs, and MSPs frequently finish the first without ever completing the second. The result is a blindspot that looks like compliance from the dashboard and looks like exposure from inside the network.

What exactly is a ghost sender?

A ghost sender is any internal system, application, or device that sends mail using a client's domain in the From header without being formally tracked, authenticated, or owned by anyone on the account. Think of the old scan-to-email function on a networked printer, a line-of-business app that emails invoices through its own SMTP relay, or a marketing automation tool a department signed up for without telling IT. It keeps sending quietly until either DMARC reports flag it or, worse, an attacker finds it first.

Every DMARC rollout guide repeats the same promise: turn on aggregate reporting and you get visibility into who is sending mail on behalf of a domain. That promise is accurate, as far as it goes. The DMARC specification itself describes aggregate reports as the mechanism by which domain holders learn which IP addresses are sending as their domain and whether those messages pass authentication. The problem is what "visibility" actually means in practice for an MSP managing dozens of client domains at once.

Why does outbound monitoring stop short of real visibility?

DMARC aggregate reports show IP addresses and authentication results, not system owners, business purpose, or risk level. An MSP technician reading a report sees a passing or failing IP, not "this is the client's old HR payroll export tool that nobody has touched in two years." Translating a report into an inventory of known, owned, authenticated systems is a separate and often skipped step.

This is a known pattern across the industry, not a hypothetical. Guidance aimed at MSPs explicitly treats sender inventory as its own distinct activity: a technician has to find every system sending mail for a client, prove whether it passes authentication, and only then move toward enforcement, as laid out in guidance on what DMARC monitoring means for MSPs. Reading that framing closely, the inventory step comes first conceptually, but it is also the one most likely to get compressed under time pressure, because unlike publishing a DNS record, it requires someone to physically chase down every department and ask what sends mail.

The practical effect is that many MSPs can tell a client their domain is protected against external spoofing while having no current answer to a more basic question: what is this domain actually being used for, today, by whom. A DMARC policy of p=reject stops unauthorized mail from being delivered, but it does nothing to tell anyone that an internal finance tool has been quietly failing SPF for eight months because nobody flattened the record after a new vendor was added.

The SPF lookup limit turns ghost senders into silent failures

Ghost senders don't always announce themselves as spoofing attempts. Often they are legitimate internal systems that fail authentication because of ordinary DNS mechanics nobody is watching. SPF evaluation is capped at 10 DNS mechanism lookups per RFC 7208, and every include, a, mx, exists, or redirect mechanism consumes part of that budget. Add one more SaaS platform to a client's SPF record and the whole thing can silently cross the line into a PermError, which fails authentication for every message from the domain, not just the new sender.

That means a system that was correctly authenticated six months ago can become a ghost sender today without anyone touching its configuration. The failure is invisible until someone reads the aggregate report closely enough to notice a new permerror pattern, and busy MSPs reviewing reports across many tenants rarely have the bandwidth to catch a quiet regression on one client's SPF record before it becomes an incident.

When does the gap actually surface?

It tends to surface during an incident, not a routine review. A breach investigation or a client complaint about bounced invoices is often the first moment anyone traces a failing or unauthorized sender back to a specific internal system, well after the authentication problem began.

By that point the cost calculus has changed. Business email compromise is not a theoretical category of loss: the FBI's Internet Crime Complaint Center recorded 21,489 BEC complaints in 2023 with adjusted losses exceeding $2.9 billion, and cumulative exposed losses from 2013 through 2023 reached roughly $55.5 billion across more than 305,000 incidents, according to the FBI's public service announcement on BEC. A domain with unmonitored ghost senders is a softer target for this category of fraud, because an attacker who compromises or spoofs one of those unmanaged systems inherits whatever trust the rest of the domain has built up with recipients.

The regulatory direction of travel makes the gap harder to ignore, too. Federal civilian agencies have been required to move to DMARC at p=reject under CISA's Binding Operational Directive 18-01, and Google now requires any domain sending 5,000 or more daily messages to personal Gmail accounts to authenticate with both SPF and DKIM and publish at least a p=none DMARC policy, per Google's own email sender guidelines. None of those requirements, on their own, force anyone to maintain a living inventory of which internal systems are authorized senders. They test the DNS record, not the org chart behind it.

Closing the gap between outbound reporting and internal ownership

Three practices separate MSPs who genuinely close this gap from MSPs who merely monitor a dashboard.

• Maintain a sender inventory per client that maps every IP or service seen in aggregate reports to a named system, department, and internal owner, updated whenever a new tool is procured.
• Treat SPF lookup count as a recurring maintenance item, not a one-time setup task, since adding a single vendor can push a record past the RFC 7208 ceiling without any visible warning.
• Review aggregate reports for new or unexplained sources on a fixed cadence rather than only when a client asks, since a quiet failure can sit undetected for months.

None of this replaces a client's own IT governance, and no scanning tool can guarantee a specific compliance outcome or substitute for a security team's judgment about which systems belong on a domain. What a platform can do is make the inventory step less dependent on a technician's memory of forty client domains. ActiScan's scanning approach is built around that distinction between "the policy is published" and "every sender behind it is accounted for," and MSPs onboarding new clients can walk through that mapping using the getting-started guide before any policy gets tightened toward enforcement.

For MSPs evaluating whether to formalize this as a service line rather than a reactive favor, it helps to see what tiers of ongoing sender monitoring typically look like across a client base, which is covered on the pricing page. Providers who want to see how the sender inventory view works against a live domain can start directly from the signup page and pull a report before committing to a workflow change.

The uncomfortable truth is that a clean DMARC report and a safe domain are not the same claim. One says unauthorized mail gets rejected. The other says someone knows what every piece of the domain's outbound mail actually is. MSPs who only monitor the first are leaving the second to find itself out during a breach, which is the worst possible moment to discover a ghost sender that has been there all along.