DMARC, SPF, and DKIM for Cyber Insurance: What Carriers Check — and What Only Some Forms Ask

Email is now one of the clearest places where cyber underwriting and external security validation overlap.

Coalition’s 2026 claims report says business email compromise (BEC) and funds transfer fraud (FTF) accounted for 58% of all claims across its dataset, with 52% of FTF claims originating as BEC and 71% of all FTF claims resulting directly from social engineering.[1] That means insurers have a straightforward reason to care about whether your domain can be spoofed or whether your email posture looks loose from the outside.

But carrier forms do not all express that concern the same way.

The Hartford’s current CyberChoice underwriting application explicitly asks about email security controls — secure email gateways, malicious attachment screening, malicious link screening, and tagging messages from external senders.[2] The Hartford’s ransomware supplemental goes even deeper and asks which protocols are used to authenticate the sender and content of emails.[3]

Coalition’s current public agency application, by contrast, does not ask a direct SPF/DMARC/DKIM question on the PDF itself.[4] But Coalition Control scans policyholders’ external attack surfaces monthly, associates assets through DNS records and other public signals, and specifically notes that findings can include SPF records that have too many IPs allowed in them.[5] Coalition also says unresolved scan findings during the policy period can lead to contingencies at renewal time.[5]

Travelers’ CyberRisk Short Form does not ask about SPF, DKIM, or DMARC directly either.[6] But Travelers’ broader cyber program includes always-on threat monitoring and tailored alerts through Cyber Risk Services,[7] and Travelers’ Social Engineering Fraud supplements focus heavily on callback, approval, and payment-verification processes that often fail only after an email-layer compromise has already happened.[8][9]

That is the key distinction:

• some carriers ask about email security controls explicitly,
• some carriers can verify parts of email posture silently,
• and all carriers care when email compromise turns into money movement.

Start with the honest question: what can be verified from the outside?

DNS-based email authentication gives insurers, brokers, and scanning platforms a rare advantage: they can check parts of it without logging into your tenant.

That matters because many underwriting questions are still attestation-based. DNS posture is one of the few areas where the carrier can independently inspect a meaningful slice of reality.

The outside-in checks are not comprehensive. They do not tell an underwriter whether your help desk honors suspicious MFA resets or whether an executive assistant can be socially engineered into wiring funds. But they do tell the market something important:

• whether your domain publishes an SPF record,
• whether you are signing mail with DKIM,
• whether you publish a DMARC policy,
• and how strict or permissive those controls appear.

That is why this topic is such a strong BindLedger wedge.

What SPF actually tells the insurer

SPF is the control that lets a domain publish which servers are authorized to send mail on its behalf. Microsoft documents SPF as a way to help validate outbound mail from Microsoft 365 and prevent spoofed senders used in phishing, ransomware, and BEC.[10]

From an insurance perspective, SPF answers a narrow but important question:

Has this domain declared which senders are allowed to send as it?

That answer becomes more useful when the record is also reasonably strict.

A weak or incomplete SPF posture can look like:

• no SPF record at all,
• a record that exists but ends in ~all when the business thinks it is tightly enforced,
• a record with so many allowed senders that it is difficult to defend as controlled,
• or a record broken by flattening, stale SaaS providers, or expansion issues.

Coalition Control’s FAQ is revealing here. It explicitly notes that findings can include SPF records that have too many IPs allowed in them.[5] That is not a theoretical concern. It is a published example of how a carrier-side platform interprets email posture from the outside.

What DKIM actually tells the insurer

DKIM adds a cryptographic signature to outgoing messages so receiving mail systems can verify that the message was signed by a key associated with the claimed sending domain. Microsoft’s DKIM documentation covers how to enable DKIM for custom domains in Microsoft 365,[11] and Google’s sender guidelines recommend DKIM alongside SPF and DMARC, especially for larger senders.[12]

For cyber insurance, DKIM matters because it improves sender authenticity and supports DMARC alignment.

It also improves the quality of the answer a broker can give when the renewal process turns from “do you use email controls?” into “what can you actually demonstrate?”

A domain with no DKIM record is not automatically uninsurable. But it is objectively harder to argue that the organization has strong email-authentication hygiene when the domain is not cryptographically signing its outbound mail.

What DMARC actually tells the insurer

DMARC is the policy layer that tells receiving systems what to do when SPF and DKIM do not align properly with the sending domain. Microsoft’s DMARC documentation emphasizes that DMARC helps validate inbound email and gives domain owners a policy mechanism for how unauthenticated mail should be handled.[13]

This is the underwriting insight most businesses miss:

SPF and DKIM without DMARC can still leave too much ambiguity. DMARC is the thing that makes the sender’s intent explicit.

In practice, insurers and external scanners will see a major difference between these three positions:

• No DMARC record — nothing published.
• DMARC with p=none — monitoring posture, but little enforcement signal.
• DMARC with p=quarantine or p=reject — materially stronger anti-spoofing position.

That does not mean every carrier requires p=reject on day one. It does mean a domain with no DMARC, soft SPF, and no visible DKIM is hard to defend as mature email hygiene in 2026.

The critical carrier distinction: who asks, who checks, and who does both

This is where generic cybersecurity advice becomes unhelpful. BindLedger’s content has to be precise.

The Hartford: asks explicitly

The Hartford is the clearest of the three public forms.

On the 2025 CyberChoice underwriting application (CB 00 H027 03 0824), Section 7 asks for the presence of:

• a secure email gateway,
• malicious attachment screening,
• malicious link screening,
• external sender tagging,
• and anti-phishing / cybersecurity awareness training cadence.[2]

On the ransomware supplemental, The Hartford also asks which protocols are used to authenticate the sender and content of emails.[3]

So if someone asks, “Does any carrier actually care about DMARC, SPF, and DKIM on the form?” the honest answer is:

Yes — Hartford is publicly asking about the email stack directly, and the ransomware supplemental gets even more specific.

Coalition: does not ask directly on the public PDF, but clearly checks externally

Coalition’s agency application (CYUSP-00NA-1022-01) does not include a line item for DMARC, SPF, or DKIM.[4] That is why a lot of MSPs incorrectly conclude Coalition “doesn’t care” about email-authentication posture.

Public Coalition materials say otherwise.

Coalition Control scans policyholders’ external attack surfaces monthly using domains provided during quotation, domains added during the policy, or domains enumerated using public information.[5] Coalition says those findings do not change the current policy mid-term, but unresolved issues can lead to contingencies at renewal.[5] Coalition also identifies DNS records as one of the ways it finds assets and gives SPF misconfiguration as a concrete example of a lower-level finding that can expand attack surface.[5]

That is the “silent underwriter” pattern.

The public PDF does not ask. The external scan still sees.

Travelers: short form does not ask, but the exposure still matters

Travelers’ CyberRisk Short Form (CYB-14203 Rev. 03-19) does not directly ask about SPF, DKIM, or DMARC.[6] Instead, Travelers’ short form focuses on broader controls such as anti-virus, patching, incident response, backups, vendor controls, MFA, and encryption.[6]

That does not mean email does not matter to Travelers. It means the short form is not the whole underwriting story. Travelers also offers Cyber Risk Services with always-on monitoring and tailored alerts,[7] and its social engineering fraud supplements focus on the downstream fraud controls that become critical when email compromise happens.[8][9]

The right way to describe Travelers in this article is:

Travelers does not ask DNS email-authentication questions on the short form, but email compromise is clearly relevant to the risk model and to the adjacent fraud underwriting process.

That is stronger and more accurate than saying Travelers “checks silently” without proof.

What DNS can prove today — and what it cannot

This is where BindLedger’s /scan page becomes productively honest.

A DNS scan can prove or strongly infer:

• whether the domain has MX records,
• whether SPF exists,
• whether SPF appears stronger or weaker,
• whether DMARC exists and which enforcement policy it publishes,
• whether common DKIM selectors are discoverable,
• whether the public email-authentication posture is obviously weak.

A DNS scan cannot prove:

• that a secure email gateway is in place,
• that malicious attachments are quarantined correctly,
• that malicious-link rewriting is enabled,
• that external sender tagging is actually applied in inboxes,
• that mailbox-level MFA is enforced,
• that finance staff follow callback procedures.

This distinction matters because carriers themselves blend visible and invisible controls.

Hartford explicitly asks for some controls a DNS scan cannot see, like external sender tagging and malicious-attachment screening.[2] Coalition Control can detect some email-related exposure from the outside, including risky SPF posture, but it still cannot see everything inside the mail stack.[5]

So the practical answer for a broker is not “our DNS scan proves all email security.” It is:

“Our DNS scan proves the public email-authentication posture. Internal filtering, tagging, and mailbox controls are documented separately.”

That is a much stronger sentence.

The four common DNS postures you will actually find in the field

1. No DMARC, weak or missing SPF, no visible DKIM

This is the classic “we assumed Microsoft handled it” posture.

It is the easiest for underwriters or carrier-side scanners to flag as weak. It is also the easiest BindLedger win because the public signal is so clear.

2. SPF present, DKIM present, DMARC at p=none

This is better than nothing. It shows the domain owner at least started the authentication journey. But it still reads as monitoring mode rather than strong enforcement.

3. Stronger DNS posture, weak internal mail controls

This is common too. The domain looks respectable from the outside, but internal sender-tagging, SEG tuning, and user training are inconsistent. That is why DNS evidence is necessary but not sufficient.

4. Strong DNS posture plus documented internal controls

This is the posture that reads well both to an external scanner and to a broker answering Hartford-style email security questions.

That is the real target state.

What a broker-friendly email-security evidence packet should look like

If you want to make email-security discussions easier at renewal, keep the packet short.

Page 1: the external proof

• domain scanned,
• MX present,
• SPF present and basic strength,
• DMARC present and policy,
• DKIM detected / not detected,
• scan timestamp,
• plain-English notes.

Page 2: the internal controls the DNS scan cannot prove

• SEG in use,
• malicious attachment screening,
• malicious link scanning or rewriting,
• external sender tagging,
• user awareness training cadence,
• mailbox MFA status.

That is exactly why BindLedger’s scanner belongs on the site before the full tenant connector is live. It gives the market a fast, objective answer for the external half of the email-security story.

Why this topic is such a strong SEO and product wedge

This article is not just educational content. It mirrors the shape of the product.

• It hits real searches close to renewal.
• It uses terminology MSPs and brokers actually use.
• It stays precise about which carriers ask, which carriers scan, and which carriers do both.
• It sends the reader directly into a live product motion.

That is exactly the kind of content a new category needs.

What to do right now

If you want a fast answer to the part of email security that an underwriter or external scanner can already see, do not wait for a questionnaire.

Scan the domain now.

Primary CTA: Check your domain at bindledger.com/scan to see the public email-authentication posture carriers and carrier-side scanners can detect right now.

Secondary CTA: Scan your client’s domain, save the result, and share the link with their broker before renewal. It is the fastest way to move the conversation from “I think our email is fine” to “here is what the public record shows.”