Customer-facing surfaces

Custom cancel domain.

Serve your hosted cancel page from cancel.yourcompany.com instead of trybackstop.com/cancel/<token>. DNS-verified, token-based, no SSL renewal headaches — the deployment platform handles certs.

Add a hostname

  1. Go to Settings → Cancel domain in the workspace dashboard.
  2. Enter the subdomain you want to use (must be a subdomain you control, e.g., cancel.yourcompany.com; apex domains aren't supported).
  3. Click Add hostname. We generate a verification token.

Add the DNS records

Two records, both at your DNS provider:

  • CNAME at cancel.yourcompany.com → trybackstop.com. Routes the customer's request to our app.
  • TXT at _backstop-verify.cancel.yourcompany.com → the verification token shown on the settings page (it looks like backstop-verify-…). Proves you control the hostname.

Verify

DNS propagation usually takes 10–30 minutes. Once both records resolve, click Verify DNS. We run resolveTxt server-side against _backstop-verify.cancel.yourcompany.comand, when the token matches, flip the workspace into “verified.” If it isn't found yet, the page shows the exact records it saw so you can spot a typo.

What happens at verification time

Once verified, our proxy starts rewriting requests. When a customer hits cancel.yourcompany.com/<token>, the proxy detects the custom host and internally rewrites to /cancel/<token>. The customer sees your subdomain in their address bar; the page renders the same cancel flow.

Removing

From the same settings page, click Remove domain. The workspace immediately reverts to the default trybackstop.com/cancel/<token> URLs. Old emails with the custom-domain link will 404 until you re-add the host (the proxy only rewrites for verified, currently-active hostnames).

Related

  • Custom send domain — the email equivalent (EasyDKIM CNAMEs for outgoing dunning).
  • Troubleshooting — a custom cancel domain is also the fix when a customer's DNS filter blocks trybackstop.com.