Email & Web Protection

Email & Web Protection

The Email & Web Protection category evaluates email security records (SPF, DKIM, DMARC), TLS encryption on both mail and web servers, and web-layer defences such as firewalls and DDoS protection. Email and web are the primary attack vectors for phishing campaigns and malware delivery. They represent the first line of defence against the most common cyber incidents. Insurers consider strong email and web filtering controls a key factor in reducing breach risk.

This category is fully assessed from the perimeter scan - no client input is needed. Below is every validation Inscora performs within this category, grouped by the protocol or control it evaluates.

Note: How to read each validation
Every validation has a short description of what it checks and why it matters for cyber insurability. In the platform, each individual validation result is tagged with a severity level (Critical, High, Medium, Low, Valid, or Info) that indicates its impact on your client's insurability posture.

DMARC (Domain-based Message Authentication)

DMARC is the overarching policy that ties SPF and DKIM together and tells receiving mail servers what to do when a message fails authentication. It is a front-line defence against email impersonation - one of the most common vectors for phishing, invoice fraud and business-email compromise.

DMARC Present on All Mail Servers

This validation checks whether the organisation's public e-mail settings include a DMARC entry: a short line published in internet address records that tells other mail systems how to verify messages claiming to come from the domain. If such an entry is found, the validation notes that the company has taken the basic step of enabling e-mail authentication. If no entry is present, it warns that the domain offers no guidance to recipients on how to tell genuine messages from fraudulent ones.

Why this matters for insurability

Confirming DMARC's presence helps gauge how easily criminals could misuse the company's e-mail identity, with direct implications for reputational harm, financial loss and data exposure. The absence of DMARC indicates a higher likelihood that staff, customers or partners may receive convincing but fake e-mails that lead to costly security incidents, whereas its presence shows the applicant has addressed a well-known risk in the e-mail ecosystem.

DMARC Correctly Configured on All Mail Servers

This validation reviews the domain's public DMARC entry to determine whether it is built correctly. It confirms the presence of the mandatory policy instruction that tells mail providers what to do with messages that fail authentication, and notes whether the optional monitoring addresses for feedback are included. Depending on what it finds, the result indicates either a sound configuration, a record that exists but lacks the policy and is therefore ineffective, or an absence of monitoring addresses that limits visibility into abuse.

Why this matters for insurability

Without a proper DMARC policy the domain is much easier to impersonate, a tactic often used to steal logins, trick staff into paying fake invoices or compromise confidential data. An insurer uses this information to gauge the likelihood of costly incidents caused by phishing or business-email compromise, and to understand how well the organisation manages one of the most common entry points for cyber claims.

SPF (Sender Policy Framework)

SPF is a DNS-based protocol that lists which mail servers are authorised to send messages on behalf of the organisation's domain. It helps receiving mail servers reject messages from unauthorised sources.

SPF Present on All Mail Servers

This validation checks whether the domain has published a Sender Policy Framework (SPF) record: a publicly visible statement listing the mail servers that are authorised to send messages on the organisation's behalf. The outcome shows either that such a record exists or that it is missing.

Why this matters for insurability

When an SPF record is absent, criminals can more easily disguise fraudulent messages as coming from the organisation, increasing the likelihood of phishing, business-email-compromise and reputational harm. When the record is present, it signals that the organisation has taken a basic step toward email authenticity. This helps an underwriter gauge the organisation's exposure to email-borne fraud and social-engineering losses, two of the most common sources of claims in cyber insurance.

SPF Correctly Configured on All Mail Servers

This validation reviews the organisation's SPF record to confirm that it is written in a way that mail servers will accept and enforce. It checks that the record is not too long for the internet addressing system, includes a rule that clearly states what should happen to mail from unauthorised computers, and avoids outdated wording that some mail servers no longer trust. A positive outcome indicates the record meets these quality points. A negative outcome highlights specific weaknesses.

Why this matters for insurability

A correctly written record helps mail providers recognise fake messages that pretend to come from the organisation, making it harder for criminals to run phishing, invoice-fraud or business email compromise attacks. Weak or ineffective settings raise the chance of costly incidents such as wire-transfer fraud, data compromise or reputational damage that can lead to claims under a cyber policy.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing emails that recipients can verify, proving the message was genuinely sent by the claimed domain and was not tampered with in transit.

DKIM Present on All Mail Servers

This validation looks at the public DNS information for the organisation's domain and confirms whether the special entry that allows outgoing e-mails to be cryptographically signed (known as DomainKeys Identified Mail or DKIM) is published. A positive result shows that at least one DKIM record is in place. A negative result means no such record exists, revealing that outbound e-mail cannot be authenticated.

Why this matters for insurability

DKIM protects the business from someone impersonating its e-mail address, a tactic common in phishing and fraud. When the record is missing, external mail systems cannot confirm that messages truly originate from the domain, making it easier for attackers to send convincing fraudulent messages that could lead to data theft or financial loss. Knowing whether DKIM is present helps gauge the likelihood of e-mail spoofing incidents, which are a frequent cause of claims related to wire-transfer fraud, ransomware entry and exposure of confidential information.

DKIM Correctly Configured on All Mail Servers

This validation checks whether all the pieces required for DKIM are present and properly filled in, such as the public encryption key and the setting that states the key type. A positive result shows that the organisation has provided complete, standards-compliant details so recipients' mail systems can confirm that messages truly came from the claimed domain. A negative result shows that some of this information is missing or incomplete.

Why this matters for insurability

An incomplete DKIM configuration leaves customers, partners and staff more exposed to forged messages that can deliver malware, steal credentials or trick users into disclosing sensitive information or funds. For an insurer evaluating cyber risk, this insight contributes to understanding the likelihood of phishing-related incidents, business e-mail compromise and the potential downstream costs associated with data breaches or financial fraud initiated through spoofed messages.

TLS (Transport Layer Security)

TLS encrypts the connection between clients and servers - whether for email or web traffic - preventing eavesdropping and tampering. Inscora checks both the presence and the quality of TLS configuration on mail and web servers.

TLS Present on Mail Servers

This validation checks whether the organisation's e-mail systems are capable of encrypting connections when users or other servers deliver or collect messages. By observing the network ports dedicated to sending and receiving e-mail, it confirms if those services offer secure communication channels based on modern encryption standards or if they fall back to transmitting data in plain text.

Why this matters for insurability

Encrypted e-mail connections prevent outsiders who can monitor network traffic from reading messages or stealing account passwords, helping to keep sensitive correspondence and credentials out of unauthorised hands. The presence of strong encryption lowers the probability and potential severity of interception-based incidents, which directly influences the assessment of risk and the pricing or terms of a cyber insurance policy.

TLS Correctly Configured on Mail Servers

This validation reviews how the organisation's e-mail servers present their encrypted connection, confirming whether the encryption settings follow current best practice or whether any weak points remain. It examines the version of encryption in use, the strength of the underlying algorithms, and whether the server's digital certificate is valid, trusted, and built on a key that is hard to crack.

Why this matters for insurability

Strong encryption on e-mail services limits the chance that attackers can read confidential messages, harvest passwords in transit, or impersonate the organisation's domain to customers and staff - all of which are common routes to fraud, data leaks and regulatory penalties. By flagging weaknesses in these settings, the validation shows whether the organisation is actively reducing the likelihood of such events.

TLS Present on Web Servers

This validation checks whether the organisation's public-facing web services offer an encrypted connection (HTTPS) rather than plain, open traffic. If the scan detects the encrypted channel, it records that fact; if it finds a site responding without encryption, it notes the gap.

Why this matters for insurability

An encrypted channel prevents outsiders from quietly viewing or altering information that customers or staff send to the site, such as login details, payment information or personal data. Knowing whether this protection is present helps gauge the likelihood of eavesdropping, fraud or data-privacy violations, and understand how exposed the business is to interception-based breaches.

TLS Correctly Configured on Web Servers

This validation reviews whether the organisation's public-facing websites are using up-to-date encryption practices. It examines the details of each site's security certificate and the rules the server follows when encrypting connections. It confirms that the certificate is still valid, issued by a recognised authority, signed with a modern algorithm, and backed by a key of sufficient size, and that the server refuses obsolete protocols and weak ciphers.

Why this matters for insurability

Strong, correctly configured encryption guards the confidentiality and integrity of data exchanged between customers and the company's websites, preventing eavesdropping, tampering, and impersonation. Evidence that encryption is current and properly implemented reduces the likelihood of data interception, credential theft, and trust-related service disruptions. Conversely, results that reveal weak or outdated encryption signal an elevated exposure to attacks and regulatory penalties.

Webmail Detection

Webmail Likely Present

This validation checks whether the organisation's server is publicly advertising any kind of web-based e-mail login page, such as Outlook Web Access, Roundcube, Zimbra or similar products. A positive result means the server has disclosed information showing an online mailbox interface is reachable from the internet.

Why this matters for insurability

When a web-mail interface is exposed to the public internet it handles user names, passwords and the content of e-mails - all attractive targets for cyber criminals who rely on password-guessing, credential stuffing or phishing to break in. Confirming the existence of such an interface helps gauge the likelihood that attackers could obtain access to confidential correspondence, reset other account passwords or spread malware through hijacked mailboxes. This informs the assessment of account-takeover and data-breach risk, and influences expectations around multi-factor authentication and patch management.

Web Protection & DDoS

These validations assess whether the organisation has protective layers between its internet-facing services and the public internet, such as web application firewalls and denial-of-service mitigation.

Web Application Firewall in Use

This validation observes whether the website appears to sit behind a Web Application Firewall (WAF), a protective gateway that filters and moderates traffic before it reaches the underlying application. A positive result signals that such a shield is likely in place. A negative result suggests the application is directly exposed to the internet without this extra layer of defence.

Why this matters for insurability

When no such protection is detected, attackers have a more direct path to exploit coding flaws, steal data or disrupt service, which raises the probability of loss events the insurer may ultimately cover. Confirming the presence or absence of this safeguard allows an underwriter to gauge baseline exposure, set appropriate premiums and recommend risk-mitigation measures aligned with the organisation's actual security posture.

DDoS Protections in Place

This validation checks whether the organisation's internet-facing server is positioned behind a recognised denial-of-service protection or content-delivery network. By looking at publicly visible service information, it confirms either that traffic first passes through a provider such as Cloudflare, Akamai or Imperva, or that no such protective layer is present.

Why this matters for insurability

A host without this buffer is more susceptible to outages that can disrupt revenue, customer access and contractual service-level commitments, whereas one that is shielded demonstrates an additional layer of resilience that reduces the likelihood and potential duration of a downtime event. Insurers rely on this insight to gauge the probability and scale of business-interruption losses when determining premiums, coverage limits and any required risk-mitigation conditions.

Tip: Use Explain to understand any validation
For any question about what a scan result means, how it affects insurability, or what to do about it, use the Explain button directly on that validation. The briefing is generated from your client's actual data and covers the technical meaning, insurability impact, real-world incident references, step-by-step remediation, and how your own services connect to the solution.