Domains and DNS
Domain types, status lifecycle, fallback behavior, API access policy, and deep link eligibility.
Domain types
Nimriz supports two categories of domains.
Nimriz built-in domains
Built-in platform domains such as nim.lu, riz.to, and rix.to are available immediately. You do not need to configure any DNS records to use them. These are shared domains-multiple workspaces create links on the same hostname.
Limitations of built-in domains:
- The slug namespace is shared across all accounts, so common words are often already taken.
- Deep links are not supported on shared domains, because app association files must uniquely identify a single brand's mobile application.
- You have no control over the root, not-found, or expired fallback URLs for these domains.
Custom branded domains
A custom domain is a hostname you own, verified, and added to your Nimriz organization. For example, links.example.com or go.yourbrand.com.
Advantages of custom domains:
- You own the entire slug namespace-no collisions with other Nimriz accounts.
- You control the fallback redirect behavior for expired and missing links.
- Deep links (routing mobile visitors into your native iOS or Android app) are supported on verified, account-exclusive custom domains.
- Stronger brand recognition for your short links.
Host matching is strict
Nimriz treats every hostname as completely independent. example.com and www.example.com are two different domains in Nimriz. If you add links.example.com, links on that domain will not resolve at www.links.example.com or any other variant.
Choose one canonical hostname and use it consistently throughout your campaigns. If you want both the apex domain and a www subdomain to work, you must add and verify them as two separate domain records.
Domain status lifecycle
Every custom domain moves through the following states:
| Status | What it means |
|---|---|
| Pending | Added to Nimriz but DNS verification not yet complete. Links cannot be created on this domain, and redirects do not work. |
| Verified | DNS verification confirmed (ownership TXT, certificate TXT, and routing record all matched). Cloudflare activation and SSL issuance may still be in progress-the domain is not yet serving traffic. |
| Ready | Verified and Cloudflare edge activation complete. Redirects are fully live. |
| Disabled | Inactive, either manually disabled or due to a policy action. Links on this domain do not redirect. |
A domain must reach Ready status before visitors can follow short links on it. Verification alone is not sufficient-the Cloudflare edge routing for your hostname must also be active.
Removing a custom domain
Open the custom domain from SettingsOrganizationDomains and use the Danger zone controls.
| Action | Result |
|---|---|
| Disconnect domain | Stops traffic, removes Cloudflare custom-hostname state, disables links on the host, and keeps the domain in your list so it can be reconnected later. |
| Delete domain permanently | Removes the domain from your list and deletes links, workspace grants, analytics history, and domain configuration tied to that host. |
Delete is permanent. Use it only when you no longer need the hostname or the short links created on it.
Fallback redirect behavior
When a visitor arrives at your short domain and no specific link applies, Nimriz uses your configured fallback URLs.
| Trigger | Fallback URL used |
|---|---|
| Visitor navigates to the root of your domain (no slug) | root_redirect_url |
| Visitor clicks a link that does not exist or is disabled | not_found_redirect_url |
| Visitor clicks a link that has expired | expired_redirect_url (falls back to not_found_redirect_url if unset) |
| Any of the above is not configured | default_redirect_url (final fallback) |
Configure these URLs from SettingsOrganizationDomains → your domain, in the landing redirects panel (the Configure landing redirects step of the domain setup checklist). Always point fallback URLs to a destination on a different hostname than your short domain itself. Pointing a fallback to your own short domain root creates a redirect loop.
Example-safe fallback:
not_found_redirect_url: https://example.com/404
expired_redirect_url: https://example.com/offers-expired
Avoid this-causes a redirect loop:
not_found_redirect_url: https://links.example.com/
Domain-level API access policy
Every domain has an API access policy that determines whether link creation and management requires authentication.
| Policy | Behavior |
|---|---|
private (default) | All control-plane requests require a valid API key. This is the correct setting for custom branded domains. |
public | Allows unauthenticated link creation. Intended for low-friction shared domains with quota protection. |
For custom domains, always keep API access set to private. Do not expose a custom branded domain to unauthenticated create flows.
Custom domain setup overview
Setting up a custom domain requires three steps. See Custom domain setup and DNS verification for the full step-by-step guides.
- Add the domain to your organization in SettingsOrganizationDomains.
- Publish the DNS records provided by Nimriz: a CNAME for traffic routing (the SSL certificate validates automatically once it is live), plus any TXT records the DNS setup panel lists.
- Trigger verification from the dashboard with Check now. Once both DNS and Cloudflare activation are confirmed, the domain becomes ready.
Deep link eligibility
Deep links allow short links to open your native iOS or Android app directly. Deep links require:
- A custom branded domain (not a built-in or shared Nimriz domain).
- The domain must be verified and ready for traffic.
- The domain must be exclusive to one account-domains shared across multiple workspaces cannot serve app association files because they cannot safely represent multiple brands.
- Full app metadata (iOS bundle ID + Team ID, and/or Android package name + SHA-256 certificate fingerprint) must be saved for the domain. Open the domain under SettingsOrganizationDomains, then use the Mobile app section to save app metadata and the Deep link readiness card to confirm status.
When these conditions are met, Nimriz serves the required app association files (apple-app-site-association, assetlinks.json) automatically from the redirect edge. You do not upload these files manually.
Domain grants to workspaces
Domains are owned at the organization level. Organization owners and admins decide which workspaces can use each domain.
A workspace can only create links on domains that have been explicitly granted to it. If you cannot see a domain you expect in the link-creation domain selector, ask your organization administrator to check the domain grant configuration.
Troubleshooting
Links on my custom domain are going to the fallback page
- Confirm the domain is in Ready status, not just Verified.
- Confirm the slug exists on that exact hostname-remember host matching is strict.
- Confirm the link is not expired or disabled.
- If the domain was recently verified, wait a few minutes for edge routing to propagate.
I added a CNAME but verification is still pending
DNS changes can take anywhere from a few minutes to several hours to propagate globally. If verification is still pending after an hour, double-check that the record name and value exactly match what the Nimriz dashboard shows. Missing characters, extra spaces, or publishing the record on the wrong hostname (e.g., example.com instead of links.example.com) are common causes.
The domain I need is not in my workspace's domain selector
Contact your organization administrator. Domains are org-owned and must be explicitly granted to your workspace before they appear in link creation.
Related guides
Related next steps
Ready to test this setup?
Create an account to try the workflow, or compare plans when the setup needs higher limits, integrations, or team controls.