A small business — a few staff, a single domain, a decent website, no in-house IT — ran our free security check against their own domain last week. The result came back at 80 out of 100. Four warnings, all of them quiet, none of them obvious. None of them would have stopped a customer enquiry coming in. All of them would have mattered the day something went wrong.

This is the story of those four warnings, the five changes we made for the business to clear them, and the one extra step — submitting to a list maintained by Google, Mozilla and Apple — that takes a domain from “configured properly” to “protected even on a visitor’s very first connection.”

If you’d rather skip the narrative and run the same check on your own domain, start here. The rest of this post is what happens when a business takes the results seriously.

The Starting Score

The four warnings, in the order the scanner reported them:

  1. HSTS max-age too short. The header was present, but only valid for six months. The scanner — like the browser preload list it mirrors — wants at least a year.
  2. SPF set to soft-fail (~all). Mail that failed SPF was being marked suspicious by receivers, not rejected. There’s a meaningful difference.
  3. DKIM not found. The mail provider had published DKIM keys, but under selector names our scanner wasn’t looking for. (We fixed both sides of this.)
  4. No CAA records. Any certificate authority on Earth could have issued an SSL certificate for the domain, and every browser would have trusted it.

None of these warnings means the domain is compromised. They mean the cost to a future attacker is lower than it should be. Each one corresponds to a specific class of real attack — and each one has been used against real businesses, frequently, in the past five years.

Fix 1: SPF — From “~all” to “-all”

What it is. SPF (Sender Policy Framework) is a DNS record that lists which mail servers are allowed to send email from your domain. When a receiving mail server gets a message claiming to be from your domain, it checks SPF and asks: “Did this come from a server you authorised?”

What the two endings mean.

  • ~all (soft fail): “Mail from any other server is suspicious. Maybe spam, maybe not. Receiver decides.”
  • -all (hard fail): “Mail from any other server is forged. Reject it.”

The business’s SPF record ended in ~all. “The receiver decides” means, in practice, “the receiver puts it in the spam folder, or doesn’t, depending on their algorithm that month.” Some Gmail accounts will still deliver soft-failed mail to the inbox if the rest of the message looks legitimate.

What happens if you leave it. This is the gap that Business Email Compromise (BEC) attacks exploit, and BEC is the single most lucrative form of internet fraud aimed at small businesses. In a typical case, a criminal sends an email that appears to come from a company’s accounts department to one of their clients, saying “Our bank details have changed — please use this new account for your next payment.” With SPF set to ~all, that email lands in the client’s inbox marked as slightly suspicious or not flagged at all. The client pays. The money is gone within minutes.

The FBI’s Internet Crime Complaint Center logged $2.9 billion in BEC losses in 2023 alone, the largest single category of cybercrime by dollar value. The defence is not exotic. It’s changing one character in one DNS record.

The catch. Tightening SPF is only safe if you know about every system that sends email on your behalf. Marketing platform? CRM? Transactional email service? Newsletter tool? Each one needs to be in your SPF record before you flip to -all, or its emails will be rejected. The business sent all its mail through Hostinger and nothing else, so the change was a one-character edit.

The fix. One DNS change in Cloudflare:

v=spf1 include:_spf.mail.hostinger.com ~all
                                      ^
                                      change to -

Fix 2: DKIM — Cryptographic Signatures for Email

What it is. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email your domain sends. The receiving server uses your public key (published in DNS) to verify two things: that the email genuinely came from your domain, and that nothing in the message has been altered in transit.

SPF tells receivers who is allowed to send. DKIM tells receivers that the message they received is bit-for-bit identical to what was sent.

What happens if you leave it. The attack here is invoice tampering. A criminal positioned on a network between your mail server and the recipient’s — or, more commonly, on a compromised mail server somewhere along the relay chain — intercepts an outgoing email, modifies the bank details in an attached PDF or in the email body, and forwards it on. Without DKIM, the recipient has no way to detect that the message was changed. The signature would have failed, but there was no signature to check.

This isn’t theoretical. Mail relay servers get compromised. Public WiFi at hotels and airports gets compromised. The 2018 Marriott breach exposed not just guest records but the mail routing infrastructure of one of the largest hospitality chains on Earth. Email integrity in transit is something you cannot assume.

The specific gap. DKIM was already configured on the business’s Hostinger mailbox — Hostinger had published keys at selectors like hostingermail1._domainkey and hostingermail-a._domainkey. The keys were there. The signatures were being added to outgoing mail. Everything was working.

Our scanner just wasn’t looking under those names. It was checking the eight most common selectors (default, google, selector1, selector2, mail, k1, dkim, smtp) and reporting DKIM as missing when in reality it was published under a vendor-specific name. While working through this business’s report, we extended the scanner’s selector list to include Hostinger’s, Proton’s, and Fastmail’s naming conventions — a one-line code change that improves the scan for every Hostinger customer who runs the check from now on.

For belt-and-braces on the business’s side, we also added a CNAME at their default._domainkey selector pointing to Hostinger’s actual key host. Now any DKIM verifier that checks the standard default selector finds the key on the first try.

The fix. Two parts: enable DKIM in your mail provider’s control panel (most have a one-click toggle now — Hostinger, Microsoft 365, Google Workspace, Proton all do), then add the resulting TXT record or CNAME to your DNS.

Fix 3: CAA Records — Locking Down Who Can Issue Your Certificates

What it is. CAA (Certification Authority Authorisation) records are DNS entries that name the specific certificate authorities allowed to issue SSL/TLS certificates for your domain. Without them, any CA on Earth — and there are over a hundred trusted ones — can issue a valid certificate for your domain if they can be convinced to do so.

What happens if you leave it. The two reference cases are over a decade old and still relevant.

In 2011, DigiNotar — a Dutch certificate authority — was compromised by an attacker who used it to issue fraudulent certificates for google.com, mail.google.com, *.windowsupdate.com and over five hundred other high-value domains. Those certificates were then used to intercept the encrypted Gmail traffic of an estimated 300,000 Iranian users. Browsers trusted the certificates because DigiNotar was in their trust store. DigiNotar was distrusted by every major browser within weeks, but the damage to the people whose mail was intercepted was already done.

In 2015, China’s CNNIC certificate authority was caught issuing fraudulent certificates for Google services through an Egyptian sub-CA. Same attack pattern, different country.

CAA records would have stopped both. With a CAA record in place, even if an attacker compromises a major CA, browsers will not trust a certificate issued by a CA that isn’t named in your DNS — because your CAA record says “only these specific authorities are allowed to issue certificates for this domain.”

This sounds like an enterprise concern, but it’s not. CAA records are free, take five minutes to add, and meaningfully reduce a class of attack that has happened to real businesses repeatedly.

The fix. Three CAA records in your DNS, one for each CA your provider uses:

yourdomain.com  CAA  0 issue "letsencrypt.org"
yourdomain.com  CAA  0 issue "pki.goog"
yourdomain.com  CAA  0 issue "ssl.com"

If you’re on Cloudflare, those are the three Universal SSL issuers in 2026. Other hosting providers may use Sectigo, DigiCert, or others — check before you add. An optional fourth record routes misissuance reports to your email:

yourdomain.com  CAA  0 iodef "mailto:[email protected]"

When you pair CAA with Certificate Transparency Monitoring (a free Cloudflare feature — turn it on under SSL/TLS → Edge Certificates), you get the full belt-and-braces: CAA prevents most misissuance, and CT monitoring tells you immediately if a certificate gets issued anyway.

Fix 4: HSTS — Locking the Browser to HTTPS

What it is. HSTS (HTTP Strict Transport Security) is a response header that tells browsers: “Once you’ve connected to this site over HTTPS, never connect over plain HTTP again — even if the user types http://, even if a link points to it, even if an attacker tries to redirect.”

The header includes a max-age value: how long the browser should remember the rule. Six months is Cloudflare’s default. The browser preload list (more on that below) requires at least one year.

What happens if you leave it. Open-WiFi downgrade attacks are the standard threat model. A sales director sits in a hotel lobby on the hotel WiFi. They type a domain name into the address bar. Their browser, by default, tries HTTP first — and an attacker on the same network intercepts that initial request before it ever reaches the real site, redirecting the traffic to a fake under their control. Without HSTS, the browser has no idea that the real site is HTTPS-only. With HSTS, the browser refuses to make the HTTP request at all; it remembers from the previous visit that the domain is HTTPS-only and goes straight to the encrypted connection.

This isn’t a hypothetical. Tools like sslstrip (released publicly in 2009) automate this attack. WiFi Pineapples — devices that mimic legitimate WiFi networks — make it trivial. And during the 2011 Tunisian uprising, the country’s ISP was caught injecting modified JavaScript into HTTP responses to harvest Gmail and Facebook credentials of activists. HTTPS would have stopped it. HSTS would have stopped browsers from ever falling back to HTTP in the first place.

The specific gap. HSTS was already on for the business, with max-age=15552000 (six months). Our scanner — which mirrors the HSTS preload list requirements — flagged it as too short. We bumped Cloudflare’s setting to 12 months, which is the sweet spot: long enough to qualify for the preload list, short enough that Cloudflare doesn’t show a warning about long-term lock-in.

The fix. In Cloudflare: SSL/TLS → Edge Certificates → HSTS → set Max Age to 12 months. Make sure “Include subdomains” and “Preload” are on. Save.

The Bonus Step: hstspreload.org

This is the one most small businesses haven’t heard of. It’s also the one that matters most for new visitors.

HSTS protects browsers that have already connected to your site at least once. The header gets delivered on that first HTTPS response, and the browser remembers it. But what about a visitor who’s never been to your site before? Their very first request might be HTTP — and there’s nothing in their browser yet that says “no, force HTTPS.” That window, before the first response arrives, is when downgrade attacks succeed.

The HSTS preload list closes that window. It’s a list of domains that ship inside Chrome, Firefox, Safari, Edge and Brave. When a browser sees a domain on the list, it forces HTTPS immediately, on the first request, before any DNS lookup or HTTP traffic happens. There’s no first-visit window for an attacker to exploit.

The list is maintained at hstspreload.org. To qualify, your domain must serve an HSTS header with:

  • max-age of at least 31,536,000 seconds (one year)
  • includeSubDomains directive
  • preload directive
  • A valid HTTPS certificate
  • A redirect from HTTP to HTTPS on the apex
  • HTTPS working on all subdomains

After the HSTS bump, the business’s domain now meets every criterion. Submission is one form at hstspreload.org. After Google reviews and accepts the domain (typically a few weeks), every major browser on Earth ships with the rule “always force HTTPS for this domain” baked in.

The one warning. Preload submission is a one-way commitment in practical terms. Once you’re on the list, every subdomain of your domain must serve valid HTTPS forever. If you ever spin up test.yourdomain.com or legacy.yourdomain.com on a host without TLS, those subdomains will be unreachable in modern browsers. Removal from the list is possible but takes months to propagate.

For a business that’s confident in its hosting architecture — a single, well-managed setup with no plans for non-HTTPS subdomains — preload is the right call. For a business that experiments with subdomains, spins up dev environments, or might in future use a host that doesn’t support HTTPS by default, it’s worth thinking carefully before submitting.

This particular business is Cloudflare-fronted on every hostname, with no plans for non-HTTPS subdomains. They’re submitting.

What the Result Looks Like

After the four fixes — SPF tightened, DKIM verified, CAA records added, HSTS bumped — the business’s domain now scores 100 out of 100 on the scanner.

That score doesn’t mean the business is unhackable. The scanner only measures publicly observable signals — email authentication, response headers, exposed paths, and DNS. It doesn’t audit their admin access controls, their backup posture, their staff phishing resistance, or their cloud configuration. Those need a real review. But the score does mean that the visible attack surface — the things any automated scanner (including the ones criminals run) can see — is closed.

For most small businesses, that visible attack surface is where 90% of opportunistic attacks land. Criminals aren’t doing targeted research on your business. They’re running automated scanners across millions of domains and following up wherever they find an easy mark. A domain with a weak SPF, no DKIM, no CAA, and a short HSTS is visible in those scans. A properly configured domain isn’t.

The total cost of the changes for this business: one DNS record edit (SPF), one DNS record addition (DKIM CNAME, in some cases multiple), three to four DNS record additions (CAA), one Cloudflare dashboard setting (HSTS). Total time, working with someone who knew what they were doing: under thirty minutes.

Run the Check on Your Own Domain

If you’ve read this far, the obvious question is what your own domain looks like.

Run the free security check →

It takes under a minute to start. The results appear live as each check runs. You’ll see exactly which of the four categories — Email Authentication, Web Security Headers, Exposed Paths, DNS Security — your domain passes, warns on, or fails. There’s no account required and no follow-up unless you ask for one.

If you’d rather have someone walk through the findings with you and identify the fastest path to fixing them — the way we did for the business in this post — get in touch with W3IT. The fixes themselves are mostly straightforward. What’s harder is knowing which ones to prioritise for your specific setup, what other senders to add to SPF before you tighten it, and what dependencies you might break in the process.

The scan is free. The fixes are mostly free. The next BEC attempt against your domain is not.