We Scanned the Cyber Insurers. Their DMARC Failed.

Hiscox and Markel both require DMARC on your cyber insurance renewal application.

We scanned their domains. Both are at p=none. Cowbell Cyber has p=reject but no SPF record at all. That's three major carriers — all misconfigured, all enforcing requirements on customers they can't meet themselves.

This isn't a gotcha. It's a map of exactly what your clients look like when an underwriter runs the same scan on their domain.

What the Insurers Are Asking For vs. What They Have

Cyber insurance applications increasingly include a standard checkbox: "Have you implemented SPF, DKIM, and DMARC to protect against phishing and email spoofing?"

Most applicants check yes. Many shouldn't.

We scanned 73 domains across the MSP security vendor ecosystem and cyber insurance space. Among the carriers:

p=none is not DMARC. It tells receiving mail servers to log unauthenticated email and do nothing about it. Attackers can still send spoofed email from hiscox.com or markel.com and it will land in inboxes. The record exists. The enforcement doesn't.

Cowbell's situation is different but equally problematic. They have the right DMARC policy but no SPF record — which means DMARC alignment checks can't work properly. DMARC relies on SPF or DKIM to pass. Without SPF, half the authentication chain is missing.

The Vendor Irony Stack

The insurance carriers aren't the only ones with this problem. We scanned the MSP security tool vendors — the companies your clients use to stay secure — and found the same pattern.

Blackpoint Cyber (blackpoint-cyber.com) — an MDR vendor selling managed detection and response — has no DMARC record and no SPF record. A cybersecurity company with zero email authentication.

Syncro (syncro.app) — one of the more popular RMM/PSA platforms for MSPs — has no DMARC record at all.

Proofpoint (proofpoint.com) — a company that sells email security and specifically sells DMARC-related products — has SPF configured with ~all (soft fail) instead of -all (hard fail). That one character difference is the gap between "unauthorized servers bounced" and "unauthorized servers accepted with a suspicious flag."

The common thread: the team managing DNS is not the team that knows what these records should say. This is organizational friction, not malice. But it's the same friction your clients have.

The Full Scan Breakdown

From our 73-domain scan on 2026-03-24:

DMARC Policy Distribution:

58.9% of the domains we scanned have actual DMARC enforcement. The remaining 41.1% have records that provide partial or no protection.

For context: when an underwriter runs an automated check and sees p=none, the answer to "do you have DMARC?" is effectively no. The record is there, but it's not doing anything.

What "DMARC Configured" Actually Means

Here's the enforcement hierarchy, weakest to strongest:

p=none       → Log unauthenticated mail. Do nothing.
p=quarantine → Send suspicious mail to spam.
p=reject     → Block unauthenticated mail entirely.

When an insurer asks about DMARC, they want p=reject. When an automated external scanner checks, it will read the policy exactly. There's no partial credit for having a monitoring record.

The correct DMARC record looks like this:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com

• p=reject — enforcement is on
• rua — aggregate reports going somewhere that gets monitored

Both fields matter. A reject policy with no reporting address means you're blocking email but flying blind on what's being blocked.

The SPF Problem Is Equally Quiet

SPF gets less attention than DMARC, but the failure mode is just as real.

Proofpoint's soft fail (~all) is a good example. The record tells receiving servers: "mail from unauthorized sources is suspicious, but accept it." In practice, most mail servers treat ~all as a weak signal and deliver the mail anyway.

The correct ending for an SPF record is -all — hard fail. That tells receiving servers to reject mail from unauthorized sources outright.

Manual check:

dig TXT clientdomain.com +short | grep spf

What you're looking for:

• v=spf1 include:provider.com -all — correct
• v=spf1 include:provider.com ~all — soft fail, minimal protection
• No result — no SPF at all

If your client's record ends in ~all, it's not correctly configured. The insurance application checkbox says yes. The actual protection isn't there.

Where This Hits Your Clients

Cyber insurance renewals are where this becomes a business problem. The process:

1. Broker sends renewal questionnaire
2. Client checks "yes" on email authentication
3. Underwriter runs automated external scan
4. Scan shows p=none or soft-fail SPF
5. Mismatch between checkbox and DNS record → premium spike or denial

The underwriter isn't calling to verify. They're running automated checks — the same kind of checks anyone can run. If your client said yes and their domain shows p=none, that's a misrepresentation on an insurance application. It's also a gap an attacker can exploit today.

Business Email Compromise (BEC) — where an attacker sends email that appears to come from your client's domain — directly exploits missing DMARC enforcement. The FBI's IC3 report puts BEC losses at $2.9B in 2023. Most of those losses hit organizations without enforced DMARC.

Your clients' insurance renewal and their actual security posture are pointing at the same problem.

How to Check This at Scale

Single-domain manual check:

# DMARC
dig TXT _dmarc.clientdomain.com +short

# SPF
dig TXT clientdomain.com +short | grep spf

# DKIM (you need the selector — ask the client's IT)
dig TXT selector._domainkey.clientdomain.com +short

What "passing" looks like:

• DMARC: v=DMARC1; p=reject; with a rua= address
• SPF: Record present, ends with -all
• DKIM: At least one active selector returning a key record

This works for one domain. For a full client base — 20, 50, 100 domains — it's a spreadsheet problem.

ComplianceLayer automates it. One API call returns DMARC policy, SPF configuration, DKIM status, enforcement grades, and findings:

curl -H "Authorization: Bearer sk_your_key" \
  "https://api.compliancelayer.net/v1/scan?domain=clientdomain.com"

Structured JSON, completes in under 15 seconds per domain. Script it across your client list and you have a pre-renewal email authentication audit before anyone touches the questionnaire.

The Part That Should Concern You

The cyber insurers in our scan are asking about DMARC because it's a genuine indicator of security hygiene. The fact that Hiscox and Markel run p=none themselves doesn't change what their underwriting systems are scanning for on your clients' domains.

External automated checks don't care about intent or circumstances. They read the DNS record.

If your client's DNS says p=none, the audit fails. If their SPF ends in ~all, the audit fails. If they have DMARC but no SPF — like Cowbell Cyber's own domain — the authentication chain is broken regardless of what the policy says.

The fix is not complicated. It's a DNS record change. The hard part is knowing which clients need it before they find out from an underwriter.

Summary

• Major cyber insurers — Hiscox, Markel, Cowbell — have email authentication gaps on their own domains while requiring it from applicants
• MDR vendor Blackpoint Cyber has no DMARC and no SPF; RMM platform Syncro has no DMARC
• Proofpoint (an email security vendor) uses SPF soft fail instead of hard fail
• p=none is not DMARC enforcement — it's a monitoring record that does nothing to stop spoofing
• 41.1% of domains in our scan had partial or no DMARC enforcement
• Underwriters run automated external scans — mismatches between the checkbox and DNS records cause premium increases and denials

Run a free scan at compliancelayer.net — no account required. If your clients' domains show anything other than p=reject, you have a deliverable and a conversation before their next renewal.

Built by ComplianceLayer — scan any domain for security compliance in seconds. Get your free API key.