Answering the Cyber Insurance Email Security and DMARC Question

To answer a cyber insurance DMARC requirement accurately, copy the exact application wording, inventory every domain and legitimate sending service, inspect SPF, DKIM, DMARC policy and reporting, then state whether DMARC is monitoring or enforcing. A record at p=none publishes DMARC but requests no enforcement action, so do not let an ambiguous carrier question shrink that fact to a bare yes or no. Ask the broker how to record it when the form forces a choice.

The question as written

Start with the form in front of you, because the wording decides what a truthful answer looks like. Question 3, "Email filtering", in QBE's public Ransomware supplement for The Solution for Cyber Risk (footer 830854 (3-25), copyright 2025 QBE Holdings, Inc.) reads:

Does the applicant utilize email filtering protocols such as Domain-based Message Authentication, Reporting and Conformance (DMARC), DomainKeys Identified Mail (DKIM), or Sender Policy Framework (SPF)?

The form offers Yes and No. That is one carrier's wording in one checked edition. It does not say which combination of the three protocols counts or which DMARC policy level satisfies it. It does include an "Other information" section for anything pertinent to the statement of fact, which is a possible home for qualifying detail.

Beazley's public Ransomware Supplemental Application, form F00765, 052022 ed., asks differently. Question 4 asks "What security controls do you have in place for incoming email?" and lists DomainKeys Identified Mail (DKIM), "Sender Policy Framework (SPF) strictly enforced" and DMARC as separate choices among other controls. It is an older form, and its incoming-email framing is not identical to publishing authentication for your own domains. How your gateway treats mail it receives and what your DNS says about mail you send are two separate facts, so record both. Neither form says how the carrier would read a specific configuration, and you should not guess on its behalf.

Why do insurers ask about email authentication?

Neither form states a reason, but published claims data shows why email fraud draws attention. The figures below describe one insurer's observed portfolio, not the whole market.

Coalition's March 5, 2026 release on its 2026 Cyber Claims Report says business email compromise (BEC) and funds transfer fraud accounted for 58% of the cyber incidents it observed, and that 52% of all its 2025 funds-transfer-fraud claims originated from BEC.

Spoofed invoices and impersonation are relevant here, because DMARC can make it harder to forge your exact domain in the visible From: line. It does not stop mailbox takeover, lookalike domains, display-name impersonation or every phishing path. A fraudulent request sent from a compromised legitimate mailbox can pass authentication, so payment detail changes still need independent callback verification. Domain authentication is also a different control from login protection, so the MFA section of the application needs its own answer.

What SPF, DKIM and DMARC do

An SPF, DKIM and DMARC answer on an insurance application rests on three related controls:

• SPF publishes which sending infrastructure is authorized for a domain. DMARC uses SPF's result for the envelope (MAIL FROM) domain, which is often not the domain a reader sees. That authenticated domain must align with the visible From: domain for SPF to satisfy DMARC. SPF alone does not prove who authored a message.
• DKIM adds a cryptographic signature associated with a domain to the message. The signing domain must align with the visible From: domain for DKIM to satisfy DMARC.
• DMARC ties the SPF and DKIM results to the visible author domain, publishes a requested handling policy for failures and can request reports. A message passes DMARC when at least one of the two produces an aligned pass.

Passing and alignment are distinct from finding records in DNS. A company can publish all three records and still send invoices from a service that fails DMARC. The policy is also a request: RFC 9989 says a receiver is not required to honor it.

Does p=none count?

It counts as DMARC being published, but not as enforcement. The current standard says that at p=none the domain owner offers no expression of preference about failed messages, so in practice it is monitoring, not requested quarantine or rejection.

RFC 9989, the current IETF DMARC standard, calls this monitoring mode. It can still produce aggregate reports when a reporting destination is configured in the rua tag. Without that tag, RFC 9989 says receivers must not generate aggregate reports, so a bare p=none gives you neither enforcement nor visibility.

Match the answer to the field:

• Broad QBE-style question asking whether a protocol is used: do not silently turn p=none into enforcement. Use a qualified answer, such as "DMARC published at p=none for monitoring; SPF and DKIM status verified as of YYYY-MM-DD; enforcement not yet enabled." Ask the broker or carrier how to map that fact to a forced yes/no field.
• Question asking specifically for quarantine, reject or enforcement: p=none is not that state.
• No valid record: answer no or state the missing control, based on the field provided.

Three fill-in examples:

• Yes / enforcing: "DMARC is at p=(quarantine or reject) on (domains), with SPF and DKIM aligned for (services), verified YYYY-MM-DD. Exceptions: (list or none)."
• Partial or qualified / monitoring: "DMARC is published at p=none on (domains), with aggregate reports going to (destination), verified YYYY-MM-DD. Enforcement is not enabled. Known failing senders: (list)."
• No / not implemented: "No valid DMARC record exists for (domains) as of YYYY-MM-DD. SPF status: (status). DKIM status: (status)."

Keep planned work separate from current configuration. Beazley's form says responses should be accurate as of the signing date and directs planned changes to its "Other Cybersecurity Controls & Preventative Measures" section. QBE's declaration has the applicant agree to inform underwriters of material changes to these facts. If you plan to move to enforcement next quarter, say so as a plan, with a date and an owner.

How to check the current state in five minutes

Run these checks only against domains you own or are authorized to assess. Replace the placeholder with your domain:

nslookup -type=txt yourdomain.com
nslookup -type=txt _dmarc.yourdomain.com

SPF is normally a TXT record at the sending domain and begins v=spf1. DMARC is a TXT record under _dmarc and begins v=DMARC1. Copy the full text, including p, sp, t and rua if present, and note the date.

Can a free lookup prove every DKIM sender is covered?

No. DKIM selectors are not globally enumerable from DNS, so a lookup can only test a selector it already knows or guesses.

Check the mail-provider or admin console or a known selector, then verify actual message headers. Send a test from each legitimate service to a mailbox you control and read the authentication results for SPF, DKIM, DMARC and the domains they used. A free DMARC lookup tool may make a record easier to read, but DNS output and provider evidence remain the source facts.

Check all owned domains, including parked or non-sending domains, and all legitimate senders. Common gaps:

• Third-party senders absent from SPF or not aligned with the visible From: domain.
• Newsletter, marketing, payroll, ticketing, CRM or invoicing tools not signing with aligned DKIM.
• Multiple SPF records or malformed or overly complex SPF. RFC 7208 treats more than one SPF record at a name, or more than 10 DNS-querying terms, as a permanent error.
• Parked domains with no explicit anti-spoofing posture. A domain that sends no mail can say so with v=spf1 -all and a DMARC policy you choose deliberately.
• DMARC records with no working aggregate-report destination. An address nobody reads is not monitoring.
• Subdomain policy or sending subdomains overlooked. A subdomain without its own record generally takes policy from the organizational domain, where sp, if present, applies instead of p.

Do not probe domains you do not own.

Path from monitoring to enforcement

This is an example for a 10 to 150 person organization with a modest number of senders. It is not a carrier rule or a guaranteed timeline. Before the first change, name who holds DNS and mail-provider rights and who approves policy changes. Those accounts also belong in your review of the admin accounts question.

1. Week 0: inventory all domains and senders, establish SPF and DKIM alignment, and publish DMARC monitoring with aggregate reporting.
2. Weeks 1 to 4: review reports for two to four weeks, identify legitimate services, fix or retire failing senders, and document exceptions.
3. Controlled enforcement: move to quarantine only after legitimate mail is understood. Watch delivery, reports, helpdesk issues and bounces.
4. Reject: move only after quarantine remains stable and every legitimate source is aligned. Keep monitoring after the change.

Do not apply this timeline when the company has many brands, acquired domains, complex forwarding or many third-party senders. Those environments need a plan built from their own report data.

What happened to percentage rollouts?

RFC 9989, published in May 2026, obsoleted RFC 7489 and classifies the old pct sampling tag as historic. Do not treat pct=10 or another partial percentage as universally reliable current-standard advice.

The standard's explanation is blunt: operational experience showed the tag was usually not accurately applied unless the value was 0 or 100. Older provider guidance and uneven receiver adoption mean percentage rollouts still appear. Google Workspace's recommended DMARC rollout, as read on November 6, 2026, still describes a percentage-based quarantine stage and does not mention RFC 9989.

RFC 9989 instead provides t=y, a policy test mode with one-step-weaker handling. With p=quarantine; t=y the owner expects failing mail to be handled as none, and with p=reject; t=y as quarantine. Follow your provider's current guidance, then verify observed receiver behavior in your reports rather than assuming a percentage or test flag is applied uniformly. If t=y is set when you complete the form, report it, because that record is not at full enforcement.

Evidence to keep

Keep a dated folder containing:

• The exact application question and edition.
• The domain and subdomain inventory, including parked domains.
• SPF, DKIM and DMARC DNS screenshots or exports.
• Known DKIM selectors and provider configuration.
• A sender inventory with SPF and DKIM alignment status.
• A DMARC aggregate-report summary.
• Current p, sp, testing and reporting state, plus the record text.
• Dates and approvers for each DNS or policy change.
• Unresolved failures and the business owner of each.
• Broker or carrier clarification of ambiguous wording.

Fill-in response template

An accurate answer keeps the application consistent with your evidence. It does not guarantee eligibility, pricing, coverage, renewal, limits or a claim outcome, and no form cited here says that any particular policy level will.

Application question and form edition:
Domains reviewed:
SPF status and evidence date:
DKIM status by legitimate sending service:
DMARC policy, subdomain, testing and reporting status:
Exact verification date:
Aggregate report period reviewed:
Exceptions and parked-domain status:
Current answer in plain language:
FUTURE WORK, not current state (change, owner, target date):
Evidence locations:
Broker or carrier clarification:

Sources

• QBE, The Solution for Cyber Risk, Ransomware supplement, 830854 (3-25)
• Beazley, Ransomware Supplemental Application, F00765, 052022 ed.
• IETF, RFC 9989, the current DMARC standard
• IETF, RFC 7208, Sender Policy Framework
• Coalition, 2026 Cyber Claims Report release
• Google Workspace, recommended DMARC rollout (provider guidance, checked against RFC 9989)