DNS
Domain Verification Records
How to prove you own a domain, whether the service asking is KapsuleHost, Google, Microsoft or anyone else, and how to add the record in KPanel.
Sooner or later a service will refuse to do something for your domain until you prove the domain is yours. The proof is almost always the same shape: they give you a string, you publish it as a DNS record, they look it up. If they can see it, you clearly control the domain, because only the owner can publish DNS for it.
This guide covers the record Kapsule asks for, the records other services ask for, and how to add either one.
Where the DNS Editor Is
Domains in the sidebar, click the domain, then the DNS tab. That is the full record editor, and it is the only place you can add or change records.
The DNS view under a site (Websites, the site, Domain, DNS) is read-only. It shows you what is published and has a link through to the full editor. If you are looking for an add button and cannot find one, you are on the read-only view.
The editor only works for domains whose DNS is hosted at Kapsule. If your domain is registered here but its nameservers point somewhere else, you have to publish the record wherever your DNS actually lives. See Nameservers.
Kapsule's Own Verification Record
Kapsule asks for one verification record, in one situation: you are adding mailboxes on a domain whose DNS we do not run.
If your domain is registered with us or its DNS is hosted with us, we can already see that you own it and nothing is asked of you. If your DNS is elsewhere, we cannot, so we ask you to prove it before we will accept mail for that domain.
The Record
| Field | Value |
|---|---|
| Type | TXT |
| Name | _kapsule-verify.yourdomain.com |
| Value | kapsule-verify= followed by the token shown in the panel |
The token is generated for your account and shown to you in the panel. Copy both the name and the value with the copy buttons rather than retyping them.
The Steps
- In KPanel, open the mailbox or domain and go to its Deliverability section.
- Find the domain verification card. It shows the record name and value, and a status badge.
- Publish that TXT record wherever your DNS is hosted.
- Wait a minute or two.
- Come back and click verify.
The check is done live, against public resolvers rather than our own, so what it sees is what the rest of the internet sees. That means the answer is honest, and it also means it can fail for a minute or two after you publish while caches catch up.
If verification fails, do not immediately assume the record is wrong. The most common cause by far is that you clicked verify before the record was visible. Wait two minutes and try again. The second most common cause is your DNS host silently appending the domain to a name that already contained it, giving you _kapsule-verify.yourdomain.com.yourdomain.com. Check what the record actually resolves to.
Afterwards
Once verified, the domain is recorded as yours and stays that way. You can remove the TXT record if you want a tidy zone, and nothing will break.
One caveat: if you ever restart verification for that domain, a new token is issued and the old published value becomes useless. So if you do remove the record and later find yourself asked to verify again, copy the fresh value from the panel rather than reusing what you had before.
Verification Records for Other Services
Every other verification record works the same way. The service gives you a value, you add it in the DNS tab, you go back and click their verify button.
The common ones:
| Service | Type | Typical name | Value looks like |
|---|---|---|---|
| Google Search Console | TXT | the bare domain | google-site-verification=... |
| Microsoft 365 | TXT | the bare domain | MS=ms... |
| Meta business domains | TXT | the bare domain | facebook-domain-verification=... |
| Various SaaS tools | TXT or CNAME | a _something subdomain | a random token |
Adding One
- Go to Domains, click the domain, then DNS.
- Add a record.
- Set the type, usually TXT.
- For the name, enter
@if the service says to put it on the bare domain or root. Enter just the label, such as_dnsauth, if it asks for a subdomain. Do not include your domain name in the label. - Paste the value exactly as given, with no quotes added by you and no trailing spaces.
- Save, wait a couple of minutes, then click verify at the other service.
Three things the editor handles for you, which save the usual arguments:
- Long values are fine. Verification tokens that exceed the 255-character limit of a single DNS string are split correctly for you.
- Quoting is handled. Paste the raw value. Do not wrap it in quotation marks yourself.
- Multiple TXT records at the same name coexist. A Google verification record on the bare domain does not replace your SPF record there. Both are published and both are found. This trips people up constantly, because it is not how most other record types work.
Never replace an existing SPF, DKIM or DMARC record with a verification token. They live at different names, or side by side at the same name. If a service tells you to "replace your TXT record", it means replace the one it gave you previously, not the ones that carry your email authentication. See SPF, DKIM and DMARC.
Records You Should Leave Alone
While you are in the DNS editor you may notice records you did not create.
_acme-challengeTXT records are created and removed automatically when a certificate is issued or renewed. Do not delete them by hand. If one lingers after issuance, it is harmless. See SSL Certificates._dmarcand_domainkeyrecords carry your email authentication. Removing them will break your mail deliverability, not your verification. See SPF, DKIM and DMARC.- SOA and NS records for the domain itself are the zone's own plumbing.
Which Record Types the Editor Supports
The type dropdown offers A, AAAA, CNAME, MX, TXT, NS, SRV and CAA. A priority field appears for MX and SRV, because those are the only two types that use one.
If a service asks for a record type that is not in the list, open a support ticket rather than trying to approximate it with something else. See Opening a Support Ticket.
How Long It Takes
A change is live on our nameservers essentially immediately: the record is written and our other nameservers are told to pick it up straight away. The editor does not ask you to set a TTL, so you do not have to think about one.
What you are actually waiting for is other people's caches. A resolver that already looked up that name will keep its old answer until its cached copy expires. In practice, verification checks usually succeed within a minute or two, and occasionally take longer.
If a service still cannot see your record after an hour, the record itself is wrong. Look at the name first, since a duplicated domain suffix in the label is the most common mistake by a wide margin.