Cyber Insurance Requirements 2026: The Email Controls Underwriters Check

Published 2026-08-21

Cyber insurance requirements in 2026 increasingly include a small set of email-authentication controls — SPF, DKIM, and an enforcing DMARC policy — that an underwriter can verify from public DNS without ever touching your network. That makes them cheap to check and, for most applicants, easy to fail. The August 2026 defaults.exposed census graded 376,928,750 domains for email authentication and found that only 2.9% — 10,902,284 — carry all three controls fully in place. Put the other way: roughly 97% of the internet would fail a strict email-authentication test, the exact control a growing number of cyber underwriters now run at application and renewal. This guide sets out what insurers check, why email authentication became an underwriting line item, and how to see where your own domain stands before your broker does.

If you are renewing a cyber policy this year, the email-authentication section of the questionnaire is one you can answer honestly in minutes — and one where an optimistic answer can come back to bite you at claim time. Underwriters no longer take these answers purely on trust: the domain-side controls are visible to anyone, so a “yes” is checkable. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.

What cyber insurers require in 2026 (answer-first checklist)

Cyber insurance requirements vary by insurer, region, and policy size, and no single checklist is universal. But across most 2026 questionnaires the same core controls recur, because they are the ones that correlate with the claims insurers pay most often. The common set looks like this:

Multi-factor authentication (MFA) on email, remote access, and privileged accounts.
Email authentication — SPF, DKIM, and an enforcing DMARC policy on your sending domains.
Secure email gateway / anti-phishing filtering.
Endpoint detection and response (EDR) across workstations and servers.
Tested, offline or immutable backups.
Patch management with no unsupported, end-of-life software exposed.
Security-awareness training for staff.
A documented incident-response plan.

Of that list, most items are things you attest to and an insurer verifies only if they investigate a claim. Email authentication is different. SPF, DKIM, and DMARC live in public DNS, so an underwriter — or the external-scan vendor many now use — can confirm your answer in seconds, before a policy is even quoted.

That is the practical reason to treat the email-authentication line as the one that will actually be checked. It is objective, external, and unforgiving: your domain either publishes an enforcing DMARC policy or it does not, and there is no benefit of the doubt. Across the whole internet, only 9.3% of domains clear that bar.

Why email authentication became an underwriting control

Cyber insurers price risk against the claims they pay, and two of the most frequent and expensive claim types — business email compromise and invoice-redirection fraud — begin with a spoofed or impersonated domain. When a criminal sends an invoice that appears to come from a supplier, or a payment instruction that appears to come from a director, an enforcing DMARC policy on the impersonated domain is one of the few controls that stops the forged message before a human ever has to spot it.

That gives underwriters a rare thing: a single, externally measurable signal that both reduces a common loss and indicates broader security hygiene. A domain that has done the work to reach p=reject has usually done other work too. So the control does double duty — it lowers the specific BEC exposure and acts as a proxy for maturity.

The mechanics of that fraud are not the subject of this article; they are covered in depth elsewhere. For the anatomy of a spoofed message, see Email Spoofing Explained: Why 90.7% of Domains Can Be Forged. For the payment-diversion loss it enables, see Invoice Fraud Prevention: Closing the Domain Spoofing Gap Behind BEC, and for the broader category, What Is Business Email Compromise: Inside the 90.7% Spoofing Gap. This article stays on the underwriting question: what is being checked, and how few domains would pass.

DMARC, SPF, and MFA: the email controls underwriters actually check

Three names come up on almost every cyber questionnaire. Two of them are visible from the outside; one is not.

SPF (Sender Policy Framework, RFC 7208) publishes, in DNS, the list of servers allowed to send mail for your domain. On its own it protects the invisible envelope address, not the From: line a person reads, which is why SPF alone is not enough. How defaults.exposed grades it is set out in the SPF methodology.

DKIM (DomainKeys Identified Mail, RFC 6376) attaches a cryptographic signature to outbound mail so a receiver can confirm it was not altered and came from an authorised system. See the DKIM methodology.

DMARC (RFC 7489) is the control that ties the other two to the visible From: domain and tells receiving servers what to do when a message fails: monitor (p=none), quarantine, or reject. Only quarantine and reject stop a forgery reaching the inbox. The grading logic is in the DMARC policy methodology. An underwriter’s scan reads this record and asks one question: does it enforce?

MFA is the odd one out. It protects your mailboxes from account takeover, and it matters enormously — but it lives inside your identity system, not in public DNS. An underwriter cannot see it from the outside; they verify it by attestation and, after an incident, by audit. defaults.exposed measures only the DNS-visible controls — SPF, DKIM, and DMARC — because those are the ones that can be confirmed without your cooperation. That is precisely why they are the controls an underwriter can quietly check before you ever fill in the form.

The reality gap: only 2.9% of domains would pass a strict email-auth test

Run the underwriting check across the entire internet and the pass rate is startling.

Of the 376,928,750 domains graded for email authentication in the August 2026 census, only 10,902,284 — 2.9% — are fully protected, meaning they publish SPF, DKIM, and an enforcing DMARC policy together. That is the strictest reading of “email authentication in place,” and roughly 97% of domains would fail it.

Relax the test to DMARC enforcement alone and the picture barely improves. Only 9.3% (34,983,618) of domains publish an enforcing DMARC policy (p=quarantine or p=reject). The other 90.7% (341,945,132) have no enforcing policy at all — most publish no DMARC record, and much of the rest sits at p=none, a record that looks present on a basic scan while instructing receivers to take no action on forged mail.

Go wider still and the floor drops out. 56.8% (214,276,774) of graded domains publish neither SPF nor DMARC — no email-authentication posture whatsoever for a scanner to read. That silent majority is profiled in The Silent Domain: 56.8% of the Internet Has No Email Authentication. Even the broadest possible pass — any DMARC record, enforcing or not — is met by just 20.0% (75,571,248) of domains.

The gap between “publishes a record” and “would pass” is where most applicants live. A domain can carry a DMARC record and still fail a strict control if that record is set to p=none. Presence is not enforcement, and an underwriter’s scan grades enforcement. The same pattern — controls that look deployed but are not actually closed — runs through every layer of the web; we measured the rare domains that close every attack surface at once in The Locked Vault: Only 10.9 Million Domains Close Every Attack Surface Simultaneously. On email authentication specifically, fewer than one domain in thirty would pass clean.

Check your domain free at defaults.exposed to see which side of that 2.9% your own domain sits on — it reads your live SPF, DKIM, and DMARC records straight from public DNS, the same way an underwriter’s scan does.

What happens to a BEC claim if your domain was not protected

This is the question that turns an abstract control into a budget line, so it is worth being precise — and honest about the limits of a general answer. Policy wordings differ, and only your own policy and broker can tell you what applies to you. What follows is general information, not legal or coverage advice.

Cyber policies increasingly ask applicants to confirm specific controls, and the answers can be treated as representations the cover is priced on. Three things tend to matter when a business email compromise loss reaches a claim:

What you attested. If an application stated that email authentication was enforced and the domain in fact sat at p=none or published no DMARC at all, that mismatch is exactly the kind of thing an insurer can examine — and it is externally verifiable after the fact, because DNS history is public.
Which cover responds. BEC and social-engineering fraud are often handled under a specific sub-limit or endorsement rather than the headline cyber limit, and that sub-limit is frequently far smaller.”Covered” and “covered in full” are not the same sentence.
Whether a required control was in place. Some policies condition cover, or a sub-limit, on named controls being live. A control that was attested but not actually deployed is the weakest position to be in at claim time.

None of this means an unprotected domain automatically voids a claim — that depends entirely on the wording. But it does mean the honest, low-cost move is to make the attestation true before you sign it. The categories of loss and the roles criminals impersonate are set out in CEO Fraud Explained: Why Publishing DMARC Is Not Enough, which is a useful reminder that enforcement, not mere publication, is what counts.

How to meet cyber insurance email requirements before renewal

The work to move from “would fail” to “would pass” is a sequence of DNS changes plus a few weeks of listening. It is low-risk when done in order, and every step is verifiable — by you, and by your insurer.

Measure your current posture. Before you touch anything, find out what your domain publishes today. If you are among the 56.8% with neither SPF nor DMARC, you are starting from zero; if you have a record at p=none, you have a monitoring posture, not a protective one.
Publish SPF and DKIM for every legitimate sender. List the services that send mail as you — your mail platform, CRM, invoicing tool, marketing system — and bring each under SPF and DKIM so genuine mail authenticates and aligns.
Start DMARC at p=none with reporting. Publish a DMARC record in monitor mode with an rua address you watch. This changes nothing about delivery while the aggregate reports reveal every sender using your domain. This is the only stage at which p=none is the right answer — as a temporary listening post, not a destination.
Move to p=quarantine, then p=reject. Once the reports confirm your legitimate senders align, tighten the policy. quarantine sends forgeries to spam; reject refuses them outright. Set pct=100 and a matching sp=reject so subdomains are covered and no mail is exempted. The DMARC reporting methodology explains how to read the reports that guide this move.
Keep the evidence. Underwriting is easier when you can show, not just assert. A dated record of your enforcing policy and monitoring is the difference between an attestation and proof.

Domains that break legitimate mail almost always skipped the listening phase and jumped straight to p=reject. Sequenced properly, the risk is minimal and the outcome is an answer to the questionnaire you can defend. If you want the gaps closed properly and kept closed — SPF, DKIM, an enforcing DMARC policy, and continuous monitoring that produces audit-ready evidence at renewal — see how the fix works.

One caveat on scope: email authentication is the domain-visible control, but it is not the whole questionnaire. End-of-life server software is another externally measurable exposure underwriters increasingly probe — 6.6 million domains still run software that openly advertises it is past support, quantified in End-of-Life Software: The Hidden Risk on 6.6 Million Domains. Regulatory regimes such as NIS2 push in the same direction, layering statutory email-security expectations on top of the commercial ones your insurer sets.

What this means

For budget-holders and finance leads, the email-authentication requirement is the rare security control with a direct, checkable line to a renewal price and a claim outcome. It costs an afternoon of configuration and a few weeks of monitoring, not a capital project. At a 2.9% full-protection rate across the internet, the base case is that your domain would fail the check — so the value of finding out first, on your own terms, is high. An attestation that turns out to be untrue is the expensive version of this discovery.

For IT and security teams, the underwriter’s scan is not a status light but a to-do list you can pre-empt.”We have a DMARC record” is not the finding; p=reject, pct=100, sp=reject, and aligned senders are. A domain at p=none will be read as unprotected by any scan worth the name, and a stakeholder who saw a green result somewhere may believe otherwise. Closing the gap before renewal, and holding it closed with monitoring, converts a compliance chore into a defensible control.

For brokers and the insured, the honest answer to the questionnaire is also the cheapest one to make true. The domain-side controls are public; there is no upside in an optimistic answer that a scan or a claims investigation can contradict. Helping a client reach enforcement before binding is a favour to both sides of the policy.

FAQ

Does cyber insurance cover business email compromise? Often, but rarely in full and rarely without conditions. Many policies handle BEC and social-engineering fraud under a specific sub-limit or endorsement that is smaller than the headline cyber limit, and some condition that cover on named controls being live. Because BEC begins with a spoofed or impersonated domain, an enforcing DMARC policy is one of the controls insurers look for — and one only 9.3% of the 376,928,750 domains in the August 2026 census actually publish. Coverage depends entirely on your wording; treat this as general information and confirm the specifics with your broker.

What do cyber insurance companies require? Requirements vary, but a recurring core appears on most 2026 questionnaires: MFA on email and remote access, email authentication (SPF, DKIM, and enforcing DMARC), anti-phishing filtering, EDR, tested backups, patch management with no end-of-life software, security-awareness training, and an incident-response plan. Email authentication stands out because it is externally verifiable from public DNS, so an underwriter can confirm it without your cooperation. The census shows how demanding even that one control is in practice: only 2.9% (10,902,284) of domains are fully email-auth protected.

Does cyber insurance require DMARC? An increasing number of cyber questionnaires ask specifically about DMARC, and some make enforcement a condition or a rating factor, because it is the control that directly reduces the domain-impersonation fraud insurers pay out on. Requirements are not universal, so check your own policy. What is universal is how few domains would satisfy a strict reading: only 9.3% (34,983,618) publish an enforcing DMARC policy, and 90.7% (341,945,132) have none. A record set to p=none counts as published but not enforcing, and an underwriter’s scan grades enforcement, not mere presence.

What are the requirements for cyber insurance? The precise list is set by each insurer, but the externally checkable email requirement is consistent: publish SPF and DKIM for your legitimate senders and an enforcing DMARC policy (p=quarantine or p=reject) on your sending domains. In the August 2026 census only 2.9% (10,902,284) of 376,928,750 graded domains met all three, and 56.8% (214,276,774) published neither SPF nor DMARC. You can find out where your own domain sits in about 30 seconds — check your domain free at defaults.exposed, which reads the same public records an underwriter’s scan would.

Data to cite

“Only 2.9% (10,902,284) of graded domains are fully email-auth protected with SPF, DKIM, and an enforcing DMARC policy, meaning roughly 97% would fail a strict email-authentication control.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“90.7% (341,945,132) of the 376,928,750 domains graded for email authentication have no enforcing DMARC policy.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Only 9.3% (34,983,618) of domains publish an enforcing DMARC policy of quarantine or reject.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“56.8% (214,276,774) of graded domains publish neither SPF nor DMARC, leaving no email-authentication posture at all.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Just 20.0% (75,571,248) of domains publish any DMARC record at all, enforcing or not.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

An underwriter’s email-authentication check is public, external, and objective: your domain either publishes an enforcing DMARC policy backed by SPF and DKIM, or it does not. For 97% of domains the honest answer is “does not” — and most owners have never seen it stated plainly, because a record showed up somewhere and the questionnaire got a hopeful tick.

Check your domain free at defaults.exposed — it reads your live SPF, DKIM, and DMARC records from public DNS and tells you instantly whether your policy actually enforces, whether your subdomains are covered, and whether your domain can be forged. It takes about 30 seconds and needs no account — the same read an underwriter’s scan performs, run on your own terms first. If you want the gaps closed properly and kept closed with audit-ready monitoring for renewal, see how the fix works.

Read the flagship census report: The State of Domain Security 2026 →

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 376,928,750 domains graded for email authentication from 432,127,908 scanned. All figures are counts of graded domains. References: RFC 7489 (DMARC), RFC 7208 (SPF), RFC 6376 (DKIM). This article is general information about common cyber-insurance controls and is not legal, coverage, or financial advice.

How to cite this report

Press / blog: defaults.exposed (2026). Cyber Insurance Requirements 2026: The Email Controls Underwriters Check. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/cyber-insurance-requirements-2026-the-email-controls-underwriters-check

Academic: defaults.exposed. (2026, August 21). Cyber Insurance Requirements 2026: The Email Controls Underwriters Check. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/cyber-insurance-requirements-2026-the-email-controls-underwriters-check

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=376,928,750 email-graded domains)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,750 of them for email authentication using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →