What building a domain checker taught us about email security

More than a hundred parastatal chief executives are facing disciplinary action over cyber security failings, following what Citizen TV reports as four billion cyber-attacks against government systems in two years.

Those are the broadcaster’s figures, not ours, and the headline number is the least useful part of the story. What matters is buried in it: a chief executive is now personally answerable for technical controls nobody ever showed them how to check.

That is worth sitting with, because most of those controls are publicly checkable in about twenty seconds, by anyone, without permission or special access. Not just for parastatals. For your business too.

Most organisations have never looked at whether someone can send email in their name. Not because they are careless, but because nothing ever prompts them to. No dashboard warns you. No provider sends a reminder. The records that decide it were set once, years ago, during a migration nobody remembers, and they have been quietly drifting ever since.

We built the free domain security checker because we were tired of explaining this in words. It is much easier to show someone their own domain.

Why we built it

The honest reason is that the conversation was going badly.

Explaining DMARC to a business owner is a losing game. You start with alignment and policy tags and within thirty seconds you can watch their attention leave the room. It is not that they do not care whether criminals can invoice their customers. It is that the vocabulary is a wall, and climbing it feels like homework for a problem they cannot yet see.

So we stopped explaining and built something that answers one question in about twenty seconds: can someone send email as you right now, yes or no? Everything else, the acronyms and the record syntax, only becomes interesting once the answer is yes.

It runs in the browser against public DNS. Nothing about the checks is clever or proprietary. Every record it reads is the same information any mail server on the internet already sees when it decides whether to trust a message claiming to be from you. That is the uncomfortable part: this information has always been public. The only thing missing was somebody looking.

What it found first: a fault in our own scoring

We pointed it at wpfoss.com before we pointed it at anyone else’s, and it docked us points for ending our SPF record in ~all rather than -all.

Then we pointed it at Google. And PayPal. And LinkedIn. All three publish ~all. PayPal is arguably the most impersonated brand on earth, and its record ends in a soft fail.

That is not negligence. It is a signal we had the rule wrong, so we went back to the mechanism. SPF validates the envelope sender, not the From: address a human actually reads. Someone can pass SPF on their own domain while displaying yours in the header. What stops that is DMARC alignment. So once DMARC is enforcing, the choice between ~all and -all barely moves the needle on impersonation — while -all does make forwarding more fragile, because a forwarding server will never be on your list.

We changed the checker. ~all alongside an enforcing DMARC policy now passes, because it is a defensible, mainstream configuration. ~all with no DMARC behind it still gets flagged, because then nothing is refusing anything.

The useful lesson was not about our DNS. It was that a scanner which flags a healthy domain is worse than no scanner, because it teaches people to ignore it. Ours told Google it had a problem.

What is worth knowing before you check

DMARC is the control that matters. Not SPF, and not the ~all argument people spend their time on. The most common failure we see is a DMARC record sitting at p=none, which watches impersonation happen and files a report about it. It is the right place to start and the wrong place to stay, and a great many domains have been parked there for years in the belief that having DMARC is the same as being protected. Of the twelve largest brands we checked, every single one enforces: ten at reject, two at quarantine. Not one sits at none.

SPF fails silently, and it fails at ten. Every include: in your SPF record costs a DNS lookup, and so does every include inside the records you include. The specification caps this at ten. Go over it and conforming receivers stop evaluating the record entirely, which is the same outcome as publishing nothing at all. Nothing warns you when it happens. You add an invoicing tool, it adds its own include, and your protection quietly switches itself off.

Two SPF records is not twice the protection. It is none. The standard allows exactly one. If two exist, because two providers were set up months apart and each politely added its own, the result is a permanent error and both are ignored.

The part nobody does

Here is the gap we see most often, and it is not technical.

Somebody publishes DMARC at p=none with a reporting address. Reports start arriving, daily, as XML, from every major receiver. And nobody ever reads them.

Those reports are the only place you can find out which systems are sending mail in your name. Not the ones you remember, the ones you have forgotten: an old marketing platform, a supplier sending statements on your behalf, a department’s own tool set up by someone who has since left. Until you can account for every source in that list, moving to enforcement is a gamble, because the mail most likely to be blocked on day one is your own.

That is the whole job, really. Not publishing records. Reading what comes back and knowing which surprises are safe to switch off.

What to do this week

Run the check. Ours, or anyone’s. Take twenty seconds and find out where you actually stand. Run it against a domain whose answer you already know first, so you can see the tool is right before you trust it on your own.

If you have no DMARC record, publish one at p=none with a reporting address that a real person monitors. That changes nothing about your security today, and it starts the clock on knowing what you are dealing with.

If DMARC says p=none, the work is not publishing anything new. It is reading reports for two to four weeks until every legitimate sender authenticates cleanly, then tightening in stages. We wrote up that sequence in DMARC policy: none, quarantine or reject.

If you have no CAA record, add one. It takes minutes, it is free, and without it any certificate authority on earth can issue an HTTPS certificate for your domain. Large brands have mostly adopted it — nine of the twelve we checked — but smaller businesses rarely have it, because nothing ever prompts them. See the CAA record explained.

If DNSSEC is off, put it last, and be careful rather than quick. Worth knowing that most large brands run without it — of the twelve we checked, only PayPal signs — so this is a genuine improvement rather than an emergency. The sequencing is what matters: sign the zone first, confirm it, then publish the DS record at your registrar. Getting that order wrong takes your whole domain offline, website and email both. What DNSSEC is covers why.

The honest summary

Most of the domains we look at are not being actively attacked. They are simply publishing an invitation and hoping nobody reads it.

The parastatal story will be read by most people as a government problem. It is not. The difference between those chief executives and everybody else is not that their exposure is worse. It is that somebody finally went and looked.

None of this is exotic work. The controls are free, they have existed for years, and the reason they stay unset is that they sit behind acronyms nobody outside the field has any reason to learn. Attackers are relying on exactly that.

We also found a fault in our own scoring on the first run, using our own tool, and had to publish a correction to it. That is not a comfortable thing to admit, but it is the most useful thing in this piece: be suspicious of any tool that grades your domain without telling you why, including this one. A checker that flags Google has a problem with its rules, not with Google.

That is not a reason for alarm. It is a reason to look.

Run the free domain security checker on your own domain. No signup, no email address. If it comes back clean, we will tell you so, and we will not invent work. If it does not, here is how we fix it.