Domain
Domain access and DNS ownership decisions for cloud deployments.
When to use this page
- You are preparing a production or staging domain for deployment.
- You need to decide who manages DNS records.
- You want to reduce risk of outages caused by domain misconfiguration.
Prerequisites
- Registered domain at a provider (for example AWS Route 53, Namecheap, GoDaddy, Cloudflare Registrar).
- Access to the provider dashboard or a clear owner contact.
- Decision on branding and URL structure.
Decide access pattern
Most products should use one of these patterns:
| Pattern | Example | Typical use |
|---|---|---|
| Root domain | example.com | Marketing site or simple single-surface product |
| Subdomain | app.example.com | Product app separated from marketing site |
| Mixed | example.com + app.example.com | Landing page on root, app on subdomain |
Select your domain for your product
- Let us know your preferred pattern and we can prepare exact DNS records.
- If branding is not finalized, we can use a temporary development domain and migrate later.
Decide management model
Choose one ownership model for DNS changes:
- Client-managed DNS: You control records at the provider; the team provides exact record changes.
- Team-managed DNS (recommended): You delegate full or partial control so deployment changes can be applied faster and more safely.
Team-managed DNS usually reduces deployment lead time and configuration errors.
Verify
- Domain ownership and renewal contacts are documented.
- Required DNS records for app and email are applied and validated.
- At least one backup admin has access to the domain provider account.
Common pitfalls
- Making DNS changes without coordination during active deployments.
- Forgetting SPF/DKIM/DMARC records, which affects transactional email delivery.
- Not documenting who can approve domain transfer or nameserver changes.
Be careful with domains
Always align domain changes with the delivery team because DNS updates can impact product availability and email.