Custom domains
Verify ownership, activate the paid add-on, attach DNS, and operate apex and www hosts.
Verify ownership, activate the paid add-on, attach DNS, and operate apex and www hosts.
A custom domain is a $2/month add-on for a site on an active paid plan. One site can have one custom-domain record at a time. The add-on is separate from AI credits, live voice minutes, and the platform plan subscription.
Understand the lifecycle#
| Status | Meaning | Your next action |
|---|---|---|
| Pending DNS | Domain record exists but ownership TXT was not found | Add the shown TXT record and select Check DNS |
| Verified | Ownership is confirmed; no domain add-on is active yet | Start the add-on checkout |
| Attaching | Payment is active and the platform is provisioning apex/www | Add every displayed DNS record and recheck |
| Active | All provider hosts are active | Open HTTPS, choose the primary host, and publish the site |
| Error | Provider attach or DNS activation failed | Read the saved error, fix records, and retry/check |
| Suspended / payment required | Plan or domain add-on entitlement lapsed | Restore billing or remove the domain |
The custom host serves only while the site is published and the platform subscription/domain entitlement is active. A valid DNS record alone does not bypass those checks.
Choose the domain and primary host#
Open the correct site's Domain page and enter the registrable domain, such as example.com. Do not enter a path, scheme, port, or unrelated platform hostname. Choose whether www.example.com or example.com (apex) should be primary; www is the recommended default for the broadest DNS-provider compatibility.
The platform attaches both apex and www variants. The selected primary host is canonical, and the other variant redirects to it when active. You can switch the primary choice later without creating a second domain record.
Verify ownership before payment#
After adding the domain, create the exact TXT record displayed in the dashboard:
Type: TXT
Name: _maf-verify.example.com
Value: <unique verification token from the dashboard>DNS providers differ in their Name/Host field: some automatically append example.com, so they may expect only _maf-verify. Follow the provider's convention and use a DNS lookup tool to confirm the final fully qualified record returns the exact token.
Select Check DNS. Verification is free and happens before checkout. Do not publish the token for another domain or reuse it across sites. Pending verification records can expire after an extended incomplete setup, so finish the flow rather than treating it as a permanent reservation.
Activate the add-on#
When the status is Verified, select Activate custom domain and complete the Polar checkout. The add-on belongs to this site/domain. A verified but unpaid setup does not serve traffic.
The platform checks provider capacity before selling the add-on. If capacity is temporarily unavailable, use the displayed request/waitlist action; do not pay for or point production traffic at an integration that cannot yet attach.
After payment, the status becomes Attaching and the platform requests both hosts from the edge provider. The page refreshes while provisioning and shows the authoritative DNS records returned for your domain.
Add activation DNS records#
Create every record exactly as shown. Depending on the DNS provider and host, these may be CNAME or other targets. Remove conflicting A, AAAA, or CNAME records for the same hostname. Do not copy a target from another customer's documentation because edge values can be deployment-specific.
If a DNS proxy/CDN is enabled, start with DNS-only mode when it hides validation or changes TLS behavior; re-enable proxying only after you understand the resulting certificate and caching path.
Select Check DNS until every host is active. The platform marks the domain Active only when all provider references report active; partial activation is not treated as success.
Verify production behavior#
- Publish the site.
- Open
https://for the primary host in a private window. - Confirm the alternate host redirects to the primary host.
- Inspect the certificate hostname and browser security state.
- Send an agent test message and complete key links/forms.
- Confirm the original hosted slug redirects or identifies the custom domain as canonical where expected.
- Add the custom host to external analytics, search, email, or provider allowlists that depend on hostname.
The site's active custom domain is automatically allowed as its embed parent; you do not need to duplicate it in the embed-origin list for that same site.
Billing, suspension, and removal#
If the domain add-on payment lapses, the domain can enter Payment required. If the overall platform plan lapses, it can be suspended even when DNS remains correct. Use the billing portal action to restore entitlement, then recheck activation.
Removing the domain detaches both hosts, cancels the associated add-on, and returns the site to its hosted subdomain. It does not alter DNS records at your registrar. Remove or repurpose those records after the hosted fallback is confirmed. Keep the old destination working during a migration until the new host serves HTTPS.
Troubleshooting#
| Symptom | Check |
|---|---|
| TXT never verifies | Final FQDN, provider auto-appended zone, exact token, propagation, and duplicate TXT values |
| Stuck attaching | Every displayed record, conflicting A/AAAA/CNAME, proxy mode, provider status, and Last checked time |
Apex works but www fails | Both host records exist; the platform waits for both before full activation |
| Browser shows certificate error | Do not share yet; wait for active state, correct DNS, and certificate issuance |
| Domain is active but site unavailable | Site published state and active platform/domain billing entitlement |
| Need a different domain | Remove the existing site domain first, confirm hosted fallback, then add/verify the replacement |
| Status reports capacity | Use the request-access action; repeated DNS edits cannot fix provider capacity |
DNS propagation has no universal instant completion time. Use the dashboard's exact records and last-checked state rather than guessing from one resolver.