Email Security Strategy

The Quiet Compliance Exposure: How Email Authentication Gaps Create Uninsured Liability for Your Clients

October 8, 2026

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

Somewhere between the annual cyber insurance renewal and the DNS console sits a gap that almost nobody in the buying process is watching. A client's broker asks whether the company authenticates its email. Someone checks a box. Nobody pulls up the actual DNS record to confirm it says what the application claims. That gap, small and procedural as it looks, is where a growing number of businesses are discovering their coverage was never really there.

Does a missing or misconfigured DMARC record actually void cyber insurance coverage? Not by itself, but it can support a finding of material misrepresentation if the application claimed authentication controls the domain never had, and that finding lets an insurer rescind the policy entirely rather than pay a claim tied to phishing or business email compromise.

Why does DMARC status matter to an insurance underwriter?

It matters because business email compromise and funds transfer fraud now drive more insurance claims than almost anything else insurers see. Coalition's 2025 Cyber Claims Report found that business email compromise and funds transfer fraud together accounted for the majority of 2024 claims, with 29% of BEC events escalating into a funds transfer fraud loss. Underwriters price risk on what predicts loss, and an unauthenticated domain is one of the more reliable predictors they have.

The FBI's Internet Crime Complaint Center backs this up with hard numbers. Its 2024 Internet Crime Report recorded total reported losses exceeding $16.6 billion, a 33% increase over 2023, with business email compromise responsible for $2.77 billion of that across more than 21,000 complaints. Every one of those incidents starts the same way: a message that looks like it came from a trusted domain, sent by someone who does not control that domain at all. DMARC, defined in RFC 7489 as the mechanism that lets a domain owner tell receiving servers what to do with mail that fails SPF and DKIM checks, is the technical control that closes exactly that hole. An underwriter who asks about it is not being pedantic. They are pricing the single largest driver of the claims they pay out.

The compliance web tightening around email authentication

Federal, payment, and mailbox-provider rules have converged on the same three protocols, and none of them are new or exotic. The Department of Homeland Security's Binding Operational Directive 18-01, issued in 2017 and still enforced by CISA, requires all federal civilian agencies to publish SPF and DMARC records and move to a DMARC policy of p=reject. That directive set a template regulators and mailbox providers outside government have since followed in their own domains.

Google made the shift concrete for the commercial internet. Its bulk sender guidelines now require any domain sending 5,000 or more messages a day to Gmail addresses to authenticate with SPF and DKIM and publish a DMARC record, and Google's own guidance confirms that the From header domain must align with either the SPF or DKIM organizational domain for messages sent directly to personal Gmail accounts. Yahoo and Microsoft followed with comparable enforcement on their own mailbox platforms. None of these mandates were written with cyber insurance in mind, but insurers read the same threat data everyone else does, and a control that mailbox providers now enforce by default is not a hard case for an underwriter to justify demanding too.

That is the quiet part of this exposure. A client can pass every mailbox provider's bulk sender check, keep phishing complaints low, and still have never told their insurance broker the truth about DMARC enforcement, because the renewal questionnaire and the DNS zone file were never compared side by side.

What happens when the application and the DNS record disagree?

The application controls the outcome, not the breach. Insurers can rescind a policy over a misrepresented security control even when that control had nothing to do with how the loss occurred, because rescission is a contract remedy, not a claims dispute. The clearest precedent for this is not even an email authentication case, and that is exactly why it matters for domain security.

In Travelers Property Casualty Company of America v. International Control Services, Travelers sought to void a $1 million cyber policy after a ransomware attack, arguing the insured had misrepresented its use of multi-factor authentication on the application. As the brokerage Lockton documented in its analysis of the case, the lawsuit was dismissed in August 2022 with judgment entered for Travelers after the insured agreed to let the court rescind the policy entirely. The ransomware attack was real. The loss was real. The insurer walked away paying nothing, because the gap between what was attested and what was actually deployed was enough to unwind the whole contract.

Swap MFA for DMARC in that fact pattern and the outcome does not change. If a renewal application says email authentication is enforced and a post-incident forensic review finds a DMARC record parked at p=none, or no record at all, the insurer has the same opening. The client's exposure is no longer just the fraud loss. It is the full cost of an incident with no policy standing behind it, because rescission voids coverage from the date the policy was issued.

Where the uninsured liability actually sits

The mismatch below is the one worth checking before a renewal, not after an incident.

None of these gaps are hard to find. They are exactly what a DNS-based scan surfaces in minutes, which is the reason MSPs are increasingly expected to catch them before a client's broker or a forensic investigator does.

Closing the gap before a renewal notice forces the issue

This is not a case for scrambling into DMARC enforcement the week before a policy renews. Moving a domain from p=none to p=reject without breaking legitimate mail requires reading aggregate reports, fixing SPF and DKIM misconfigurations, and tightening policy in stages, and rushing that sequence is how businesses knock out their own email delivery days before they need proof of coverage the most.

For MSPs managing this across a client base, the more durable fix is treating DMARC, SPF, and DKIM status as a standing item in every account review rather than a renewal-season fire drill. ActiScan's getting-started guide walks through the initial domain scan and record interpretation so gaps surface before a client's broker asks about them. Firms evaluating how this fits into existing service tiers can compare options on the pricing page, and the fastest way to see what a client's current authentication posture actually looks like is to run a scan after creating an account.

The compliance exposure here was never really about DMARC as a protocol. It is about the distance between what gets attested and what gets enforced, and that distance is exactly what carriers, mailbox providers, and now the FBI's own loss data all say to close.