Clients retain full ownership of their domain registration while delegating specific DNS management to the studio during production and launch. The Technology department oversees all record configurations, verifies routing, and schedules propagation cutovers within standard working hours.
Domain ownership vs DNS management
Xylora Studios does not purchase domains on behalf of clients or take over registrar accounts. Your domain must remain registered under your own organisation's registrar account (such as Cloudflare, Namecheap, or GoDaddy), ensuring you maintain continuous, uncompromised legal ownership.
For deployment, we operate under two distinct DNS models:
1. Managed delegation (Recommended): You delegate nameservers directly to our managed infrastructure or our studio DNS management zone. This grants the Technology department direct control over A, AAAA, and CNAME records, allowing us to manage SSL provisioning, automated failover, and staging subdomains without requiring manual intervention from your team. 2. Manual client-side configuration: If your organisation enforces strict internal IT policies that prohibit nameserver delegation, our Technology department provides a precise record specification sheet. Your internal network administrator or IT team is then responsible for applying the records exactly as specified.
The deployment sequence
Transitioning a domain from staging to a live production environment requires a strict sequence of steps to prevent broken links and service downtime:
1. Zone discovery and audit: Five working days before scheduled deployment, our Technology department reviews your active DNS zone. We inventory all active records, paying close attention to MX, SPF, DKIM, and external validation TXT strings. 2. TTL reduction: Forty-eight hours prior to launch, we instruct your team (or execute directly under managed delegation) to reduce the Time to Live (TTL) on existing web records to 300 seconds (5 minutes). This ensures that traffic migrates rapidly once the actual switch occurs. 3. Record provisioning: During scheduled launch windows, we bind the new origin IPs or canonical hostnames and initiate automated SSL certificate issuance. 4. Propagation monitoring: We monitor external resolver nodes globally to ensure records resolve cleanly across major telecommunications backbones.
Cutovers are scheduled exclusively during operational studio hours: Monday to Thursday, between 09:00 and 17:00 GMT. We do not conduct high-impact DNS cutovers outside of these hours, ensuring full developer availability should unexpected edge routing anomalies arise.
Handling email and third-party records
The most critical failure point in any web launch is the accidental disruption of corporate email. The Technology department will never alter nameservers or purge a DNS zone without an explicit, documented map of your existing email routing.
If you use Google Workspace, Microsoft 365, or an independent mail host, all relevant MX records and authentication TXT records (SPF, DKIM, and DMARC) are duplicated identically in the new zone before any nameservers are pointed to our systems. If your IT setup requires specific routing for VPNs, internal directories, or third-party CRM hooks, you must supply these records to us during the project handover phase.
Failure cases and troubleshooting
When DNS disruptions occur, they almost invariably stem from three common issues:
* Unlowered TTLs: If TTLs were left at standard default values (such as 86400 seconds / 24 hours), some global ISP resolvers will continue caching the old site until the lease expires. This creates inconsistent behaviour where some users see the old site and others see the new one. * Conflicting root records: Attempting to assign both a CNAME and an A record to the apex/root domain (`yourdomain.co.uk`) will cause RFC compliance violations and complete DNS resolution failures. We enforce ANAME/ALIAS records or root-level Cloudflare CNAME flattening to circumvent this. * Two-factor authentication locks on registrar accounts: In manual configurations, delays often occur because the client's internal domain administrator is unavailable to approve two-factor authentication requests during the agreed cutover window.
If resolution issues emerge post-launch, contact our team immediately through the Ask Xylo chat on this portal. Enquiries received during working hours are addressed promptly under our standard 24-hour first reply target, with operational deployment emergencies prioritised by the Technology team.
Pre-launch DNS checklist
Ensure the following requirements are fulfilled before your project cutover date:
* Registrar account login credentials and administrative access confirmed by your team. * Two-factor authentication access arranged for the specific individuals handling the deployment. * Comprehensive export or screenshot of all active DNS records submitted via the Ask Xylo chat. * Email service provider (Google Workspace, Microsoft 365, etc.) explicitly identified in writing. * Current TTLs on existing web records lowered to 300 seconds at least 48 hours in advance. * Deployment scheduled within studio working hours (Monday to Thursday, 09:00-17:00 GMT).