DMARC
The Operational Reality of Running DMARC Across Every Client Domain You Own
September 25, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
Every MSP that has rolled out DMARC across a client base eventually learns the same lesson: the DNS record is the easy part. The hard part is everything that happens after publication, across dozens or hundreds of domains, most of which were never inventoried properly, and many of which sit forgotten with active mail flows nobody remembers authorizing.
What does it actually take to keep DMARC running across every client domain?
Running DMARC at scale means continuously monitoring aggregate reports, updating SPF and DKIM records as clients adopt new mail tools, and pushing each domain from a monitoring-only policy toward enforcement without breaking legitimate mail. It is a recurring operational cycle, not a one-time DNS entry, and it demands ownership across an entire client portfolio rather than a single deployment event.
That cycle exists because DMARC itself was designed as a feedback loop, not a switch. The specification, published as an IETF standard, defines three policy states an owner can request: none, quarantine, and reject. The RFC is explicit that the "none" option, where the domain owner requests no specific action be taken regarding delivery, is meant to be a temporary monitoring stage, not a resting place. Yet across the industry that resting place is exactly where most domains stay. Recent research from EasyDMARC found that of over 900,000 domains tracked with a DMARC record in 2026, a majority still sit on p=none, and the firm's earlier 2025 report noted that over 80% of domains globally either lack a DMARC record entirely or use a non-enforcing policy. For an MSP holding that many client domains, that statistic is not an abstraction. It is a backlog.
Why domain inventory is the part everyone underestimates
Before any policy can be tightened, someone has to know every domain exists, including parked domains, acquired brands, and marketing subdomains nobody currently sends from. This inventory step is consistently the most underestimated piece of a DMARC rollout because client environments accumulate domains faster than anyone documents them.
A domain that looks dormant is often the one an attacker targets first, precisely because nobody is watching its DNS. Guidance from the Cybersecurity and Infrastructure Security Agency's directive on federal email security made this explicit years ago, requiring agencies to set a DMARC policy of reject for all second-level domains and mail-sending hosts within one year, not just the domains actively used for outbound mail. Applying that same discipline to a commercial client base means every acquired brand, every legacy website domain, and every "just in case" subdomain needs its own record, because an unprotected domain is an open channel for spoofed mail regardless of whether anyone at the client remembers it exists.
Building that inventory manually across a client roster of any real size does not scale. This is precisely the gap that pushes MSPs toward centralized scanning, and it is why getting a clean per-tenant view early, through a structured process like the one outlined in ActiScan's getting-started guide, saves far more time later than skipping straight to record publication.
The SPF ceiling nobody budgets for
SPF has a hard technical limit that trips up multi-tool client environments constantly. Per RFC 7208, the specification governing SPF, implementations must limit the total number of DNS-querying mechanisms during evaluation to 10, and exceeding that limit forces a permanent error result rather than a pass or fail. Every "include" for a marketing platform, CRM, helpdesk tool, or e-signature service adds to that count, and client stacks routinely exceed ten mechanisms without anyone tracking the total. When that happens, SPF stops evaluating cleanly for every message from the domain, including the legitimate ones, which quietly undermines the DMARC alignment the whole deployment was built to achieve.
Managing this at scale means treating the SPF record as a living inventory of every sending service a client uses, reviewed each time a tool is added or dropped. That review has to happen per domain, per client, on an ongoing basis, which is a materially different workload than the one-time SPF lookup most onboarding checklists assume.
Why the bulk sender rules changed the urgency
Google and Yahoo's 2024 authentication requirements turned DMARC from a best practice into a delivery prerequisite for anyone sending meaningful volume. Google's own sender guidelines state plainly that for direct email, the domain in the sender's From header must be aligned with either the SPF domain or the DKIM domain, and that this alignment is required to pass DMARC. Senders who exceed roughly 5,000 messages a day to Gmail addresses without meeting authentication requirements now risk temporary errors and eventual delivery failures on their traffic.
That threshold catches far more client domains than most MSPs initially expect, including small business clients running email marketing or invoicing platforms that quietly cross 5,000 messages during a campaign month. Once a domain is in that zone, a broken SPF record or a DMARC policy stuck on none is no longer just a security gap. It becomes a deliverability problem that shows up as client complaints before anyone traces it back to DNS.
Moving from none to enforcement without breaking mail
Enforcement has to be earned through data, not assumed from a template. The standard path is to publish DMARC at p=none, let aggregate reports accumulate for several weeks, identify every legitimate sending source showing up in those reports, fix alignment for each one, and only then step the policy to quarantine and eventually reject.
| Stage | Typical duration | Primary risk if skipped |
|---|---|---|
| p=none, monitor only | 2-4 weeks minimum | Unknown senders go unidentified before enforcement |
| p=quarantine (low percentage) | Several weeks | Legitimate mail lands in spam if alignment is incomplete |
| p=reject | Ongoing | Misconfigured forwarders or shadow IT tools get silently blocked |
Skipping straight to reject across a client's entire domain feels efficient but routinely breaks something client-facing, whether that is an invoicing tool, a support ticketing system, or a legacy marketing platform someone in the business still uses quarterly. The aggregate reports defined in the DMARC specification exist specifically to surface those senders before enforcement bites, and reading them consistently across every client domain, not just the flagship ones, is the operational discipline that separates a durable rollout from a support ticket.
What breaks first when nobody is watching
The most common failure mode is not a dramatic spoofing incident. It is quiet decay: a client rotates email service providers, a DKIM selector expires, a new SaaS tool starts sending on the domain's behalf without being added to SPF, and nobody notices until deliverability drops or a report shows unauthenticated volume climbing. Multiplied across dozens of client domains with different renewal cycles and different vendors, that decay becomes a scheduling problem as much as a technical one.
That is the practical argument for scanning infrastructure rather than spreadsheets. An MSP tracking DMARC posture across an entire client roster needs a way to see policy state, alignment failures, and report volume across every domain at once, which is the core reason tools built for multi-tenant visibility exist in the first place. Reviewing what that kind of ongoing coverage costs against the labor of manual per-client checks is worth doing early, and the breakdown on ActiScan's pricing page is built around exactly that comparison for MSPs sizing the workload against a growing domain count.
Bringing new client domains in without starting from zero
Every new client engagement adds another domain to the same lifecycle: inventory, SPF audit, DKIM verification, DMARC monitoring, then enforcement. Standardizing that intake sequence, rather than reinventing it for each client, is what keeps the operational load from growing faster than the client base itself.
Building that standard sequence once, and running every new domain through it via a sign-up flow that already assumes multi-domain management, turns what could be a growing backlog into a repeatable checklist. DMARC was never intended to be set once and forgotten, and an MSP's operational maturity on this front increasingly shows up in how clients evaluate the relationship itself.
The domains that stay stuck on p=none are not usually the ones where nobody cared. They are the ones where the initial rollout succeeded and then nobody built a process to keep watching. That gap between initial deployment and sustained operation is where most of the real exposure sits, and closing it is a scheduling and tooling problem before it is ever a technical one.