Domain
Useful for
Introduction
The company domain is part of the trust boundary for identity, email, DNS, the website and customer communication. It should be owned, recoverable, monitored and treated as a business-critical asset.
Knowledge scope
This is startup-specific guidance in the public playbook. It is framed around the Day Zero -> Company Ready decision point and the practical trade-offs a small company faces while moving from idea to Production.
Why it matters
Domain and DNS mistakes can break email, SSO, website availability, product routing, certificate validation and customer trust. They are not only technical changes; they are business-impacting changes.
How it fits the playbook
This reference supports the Day Zero -> Company Ready stage of the startup CTO playbook. It gives the public context for the decision without exposing the deeper assessment method behind the agentic operating model.
Design considerations
- Keep domain ownership with the company and make recovery possible.
- Know where root DNS is hosted and who can change it.
- Treat MX, SPF, DKIM, DMARC, SSO, website and product-routing records as critical.
- Alert on DNS changes that could affect identity, email or service availability.
- Record ownership and rollback expectations for material DNS changes.
What good looks like
The company can prove who owns the domain, who can change DNS and how critical DNS changes are detected and governed.
How Brokenhouse helps
Turn this into a practical plan.
I help technology teams turn this guidance into decisions, implementation plans, governance evidence and production-ready operating models.
Talk through your situationNext guidance
Related decisions to work through
Is the company ready?
The first few months of a software business are not just about building the product. They are about creating the conditions that allow the product to be built, deployed, governed and supported without the company tripping over its own foundations.
Agentic software delivery governance
Agents used by the delivery team need a different governance model from AI models embedded in the product. Delivery agents may not sit in the customer-facing service, but they can still read code, write code, inspect logs, summarise documents, generate infrastructure changes or draft customer-facing material.
AI model governance
AI models used by the product need their own governance model. They sit close to customer workflows, user data, automatic processing and contractual promises, so they need stronger control than delivery agents used internally.