Beazley's ransomware supplement: what it asks about email, and how to answer accurately
Map a domain to insurance email questions →This article is a how-to. The matching tool checks a live domain.
Beazley's ransomware supplemental application, form F00765, 052022 ed. (Beazley Insurance Company, Inc.), is dated May 2022 and names DKIM, SPF and DMARC directly. It runs to 46 numbered questions over five pages. This page covers the email-related ones, quoted from the form, and how an MSP can help a client answer them from evidence. It isn't insurance advice. What an answer means for a quote is Beazley's call.
About the form
- Form: F00765, 052022 ed. (May 2022), Beazley Insurance Company, Inc. The footer reads "Page x of 5." It's over four years old, so ask the broker whether Beazley has a newer edition.
- Source: a public PDF on beazley.com.
- Scope: the form says responses concern "the Information Technology (IT) environment of your organization and any subsidiaries for which the insurance is being sought."
- Timing: responses "should be accurate as of the date that the application is signed and dated." Planned IT changes before inception or during the policy period go in the "Other Cybersecurity Controls & Preventative Measures" section.
Question 4: incoming email controls
The Email Security section opens with:
> What security controls do you have in place for incoming email? Choose all that apply.
The options:
- a. Screening for malicious attachments
- b. Screening for malicious links
- c. Quarantine service
- d. Detonation and evaluation of attachments in a sandbox
- e. Tagging external emails
- f. DomainKeys Identified Mail (DKIM)
- g. Sender Policy Framework (SPF) strictly enforced
- h. Domain Based Message Authentication, Reporting and Conformance (DMARC)
It's a checklist, not a pass/fail question. The form doesn't say which boxes, if any, Beazley expects.
Reading f, g and h carefully
The question asks about controls for incoming email. Read literally, DKIM, SPF and DMARC here mean the client's mail system checks those results on inbound messages. Publishing the client's own records is a different thing, though it's related, and many people answer this question about their own domain. The form doesn't define "SPF strictly enforced." It could mean the client's filter rejects inbound SPF failures, or that the client's own record ends in -all. If it's unclear, ask the broker what Beazley means rather than guessing.
The honest approach is to collect evidence for both sides:
- Inbound: what the filter or gateway does with messages that fail SPF, DKIM or DMARC (reject, quarantine, tag, or nothing).
- Outbound / the client's own domain: the published SPF record and its
allqualifier, whether mail is DKIM-signed with the client's domain, and the DMARC policy. DNS can show these.
Common mistakes on Q4
- Ticking DMARC because a record exists. With
p=none, RFC 9989 says the domain owner "offers no expression of preference" for failing mail. It's a monitoring stage. If the underwriter asks about policy, give the actual tag. - Ticking DKIM for the vendor's signature. If outbound mail is signed only with the provider's default domain and not the client's, say that.
- Ticking sandboxing or link screening the license doesn't include. Q4d and Q7b both depend on what's actually licensed and switched on.
The other email-related questions
- Q5: how often "Interactive phishing training" and "Phishing email simulations" happen for all employees (Never/not regularly, Annually, ≥2x per year).
- Q6: whether employees who fail phishing simulations get additional training.
- Q7a: which Microsoft 365 license (or equivalent) "all, or substantially all" users have: E1, E3, E5, Other, None.
- Q7b: whether a Microsoft 365 client uses "the Microsoft 365 Defender (formerly known as Advanced Threat Protection) add-on or an equivalent cybersecurity product with advanced threat hunting."
- Q8a/b: whether macros are disabled by default, and whether users may enable them.
- Q9:
> Have you disabled legacy email protocols that use basic authentication (a username and password only), such as IMAP, POP3, and SMTP?
- Q10: MFA enforced for all user accounts (other than Domain Administrator accounts) when accessing the network remotely. The form's definition of "user accounts" includes "third-party contractors."
- Q11a: "Do you permit users remote access to web-based email (e.g., Outlook Web Access (OWA))?"
- Q11b: if yes, "do you enforce MFA for access to web-based email?"
- Q13: MFA for all Domain Administrator accounts.
The form also asks about remote desktop tools such as RDP, VNC, AnyDesk and TeamViewer, and whether they require MFA (Q31). It asks about protective DNS (Q29) and about backups (Q38–44). These aren't email questions, but an MSP will usually be the one with the answers.
How an MSP can prepare
- Q4 inbound: document what your filter does today: attachment and link scanning, quarantine, sandboxing, external tagging, and how it acts on SPF/DKIM/DMARC failures. Tick only what's configured.
- Q4 own domain: run a DNS check and keep the dated output. If the client's DMARC is
p=none, say so. Don't tick DMARC to suggest enforcement. - Q7: check the actual licenses in the tenant admin center, not the quote you remember.
- Q9 and Q11: confirm in the tenant whether basic-auth protocols are off and whether web mail requires MFA for every user.
- Exceptions: note them in "Other Cybersecurity Controls & Preventative Measures," as Q10 and Q13 ask.
- Changes after signing: the declaration says the applicant will "immediately notify the insurer" if information changes before the effective date.
Get the DNS side documented
Run the free insurance email controls check →
It reads the client's public SPF, DKIM and DMARC records and labels each finding Verified, Unknown or Not tested, with evidence you can paste. It can't see how your filter treats inbound mail, or the tenant's MFA, licensing or protocol settings. It's not insurance advice.
Founding Partner: $1,999, one time. Turn every renewal into a branded, dated email security report your clients keep. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.
See Founding Partner details →
FAQ
- What edition is the Beazley ransomware supplement?
- Form F00765, 052022 ed. (May 2022), from Beazley Insurance Company, Inc. It has five pages and 46 numbered questions.
- Does Beazley ask about DMARC?
- Yes. Question 4 lists DMARC, DKIM and "SPF strictly enforced" among the incoming email controls the applicant can tick ("Choose all that apply").
- Does the Beazley form require DMARC?
- The form doesn't say any option is required. It asks which controls are in place. How answers affect terms is up to Beazley's underwriting.
- What does "SPF strictly enforced" mean on the Beazley form?
- The form doesn't define it. Since Q4 is about incoming email, it may refer to how inbound SPF failures are handled. Ask the broker, and keep evidence of both your inbound handling and the client's own SPF record.
- Does Beazley ask about MFA on email?
- Yes. Q11a asks whether users can reach web-based email remotely (e.g., OWA), and Q11b asks whether MFA is enforced for it.
- Who signs the Beazley supplement?
- Someone "authorized by the applicant to sign this application on the applicant's behalf," who gives a name, title, company and date.