# Custom domains DNS reference

> The exact DNS records for pointing a domain at your Vaulter app.

This page explains the DNS records involved in pointing a custom domain at your Vaulter app: what each one is, and why it exists. The exact values for your domain are generated in **Vault → Domains** when you add it, and that screen is always the authoritative source; every record there has a copy button.

## The three records

When you [connect a domain you own](/docs/publish/connect-domain), Vaulter asks for three records at your DNS provider:

### 1. The traffic record (CNAME)

A **CNAME** on your chosen host (for example `www`, or a subdomain like `app`) pointing at Vaulter's edge, `proxy-fallback.vaulter.run`. This is the record that actually routes visitors to your app. Vaulter's network receives the request, recognizes your domain, and serves your latest published deployment.

### 2. The certificate record (CNAME)

A second CNAME used for **SSL issuance**. It lets the certificate authority confirm, continuously, that your domain should have a certificate for Vaulter to serve, which is how your app gets and keeps HTTPS without you ever touching a certificate. Its name and value are unique to your domain; copy them exactly from the Domains panel.

### 3. The ownership record (TXT)

A **TXT** record proving you control the domain, so nobody else can claim your domain onto their app. It is checked when you connect and should stay in place.

## Root domains vs subdomains

- A **subdomain** like `app.example.com` connects directly with the records above.
- A **root domain** like `example.com` is served at `www.example.com`, because DNS does not reliably allow CNAME records at the root. Add your provider's redirect from the bare domain to `www` so both forms reach your app; nearly every provider has this as a built-in option.

## Domains bought in Vaulter

None of this page applies to a [domain bought inside Vaulter](/docs/publish/buy-a-domain): registration, all records, connection, and SSL are configured automatically, and Vaulter manages the DNS for you.

## Reading the status

The Domains panel shows one status per domain, and each one means something specific:

| Status | What is happening | What to do |
| --- | --- | --- |
| **Pending** | Waiting for your DNS records to appear on the internet | Add the records if you have not; otherwise wait, propagation takes minutes to hours |
| **Verifying** | Records found, ownership being confirmed | Nothing; this resolves on its own |
| **Pending SSL** | Ownership confirmed, certificate being issued | Nothing; a progress bar tracks issuance |
| **Active** | Done; your app is live on the domain over HTTPS | Visit it |
| **Failed** | A check hit a hard error | Read the error shown on the row, fix the named record, and re-verify |

The panel keeps re-checking automatically, so a fixed record is picked up without you doing anything else.

## When it will not verify

DNS changes take minutes to hours to propagate. If a domain is stuck well past a few hours, work down this list; it is ordered by how often each one is the culprit.

### Compare every record character for character

Use the copy buttons in the panel, never retype. The classic mistakes: a stray space, the domain duplicated in the name field (your provider may want `www` where the panel shows `www.example.com`, or the reverse), and a trailing dot where there should not be one. Check the certificate CNAME as carefully as the traffic one; it is the most commonly mangled because its values look like random noise.

### Look for a conflicting record on the same name

A leftover **A record** (or an old CNAME) on `www` from a previous host wins over your new CNAME at many providers, and everything looks right at a glance because your record is also there. Delete the old record, keep only the panel's.

### Turn off proxying on the records

Some providers (Cloudflare's orange cloud is the famous one) proxy CNAME records by default. Both CNAMEs must be published **DNS-only**, exactly as given; a proxied certificate CNAME can never validate. The same goes for providers that "flatten" CNAMEs at the root: connect a subdomain like `www` instead.

### Check where the domain's DNS actually lives

Records must be added at the provider that currently answers for the domain, which is not always where you bought it. If the domain's nameservers point at a different service (an old website builder, a parking service), records added at the registrar do nothing. Your registrar's dashboard shows the nameservers; that is where the records go.

### Give real propagation time, then re-add

If everything above checks out, wait a few hours; some resolvers are slow. As a last resort, remove the domain in the panel and connect it again fresh, which regenerates the records and restarts every check cleanly.

## Frequently asked

#### The domain is Active but visitors get a security warning

Certificate issuance can lag the Active flip by a few minutes, and the visitor's browser may also be holding a stale connection. Wait a few minutes and hard-reload. If warnings persist past half an hour, disconnect and reconnect the domain to restart issuance.

#### www works but the bare domain does not

Expected until you add the redirect: the app is served at `www`, and the bare domain needs your provider's redirect pointing to it (see "Root domains vs subdomains" above). Nearly every provider has this as a checkbox or a built-in forwarding rule.

#### The old site still shows up for some visitors

DNS caching. Networks remember old records for up to a day, so a recently moved domain can show the old destination to some visitors and the new one to others. It resolves on its own as the caches expire.

#### My provider does not accept the record name

Providers differ on whether the name field wants the full hostname (`www.example.com`) or just the host part (`www`). If one form is rejected or produces a doubled name like `www.example.com.example.com`, use the other form.

#### Does connecting a domain affect my vaulter.run address?

No. The vaulter.run address keeps working alongside your custom domain, and both serve the same published app.

#### Verification succeeded once, then the domain went back to Failed

Something changed at the DNS side after connection: a record was deleted, or a provider migration rewrote the zone. Compare all three records against the panel again; the ownership TXT and certificate CNAME must **stay** in place, not just exist at setup.