A small accountancy firm in Manchester. Good reputation. Proper website. Ten staff who’ve all done the basic phishing awareness training. Their IT is looked after by whoever’s cheapest that month.

One afternoon, one of their clients received an email from the firm asking them to update their bank details ahead of an upcoming payment. The email address was perfect — looked exactly right. The email was professionally written. The client updated their details.

The money went to a criminal.

The accountancy firm’s domain had no DMARC record. No SPF enforcement. No barrier whatsoever to someone sending email that appeared to come from their address. The firm didn’t know. Nobody had ever checked.

That’s what this tool is designed to catch — before something goes wrong.

What the W3IT Security Check Actually Does

The W3IT free security check runs an automated scan against your business domain and shows you the results in real time. Enter your domain, watch the checks run live, and get an instant report. No waiting. No salesperson. No catch.

It tests four areas that represent the most common and most exploitable gaps in small business security.

Email Authentication

This is the one that causes the most damage when it’s wrong.

Every business domain can be spoofed — someone can send an email that appears to come from your address — unless you’ve configured three DNS records that tell the world’s email servers how to handle that attempt.

SPF (Sender Policy Framework) lists which mail servers are authorised to send email on your behalf. If you use Microsoft 365 and your CRM also sends emails for you, both need to be listed. Miss one, and legitimate emails bounce. Miss the record entirely, and anyone can impersonate you.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your outgoing emails. The receiving server checks the signature against a public key in your DNS. If the email was spoofed or tampered with, the signature fails. Most email providers (Google Workspace, Microsoft 365) support DKIM out of the box — but you have to turn it on and add the DNS records.

DMARC is the one that actually enforces the others. Without a DMARC policy, SPF and DKIM exist but the results are ignored — receiving mail servers don’t know what to do if a message fails the checks. A DMARC record set to p=reject means spoofed emails are blocked before they reach your customers. Set to p=none — which is what most businesses have, if they have anything — means “log but do nothing.” Functionally identical to having no protection at all.

What we see in practice: Roughly 60–70% of small business domains we check have either no DMARC record or a DMARC record set to p=none. The majority have SPF records that are incomplete — missing third-party senders like Mailchimp, Xero, or Salesforce. About a third have no DKIM configured at all.

Web Security Headers

When your browser connects to your website, the server sends back more than just the page. It sends a set of HTTP headers that tell the browser how to handle that page securely. Most small business websites are missing several of them.

HTTPS enforcement is the baseline. Is your site accessible over HTTPS? Does it redirect HTTP to HTTPS? Does it have a valid certificate?

HSTS (HTTP Strict Transport Security) is the next step — it tells browsers to only ever connect to your site over HTTPS, even if someone tries to send them to the HTTP version. Without it, an attacker on a shared network (say, the hotel WiFi your sales director uses) can intercept and modify what your visitors see.

X-Frame-Options and Content-Security-Policy prevent your pages from being embedded in iframes on other sites — a technique used in clickjacking attacks to trick users into clicking things they think are on your website.

Server version disclosure is subtle but relevant. If your web server includes a header like Server: Apache/2.4.1 (Ubuntu), you’ve just told every scanner on the internet exactly what software you’re running and what known vulnerabilities to look for.

What we see in practice: Missing HSTS is extremely common. CSP headers are present on perhaps 20% of small business sites. Server version disclosure is rampant — the majority of sites running older hosting setups broadcast exactly what they’re running.

Exposed Paths

This one is blunt and alarming in roughly equal measure.

The check probes your domain for files and directories that should never be publicly accessible. If they are, it means something has gone wrong — either in how your site was set up, or in how it’s been maintained over time.

.env files are used by developers to store configuration — database passwords, API keys, email credentials. They’re not meant to go live. They regularly do. A publicly accessible .env file is one of the most serious things this check can find.

.git directories — if a website’s Git repository is accessible from the web, an attacker can download the entire history of your codebase, including anything that was ever committed to it. Credentials rotated six months ago? Still in the git history.

WordPress login pages and XML-RPC endpoints — WordPress powers roughly 40% of the internet, which makes it a major target. An exposed /wp-login.php isn’t itself a vulnerability, but it confirms the site is WordPress and enables brute-force and credential stuffing attacks. An open /xmlrpc.php is worse — it can be used to launch those attacks more efficiently.

phpMyAdmin and admin panels — database management tools that should only be accessible via VPN or restricted IP, not from a public URL. Finding one open to the internet is a serious finding.

What we see in practice: The majority of small business sites have none of these. But the ones that do tend to have multiple exposures, often from legacy setups or sites that were “done once” years ago and never reviewed.

DNS Security

Less dramatic than the others, but foundational.

DNSSEC cryptographically signs DNS records so that responses can be verified as authentic. Without it, an attacker in a position to intercept DNS traffic (a technique called DNS hijacking) can redirect your domain to their own server. Most small business domains have DNSSEC available through their registrar — few have it enabled.

CAA records (Certification Authority Authorisation) restrict which certificate authorities are allowed to issue SSL certificates for your domain. Without one, any certificate authority in the world can issue a certificate for your domain if they can be convinced to do so (or compromised). With a CAA record, only the authorities you list can issue certificates — a meaningful protection against certain types of man-in-the-middle attacks.

Basic resolution — can your domain actually be resolved? This catches configuration errors and registrar issues (including the registry hold scenario, where a domain becomes suddenly unreachable due to a dispute or administrative hold).

The Score Is a Starting Point, Not a Report Card

After the scan runs, you’ll see a security score and a risk level: Low, Medium, High, or Critical.

The score reflects how your domain performs across the four categories relative to a baseline of expected controls. A score in the 70s with a Medium risk level is fairly typical for a small business that’s done some things right but has gaps. A score in the 30s with a High or Critical risk level usually means email authentication is missing entirely, web headers are absent, and there are one or more exposed paths.

Neither end of the scale should produce complacency. A score of 85 doesn’t mean you’re secure — it means your publicly visible controls look reasonable. The score doesn’t assess your internal network, your staff access controls, your backup posture, or your cloud configuration. Those require a proper review.

What the score does do is give you a fast, factual starting point. Business owners who go through the check often tell us one of two things: either “I had no idea that was exposed” or “I knew something wasn’t right but didn’t know what.” Both are good outcomes from a five-minute scan.

A Real-World Pattern

Here’s a composite profile based on the kinds of findings that come up repeatedly.

A professional services firm — solicitors, surveyors, consultants — runs their business on Microsoft 365. Their website is on a managed WordPress hosting plan from a provider they’ve used for years. They have a reasonable IT budget but no dedicated IT person.

Their scan typically shows:

  • Email Authentication: SPF present but incomplete (missing their CRM sender). DKIM configured. DMARC present but set to p=none — enforcement is off.
  • Web Security Headers: HTTPS working. HSTS missing. CSP absent. Server header disclosing exact PHP and Apache version.
  • Exposed Paths: Usually clean, unless the WordPress site has been customised by a developer who left debug tools accessible.
  • DNS Security: Domain resolves correctly. No DNSSEC. No CAA record.

That’s a Medium risk profile. The DMARC gap is the most immediately exploitable — a targeted Business Email Compromise attempt against their clients is possible right now. The header gaps are lower-risk but fixable in an afternoon. DNSSEC and CAA are twenty-minute jobs at the registrar.

Total remediation time for someone who knows what they’re doing: a few hours. Total risk of leaving it: ongoing and increasing.

Why Most Businesses Don’t Know

The gaps this check finds aren’t caused by negligence. They’re caused by the way small business IT tends to work.

A developer built the website three years ago and moved on. A managed hosting provider set up the DNS and never revisited it. Microsoft 365 was configured by someone following a YouTube tutorial that didn’t cover DMARC. DNSSEC was never mentioned by the registrar when the domain was registered.

None of these people did anything wrong, exactly. But the result is a domain with visible gaps that any automated scanner — including the ones attackers run — will find in seconds.

The W3IT security check runs the same kind of check, and shows you what it finds before someone else does.

What Happens After the Check

The automated report tells you what was found. If the findings are concerning — particularly anything in email authentication or exposed paths — the next step is a conversation with someone who can help you prioritise and fix them.

The report includes a direct link to get in touch with W3IT with your scan results pre-filled. You don’t have to explain your setup from scratch.

If you prefer to act on the findings yourself, the report gives you enough context to do that. SPF, DKIM, and DMARC records are manageable with the right documentation. Security headers can usually be added through your hosting provider’s control panel or a plugin. Exposed paths need to be closed at the server or application level.

What the automated scan can’t do — and what a manual review can — is look at your internal configuration, your cloud setup, your access controls, and give you a complete picture. The scan is the starting point.

Run the free security check on your domain →

It takes under a minute to start. The results appear live as each check runs. There’s no account required, no email gate, and no follow-up unless you ask for one.