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 record confirmed. The domain is eligible for link creation and 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.
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 |
| Any of the above is not configured | default_redirect_url (final fallback) |
Configure these URLs in your workspace domain settings. 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 Settings → Domains.
- Publish the DNS records provided by Nimriz (a TXT verification record plus a CNAME for traffic routing).
- Trigger verification from the dashboard. 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 deep link configuration (iOS Universal Link metadata and/or Android App Link metadata) must be complete in your domain settings.
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.