Trust & security

We sell dated, signed evidence about other people's domains. It would be strange to ask you to take our own on faith. This page states what we run, who touches your data, how the signing key is handled — and, at the end, the things we deliberately do not claim.

Everything here is checkable. Where a claim concerns our own domain, you can re-run the check yourself: domainposture.com scores us with the same engine our customers buy.

Who you are contracting with. Domain Posture is built and operated by Hikmah Technologies. The selling entity on an invoice is whichever one took the payment: The Media Inc LLC (United Arab Emirates) for Stripe orders and all subscriptions, Hikmah Technologies (India) for Razorpay orders from India. Tax registrations for both are on the terms page — the detail a vendor-onboarding form asks for.

1. Our own posture

The controls we grade our customers on, applied to us. Verified against live DNS and response headers on 12 August 2026. Two rows are open — we would rather show them than quietly omit them:

MTA-STS sits in testing mode on purpose: it is the mode that reports failures without bouncing legitimate mail, and we move to enforce once the TLS-RPT reports come back clean. A Content-Security-Policy is not yet set. Both are tracked publicly in our issue tracker.

2. The signing key

Every report is signed with an Ed25519 key whose id is drwhome-evp-v1. The public half is published at /.well-known/evidence-pack-pubkey.pem and is the same key our offline verifier uses, so a report can always be checked without touching our servers — see /verify.

• The private half is held in our hosting platform's encrypted secret store and injected into the process at runtime. It is not in the repository, not baked into the container image, and never reachable from the browser.
• It signs a manifest — the domain, the scan timestamp, and the SHA-256 of each artifact — not the PDF layout. That is why branding on a white-label report never changes the signature.
• The key id is part of every manifest, so a future rotation to evp-v2 leaves every already-issued report verifiable against the key it was signed with. We publish superseded public keys rather than withdrawing them.

Rotation follows a written runbook, on a 24-month target cadence or immediately on suspected compromise. Rotating mints a new keypair under a new key id and publishes the new public half alongside the old one — the superseded key stays published, because withdrawing it would silently break every report already in a customer's hands.

3. Data we hold

• Scan results. The DNS, email-authentication and TLS facts we observe about the domains you ask us to check. These are public-DNS observations, not secrets — the same lookups any recipient mail server performs.
• Account and billing records. Your email address, your organisation and client names, orders, and subscription state. Card details are held by Stripe or Razorpay and never reach us.
• Issued reports. The signed PDF/JSON artifacts and their manifests, so a report you were issued stays retrievable and verifiable later.

We scan public infrastructure only. We do not ask for, want, or accept credentials for your systems — no API tokens, no DNS-provider access, no agent installed anywhere. There is nothing of yours for us to lose that is not already public.

Retention is deliberately indefinite. Evidence records are kept as a dated series and are never overwritten, because a report you handed to a reviewer last year has to still resolve and still verify this year — expiring them would break the product's core promise. So we do not offer a bounded retention window. Deletion is available on request and handled manually by a person, not by a self-serve button: email [email protected] or use the address in the privacy policy, and note that deleting a record also destroys the verifiability of any report issued from it.

4. Subprocessors

Third parties that process data on our behalf, and what reaches each one:

The application itself runs on infrastructure operated by Hikmah Technologies, not on a shared platform tenancy.

5. Access + auth

• Customer accounts are passwordless. Sign-in is an emailed one-time link; no public path sets a password, so there is no password of yours for us to store or leak. (Internal administrative accounts use a bcrypt-hashed password, rate-limited, set out of band.)
• Sign-in links never render a page. The emailed link hits a route that moves the token into an httpOnly cookie and redirects before anything is displayed, so a live token is never exposed to page-level analytics or a browser history entry.
• Tenant isolation. Every read of an order, report or schedule is scoped through organisation membership in the query itself, not filtered after the fact.
• Payment webhooks are signature-verified. Entitlement is only ever granted by a webhook whose HMAC signature we have checked; an unconfigured payment gateway fails loudly rather than silently granting access.

6. What we do not claim

A trust page that only lists strengths is marketing. These are the things a reviewer might reasonably want that we cannot honestly assert today:

• We are not SOC 2 or ISO 27001 certified. We help you answer the domain section of those audits; we have not been through one ourselves.
• No third-party penetration test has been performed against this application.
• No formal, published incident-response or business-continuity policy exists yet.
• No multi-factor authentication on customer accounts. The sign-in link goes to your mailbox, so today your email provider's MFA is the control. If you need MFA here, tell us — it is a question of demand, not difficulty.
• No instant session revocation. Sessions are signed tokens rather than server-side records, so signing out clears your browser but a token already issued remains valid until it expires. Tell us if you need a session killed and we will invalidate it by rotating the signing secret.
• No bug-bounty programme. We publish a security contact and we will work with you, but there is no payout scheme.
• We are a very small team. There is no 24/7 on-call rotation. If that is a blocker for your risk assessment, it should be — say so and we will tell you plainly whether we fit.
• A signature is not an audit. It proves a report is unaltered and came from us. It does not make any domain compliant, and it does not replace an auditor.

7. Reporting a problem

If you find a security issue in this service, email [email protected]. Tell us what you found and how to reproduce it. We will acknowledge, keep you posted while we fix it, and credit you if you would like to be credited. We will not threaten you with legal action for reporting in good faith.

For anything else, get in touch. The methodology behind the checks themselves is at /methodology/v1.