When you attach a custom domain, dply checks that the hostname points at your app, and, where needed, that you own it. After that, it issues a TLS certificate. This page explains each record, shows examples, and covers the common reasons a domain stays in Pending DNS or Failed.
What dply checks
A custom domain goes through three stages:
- Routing. The hostname has a CNAME record pointing at the CNAME target shown on the domain row. An apex domain instead answers with the same addresses as the CNAME target, through ALIAS, ANAME or CNAME flattening.
- Ownership. If the domain row shows a Verification TXT record, that record must also exist.
- Certificate. Once DNS is Ready, dply requests a certificate. The badge moves from Issuing certificate to TLS active.
Copy each value exactly as the domain row shows it. Every row has its own values. The examples below use placeholders.
Records you may be asked for
CNAME record
Points your hostname at dply. It's required for every subdomain. For an apex, see Apex domains.
| Type | Name | Value |
|---|---|---|
CNAME |
www |
the CNAME target from the domain row |
Verification TXT record
Proves that you, and not another dply customer, control the hostname. It appears under Verification TXT record while the domain isn't Ready yet. It's always required for an apex domain.
| Type | Name | Value |
|---|---|---|
TXT |
_dply-verify.www |
dply-verify=… (copy from the domain row) |
The full record name is _dply-verify.<your hostname>, for example _dply-verify.www.example.com. Many DNS providers append your zone automatically, so you enter only _dply-verify.www.
The token is created once per hostname and doesn't change if you verify again. You can delete the record after the domain is Ready.
Ownership TXT record
Some hostnames also need a record from the certificate provider before the certificate can be issued. When one is needed, the row shows it as Ownership TXT record, usually named _cf-custom-hostname.<your hostname>. It disappears from the row once TLS is active.
Example: www.example.com
For www.example.com in a zone example.com, the records usually look like this:
www.example.com. CNAME <CNAME target from the row>
_dply-verify.www.example.com. TXT "dply-verify=<token from the row>"
Then choose Check DNS now (in the domain's dialog). When it succeeds, you see "DNS verified — www.example.com is live on Edge."
Apex domains
For example.com itself, create one of these at the root (@), pointing at the CNAME target from the row:
- an
ALIASorANAMErecord, or - a
CNAMErecord, if your provider flattens CNAMEs at the root (Cloudflare does this automatically).
Keep it DNS-only, and add the verification TXT record:
example.com. ALIAS <CNAME target from the row>
_dply-verify.example.com. TXT "dply-verify=<token from the row>"
A flattened apex answers with IP addresses, not a CNAME. dply accepts it when those addresses match the CNAME target's addresses and the TXT record holds your token. The addresses are shared by every app behind the target, so the TXT record is what proves ownership.
If example.com is an active zone in your organization's Cloudflare account, dply creates the root record for you and you don't need the TXT record. See Domains.
If your DNS is on Cloudflare
- If your organization has a Cloudflare credential that can see the zone, and the zone is active, dply creates the CNAME for you. There's nothing to add by hand. See Domains.
- If you add the CNAME yourself, set it to DNS only (gray cloud). A proxied record answers with Cloudflare IP addresses instead of the CNAME, so Check DNS now (in the domain's dialog) can't see it.
- TXT records are never proxied. Add them as normal TXT records.
Check your records from a terminal
Replace www.example.com with your hostname.
# Who serves DNS for the domain?
dig NS example.com +short
# Does the hostname CNAME to the target shown in dply?
dig CNAME www.example.com +short
# Apex: do its addresses match the target's?
dig A example.com +short
dig A <CNAME target from the row> +short
# Is the verification token visible?
dig TXT _dply-verify.www.example.com +short
No output means the record is missing, or hasn't propagated yet. Propagation usually takes a few minutes, but can take up to your record's TTL (and longer for a freshly delegated domain).
Troubleshooting
"No DNS records found for …"
dply didn't find a CNAME, A or AAAA record for the hostname. Check the record name. A common mistake is entering www.example.com in a field that already appends example.com, which creates www.example.com.example.com. Wait for propagation, then choose Check DNS now (in the domain's dialog).
"Hostname resolves to …, expected …"
The hostname points somewhere else, such as an old host or a parking page. Update the CNAME value to the CNAME target on the row. Remove any A or AAAA records for the same name, because they conflict with the CNAME.
"Add a TXT record … to prove you own this hostname"
The CNAME is correct but the verification TXT record is missing or has a different value. Add _dply-verify.<hostname> with the exact value from the row, then verify again.
"… is already attached to another site" or "… is already live on another site"
A hostname can belong to only one app across all dply organizations. Remove it from the other app first. If you own the domain but can't access the app that has it, contact support.
The domain shows Failed after I fixed DNS
dply keeps re-checking a Failed domain for 72 hours after you attach it: every 15 minutes for the first hour, hourly for the rest of the first day, then every 6 hours. It turns Ready on its own once your records resolve. After 72 hours, or to skip the wait, choose Check DNS now (in the domain's dialog).
Apex domain won't verify
- Check that the root record is an
ALIAS,ANAMEor flattenedCNAMEto the CNAME target, and that it's DNS-only. A proxied record answers with your own Cloudflare zone's addresses, which don't match. - Check the verification TXT record at
_dply-verify.example.com. An apex always needs it. - Remove any other A or AAAA records at the root, such as an old host's, so every address the root returns belongs to the target.
TLS failed
The domain row shows the reason from the certificate provider. The most common causes are a CAA record that doesn't allow Cloudflare's certificate authorities, and a CNAME removed while issuance was in progress. Fix the cause. dply retries certificates every 15 minutes.
Related
- Domains
- Edge network
- Notification channels: get alerted when a domain verifies or starts failing