Cyber insurance email controls: what applications ask and how MSPs can help clients answer

Map a domain to insurance email questions →This article is a how-to. The matching tool checks a live domain.

Renewal season usually arrives as a forwarded PDF: "Our broker needs this back by Friday. Can you fill in the IT part?" A large part of that IT section is about email. This page walks through what real, publicly available cyber insurance forms ask about email security, quoted directly, and how to help a client answer accurately without guessing.

One rule up front: every insurer, form, and edition is different. Nothing below means a specific insurer requires a specific control for coverage. We're quoting what particular forms ask. Your client's application is the only one that matters for them.

What real application forms ask

We reviewed three publicly available insurer documents. Each one is cited at the bottom of this page.

Multi-factor authentication for email

MFA on email shows up on every form we reviewed:

  • At-Bay, Cyber Short Application (edition 06/2026): "Does the Applicant have multi-factor authentication enforced on all email access?" It also asks about MFA "on all remote access including VPN or other remote network access."
  • Travelers, Multi-Factor Authentication Supplement (CYB-14306, Rev. 03-23): asks the applicant to answer Yes, No, or "Email is not web based" to "Multi-Factor authentication is required for all employees when accessing email through a website or cloud based service." It goes on to ask about MFA for all remote network access and for internal and remote admin access to directory services, network backup environments, network infrastructure, and endpoints/servers, including access given to third-party service providers. It also asks whether the signer completed the form "with the assistance of the person in charge of IT security."
  • Beazley, Ransomware Supplemental Application (F00765, 052022 ed.): asks whether users have remote access to web-based email (for example, Outlook Web Access), and if so, "do you enforce MFA for access to web-based email?" It also asks about MFA for all user accounts accessing the network remotely, and for all Domain Administrator accounts.

The Travelers supplement explains its reasoning in plain terms: without MFA on remote email access, "an intruder can easily gain access to a user's corporate email account."

SPF, DKIM, and DMARC

Of the three documents, only the Beazley supplemental names SPF, DKIM, or DMARC. Neither the At-Bay short application nor the Travelers MFA supplement mentions them. Beazley's question 4, "What security controls do you have in place for incoming email? Choose all that apply," includes these options:

  • "DomainKeys Identified Mail (DKIM)"
  • "Sender Policy Framework (SPF) strictly enforced"
  • "Domain Based Message Authentication, Reporting and Conformance (DMARC)"

The same list includes screening for malicious attachments and links, a quarantine service, sandbox detonation of attachments, and tagging external emails.

Read it closely. The question is framed around incoming email, so it's not clear whether it's asking if the client checks SPF, DKIM, and DMARC on mail they receive, or whether they publish those records for their own domain. It also doesn't define what level of DMARC counts, or what "strictly enforced" means for SPF. That's exactly the kind of ambiguity you should flag for the client and their broker rather than resolve yourself.

Email filtering and related controls

  • At-Bay (06/2026) asks, as an optional question, which inbound email security product (Secure Email Gateway) the applicant uses. The list includes Microsoft Defender for O365, Google, Mimecast, Proofpoint, and others, plus "No SEG in place" and "Other/Unknown." The same form also asks the applicant to list every domain, including "any primary domains used for corporate email," and asks (optionally) whether the applicant uses a Managed Service Provider.
  • Beazley (052022 ed.) asks which Microsoft 365 license (or equivalent) is used, whether Microsoft 365 users have the Microsoft 365 Defender add-on or an equivalent product with advanced threat hunting, whether macros are disabled by default, and whether legacy email protocols that use basic authentication (IMAP, POP3, SMTP) are disabled. It also asks about phishing training and simulations.

Which of these can you verify from outside?

This matters, because a wrong answer on an application is the client's problem and can become yours.

Visible in public DNS:

  • Whether an SPF record exists, whether there's exactly one, and whether it stays within the 10-lookup limit.
  • Whether a DMARC record exists, and its policy (none, quarantine, or reject).
  • Whether a DKIM key is published at a selector you know to check. A miss on common selectors doesn't prove DKIM is absent, because selectors aren't listed anywhere in DNS.
  • Whether MX records point to a recognizable filtering gateway.

Not visible from outside: MFA enforcement, conditional access, legacy protocol status, Defender licensing, macro policy, training, backups, and EDR. These need evidence from the tenant or the client, such as admin console screenshots, policy exports, or vendor reports.

How MSPs can help without overstepping

  1. Get the actual form. Don't work from a generic checklist. Wording differs. "Enforced on all email access" is not the same as "required when accessing email through a website."
  2. Map each question to evidence. For every Yes, note where the proof lives: a DNS lookup with a date, a conditional access policy, an MFA registration report. If there's no evidence, the honest answer may be No or "unknown," with an explanation in the form's notes field. Travelers asks for an explanation of any "No" answer in its Additional Information section. Beazley asks applicants to note exceptions in its "Other Cybersecurity Controls & Preventative Measures" section.
  3. Fix before you answer, where you can. Turning on MFA for every mailbox, merging a duplicate SPF record, enabling DKIM for the custom domain, and starting DMARC with reporting are all achievable before most renewal deadlines. Moving DMARC to enforcement safely usually takes longer. Start early.
  4. Let the applicant sign. You can supply facts and evidence. You aren't the applicant, and you shouldn't interpret coverage or tell a client a control will lower premiums. Point coverage questions to the broker.
  5. Re-check before submission. DNS changes. Date every piece of external evidence and re-run it right before the form goes back.

A short, practical baseline

The controls asked about on the forms above are also sensible on their own merits. MFA appears on all three forms, and SPF, DKIM, DMARC, and filtering on at least one. Together they give you a defensible baseline to work toward with every client:

  • MFA on all mailboxes and any web or remote email access
  • MFA on admin accounts and remote access
  • One valid SPF record, within the lookup limit
  • DKIM signing with the client's own domain
  • DMARC published with reporting, on a plan toward enforcement
  • An inbound email filtering layer, and legacy basic-auth protocols disabled where the platform allows it

Map a domain to the email questions

Run the free cyber insurance email controls check →

It maps public DNS to common email questions (DMARC, SPF, DKIM, filtering) and labels every answer Verified, Unknown, or Not tested, with an evidence line you can paste. MFA, backups, EDR, and training stay Not tested on purpose. This is not insurance advice.

Founding Partner: $1,999, one time. Founding Partner includes the insurance questionnaire with scan auto-fill and the insurance evidence pack, plus coverage for 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

Do cyber insurers require DMARC?
It depends on the insurer, product, and form edition. Don't assume. For example, Beazley's 2022 ransomware supplemental lists DMARC, DKIM, and "SPF strictly enforced" among the controls to tick for incoming email. That's a question on a form, not a published coverage requirement. Read your client's actual application and ask the broker.
Which email question shows up most often?
On the three insurer forms we reviewed (At-Bay, Travelers, and Beazley), every one asked about multi-factor authentication for email access. The exact wording differs, so answer the question as written.
Can a DNS scan answer the insurance application for my client?
Only partly. SPF, DMARC policy, published DKIM keys, and gateway MX records are visible in public DNS. MFA, conditional access, licensing, and training aren't, and need evidence from the tenant or the client. The applicant is responsible for every answer.
Does p=none count as "having DMARC"?
The forms we reviewed don't define it, so it's ambiguous. Report what's actually published (for example, "DMARC published at p=none with aggregate reporting, as of [date]"). Let the client and broker decide how to answer, and work toward enforcement.
Will fixing email controls lower my client's premium?
We can't say, and you shouldn't promise it. Pricing and eligibility are underwriting decisions. What you can do is help the client answer accurately and close real gaps.
Cyber Insurance Email Controls: MFA, DMARC, SPF and DKIM | Client Posture