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
Hear about the beta
For SaaS teams whose customers add DNS records to use the product.
Ready to try it? Create an account. Already have one? 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. Group embeds by the app or product they run in. Checks are recorded from wherever the embed runs.
- Embed IDs. Add the ID 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?
Now. Create an account and you get an organization and its dashboard right away. The list on this page is only for hearing about the beta; joining it doesn’t create an account.
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 ID 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 ID, 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 embed ID isn’t a secret (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. Create an account and add your first site in a couple of minutes.
Create an account