MSP Operations
Why Email Authentication Is Becoming a Standard Line Item in MSP Contracts
September 17, 2026
Randy Hall, CEO— AI-assisted and reviewed prior to publication.
A few years ago, most managed service providers treated SPF, DKIM, and DMARC as a one-time setup task buried inside a broader "email security" bundle. That habit is disappearing fast. Mailbox providers, payment card auditors, and cyber insurers have each independently decided that email authentication is no longer optional infrastructure, and MSPs that fail to price it, document it, and contract for it separately are now exposed to real liability.
Why is email authentication showing up as its own contract line item?
Email authentication is becoming a distinct line item because three separate external forces now enforce it on different timelines: mailbox providers reject unauthenticated bulk mail, payment auditors check for anti-phishing controls, and insurers ask about it during underwriting. When three unrelated gatekeepers all demand the same control, MSPs stop treating it as a courtesy and start treating it as a billable, auditable deliverable with its own scope and renewal cadence.
That shift did not happen because MSPs decided authentication was suddenly more profitable to sell. It happened because the cost of not having it moved from abstract to concrete. A client whose mail gets routed to spam, or whose cyber policy gets denied, has a very specific and traceable failure point, and that point increasingly leads back to whoever managed the domain's DNS records.
The mailbox providers made the first move
Google set the pace in October 2023 by publishing new guidelines that took effect in February 2024, requiring anyone sending more than 5,000 messages a day to Gmail addresses to authenticate their mail. According to Google's own support documentation, bulk senders must set up SPF, DKIM, and DMARC, while even smaller senders are told to configure at least SPF or DKIM to avoid spam filtering. Yahoo moved in lockstep with nearly identical thresholds, and by the time Microsoft followed, the pattern was unmistakable.
Microsoft's rollout landed in 2025. Its Defender for Office 365 team announced that starting May 5, 2025, Outlook would begin routing messages from high-volume domains lacking proper authentication into the junk folder, with harder enforcement to follow for continued noncompliance. That one sentence, buried in a Microsoft Tech Community post, effectively told every domain owner sending real volume to Hotmail, Live, and Outlook addresses that authentication was no longer a best practice but a delivery precondition.
The technical requirements themselves are not new. RFC 7208 defines SPF, RFC 6376 defines DKIM, and RFC 7489 defines DMARC, and NIST has been recommending all three since at least 2016 in its guidance on trustworthy email. What changed is enforcement. NIST's own publication on the subject describes SPF, DKIM, and DMARC as the mechanisms that let receiving systems verify that a message actually originated from where it claims, and mailbox providers finally started acting on that verification at scale rather than treating it as advisory.
For an MSP managing dozens or hundreds of client domains, that enforcement wave turned a background configuration task into an active compliance surface. Getting a client's authentication records right the first time, and keeping them right as vendors and marketing tools rotate through the DNS, is exactly the kind of recurring work that belongs in a signed scope of work rather than a goodwill favor.
What does the compliance and insurance side actually require?
Payment card processors and cyber insurers now expect documented anti-phishing controls, and DMARC-aligned authentication is one of the few technical measures both accept as evidence. PCI DSS 4.0's Requirement 5.4.1 calls for automated mechanisms to detect and stop phishing, a bar that awareness training alone does not meet, and insurers are asking similar questions before binding coverage.
The PCI Security Standards Council's current standard is explicit that training is not sufficient on its own. Proofpoint's guidance on the requirement notes that Requirement 5.4.1 mandates automated processes to detect and protect personnel against phishing attacks, and that this is not satisfied by training alone. For any MSP client that processes cardholder data, that requirement effectively forces a technical control conversation, and DMARC enforcement is one of the more defensible answers available.
Insurance underwriters have their own reasons to care. Coalition's 2025 Cyber Claims Report found that business email compromise and funds transfer fraud together accounted for 60 percent of all claims in 2024, with 29 percent of BEC events escalating into an actual funds transfer loss. When six in ten claims trace back to the inbox, it is not surprising that underwriting questionnaires increasingly probe whether a domain publishes DMARC at enforcement, not just monitoring.
None of this means authentication guarantees a lower premium or a clean audit. It means the absence of it is now a flagged gap in two separate risk assessments that MSP clients face regardless of what their provider bundles into a support contract.
Federal guidance now treats MSPs as part of the client's attack surface
The joint advisory issued by CISA, the NSA, and the FBI, along with international partners, was written specifically because MSPs sit inside the trust boundary of every client network they touch. The advisory recommends that organizations define appropriate security measures in contractual agreements with their MSP, and that MSP customers should ensure their own contractual arrangements formalize which security functions the provider delivers.
That single recommendation is the clearest regulatory signal MSPs have received that vague, verbal understandings about who owns email security are no longer defensible. If a customer's cyber insurer or a post-incident forensic review asks who was responsible for DMARC enforcement on a compromised domain, "it was probably included" is not an answer that holds up. A dated statement of work naming SPF, DKIM, and DMARC monitoring as a specific service is.
How MSPs are structuring authentication as a billable service
The MSPs adapting fastest are not just adding a line to the invoice, they are formalizing the entire lifecycle: discovery, deployment, enforcement, and ongoing monitoring as domains and sending sources change.
- Discovery and baseline audit: scanning every client domain and subdomain for existing SPF, DKIM, and DMARC records, including forgotten marketing or HR platforms that send mail on the client's behalf.
- Policy staging: moving DMARC from
p=nonetop=quarantineand eventuallyp=rejectin controlled stages, since jumping straight to enforcement without visibility into legitimate senders risks blocking real mail. - Ongoing monitoring and reporting: reviewing DMARC aggregate reports on a recurring basis, since authentication drifts whenever a client adds a new SaaS tool that sends email under their domain.
That staged approach mirrors what most vendor documentation recommends and it also maps neatly onto a recurring managed-services fee rather than a one-time project charge. A domain that reaches enforcement and then goes unmonitored for a year is not meaningfully safer than one that was never configured, because a single new unauthenticated sender can quietly break alignment.
| Contract model | What it typically includes | Where it falls short |
|---|---|---|
| Bundled into general email support | Ad hoc fixes when deliverability breaks | No baseline audit, no enforcement roadmap, no documentation for insurers |
| One-time DMARC setup project | Initial SPF/DKIM/DMARC deployment | No monitoring after go-live, drift goes unnoticed |
| Recurring authentication line item | Audit, staged enforcement, ongoing report review, client-facing documentation | Requires tooling and process, but matches how the risk actually behaves |
For MSPs building out that third model, the practical starting point is a domain-level scan across the entire client book rather than a manual, one-domain-at-a-time review. ActiScan's getting-started guide walks through setting up that baseline scan so technicians can see which client domains already have enforcement-grade DMARC and which are still sitting at p=none or missing SPF entirely. From there, the pricing conversation becomes concrete: clients can see exactly which domains are exposed and what closing that gap involves.
The contract language is catching up to the risk
Email authentication has followed a familiar pattern in the MSP world. A technical control starts as something a good technician does anyway, then a major platform makes it a delivery requirement, then an auditor or insurer makes it a compliance question, and finally it shows up in the master services agreement with its own price and its own renewal date. SPF and DKIM have been through most of that cycle already, and DMARC enforcement is now moving through the same stages on a compressed timeline.
MSPs that keep authentication folded into a generic support retainer are underpricing a service that mailbox providers, card networks, and insurers have all separately decided matters. Those that carve it out, document it, and monitor it on a recurring basis are better positioned when a client's cyber insurance renewal or PCI assessment asks a pointed question about anti-phishing controls. Reviewing the current pricing structure for a domain-scanning tool built around that workflow, or starting directly from the signup page to baseline a client portfolio, is a reasonable next step for any provider still treating authentication as an afterthought rather than a service.