Skip to main content
A check is three questions, and only the first one decides whether you are proved. The other two exist so that a “no” arrives with a reason attached instead of on its own.

What does the internet see?

ownsi asks three public resolvers — Google, Cloudflare and Quad9 — for the TXT records on _ownsi-challenge.acme.com, at the same time. Majority of three wins.These are the resolvers the rest of the world actually uses, which is the point. A record that only your own nameservers know about is not published yet, and calling that “proved” would be proving something nobody else can check.

If they say no — what do your nameservers say?

Only when the answer was negative. ownsi goes to the nameservers your domain is actually delegated to and asks them directly.This is the question that separates “you have not created the record” from “you created it and the internet has not caught up”. From a public resolver those two look identical, and they need completely different sentences.

Which known problem is this?

Thirteen checks run over what was already collected — no further queries. Each one recognises one specific shape of wrongness: the record on the apex, the domain appended twice, the value in quotes, a CNAME in the way, a previous token still sitting there.Whichever matches produces a named cause and a fix with your domain and your token in them.

The three answers

Every check ends in exactly one of these, and the third is not a worse version of the second.

Found

The token is published and the resolvers agree. You are proved, and the proof is dated by this run.

Absent

The resolvers answered, and your token is not there. This is where a diagnosis or a wait comes from.

No trustworthy answer

ownsi could not read DNS properly. This changes nothing — no state moves, no email is sent, nothing counts against you.
That third one is inert on purpose. A resolver outage on our side must never look like your record disappearing, and must never send you an email saying it did. If DNS breaks for everyone at once, ownsi sends zero emails.

When the next check happens

ownsi picks the moment rather than polling on a fixed timer. It uses how old the claim is, how many checks have come back empty, and one number read from your own zone: how long resolvers cache a “does not exist” for names in it. That last one is why the waiting screen can be specific. If your record was created two minutes ago in a zone that caches negatives for five, then the resolvers will keep saying no for about three more minutes no matter how many times anyone asks — so ownsi says “resolvers forget the ‘does not exist’ in about 3 min” and schedules itself for then. You can always ask for a check now, and there is a button for it. It does not make DNS answer any sooner.

Never both empty

While a domain is not proved, you always have exactly one of two things, and they mean opposite things:
  • A wait. Nothing needs changing. Here is roughly how much longer.
  • A diagnosis. Something needs changing. Here is what.
Never neither, and never both. Working out which one you are looking at.

Once you are proved

Nothing sweeps proved domains on a schedule, and nothing can quietly un-prove one. Prove the same name again later and that is a second proof with its own date — the dates only move forwards. What the proof states, and what it does not.