What a stranger can already see about your business online

Where does public information about a business come from?

Three separate systems, each public for a reason that has nothing to do with you.

DNS

The internet's address book. It has to be readable by anybody, because every mail server that delivers to you and every browser that opens your website starts by asking it a question. There is no such thing as a private public DNS record.

Certificate transparency logs

Public, append-only records of every certificate a publicly trusted authority issues. They exist so a certificate wrongly issued for your domain cannot be used quietly — browsers expect to see the proof of logging. The security benefit is real, and the side effect is that every name you have certified is searchable.

The domain registry

A domain name is a registration, and registrations have public particulars: the registrar of record, when it was created and when it expires, the status flags, the name servers. Personal contact details are usually redacted now; the operational facts are not.

What follows uses baharicourt.example — a fictional coastal hotel on the reserved .example domain, and the same one our worked sample report is written about.

What does DNS reveal?

The mail-related records get their own guide, because they are the ones that decide whether a criminal can email your guests or suppliers as you, and because the fix is free — SPF, DKIM and DMARC, explained properly.

The last line in that block is the one worth dwelling on. Stray records outlive the suppliers that created them. A CNAME pointing at a service you cancelled is not merely untidy: if the target can be re-registered by somebody else, they get to publish content on a subdomain of your business, with your name on it. Cleaning up old records is free and nobody schedules it.

What do certificate transparency logs reveal?

Every time you or a supplier obtains an HTTPS certificate from a publicly trusted authority — including the free automated ones — the hostnames on it are written into public logs, permanently. You can search them by domain. So can everyone else.

This is not a flaw to be fixed; it is the mechanism working. The useful response is to be the first person to read your own log, not the last.

What does the domain registry reveal?

Registry data is published through RDAP, the protocol that replaced WHOIS. Personal contact details are usually redacted these days. The operational facts are not, and they are the ones that matter.

Why it matters: three chains that start here

Individually these are facts. The damage comes from combining two or three of them, and each of the following needs no access to anything.

1. MX plus no DMARC becomes invoice fraud. The MX record says you use a well-known mail provider. The absent DMARC policy says nobody has told receiving servers to reject mail that only claims to be you. An email goes to a supplier, from your address, with different bank details. Nothing was hacked.
2. A certificate log entry becomes a convincing phishing page. pms.baharicourt.example names the property-management vendor. The login page is copied, the email is themed to match, and it goes to three people at the front desk who use that system every day. The credential that comes back is genuine, so every check passes afterwards.
3. An expiry date plus no lock becomes a hijack. A domain twenty days from expiry with no transfer lock, on a registrar account whose contact address is published, is a queue of one. Losing the domain means losing the website, the email and the ability to prove to anyone that you are you.

What can I actually do about it?

You cannot withdraw any of this. DNS is public because it must be, certificate logs are append-only on purpose, and registry entries are the record of a registration. What you can do is change what they say, and know it before someone else does.

1. Fix the mail records first. Free, DNS-only, and it closes the most commonly exploited path — the full method is here.
2. Put multi-factor authentication on the registrar account and the DNS account. These two accounts control everything else on this page, and they are usually the least protected things a business owns.
3. Turn on the registrar lock and auto-renew, and make sure the address the renewal notice goes to is one somebody still reads.
4. Retire stray DNS records, and check any CNAME that points at a service you no longer pay for.
5. Be deliberate about hostnames in public certificates. A wildcard certificate covers subdomains without naming each one, which keeps individual names out of the log — at the cost of one key covering more, so it is a trade rather than a free win. The stronger move is not to publish internal services on public names at all.
6. Read your own certificate transparency log occasionally. A certificate you did not ask for is worth knowing about early, and so is one a supplier issued for a subdomain nobody told you about.
7. Publish a security.txt file at /.well-known/security.txt (RFC 9116) with an address that reaches a person. Someone who finds a problem with your systems currently has nowhere to send it, and the second-best outcome is that they give up.

Checking your own, in about ten minutes

All of this is public, so you can do it yourself, right now, without any tool we sell.

If you would rather someone read it back to you in plain language, that is precisely what our free snapshot is: a domain and a work email in, a written report out, in one to two business days.

Is it legal for anyone to look at this?

Kenya's Computer Misuse and Cybercrimes Act 2018, as amended in 2025, draws the line in a place worth understanding — because it is the same line we work inside. Reading information that is already published infringes no security measure and is lawful. Connecting to somebody else's system to test it is a different act, and it requires their written authorisation.

Kenya has no responsible-disclosure safe harbour, and probing systems classed as protected — hospitals and payment systems among them — carries penalties of up to KES 25 million and 20 years. That is why a stranger reading your public records is doing something ordinary, and why anyone offering to "test" your systems without a signed authorisation is offering you a problem rather than a service.

If you find something with wider public consequences, the route in Kenya is the national response team, KE-CIRT, rather than a public post.

What we do with it, and what we do not

This is the material Reconesys works from. We read public records — DNS, mail records, certificate transparency logs and the domain registry. We never connect to your website or servers, never log in, and never test your defences.

One honest qualification, because the absolute version of that sentence would be false. Looking up a domain asks whichever name servers are authoritative for it, and those may be machines you or your provider run. So we will not tell you that nothing of ours ever reaches anything of yours. What is true is narrower and still strong: the only contact is a public DNS lookup of the same kind every mail server on the internet makes to find you, and nothing we do opens a connection to your website, your ports or your applications. Anyone claiming their outside-in check reaches nothing of yours at all is describing something that cannot be done.

Checks that would require connecting to your systems — what your live website actually serves, how your TLS is configured — stay switched off until you prove you control the domain or give us written authorisation. That is not a policy we could quietly change; it is enforced in our software.

The free snapshot is one domain, one report, written by a person and sent in one to two business days, with a rating, the three issues that matter most and a 30-day plan. It is not a penetration test. It is not monitoring — it is a picture of one day, and nothing will alert you if something changes afterwards. And it does not make your business compliant with the Data Protection Act.

• Read the worked sample report and judge it before giving us anything.
• Exactly what the snapshot covers — what it does not, at the same length, and why a person reads every report before it is sent.
• What the fix sprints cost, if you would rather the work were done for you than done by you.
• Where this sits in the Data Protection Act, if you are being asked for evidence.