# Domain Verification (/docs/domain-verification)



Publishing requires a verified domain. Verification is one file, served over HTTPS, checked from the Voidnet side. Console setup lives under Console → Domains.

## The canonical address [#the-canonical-address]

Serve the verification file with HTTP 200 at:

```
https://YOUR-DOMAIN/.well-known/voidnet-site-verification-<token>.html
```

The root path (`https://YOUR-DOMAIN/voidnet-site-verification-<token>.html`) stays accepted as legacy, but the canonical address above is checked first. Serving both is harmless; serving only the canonical address is sufficient.

## What gets checked [#what-gets-checked]

* HTTPS with a valid certificate, 15-second timeout, 64 KB body cap.
* Exact body match against the issued file content.
* Redirects are **not** followed — a 301/308 to another host or path fails the check. Serve the file directly at the checked address.
* No authentication may stand in front of the file. CDN challenge pages and login walls fail closed.

## Reading a failure [#reading-a-failure]

A failed verification returns per-address evidence — the same table the Console renders inline. Each row names the URL tried, the HTTP status received, any redirect target, and the fetch error:

| Column    | Meaning                                                                            |
| --------- | ---------------------------------------------------------------------------------- |
| URL tried | The exact address fetched, in check order                                          |
| Status    | HTTP status received (`—` means no response arrived)                               |
| Redirect  | `location` header when one was sent (informational — redirects are never followed) |
| Error     | Transport cause: DNS failure (`ENOTFOUND`), timeout, TLS rejection, oversize body  |

Match these rows against your own server and CDN logs: a missing row on your side with `ENOTFOUND` on ours means DNS never resolved; a 301 row with a `location` means the file lives behind a redirect you must remove.

## Common causes, in order [#common-causes-in-order]

1. **DNS** — the domain does not resolve publicly (`ENOTFOUND`). Propagated locally but not globally is the classic variant.
2. **Redirects** — apex-to-www, HTTP-to-HTTPS-chain, or trailing-slash rewrites in front of the file. Flatten them for this path.
3. **CDN challenge or bot wall** — Cloudflare-style interstitials return HTML, not the file. Exempt the verification path.
4. **Auth or IP allowlists** — the fetch comes from Voidnet infrastructure, not your browser session. Anything your browser passes and a stranger fails will fail here too.

## Ownership [#ownership]

One domain belongs to one account. A domain already verified on any account cannot be verified again elsewhere: re-initiating it on the same account reports it as already verified, and initiating it on a different account is rejected while the existing verification stands.

## Expiry [#expiry]

A verification record expires 7 days after initiation. Verify inside that window; expired records need a fresh initiation, which issues a new token.