White label and custom domain

Serve the verification flow from verify.yourbrand.com instead of verify.didit.me - the requirements, the two DNS records, and what it costs.

Written by Didit Support · Updated 19 August 2026

Short answer

A subdomain you control - verify.yourbrand.com - pointed at Didit with two CNAME records. It's part of White Label, needs write access to Customization, and must be enabled on your account. Root domains and www. are rejected.

#What it changes

With a custom domain, users stay on your domain for the whole verification journey. Combined with the Style Editor, it removes the last visible reference to Didit in the flow.

The white label editor in the Didit console with the Domain tab and Save changes
  1. Branding carries the logo and colours users see.
  2. Domain is where a verified custom domain replaces verify.didit.me.
  3. Nothing applies until Save changes - and the workflow has to enable white label too.
White label is configured here, then switched on in the workflow.

#Requirements

RequirementDetail
Subdomain onlyverify.yourbrand.com. A root domain like yourbrand.com is rejected, and so is a www. prefix
Not already in useThe subdomain can't already point at a site or app of yours
DNS accessYou need to create two records at your DNS provider
PermissionWrite access to Customization - read-only members see the section disabled
Enabled on your accountCustom domain is part of White Label and has to be switched on for you

#How it works

You enter your subdomain in the console. Didit generates two DNS records for you to add:

RecordPurpose
Verification CNAMEProves you own the domain, which issues the SSL certificate
CloudFront CNAMEPoints your subdomain at the verification UI

Both are required. Once they resolve, you verify ownership from the console and the flow starts serving from your domain.

  1. Add the domain

    Business Console → White Label → Domain, enter your subdomain, click Add Domain. The console generates your records.

  2. Create both DNS records

    Add them at your DNS provider exactly as shown. A partial setup leaves the certificate unissued and the domain unusable.

  3. Verify ownership

    Once the records resolve, verify from the console. DNS propagation is the slow part and is entirely on your provider's side.

Note

If verification doesn't complete, the cause is nearly always DNS: a record added at the wrong level (a provider that appends the zone name, producing verify.yourbrand.com.yourbrand.com), a proxy or CDN in front of the record rewriting it, or simply propagation that hasn't finished. Check what the record actually resolves to before reporting it.

#What it costs

The custom domain is part of White Label, which is billed at $0.20 per completed verification. It is not a separate line item on top of the white-label fee, and there's no additional per-domain charge - but it does mean a workflow serving from your own domain is a white-labelled workflow, with the white-label price. See what counts as a billable check.

#Embedding instead of redirecting

A custom domain solves "the URL says Didit". If your concern is instead "I don't want the user to leave my app at all", the answer is a different one: embed the flow. There are web SDK and in-context options that render verification inside your own frontend, and native SDKs for mobile. See ways to integrate.

Which of those is available on your plan is worth confirming with your Didit contact rather than assuming, particularly if you're scoping a project around it.

#Reseller and multi-brand setups

If you're running verification on behalf of several of your own customers, each wanting their own branding, that's a different shape from one company with one brand - and the answer involves how your organizations and applications are structured. Talk to your Didit contact about it before building; retrofitting a multi-brand structure is considerably more work than starting with one.