Docs

How Domainly verifies a domain.

How we verify a domain

  1. 1. Domain shape

    We normalize whatever you type — lowercasing it, stripping any scheme, path, port, or trailing dot — then check it's a syntactically valid DNS name before anything else runs.

  2. 2. Public suffix boundary

    We reject domains that are themselves a — a like co.uk that many independent registrants sit below, or a hosting/CDN provider's shared DNS zone like vercel.app. Claiming one of those would imply authority over every domain beneath it, not just yours.

  3. 3. DNS delegation

    Before we hand you a token, we confirm the domain is — it needs working nameservers before it's able to serve the we're about to ask for.

  4. 4. The TXT challenge

    We generate a one-time token and ask you to publish it as a at a Domainly-specific name (_domainly-verify.yourdomain.com), never at your domain's apex — so it can't collide with your other DNS records and can't be mistaken for anyone else's challenge.

  5. 5. DNSSEC validation

    Every DNS lookup we perform — delegation and the TXT challenge alike — goes through a resolver that validates signatures. If your domain is signed and its records fail to validate, we treat that answer as untrustworthy and refuse to confirm the claim, rather than trusting a DNS answer we can't verify. Unsigned domains aren't penalized — DNSSEC is validated when present, never required.

Checking a certificate as a relying party

  1. 1. What you get from your customer

    A domain and a — an opaque secret your customer hands you after their own domain finishes verifying with Domainly. Treat the certificate like a bearer token; there's nothing to parse or decode in it.

  2. 2. The one call you make

    Send both to POST /api/v1/verify with your API token as Authorization: Bearer. A 200 means the certificate matched the domain and was still live — turn the feature on. A 404 means it didn't, for any reason (wrong certificate, already used, expired, or the underlying claim was revoked) — Domainly won't tell you which, so ask your customer for a fresh certificate rather than debugging the old one. Full request and response shapes are on the API page.

  3. 3. Once, not on a loop

    A certificate is single-use: a successful check burns it immediately. Checking the same certificate twice gets you 404 the second time, indistinguishable from one that was never valid. Call it once, right when your customer connects the domain — not as a background job re-checking on a schedule, and not as a retry if your own downstream write fails.

  4. 4. What you never see

    No DNS record, no WHOIS data, no mail-sending signal (DKIM, SPF, MX). A 200 only means DNS control was proven at some point — it says nothing about who's on paper as the registrant, whether the domain currently resolves to anything, or whether mail is configured correctly. If your product needs those checks, run them yourself.