Cyber insurance email controls

Which email questions can this domain answer Yes on a cyber application?

Map public DNS to the email questions carriers actually ask. Every answer is Verified, Unknown, or Not tested, with a paste-ready evidence line. Not insurance advice.

How to read this

Many cyber applications ask about email security. Some ask specifically about SPF, DKIM, and DMARC; others ask about email filtering, MFA, or phishing training. This check covers the email controls underwriters look at most.

This page maps public DNS to those questions using the same three labels as the product: Verified, Unknown, Not tested. We will not tell you to answer Yes unless the evidence is Verified. A missing DKIM selector is Unknown — you still need the mail admin. Microsoft Defender does not show in MX, so filtering without a gateway MX is Unknown, not No.

Each row has the wording carriers typically use, the answer you can defend from this lookup, and a one-line evidence sentence you can paste into the application or the broker’s worksheet. Dates are the day we looked. Re-run before you submit; DNS changes.

This is not insurance advice and it is not a statement that the domain is “insurable” or that a score lowers premium. The applicant is responsible for every answer on the form. MFA, backups, EDR, and training cannot be seen from DNS — those stay Not tested here on purpose.

If you sell this to clients, the “How this looks to your client” line is the sentence you can put in an email. The full branded report — logo, colors, next-step quote — is what Client Posture is for.

Paste the evidence line only for Verified rows. If a row is Unknown, the honest application answer is “not sure” or a note that the control lives in the tenant. Guessing Yes from a blank DKIM selector or a missing gateway MX is how applications get messy at binding.

The four rows match what we see on applications most weeks: DMARC enforcement (quarantine or reject, not t=y), a valid single SPF under the lookup cap, DKIM with a published key, and inbound filtering beyond a spam folder. MFA on email, restore tests, and EDR stay Not tested because they are not in public DNS.

Carriers usually ask the DMARC question as “Do you enforce DMARC?” not “Do you have a record?” We answer No, Verified when p=none or when the record is missing, and Yes, Verified only for quarantine or reject without t=y. An existing pct is historic and is not a No. SPF is Yes when there is one valid record that is not +all and is under ten lookups. DKIM is Yes only when we retrieved a key; otherwise Unknown. Filtering is Yes only when MX points at a named gateway we already detect (Proofpoint, Mimecast, Barracuda, and the rest of that list). A Microsoft 365 MX without a gateway in front is Unknown for filtering — Defender lives in the tenant.

FAQ

Can we answer Yes to DMARC if p=none?
Not for forms that ask about enforcement. p=none is a record, not a control. We mark that No, Verified.
Why is filtering Unknown when we use Defender?
Defender does not change MX. We cannot see it from outside. Confirm in the tenant, then answer Yes yourself.
Is this a substitute for the Client Posture insurance pack?
No. This is the public email slice. The in-app pack covers the rest of the questionnaire, evidence files, and MSP-branded PDF.

Fix this for your clients, white-labeled

Client Posture runs the same checks under your logo, with a branded PDF and a quote attached. MSPs use it to walk into the next meeting with evidence instead of a generic screenshot.

Cyber insurance email controls — DMARC, SPF, DKIM, filtering | Client Posture