SiteKensa

Overview

SiteKensa diagnoses how a site and its domain are configured, then lays out what to do next as concrete steps. Rather than stopping at the diagnosis, it identifies both the mail platform and the DNS host in use, and shows which screen to open and what to add there. Development started on 2026-07-25 and the site went live on 2026-07-28. Alongside the diagnosis it carries 36 DNS-host guides, 24 mail-platform guides, and 11 explainer articles. Domain names entered are never stored on the server.

The problem

Existing checkers stop at showing results, and they ask for a DKIM selector as if the user already knew it. Where a record has to be added is decided by the DNS host, yet that side is left unexplained. On top of that, a recursive resolver can answer "not configured" right after a record is added, leaving no way to tell a missing record from one still propagating.

Key features

• Identifies the mail platform from MX and SPF, then tries that service's default DKIM selectors
• Identifies the DNS host from NS records and points to the exact screen, including host-specific pitfalls
• Cross-checks SPF, DKIM, and DMARC to catch contradictions that look fine in isolation
• Compares authoritative nameservers with recursive resolvers to separate "missing" from "still propagating"
• Covers the site side too — TLS certificates, HTTPS canonicalisation, security headers, and robots.txt
• Offers per-record entry points for SPF, DMARC, DKIM, and MX, plus setup guides for nine DNS hosts with real console screenshots
• Leaves values it cannot determine as placeholders instead of asserting a guessed record

Tech stack

Architecture

The diagnosis logic is split between a runtime-agnostic core and Node-only implementations — direct authoritative nameserver queries, TLS certificates, HTTP and security-header checks. DNS resolution goes through DoH, with Google and Cloudflare as fallbacks for each other. The API runs on a Lambda Function URL; the site is a static Next.js export served from S3 + CloudFront + ACM, with infrastructure defined in AWS CDK. There is no database. Diagnosed domains are never stored, and the client IP used for rate limiting is kept only as a salted hash. The Function URL is behind AWS_IAM auth so only CloudFront can reach it, and Lambda's reserved concurrency acts as the ceiling on cost. Rate limiting counts weight proportional to outbound traffic rather than request count, so the fix-and-recheck loop doesn't run into the limit.

AI's role and boundaries

No LLM takes part in the diagnosis itself. The bar is zero false alarms, which means every claim has to trace back to a specific RFC section or a measurement against real domains. The rule against writing numbers or vendor behaviour from guesswork is written into the repository. AI works on the production side — implementation, article structure, and review — and never enters the diagnosis logic. Remove it and the results are unchanged; quality rests on 280 tests in the diagnosis core plus a run against 20–30 real domains for every new finding.

Evaluation & Operations

The site has just launched, so search traffic is still building. The bar is zero false alarms: every new finding is run against 20–30 real domains, and each false alarm found gets a fix and a regression test together. The diagnosis core has 280 tests; a push to main ships only when the core, the frontend, and the infrastructure checks all pass, and the deploy is followed by hitting the live API and every sitemap URL. DKIM selectors are only asserted for services proven against real domains — adding a fixed selector without evidence fails the test suite. The project's own domain is continuously checked with its own diagnosis.