Reconesys Nairobi

Illustrative sample · fictional business · invented records

Bahari Court Hotel

What a stranger can already see about your hotel online, read from public records. We never connect to your website or servers, never log in, and never test your defences.

Client
Bahari Court Hotel, Westlands, Nairobi
Domain
baharicourt.example
Type
Passive exposure snapshot
Report date
25 July 2026
Collected
24 Jul 2026 · 09:12–09:16 EAT
Reference
RX-SNAP-2026-0731
Prepared by
Reconesys · Nairobi
Reviewed by
A Reconesys analyst before release

Navigation

Contents of this report

The collection log

_dmarc → NXDOMAIN. No policy exists, so no receiving mail server has been told what to do with a message that fakes this address. Finding 01, high.

SPF → PermError. Fourteen lookups against a limit of ten. Receivers that hit that error treat the result as neutral — the same as publishing nothing. Finding 02, high.

A second MX on bookings. A mail route outside the managed platform, and the easiest name the hotel owns for an outsider to impersonate. Finding 03, high.

Everything in this report is read from these eight lines

Public records · baharicourt.example · 24 Jul 2026 09:12–09:16 EAT $ dig +short · crt.sh · rdap.org
MX · apex
1 aspmx.l.google.com · 5 alt1 · 5 alt2 · 10 alt3 · 10 alt4
MX · bookings
0 mail.kilifihost.example — a second mail path, no SPF at that name
TXT · SPF
v=spf1 a mx ptr include:… ~all → 14 lookups, limit 10 → PermError
TXT · _dmarc
NXDOMAIN — no policy published
DKIM
17 common selectors probed via DNS, all NXDOMAIN
CT log
31 certificates · 19 unique names · incl. pms-test, vpn, cctv
CAA
no records — any authority may issue for this domain
RDAP
transfer, delete and update locks set · expires 2027-04-12

Eight records, four public sources, no contact with the hotel’s own systems beyond the DNS lookup any mail server makes. Six lines are flagged; two are already right. Appendix B has all of it, unedited.

01 Executive summary

Bands are fixed: A 0–14, B 15–29, C 30–49, D 50–69, E 70–100. A lower number is better.

Rating model v1.0.0 · rule catalogue v1.0.0.

Where Bahari Court Hotel stands today

Bahari Court Hotel shows an Exposed posture in the part of the picture we can see from outside: multiple weaknesses that increase the likelihood of a preventable loss.

Confidence Moderate — capped by the free tier. No questionnaire was completed, and the checks that need your permission were not run.

  1. AStrong0–14
  2. BManageable15–29
  3. CExposed This report30–49
  4. DHigh risk50–69
  5. ECritical70–100

The three reasons for this rating

  1. Nothing stops someone sending email that appears to come from your hotel. There is no DMARC policy published at all, and the SPF record you do have cannot be evaluated by receiving mail servers — so in practice it protects nothing.

  2. A second, older mail route exists on bookings.baharicourt.example that sits outside your main managed email platform and has no sender protection of its own.

  3. Public certificate logs list nineteen hostnames under your domain, including names like pms-test and cctv that describe your internal systems to anyone who looks — and two names whose certificates lapsed and were never renewed.

02 Headline snapshot

The numbers, and what we could not measure

Our rating model has three components. A free snapshot can only compute one of them. We show the other two as not assessed rather than guessing — a blank is honest, a zero would be an invention.

External exposure

41.3/ 100

Higher means more exposed. Drawn from mail posture, domain footprint and record hygiene. Component weight 40, renormalised to 100 because the other two components were not assessed.

The three rating components, and why two of them are blank
Component Result Weight Why
External exposure 41.3 / 100 40 → 100 Computed. Everything visible from public records: mail posture, domain footprint and record hygiene.
Internal readiness Not assessed 35 → excluded Backups, MFA, device handling, incident response and staff practice cannot be seen from outside. There is no questionnaire at this tier.
Mobile-first operational risk Not assessed 25 → excluded M-Pesa dependence, SIM-swap exposure, OTP recovery and front-desk assisted payment flows need a short sector questionnaire.

Excluded, not zeroed. A zero would assert that we looked and found nothing; a blank says we did not look.

How 41.3 was calculated

The external exposure component has five areas. Three can be read from public records; two need you to verify that you control the domain. The two unread areas are excluded and the remaining weights renormalised. Every number below is arithmetic you can check with a calculator.

External exposure: area weights, sub-scores and the contribution of each
Area Weight Sub-score Renormalised Contribution
Mail authentication 33 52 / 100 33 ÷ 56 = 58.9% 30.64
Domain footprint 17 28 / 100 17 ÷ 56 = 30.4% 8.50
Record hygiene 6 20 / 100 6 ÷ 56 = 10.7% 2.14
Live TLS behaviour 22 Not assessed excluded —
Website exposure 22 Not assessed excluded —
Total 100 56 collected 100% 41.3

Evidence basis

This rating rests on 56% of the evidence weight a verified domain would carry. Two exposure areas — live TLS behaviour and website exposure, 22 points of weight each — are missing because the free tier does not connect to your servers, not because we tried and failed. Nothing failed to collect on this run.

Headline snapshot: what each part of the rating shows, and what could not be measured
Area Result Comment
Overall rating C — Exposed Multiple weaknesses that raise the likelihood of a preventable loss. No evidence of an active compromise was collected, and none was looked for.
Confidence Moderate Capped at moderate for every free snapshot: no internal questionnaire, and two exposure areas are outside what we may collect without your permission.
External exposure score 41.3 / 100 Mail authentication is the dominant contributor at 52/100; domain footprint 28/100; record hygiene 20/100.
Internal readiness score Not assessed No questionnaire is collected at this tier. Excluded from the calculation rather than scored zero — we have no evidence either way.
Mobile-first operational risk Not assessed Same reason. For a hotel taking M-Pesa deposits this is a real gap in the picture, and it is the part a short conversation would close fastest.
Findings raised 13 issues · 4 strengths 3 high, 4 medium, 4 low, 2 informational. All from public records.

Wide tables scroll sideways on a narrow screen.

03 Top three issues

Thirteen issues were raised. These three carry most of the risk; the remaining ten are grouped in Appendix A so they do not compete for your attention.

Ranked by what they cost you, not by how technical they are

  1. 01

    Anyone can send email that looks like it came from your hotel

    High

    Why it matters — money and trust. Your domain publishes no DMARC policy, so no receiving mail server has been told what to do with a message that fakes your address. The SPF record that exists needs more DNS lookups than the standard permits, which makes it fail to evaluate — receivers treat that as “no answer”, so it is not filling the gap either. The practical result is that a fake “Bahari Court Hotel” invoice, deposit request or booking confirmation has a good chance of landing in an inbox looking legitimate. Hotels are a standard target for this because deposits are routine and the counterparty is usually a stranger.

    Urgency
    High — start this week
    Owner
    Whoever administers your email, or your IT provider
    Effort to fix
    Low to start, medium to finish
    Cost shape
    None — DNS changes are free
  2. 02

    Your booking mail has a second route through an old shared server

    High

    Why it matters — operations and guest data. Your main domain receives mail through a well-known managed platform, which is good. But bookings.baharicourt.example has its own separate mail record pointing at a shared hosting server, with no sender protection published for that name. Two consequences follow. First, guest correspondence — names, dates, phone numbers, sometimes card or ID details — may be sitting on a mailbox that is not covered by the controls you think apply. Second, it is the easiest name for an outsider to impersonate, because it is the one with nothing in front of it. Under Kenya’s Data Protection Act you are accountable for personal data wherever it sits, including on a server somebody set up years ago and forgot.

    Urgency
    High — decide within 30 days
    Owner
    Internal IT with your hosting provider
    Effort to fix
    Medium
    Cost shape
    Low — usually a migration, not a purchase
  3. 03

    Public certificate logs describe the shape of your internal systems

    Medium

    Why it matters — identity and operations. Every time a certificate is issued for one of your hostnames, that name is written into a public, permanent, searchable log. We found nineteen names under your domain, including pms-test, staff-portal, vpn and cctv. Individually harmless; together they hand an outsider a map of what you run and what to aim a phishing email at. Two of those names have certificates that expired and were never renewed, which usually means a system was retired without being cleaned up — or is still running with an expired certificate. We did not connect to any of them, so we cannot tell you which. The important honest point: certificate logs cannot be un-published. The fix is not to hide the names, it is to know which are still live, retire what is dead, and stop naming internal systems descriptively in public.

    Urgency
    Medium — inventory within 30 days
    Owner
    Internal IT
    Effort to fix
    Medium — mostly discovery
    Cost shape
    Low

04 What is already working

A report that only lists problems is a sales document, not an assessment. These reduce your risk today, and they change the shape of the fix — you are consolidating, not starting from nothing.

Four things you are doing right

  1. Main email is on a reputable managed platform

    Your apex mail records point to a major managed provider with correct priorities and no stray or misordered entries. Spam filtering, patching and platform security are handled by people who do it full time. This is the single most valuable thing a small business can get right about email, and you have it.

  2. An SPF record already exists and names your real senders

    It lists four sending services that look like genuine business tools. The hard part of this job — working out who legitimately sends mail as you — has largely been done. The fix is consolidation to bring it under the lookup limit, not investigation from scratch.

  3. The domain registration is locked

    The public registration record shows transfer, delete and update locks set. That is real protection against a domain hijack, which is the worst single thing that can happen to a business’s online identity. Registration also runs to April 2027, so there is no expiry cliff approaching.

  4. No sign of certificate mis-issuance

    All 31 certificates in the public log come from two well-known certificate authorities consistent with your hosting. We saw no certificate issued for your domain by an unexpected party — one of the earlier signals of an attempted takeover.

05 What this means

Written for the owner, not for the IT provider. Every technical term in this section is explained where it first appears.

In plain language

Everything in this report was read from public records: the internet’s address book (DNS), your mail records within it, the public log of certificates issued for your name, and the public registry entry for your domain. We never connected to your website or servers, never logged in, and never tested your defences. That is a deliberate limit, and it means this is a view of your front door from the street — informative, but not the whole house.

From the street, the clearest weakness is your email identity. Your domain is your name in every transaction you do by email, and right now that name is not protected by the two mechanisms the rest of the internet uses to check it. Nobody has to break into anything to exploit that; they simply send a message that says it is from you. The realistic scenarios are ordinary and expensive: a fake deposit request to a corporate client, a supplier invoice with altered payment details, a “booking confirmed” message to a guest that harvests card data, or a message to your own front desk that appears to come from the general manager. Kenyan businesses lost an estimated KES 29.9 billion to cybercrime in 2024/25, and this category — business email compromise — is consistently among the biggest contributors because it needs no technical skill and works on trust.

The second theme is drift. A second mail path on an old shared server, two hostnames whose certificates lapsed and were never renewed, and two different spellings of your booking hostname all point to the same ordinary story: systems were added over the years, people moved on, and nobody has drawn the map recently. Drift is not negligence, but it is where incidents start, because nobody defends a system they have forgotten they own. It also matters directly for the Data Protection Act: you cannot show a regulator that guest data is protected if you cannot say where it is.

What changes if you act on the plan overleaf: within a week you will be able to see who is sending email in your name, which is information you have never had. Within a month, the mail identity problem is closed and your published record is defensible — the single largest contributor to your current score, worth roughly thirty of the forty-one points. The map of your own estate is the slower job, but the first pass is an afternoon’s work with the list in Appendix B. None of this requires new software or a new supplier.

06 The next 30 days

Four weeks, in order, with the reasons for the order

Sequence matters here. Publishing DMARC in monitoring mode first is what makes the SPF and DKIM work safe — you get to see the effect of each change before you enforce anything.

The 30-day plan: one action per week, in the order they should be done
Week Action Effort Cost Owner
1 Publish a DMARC record in monitoring mode. One TXT record at _dmarc.baharicourt.example with p=none and a reporting address. It changes nothing about how your mail is delivered — it only asks the world to tell you what is being sent in your name. Low~30 min None Email administrator
2 Rebuild the SPF record so it can actually be evaluated. Get it under the 10-lookup limit by dropping services you no longer use, removing the redundant a, mx and deprecated ptr mechanisms, and flattening where a provider supports it. Keep the soft-fail ending until week 4. Medium~2 hrs None Email administrator or provider
3 Turn on DKIM signing, and decide the fate of the second mail path. DKIM is a switch in your mail platform’s admin console plus one DNS record. In parallel: does bookings. still need its own mailbox server? Migrate it onto the managed platform, or shut it down and forward the address. Medium~half day Low Email administrator + hosting provider
4 Inventory the nineteen hostnames, then tighten DMARC. Walk the list in Appendix B and mark each name live, retired or unknown; decommission what is dead. Once the week-1 reports show every legitimate sender passing, move DMARC to p=quarantine. Add a CAA record while you are in the DNS console. Medium~half day None Internal IT

07 Issue detail and fixes

Every issue carries two fixes. The preferred one closes it; the fallback is what to do when nobody has a spare afternoon this month.

The three headline issues, with the preferred fix and a cheaper fallback

Issue 1 — Email identity is unprotected High

Two separate mechanisms are meant to let a receiving mail server check that a message claiming to be from your domain really is. Neither is working. There is no DMARC record at all, and your SPF record requires 14 DNS lookups to evaluate against a hard limit of 10, which produces a permanent error — receivers that hit that error treat the result as neutral, which is the same as having published nothing. No DKIM signing key was found on any of the 17 common selector names we tested.

Business effect

Impersonation of your reservations, accounts and management addresses is currently cheap and reliable. The losses that follow are usually a redirected deposit, an altered supplier invoice, or guest card details harvested through a convincing “confirm your booking” message. The second-order cost is a data-protection incident you would have to notify within 72 hours, and a guest-trust problem that outlasts the money.

Preferred fix

Publish DMARC at p=none with an aggregate reporting address today. Rebuild SPF into a single evaluable record under the lookup limit, dropping unused senders and the deprecated ptr mechanism. Enable DKIM signing in the mail platform and publish the selector record. After two to four weeks of clean reports, move DMARC to p=quarantine and then to p=reject, and change SPF from ~all to -all only at that point.

Lower-cost fallback

If nobody has time for the full sequence, do the single highest-value step: publish the DMARC record at p=none. It takes half an hour, cannot break your mail, and turns an invisible problem into a weekly report you can act on when there is time.

Issue 2 — A second mail path outside your managed platform High

bookings.baharicourt.example publishes its own mail record pointing to a shared hosting server, separate from the managed platform serving your main domain. That subdomain publishes no SPF record of its own, and because there is no organisational DMARC policy at the apex, nothing covers it by inheritance either.

Business effect

Guest correspondence may be stored somewhere outside the controls you believe apply — and outside whatever backup and access rules you rely on. It is also the softest name to impersonate. From a Data Protection Act standpoint, a mailbox you have forgotten about is still personal data you are accountable for, and “we did not know it was there” is not a defence a regulator accepts.

Preferred fix

Establish who uses that address and what is stored on it. Migrate the mailbox onto your managed platform, remove the old mail record, and let the subdomain inherit the same protections as everything else. Export and retain only what you have a business reason to keep.

Lower-cost fallback

If the migration cannot happen quickly, publish a restrictive SPF record for that subdomain naming only the shared host, and set an explicit subdomain policy in your DMARC record once it exists. That contains the impersonation risk while you plan the move — it does not address the data-location question.

Issue 3 — Nineteen hostnames are publicly listed, and some are stale Medium

Certificate transparency is a public, append-only log of every certificate issued by a trusted authority. Searching it for your domain returns 31 certificates covering 19 distinct hostnames — including pms-test, staff-portal, vpn, webmail, and a cctv name whose certificate expired in November 2024 and was never renewed. There are also two spellings of your booking host, booking. and bookings., which suggests at least one is a leftover.

Business effect

Two effects, one immediate and one slow. Immediately, this is a targeting list: a phishing message referencing your actual staff portal is far more convincing than a generic one. Slowly, the stale names indicate systems nobody owns any more — the standard starting point for an incident, because unowned systems do not get updated. We cannot tell you whether the lapsed names are retired or simply running on expired certificates, because answering that requires connecting to them, which we did not do.

Preferred fix

Take the list in Appendix B and mark every name live, retired or unknown. Decommission the retired ones and remove their DNS entries. For genuinely internal systems, stop issuing public certificates with descriptive names — use a wildcard certificate or an internal-only name so the log stops advertising your estate. Do this once properly and keep the list.

Lower-cost fallback

Do the inventory and nothing else. Even a spreadsheet of nineteen rows with an owner’s name against each one closes most of the practical risk, because the danger is not that the names are public — it is that nobody knows which are still running.

08 The Kenyan context

Why a hotel in particular should care

These are facts about the law and the current enforcement position, stated neutrally. They are not predictions about your business, and nothing in this report suggests you are under investigation.

Kenyan legal and enforcement context, with the source of each
Fact Where it comes from
Hospitality firms must register with the Office of the Data Protection Commissioner regardless of size. Registration fees run from KES 4,000 for micro and small businesses to KES 40,000 for large ones; a certificate lasts 24 months. Data Protection Act 2019; Data Protection (Registration of Data Controllers and Data Processors) Regulations 2021, Third Schedule
Administrative penalties reach KES 5,000,000 or 1% of annual turnover, whichever is lower, per infringement. Data Protection Act 2019
Enforcement is active in this sector: a Nairobi hospitality business was fined KES 1.85M in September 2023, and the regulator has announced hospitality-sector inspections. ODPC enforcement determinations and public statements
Obligations include security safeguards, audit trails and event monitoring, “regularly reviewing and testing software to uncover vulnerabilities”, and breach notification within 72 hours. Data Protection Act 2019 and its regulations
Kenya’s national response team recorded 4.56 billion cyber threat events in Q4 2025 and 3.37 billion in Q1 2026. Communications Authority / KE-CIRT quarterly reports

A Technical findings

All thirteen findings, with evidence

Every finding below is derived from one of the four permitted passive sources: public DNS records, mail records within DNS, public certificate transparency logs, or the public domain registry read over RDAP. Severity reflects business impact, ease of abuse, exposure and fixability together — not a raw vulnerability score.

Appendix A: all thirteen findings, with the evidence, severity, confidence and both fixes for each
Finding Evidence Severity Confidence Preferred fix Lower-cost fallback
No DMARC policy publishedmail.dmarc.absent _dmarc.baharicourt.example TXT → NXDOMAIN (resolver 9.9.9.9, 2026-07-24 09:12:38 EAT; authority SOA serial 2026061801) High High Publish v=DMARC1; p=none; rua=mailto:…, then escalate to quarantine and reject once reports are clean Publish the monitoring-only record and read the reports monthly
SPF record exceeds the DNS lookup limit and fails to evaluatemail.spf.permerror 14 lookups required, limit 10 (RFC 7208 §4.6.4). Expansion: a=1, mx=1, ptr=1, _spf.google.com=4, spf.protection.outlook.com=3, mailgun.org=2, _spf.mailjet.com=2 High High Rebuild as one record under 10 lookups; drop unused senders; remove a, mx, ptr Remove the two least-used includes to get under the limit today
Second mail path on a subdomain, outside the managed platformmail.mx.split_path bookings.baharicourt.example 14400 IN MX 0 mail.kilifihost.example. — no TXT SPF record at that name High High Migrate the mailbox to the managed platform and remove the MX record Publish a restrictive SPF for the subdomain and set an explicit DMARC subdomain policy
No DKIM signing key found on any tested selectormail.dkim.no_selector_found 17 common selectors probed via DNS, all NXDOMAIN — incl. google, default, selector1, selector2, s1, s2, k1, mail, dkim, smtp (full list in Appendix B) Medium Moderate Enable DKIM in the mail platform admin console and publish the selector record Same — there is no cheaper version; it is a switch and one DNS record
Public certificate log exposes internal system namesfootprint.ct.internal_naming crt.sh query %.baharicourt.example, 2026-07-24 09:13:55 EAT → 31 certificates, 19 unique names incl. pms-test, staff-portal, vpn, cctv Medium High Inventory and decommission; use a wildcard or internal-only names for internal systems Inventory only — record every name with an owner
Two hostnames with lapsed certificates, never renewedfootprint.ct.stale_name cctv.baharicourt.example — last cert expired 2024-11-17; old.baharicourt.example — last cert expired 2021-03-01. Liveness not checked. Medium Moderate Confirm each system is retired, then remove its DNS records Ask whoever set them up; record the answer
SPF terminates in soft-failmail.spf.softfail_all Record ends ~all. Receivers are asked to accept-and-mark rather than reject unauthorised senders. Medium High Move to -all once DMARC reporting confirms every legitimate sender passes Leave as-is until DMARC data exists — changing this first can break delivery
Look-alike domain name observed in certificate logsfootprint.ct.similar_name bahari-court.example — 1 certificate issued 2026-05-30, expires 2026-08-28. No other data collected; site not visited. Low Moderate Identify the owner. It may be a partner, a former agency, or unrelated — we have no evidence of misuse Ask your marketing and booking partners whether it is theirs
Deprecated ptr mechanism in SPFmail.spf.deprecated_ptr Token ptr present. RFC 7208 §5.5: SHOULD NOT be published; slow and unreliable to evaluate. Low High Remove it during the SPF rebuild — it also recovers a lookup Same
No CAA record — any certificate authority may issue for your domainhygiene.caa.absent baharicourt.example CAA → no records returned (2026-07-24 09:12:44 EAT) Low High Publish a CAA record naming only the authorities you actually use Same — one record, five minutes
Both nameservers sit with a single providerhygiene.ns.single_provider ns1.serengeti-dns.example, ns2.serengeti-dns.example — same operator, same network Low High Add a secondary DNS provider if your booking flow cannot tolerate a DNS outage Accept the risk knowingly; note it in your continuity plan
No MTA-STS or TLS reporting policy publishedmail.mtasts.absent _mta-sts.baharicourt.example TXT → NXDOMAIN; _smtp._tls.baharicourt.example TXT → NXDOMAIN Info High Optional once DMARC is enforced; most managed platforms support it with a policy file Skip — this is a refinement, not a gap
Domain is not DNSSEC-signedhygiene.dnssec.unsigned No DS record at the parent zone; AD flag not set on authoritative answers Info High Enable signing at your DNS provider if they support it as a one-click option Skip — low practical benefit for a business of this size today

Severity is assigned by rule catalogue v1.0.0. Confidence reflects how directly the evidence supports the conclusion: “moderate” on the DKIM finding because selector names cannot be enumerated from DNS — we can only test known ones, so a key on an unusual selector would not be seen.

B Evidence log

The raw records, exactly as collected

Everything below is public. Reproduce any of it yourself with dig or a public lookup site — none of it requires our tools or our permission.

B.1 — Mail records

; apex MX — 2026-07-24 09:12:31 EAT · resolver 9.9.9.9
baharicourt.example.      3600  IN  MX   1 aspmx.l.google.com.
baharicourt.example.      3600  IN  MX   5 alt1.aspmx.l.google.com.
baharicourt.example.      3600  IN  MX   5 alt2.aspmx.l.google.com.
baharicourt.example.      3600  IN  MX  10 alt3.aspmx.l.google.com.
baharicourt.example.      3600  IN  MX  10 alt4.aspmx.l.google.com.

; subdomain MX — separate mail path, 09:12:35 EAT
bookings.baharicourt.example. 14400 IN MX 0 mail.kilifihost.example.
bookings.baharicourt.example.       TXT  → no SPF record present

; SPF — 09:12:41 EAT
baharicourt.example.  3600  IN  TXT  "v=spf1 a mx ptr include:_spf.google.com
    include:spf.protection.outlook.com include:mailgun.org
    include:_spf.mailjet.com ~all"
  → DNS lookups required: 14   (limit 10, RFC 7208 §4.6.4)
  → evaluation result:    PermError  — receivers treat as neutral

; DMARC — 09:12:38 EAT
_dmarc.baharicourt.example.  TXT  → NXDOMAIN
  authority: baharicourt.example. SOA hostmaster.serengeti-dns.example. 2026061801

; DKIM selectors probed via DNS — 09:12:52 EAT — all NXDOMAIN
  google  default  selector1  selector2  s1  s2  k1  k2  mail  dkim
  smtp    mandrill  mailjet   mxvault    zoho  everlytickey1  pic

; MTA-STS / TLS-RPT — 09:12:58 EAT
_mta-sts.baharicourt.example.    TXT  → NXDOMAIN
_smtp._tls.baharicourt.example.  TXT  → NXDOMAIN

B.2 — Domain and nameserver records

; NS and CAA — 2026-07-24 09:12:44 EAT
baharicourt.example.  86400  IN  NS   ns1.serengeti-dns.example.
baharicourt.example.  86400  IN  NS   ns2.serengeti-dns.example.
baharicourt.example.         IN  CAA  → no records
baharicourt.example.         DS  at parent → none (zone unsigned)

; RDAP registration record — public registry data, 09:13:10 EAT
  created:      2016-04-12
  expires:      2027-04-12
  status:       clientTransferProhibited, clientDeleteProhibited,
                clientUpdateProhibited
  registrant:   redacted by registrar privacy service
  nameservers:  ns1/ns2.serengeti-dns.example

B.3 — Certificate transparency: 19 names across 31 certificates

Source: public certificate transparency log index (crt.sh), queried 2026-07-24 09:13:55 EAT. A row here proves a certificate was issued for that name. It does not prove the host is live, reachable, or running anything — confirming that requires connecting to it, which we did not do. Use this as your inventory worksheet.

Appendix B.3: the nineteen hostnames seen in public certificate transparency logs, as an inventory worksheet
Hostname First seen Latest certificate Assessment note
baharicourt.example 2016-05-02 valid to 2026-09-12 Expected — main site
www.baharicourt.example 2016-05-02 valid to 2026-09-12 Expected
booking.baharicourt.example 2022-06-11 valid to 2026-08-30 Expected — but see the next row
bookings.baharicourt.example 2023-01-19 valid to 2026-10-04 Two spellings of the same thing. One is probably a leftover; this is also the name with the separate mail path
webmail.baharicourt.example 2016-05-02 valid to 2026-09-12 Review — is a web mail interface still needed on the old host?
staff-portal.baharicourt.example 2024-05-22 valid to 2026-09-20 Review — a named staff login is a phishing target; confirm it enforces MFA
vpn.baharicourt.example 2025-11-03 valid to 2026-08-01 Review — remote access endpoints deserve deliberate ownership. Liveness not checked
pms-test.baharicourt.example 2026-02-14 valid to 2026-08-14 Names a test property-management system in public. Test systems often hold copies of real guest data and get less attention
cctv.baharicourt.example 2024-08-19 expired 2024-11-17 Stale. Either retired without cleanup, or still running on an expired certificate. We cannot tell from outside
old.baharicourt.example 2020-11-30 expired 2021-03-01 Stale. Almost certainly a migration leftover — confirm and remove the DNS entry
+ 9 further names (mail, autodiscover, cpanel, cpcalendars, cpcontacts, whm, ftp, dev, staging) — routine hosting-panel and development names, listed in the machine-readable export

C Limits

This is the most important page in the report. A snapshot that overstates its own reach is worse than no snapshot, because it lets you believe you have been checked when you have not.

What was not tested

The sources this report is permitted to use

A free snapshot has a fixed ceiling, and these four public sources are all of it. Every finding in this report traces to one of them.

  • Public DNS records — A, AAAA, MX, NS, TXT, CNAME and SOA for your domain and its subdomain labels. The internet’s public address book.

  • Mail posture derived from those DNS records — SPF including its include-chain, DMARC, and DKIM selector testing done as DNS lookups only.

  • Certificate transparency logs — queried at a public third-party log index, never at your systems.

  • The public domain registry, read over RDAP — creation and expiry dates, registrar lock status and nameserver delegation. This is the registry’s own published record of your domain, not something read from you; it is what tells us your locks are set and your registration runs to 2027.

That list is a ceiling, not a summary of what we felt like doing. Everything past it — a TLS handshake, an HTTP request, a port probe, a login — needs you to verify that you control the domain, or to authorise us in writing.

This report is not, and does not contain

  • Not a penetration test. Nothing was attacked, exploited, bypassed or logged into.

  • Not a vulnerability scan. No port was probed, no service was fingerprinted, no software version was identified.

  • Not a security audit or a compliance certificate. No control was verified against a standard, and no auditor’s opinion is expressed.

  • Not proof that no other problems exist. Absence of a finding here means we did not see it from outside — nothing more.

Specifically not checked

  • Your website and booking engine. We made no HTTP request. We do not know what software they run, whether they are patched, or how they handle guest data.

  • Your TLS and certificates in practice. We performed no TLS handshake. We know what certificates were issued; we do not know what your servers actually present, which protocol versions they accept, or whether any certificate is expired in use.

  • Whether any of the nineteen hostnames is live. Confirming that requires connecting to them.

  • Your internal systems. Property-management system, point-of-sale, Wi-Fi (guest or staff), CCTV, door locks, payment terminals, back-office computers, and every device on your premises — all outside a passive external view entirely.

  • Your staff accounts and passwords. No account was tested, no credential was checked, no breach database was queried against your staff.

  • Your M-Pesa, SIM and OTP workflows. The mobile-first risks that matter most to a Kenyan hotel — SIM-swap exposure, front-desk assisted payments, PIN handling, recovery flows — are process questions. They need a conversation, not a scan.

  • Your backups, MFA, incident response and staff training. Not visible from outside by any means.

  • Your ODPC registration and data-protection documentation. We did not look, and this report says nothing about your compliance status.

D Coverage

This snapshot versus a full assessment

Presented so you can judge whether the missing 44% of the evidence weight matters for your decision. Sometimes it does not.

What each level of assessment looks at: this free snapshot, a verified domain, and a full assessment
What gets looked at This free snapshot After you verify the domain Full assessment
DNS records, mail posture (SPF, DKIM, DMARC, MX) Yes Yes Yes
Certificate transparency and domain footprint Yes Yes Yes
Public registration record and record hygiene Yes Yes Yes
Live TLS behaviour — what your servers actually present No Yes Yes
Web exposure — exposed panels, admin interfaces, stray services No Yes Yes
Which of your hostnames are actually live No Yes Yes
Internal readiness — backups, MFA, devices, incident response No No Yes — questionnaire
Mobile-first risks — M-Pesa, SIM swap, OTP, assisted payments No No Yes — sector module
Rating confidence achievable Moderate at best Moderate High
What unlocks it Nothing — it is free One DNS record, ~5 minutes, no charge A written authorisation and a scoped engagement

Verifying your domain does not commit you to buying anything, and it does not sign you up for monitoring. It changes what we are legally permitted to look at, nothing else.

E Next step

Two ways forward — one paid, one free

Both close the same issue. Choose on whether you would rather spend money or spend an administrator’s afternoon. We would genuinely rather you fixed it yourself than not at all.

Recommended · Fix Sprint One-time

Email & Domain Shield

$199

≈ KES 25,700 · fixed scope

  • DMARC published, monitored, and escalated to enforcement once the reports are clean
  • SPF rebuilt into a single evaluable record under the lookup limit
  • DKIM signing enabled and verified end to end
  • The second mail path resolved — migrated or closed, with you deciding which
  • CAA record added; the nineteen-name inventory handed over as a worksheet
  • A re-run of these checks afterwards, with a written before-and-after

Typically five working days. Fixed price — not an hourly engagement. Payable in KES by M-Pesa.

Do it yourself No charge

The 30-day plan, unassisted

Free

≈ one administrator-day of your own time

  • Section 06 is the complete instruction set, in order, with the reasoning for the order
  • Every change is free at your existing DNS and mail providers — no product to buy
  • Appendix B has the exact records so you can verify each change yourself
  • The one warning that matters: do not enforce DMARC before you have read the reports

When you are done, request another free snapshot and we will send you the updated rating at no charge. We would rather you were fixed than billed.

Get a free snapshot for your own domain See how a snapshot is produced

F Data handling

What we collected about you, and how to make us delete it

How Reconesys handled the data behind this report, and how to have it deleted
Question Answer
What did you collect? Public DNS records for baharicourt.example and its subdomain labels; the public certificate transparency index for names under that domain; the public RDAP domain registration record. Plus the email address and business name submitted with the request for this report.
Where did it come from? Public DNS resolvers, the public certificate transparency log index, and the public domain registry read over RDAP — all third-party public directories. We read public records — DNS, mail records, certificate transparency and the domain registry. We never connect to your website or servers, never log in, and never test your defences. As Appendix C sets out, resolving your domain can end at your own authoritative nameservers, exactly as any ordinary lookup of your name does; that is the one thing we will not claim otherwise.
What did you deliberately not collect? No personal data of your guests or staff. No email content. No credentials, no passwords, no password hashes. If any string resembling a secret had appeared in a public record, our redaction layer would have removed it before storage — that layer cannot be bypassed by the collection code.
How long do you keep it? The raw collected records are deleted 30 days after collection. This report and the evidence excerpts that back it are kept for 12 months so that a follow-up snapshot can show you what changed. The contact details you gave us are kept until you ask us to delete them.
Who else sees it? A Reconesys analyst reviews every report before it is sent. Nobody outside Reconesys receives it. We do not sell, share or publish findings about a named business, and we do not use your report as a public example without written permission.
How do I get it deleted? Email privacy@reconesys.example with the report reference (RX-SNAP-2026-0731). We delete everything within 7 days and confirm in writing. You do not need to give a reason, and asking costs you nothing.
What if I am unhappy about it? Write to us first — we would rather fix it. You also have the right to complain to the Office of the Data Protection Commissioner under the Data Protection Act 2019.

The one-screen version

A real report ships as a PDF plus a machine-readable findings export. This block exists because the person who has to act on it is usually not the person who received it.

For pasting into an email or WhatsApp

Bahari Court Hotel — external exposure snapshot, 25 July 2026

Rating: C (Exposed) with moderate confidence. External exposure 41.3/100.

Top three issues:

  • No DMARC policy, and the SPF record fails to evaluate — anyone can send email as us.
  • A second mail route on bookings. sits outside our managed platform with no protection.
  • Nineteen hostnames are listed in public certificate logs, including test and CCTV systems; two are stale.

Top three actions for 30 days:

  • Week 1 — publish DMARC at p=none with a reporting address. Half an hour, free, cannot break mail.
  • Week 2–3 — rebuild SPF under the 10-lookup limit and turn on DKIM.
  • Week 4 — inventory the nineteen hostnames; tighten DMARC once the reports are clean.

Limits: a passive external snapshot read from public records only — DNS, mail records, certificate transparency logs and the domain registry. Reconesys never connected to our website or servers, never logged in and never tested our defences. It is not a penetration test, a vulnerability scan or a compliance certificate.