Cyber insurance email security questions: how to answer them

Key facts

• Australian proposal forms ask a single email security question, worded around filtering, authenticating and quarantining suspicious content such as executable files.
• The requirement is that filtering is activated for all email accounts, which includes shared mailboxes, service mailboxes and any account created for an integration.
• Some insurers explicitly accept native platform tooling rather than requiring a third-party gateway, naming the platform’s own protection as sufficient.
• One form’s wording asks about tooling that authenticates emails, which reads onto sender authentication through SPF, DKIM and DMARC as well as content scanning.
• Mailbox compromise is the delivery mechanism for the payment fraud that the criminal financial loss questions cover, so this control sits underneath those answers.
• Legacy authentication protocols bypass multi-factor authentication on a mailbox entirely, which makes them an email security issue as much as an identity one.

Why one question carries this much weight

Email is the entry point for the two loss types that dominate Australian small and medium business cyber claims: ransomware delivered through a malicious attachment or link, and payment redirection following a mailbox compromise. The second is more common and less dramatic. Nobody is locked out of anything. An attacker sits in a mailbox reading invoice threads, waits for a real payment to be discussed, and sends a plausible message changing the bank details.

Insurers ask one question because a single control, applied everywhere, prevents a large share of that. The reason the wording emphasises “all email accounts” is that partial deployment is common and useless. A shared accounts@ mailbox excluded from filtering during a migration is exactly the mailbox that receives supplier invoices.

The question below comes from Australian cyber insurance proposal forms current as at September 2026. No insurer is named. The full set of 45 technical questions is on the cyber insurance questionnaire guide.

The email security question insurers ask

Do you use an email filtering and scanning tool activated for all email accounts?

Australian cyber insurance proposal forms word this in two ways. One asks whether you use an email filtration and scanning tool to authenticate emails and flag and quarantine suspicious content, giving executable files as the example. Another asks whether an email filtering system is in place, naming both third-party gateways and the platform’s own native tools, activated for all email accounts. The answer underwriters accept is yes, on every mailbox, with no exclusions.

What has to be in place is a filtering platform, or the native protection built into your email platform, with the policy scoped to all mailboxes rather than to a group that was current at rollout. Executables and other dangerous attachment types need to be blocked or quarantined rather than merely scanned. The point worth knowing is that a third-party gateway is not universally required, because at least one Australian insurer names native platform tooling as acceptable, and that changes the cost of a yes considerably for a business already paying for a licence that includes it.

The evidence is the policy scope showing every mailbox covered, quarantine and detection reporting for the period, and the attachment blocking rule list. Check shared and service mailboxes specifically. They are frequently outside the policy and they are frequently the ones handling money.

Does native email protection count, or do insurers want a third-party gateway?

Native protection counts on the forms we have seen, and at least one Australian insurer names it explicitly alongside the third-party products. That said, the answer to the form and the answer to the risk are not identical. Native tooling in a standard licence tier is often weaker on impersonation detection and on link rewriting than a dedicated product, and impersonation is the technique used in the payment redirection attacks that drive most claims.

The practical position is that native protection, properly configured and switched on for everything, is a legitimate yes and is much better than a third-party product deployed to half the mailboxes. Whether to add a dedicated gateway is a risk decision rather than an insurance one, and it turns on how much of your business runs through email invoices.

What makes the answer strong rather than just accurate?

Four controls sit behind a strong yes, and none of them is asked about by name on the forms we have reviewed. They matter because the insurer is trying to assess how likely a mailbox compromise is, and the single question only partly measures that.

Sender authentication comes first. SPF, DKIM and DMARC together stop other people sending mail that appears to come from your domain, which is what protects your customers and suppliers from being defrauded in your name. One form’s reference to a tool that authenticates emails reads onto exactly this. Second is impersonation and lookalike domain protection, which catches the display-name spoofing and near-miss domains used in invoice fraud. Third is the disabling of legacy authentication protocols, since protocols such as POP, IMAP and SMTP AUTH cannot present a second factor and let an attacker with a valid password into a mailbox that has multi-factor authentication enforced. Fourth is alerting on the creation of inbox rules, because the first thing an intruder does in a compromised mailbox is create a rule that hides their replies from the real owner.

That fourth one is the early warning for the payment fraud questions elsewhere on the form. A rogue inbox rule usually appears days before a fraudulent payee change request arrives, which makes it the cheapest detection available for the most expensive thing that happens to Australian small businesses by email.

The evidence to assemble before the form arrives

Five artefacts cover the question and the controls behind it:

• The filtering policy scope, showing every mailbox in the tenant covered, including shared and service accounts.
• Quarantine and detection reporting for the last full month.
• The attachment blocking rule list, showing executables and other dangerous types handled.
• Current SPF, DKIM and DMARC records for every sending domain, with the DMARC policy state.
• The policy blocking legacy authentication protocols, plus whatever alerts on inbox rule creation.

The related questions elsewhere on the form are the payment fraud controls, which depend on this one, and the awareness training questions, which cover the human side of the same attack. The full questionnaire guide sets out how the areas connect.

One thing not to do

Do not answer yes on the strength of the platform having protection available. The question asks whether filtering is activated for all email accounts, and the two most common gaps are a policy scoped to a user group that has drifted out of date, and shared mailboxes that were never in scope. Both produce a technically defensible yes and a mailbox that receives supplier invoices with no filtering in front of it. Checking the policy scope takes minutes and it is worth doing before the form goes back rather than after a payment goes to the wrong account.

If a cyber insurance questionnaire has landed and you want the email answer to be accurate rather than hopeful, 4iT checks the policy scope across every mailbox, closes the gaps, and produces the evidence pack the underwriter will ask for. Request a callback and we will take a look.