Cyber insurance: what insurers look at on the email side

p=reject: the insured risk shrinks mechanically

An insurance contract covers an expected loss. Any control that lowers the probability or the severity of an incident lowers the risk transferred to the insurer — that is the raw material of pricing. And DMARC at enforcement acts exactly there. When a domain publishes

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

receiving servers that honor the policy reject any message claiming to come from example.com without aligned authentication. Impersonation of the exact domain — the fake executive email sent "from" the real address, aimed at the company's own finance team or at its customers — stops being an option for the attacker. A whole slice of CEO fraud becomes blockable by construction, before any human judgment, before any heuristic filter.

Honesty requires drawing the exact perimeter: DMARC stops neither lookalike domains, nor deceptive display names, nor compromised legitimate accounts — three vectors that call for other defenses (defensive registrations, filtering, MFA, a call-back procedure before any bank-detail change). Insurers know this, which is precisely why the DMARC question is added to the others rather than replacing them. But across the landscape of anti-fraud controls, this one offers a cost-effectiveness ratio that is hard to beat: one line of DNS, enforceable against the entire world.

The public DNS talks: underwriting gets scanned

A fact less known to policyholders: part of the questionnaire can be verified without asking anyone anything. The DMARC record is a public DNS record — a dig TXT _dmarc.example.com query is enough to read it, and the same goes for SPF. Brokers and carriers now lean on external rating tools that automatically scan an applicant's exposed surface: open ports, certificates, outdated services… and the DMARC policy. The result lands on the underwriter's desk before the completed questionnaire does.

The consequences are very concrete. An answer declaring "email authentication in place" while the DNS shows p=none — or no record at all — creates a visible contradiction between the declared and the observed, with the worst possible effect on how the overall reliability of the file is judged. Conversely, a domain at p=reject, coherent and cleanly configured, speaks in the applicant's favor without a word being said: the control is observed rather than claimed. Some players explicitly fold these external signals into their risk assessment, and the gap between declaration and observable reality becomes a criterion in its own right.

A wrongly ticked box can cost dearly at claim time

Insurance rests on a declarative principle: the contract is priced and granted on the strength of the answers given at underwriting. A box ticked wrongly — "DMARC at enforcement" while the domain sat at p=none, "MFA everywhere" while one access path escaped it — is not an administrative detail. Depending on national law and the wording of the clauses, an inaccurate declaration can ground a proportional reduction of the payout, or even a denial of coverage at the precise moment the company would need it most. Public disputes around cyber claims have already turned on exactly this ground: whether the underwriting answers matched reality.

None of this constitutes legal advice — every contract deserves its own reading — but the prudent rule is simple and technical: declare the actual state, dated, and keep it current. "DMARC published at p=none, move to p=reject planned for next quarter" is an honest answer, and often a well-received one, because it shows a managed program. The optimistic version of the same box turns against the declarant the day the claims adjuster compares the questionnaire with historical DNS — because DNS gets archived, and scanners remember past states.

Preparing the file: state, trajectory, evidence

Facing a questionnaire or a renewal, the email chapter of the file is prepared like an audit file, with three exhibits.

The state, first: an exact inventory of the organization's domains — active ones, but also defensive and dormant ones, which scanners see just as well — with, for each, the SPF, DKIM and DMARC state actually observed in the DNS. A dormant domain with no policy is an open door bearing the company's name; neutralizing it (SPF v=spf1 -all, DMARC p=reject) takes minutes and improves the overall profile.

The trajectory, next: for domains still on the way, the documented progression from p=none to p=reject, with the date of each step. Passing through p=quarantine, or using the t=y test mode introduced by DMARCbis, shows a controlled ramp-up rather than a prolonged status quo.

The evidence, finally: actual collection of aggregate reports, alerts on unknown sources, a trace of ongoing operation — periodic reviews, tickets, an audit log. It is exactly the evidence logic of a security management system, developed in DMARC in an ISO 27001 program: a control without proof of operation is worth little more than an absent control, in the eyes of an auditor and of an underwriter alike.

Beyond the premium: reducing the real risk

It would be a waste to reduce email authentication to an insurance-compliance exercise. The questionnaire box merely reflects a more interesting reality: p=reject does not just reassure an underwriter, it genuinely removes an attack vector — the most humiliating one of all, the one that turns the company's exact name against its own teams, its customers and its suppliers. A softened premium is a bonus; the fraud that never happens is the main gain.

The economics remain favorable well beyond insurance, for that matter. The cost of a full DMARC program — the detailed breakdown sits in what a DMARC service really costs — is out of all proportion to a single successful wire-transfer fraud, or even to the deductible increase that follows a claim. Add the collateral benefits: stronger deliverability since Gmail and Microsoft began requiring authentication from bulk senders, a protected brand, and a signal of seriousness readable by any partner who bothers to query the DNS.

In summary

Wire-transfer fraud dominates cyber losses, email is its vector, and underwriting questionnaires have drawn the conclusion: alongside MFA, backups and EDR, domain authentication — SPF, DKIM and above all the DMARC policy — has become a standard question. p=reject mechanically shrinks part of the insured risk by making exact-domain impersonation blockable; the public DNS lets insurers verify answers without asking; and the declarative principle makes any optimistically ticked box dangerous. A good file holds three exhibits — an exact state, a dated trajectory, evidence of operation — and once in place, the control protects far beyond the premium.

Before the next questionnaire, the useful reflex costs nothing: a free DMARC analysis of the domain shows in seconds what the underwriter will see from the other side — published policy, SPF and DKIM alignment, remaining weak points. And to turn that snapshot into a documented trajectory toward p=reject, reports in hand, creating an account makes it possible to date every step — all the way to the box nobody will hesitate to tick.