Chief executives of Kenyan state corporations are facing disciplinary action for failing to secure government systems. Among the specific failures named: delay in implementing domain and email protection measures for government websites, work meant to be done with the Communications Authority of Kenya.
The scale behind that instruction is worth sitting with. National digital systems absorbed roughly four billion cyber-attacks over two years. In one three-month window alone, the National Computer and Cybercrime Coordination Committee counted more than three billion attempts against government systems and critical services. The State House website was defaced, its homepage replaced with messages aimed at the President, and a Bitcoin ransom of around Sh41 million demanded.
Notice what is being asked for. Not a firewall. Not a bigger security budget. Domain and email protection. That is a specific, checkable thing, and it is the part of security most organisations have never looked at.
Why I built the checker
Three DNS records decide whether someone can send email pretending to be you.
SPF lists the servers allowed to send as your domain. DKIM signs each message so it cannot be altered on the way. DMARC ties both to the address recipients actually see, and tells receiving servers what to do when a message fails.
Get these wrong and someone can email your customers, your bank, or your suppliers, from your domain name, and it will look correct. No system is breached. Nothing is hacked. The domain simply never told the world who was allowed to speak for it.
I have spent seventeen years running hosting and domain infrastructure in Kenya, and I still could not tell you, from memory, what most domains publish. So I built a tool that reads it: onduu.ke/email-security. It is free, it asks for nothing, and it explains what it finds in plain language. Type a domain, get the answer.
What it found first: my own domain, broken
I ran onduu.ke through it. The result came back unable to read anything at all. No MX. No SPF. It reported no DMARC policy, on a domain I knew had one.
The tool was right and I was wrong. My DNSSEC was broken.
DNSSEC signs DNS answers so a resolver can verify nobody tampered with them. It depends on a small record at the registry — a DS record — matching the key published in the zone. Mine did not match. The key tag was right, the algorithm was right, the digest was wrong.
The consequence of that mismatch is total. Every resolver that validates DNSSEC — Google’s, Cloudflare’s, Quad9, many ISPs — stops. Not “returns fewer records.” Refuses to answer at all. For every one of those users, my website was unreachable and mail to me was undeliverable. The error from Google’s resolver was blunt: No DNSKEY matches DS RRs of onduu.ke.
I had no idea. There is no alert for this. Nothing in my inbox, no dashboard going red. The site loaded fine for me, because my own resolver did not validate. The tool I had built to check other people’s domains was the thing that caught mine.
That is the lesson, and it is worth more than the code: you do not know what your domain publishes. You know what you intended it to publish. Those are different, and the gap between them is where the trouble lives.
Three things worth knowing before you check
Most domains have one or two of the three. SPF is common because hosting providers add it. DKIM is often there because the mail provider set it up. DMARC is the one usually missing, and it is the one that makes the other two mean anything.
A green tick on DKIM does not mean your mail is signed. DNS can only show that a key is published. It cannot show that anything is using it. The usual real-world gap is that the main mailbox signs correctly while the invoicing system and the CRM do not. To actually confirm it: send yourself a message at any Gmail address, open it, choose Show original, and look for dkim=pass. Do that for every system that sends as you.
p=reject is the goal, not the starting point. DMARC’s policy tag tells receivers to reject anything that fails. It is real protection. It also blocks your own invoices if a legitimate sender of yours was never set up properly. The correct order is to publish p=none, read the reports for a few weeks until every legitimate sender passes, and only then tighten. Moving early is how organisations break their own billing and blame the security consultant.
The part nobody does
DMARC asks receiving servers to send you reports — daily files listing every IP address sending as your domain and whether it passed.
Almost nobody reads them, because raw they are gzipped XML. Dozens a week, unreadable without tooling. So the reports arrive, land in a mailbox nobody opens, and the whole feedback loop that makes DMARC safe goes unused.
This matters for the government directive too. An agency can publish all three records this month and satisfy the letter of the instruction. Without reading the reports, it will not know when a new supplier’s system starts failing, or when someone genuinely starts spoofing them. Publishing a record is a configuration change. Knowing what your domain is doing is an ongoing practice.
What to do this week
If you run a business, a SACCO, a school, or a state agency, this is a short list and none of it costs money:
- Check what you publish. Run your domain through the checker. It takes ten seconds and the explanations are written for people who are not engineers.
- Confirm signing from a real message. Gmail, Show original, look for
dkim=pass. Test each system that sends as you, not just your main mailbox. - If you have no DMARC, publish
p=nonewith a reporting address. It changes nothing about delivery and starts the data flowing. - Check DNSSEC deliberately. It is worth having. It is also the one setting that takes your entire domain offline when the chain breaks, silently, as mine did.
- Write down who controls your DNS. Not the vendor’s name. The login.
New to the terms? The glossary defines eleven of them in plain language, with no jargon left undefined.
The honest summary
Four billion attack attempts is a frightening number, and frightening numbers are usually where the useful conversation stops. The instruction underneath it is not frightening at all. It is administrative: publish the records that say who may send as you, then check they are working.
Most Kenyan organisations have never done it. Most do not know whether they have. I did not know about my own domain, and I have been doing this since 2005.
That is not a reason for alarm. It is a reason to look.
Sources: The Standard (opens in a new tab) · The Star (opens in a new tab)