Email Security & Compliance

Email Authentication Is Now an Insurance Line Item — MSPs Should Treat It Like One

September 17, 2026

Randy Hall, CEO— AI-assisted and reviewed prior to publication.

Renewal season used to mean filling out a questionnaire, checking a few boxes about firewalls and backups, and moving on. That process has changed shape. A growing share of cyber insurance applications now ask pointed questions about SPF, DKIM, and DMARC, and a growing share of carriers are no longer content to take the applicant's word for it.

For MSPs, the practical answer to whether email authentication belongs in the insurance conversation is yes, and not as a footnote. Underwriters increasingly treat a domain's DMARC policy, SPF configuration, and DKIM signing as observable, verifiable evidence of security maturity, the same way they treat patch cadence or MFA enforcement. A client sitting at no policy or p=none is walking into renewal with a visible gap.

Why Are Insurers Asking About DNS Records Now?

Because business email compromise is where the money actually leaves the building. In its 2026 Cyber Claims Report, Coalition found that business email compromise and funds transfer fraud together accounted for 58% of all cyber incidents the insurer observed in 2025, with over half of funds transfer fraud claims originating from a BEC event. That is not a niche threat category. It is the largest single driver of claims dollars, and it is also the category that domain-level email authentication is specifically designed to reduce.

Insurers have noticed. The National Association of Insurance Commissioners tracks the market through its annual Cybersecurity Insurance Report, and the 2025 edition describes a market where rate softening and slower topline growth have followed a period of rapid premium increases, as insurers grow more comfortable with the controls policyholders have in place. Softer pricing does not mean softer scrutiny. It means underwriters have gotten better at telling which applicants have actually closed their gaps and which have not.

The American Academy of Actuaries has been building out a Cyber Risk Toolkit that gives the actuarial profession a shared framework for pricing this exposure, a sign that email-borne fraud has moved from an IT problem into a line item that shows up in loss models. When the actuarial side of the industry starts formalizing a risk category, it tends to show up in underwriting questionnaires not long after.

What Happens When a Client's DNS Record Doesn't Match What They Told the Carrier?

It creates a documentation problem that surfaces at the worst possible time, during a claim. Carriers are increasingly running their own DNS lookups against an applicant's domain rather than relying solely on self-attestation, and a mismatch between what was claimed on the application and what the record actually shows is a material misrepresentation issue, not a technicality.

This is the part MSPs should sit with. A client who checked "yes, we have DMARC" on a renewal form, when the domain is actually unauthenticated or parked at p=none, has created a paper trail that a claims adjuster can pull up in minutes. Nobody can promise a specific outcome once a policy is in force, but a documented gap between attestation and reality is exactly the kind of thing that turns a routine BEC claim into a contested one.

The underlying protocol makes this easy to check from the outside. DMARC, formalized in RFC 7489, is published in DNS as a plain-text record, which means anyone, including an underwriter's automated tooling, can query it without needing access to the client's mail servers or credentials. There is nowhere to hide a gap once someone knows to look.

The Compliance Backdrop Is Converging on the Same Answer

Insurance questionnaires are not happening in isolation. They are arriving alongside a set of mailbox-provider and payment-industry requirements that already point the same direction. Google's own guidance for anyone sending mail to Gmail accounts states plainly that senders must set up SPF, DKIM, and DMARC authentication for their sending domains, with escalating enforcement for higher-volume senders. Yahoo and Microsoft have layered on similar expectations over the same period.

The payment card industry moved in a related direction with PCI DSS v4.0.1. The binding text of Requirement 5.4.1 asks for automated mechanisms to detect and protect personnel against phishing, without naming a specific protocol, but the standard's own guidance column names DMARC, SPF, and DKIM as the anti-spoofing controls it expects entities to consider when meeting that requirement. Whether a carrier's questionnaire literally references PCI DSS or not, an assessor and an underwriter are increasingly reading the same signal off the same DNS record.

That convergence matters for how MSPs prioritize the work. A client does not need three separate justifications to fix a missing DMARC record. Deliverability, payment compliance, and insurability are now pointing at the identical fix.

What Enforcement Level Actually Signals to an Underwriter

Not all DMARC records read the same way to a reviewer, human or automated. The policy tag is the difference between a domain that is merely monitoring and one that is actually blocking spoofed mail.

A client can technically answer "yes" to "do you have DMARC" while sitting at p=none, and that answer is not false, but it also is not the same claim as enforcement. MSPs who can show the difference, and who can move clients from monitoring to enforcement in a documented, staged way, are giving their clients something concrete to hand a broker.

Turning This Into a Documented MSP Process

Getting a client to enforcement is a technical project. Turning that project into insurance-grade evidence is a documentation project, and MSPs are better positioned to own that second piece than almost anyone else in the client's vendor stack. That starts with a baseline scan across every domain in the book of business, not just the ones a client happens to ask about.

A few things separate a defensible record from a shaky one:

• Continuous monitoring of policy level and alignment rates, not a one-time check at onboarding
• Historical evidence that shows when enforcement was reached and that it has held since
• Reporting formatted for a broker or underwriter, not just for an internal ticket

This is the gap ActiScan is built to close for MSPs managing dozens or hundreds of client domains at once. The platform's getting-started guide walks through connecting a first batch of domains and reading the initial authentication findings without needing a DNS background on the team. From there, ongoing scans turn what used to be a manual DNS lookup into a standing record an MSP can point to at renewal time, for any client, on demand.

Because this is a portfolio problem for MSPs rather than a single-domain problem, the pricing page is structured around scanning a client base rather than one domain at a time, which is the shape the work actually takes once authentication becomes a recurring line item on every renewal conversation. Firms that have not yet formalized this as a service line can see the tiers and start with a free signup to see where their current client domains actually stand before the next renewal cycle forces the question.

The Bottom Line for MSPs

None of this means an MSP can promise a client a lower premium or a smoother renewal. Underwriting decisions sit with the carrier, and no amount of DNS hygiene overrides the rest of an applicant's risk profile. What an MSP can control is whether the client walks into that conversation with a defensible, documented authentication posture instead of a guess.

Email authentication was already good security practice before it became an underwriting question. What has changed is who else is checking, and how quickly a bad answer surfaces. Treating it as a standing service line, tracked and reported the same way an MSP already tracks patch levels or backup status, is the difference between reacting to a broker's question and having the answer ready before it's asked.