DNS setup embed · Private beta
Let customers finish their DNS setup without a support ticket
Add one script tag to your onboarding page. Each customer sees the records you need in the terms their own DNS host uses, watches each record turn verified, and your dashboard shows which customers are still stuck.
- Detects the customer’s DNS host from their nameservers
- Checks public resolvers live and marks each record verified
- Flags the conflicts that stop a record from working
Request beta access
For SaaS teams whose customers add DNS records to use the product.
Already have an account? Log in
DNS is where onboarding stalls
Custom domains, email sending, domain verification and CDN or WAF onboarding all end the same way: you hand the customer a table of records and hope. That table wasn’t written for their DNS host. They type the full name into a field that wants only www, add a second SPF record next to the first, or leave an old CNAME where the new A record has to go.
Then the ticket arrives, and someone on your team spends the afternoon asking whether they’ve added the record yet.
How it works
Add the script tag
Load the script once on the page where customers connect their domain. It renders a custom element in a shadow root, so your styles and its styles stay apart.
Declare each customer’s records
Pass the records this customer’s domain should have, inline. You say what DNS should look like; the widget works out the steps.
Your customer follows the steps
The widget re-checks while the page is open and fires a
dns-setup:verifiedevent when every record is right, so your app can move them on.
<dns-setup domain="acme-shop.com"
customer-ref="acct_4821"
records='[
{"type":"CNAME","name":"www","value":"shops.example.net"},
{"type":"TXT","name":"_verify","value":"token-7f3a9c"}
]'></dns-setup>What your customer sees
Steps written in their DNS host’s field names, a status on every record, and a “Send instructions” button for when someone else manages their DNS. It inherits your font and colors, and you can restyle it with CSS custom properties and ::part().
@Targetold-host.example.org@IPv4 address192.0.2.10wwwTargetshops.example.netThe mistakes it catches
- A CNAME in the way
- An A record can’t sit beside a CNAME. When one holds the name, the widget adds a “Delete the CNAME record” step before the add, and marks it removed once it’s gone.
- An SPF or DMARC policy that already exists
- A name gets one SPF policy and one DMARC policy. If the customer has one, the step reads “Change the TXT record” and shows the current value, so they edit it instead of adding a second.
- A CNAME at the root of the domain
- Most DNS hosts won’t take a plain CNAME at the root. The step uses the host’s own feature (ALIAS, ANAME, CNAME flattening) or, on hosts without one, the fallback A and AAAA addresses you supply.
- A dangling CNAME
- A CNAME pointing at a name that no longer exists is a takeover risk. The widget shows a step to delete it.
- DKIM and verification records behind a CNAME
- TXT and MX records are judged through a CNAME, because DKIM selectors and ACME challenges delegate that way on purpose.
See which customers are stuck
The embed runs without an account. A beta account records what each customer’s checks find, so you can reach out to the ones who stalled before they write in.
- Organizations and teammates. Invite the people who handle onboarding and support.
- Sites with allowed origins. Statuses are recorded only for checks from the origins you list.
- Embed keys. Add the key and a
customer-refto the element. Nothing else in your integration changes. - A live status for every record. Verified, pending, blocked or error, grouped by your own customer reference.
| Record | Status |
|---|---|
| acct_4821 | |
CNAME www | Verified |
TXT _verify | Verified |
| acct_5307 | |
A @ | Blocked by CNAME |
TXT _verify | Pending |
| acct_5590 | |
CNAME www | Error |
Questions
What does it cost?
Nothing during the beta. There is no billing yet.
When do I get access?
We’re letting teams in gradually. We review each request, and when yours is approved we email an invite link to set up your account and first organization.
What do I need to use it?
A page in your app where customers set up DNS, where you can add a script tag. If your site sends a Content Security Policy, you’ll allow our origin for scripts, connections and images. The embed docs cover installation, the record format, events and theming.
Do I need an account to use the embed?
No. The embed works today without one; see the live demo. An account adds the embed key that records each customer’s statuses, and the dashboard to read them.
Which records does it handle?
A, AAAA, CNAME, TXT and MX, up to 20 entries per customer, as adds or removals. The widget works out whether each one is an add, a change or a delete from what the customer’s DNS holds now.
What data do you keep about my customers?
With an embed key, we store each entry’s latest status, grouped by your customer-ref. Make that an opaque internal id, never an email address or a name, because it’s stored and shown as sent. During the beta the key is public (it sits in your page’s HTML) and requests aren’t signed, so treat recorded statuses as a guide and re-check on your server before acting on them.
Get your customers through DNS setup on their own
Free during the beta. Tell us where you’d add the embed and we’ll email an invite when your account is ready.
Request beta access