Launch a new domain safely

A domain launch joins several control planes that do not become ready automatically: registration, parent delegation, authoritative DNS, DNSSEC, web hosting, certificates, redirects, email, renewal, and account recovery. Launch them as an ordered change with named owners, evidence, and a rollback state.

Blast radius and owners

An incorrect launch can make the whole domain unreachable, expose traffic to the wrong service, reject email, or leave registration recovery with the wrong person.

Control point	Responsible owner
Registrant data, renewal, lock, recovery, and parent delegation	Authorized registration owner
Authoritative zone, records, signing, and exports	DNS operator
Website hostname, edge, certificate, redirect, and origin	Web or CDN owner
MX, mailboxes, sender policy, and delivery	Email owner
Verification records and third-party integrations	Service owners
Approval, window, monitoring, and rollback	Launch owner

Registration creates a renewable contractual right to use the name; it is not permanent property. ICANN documents the registrant, registrar, registry, and registration-data roles [1].

Prerequisites

• an approved domain spelling and intended registrant organization;
• authorized registrar and DNS-provider accounts;
• tested account recovery and multi-factor authentication;
• named technical and business owners;
• approved website and email destinations;
• a complete minimum record inventory;
• maintenance and communication windows; and
• an evidence archive accessible to the rollback owner.

Do not use a launch to test account ownership, provider access, or application readiness for the first time.

Inventory and export

Before changing public state, record:

• exact registered domain and registrar;
• registrant organization, renewal date, auto-renew state, contacts, account recovery, and lock state;
• intended authoritative nameserver set and any required glue;
• staged zone export, SOA, NS, TTLs, and DNSSEC intent;
• apex and www website records;
• certificate and hostname requirements;
• approved redirect and canonical destination;
• MX and exchanger addresses;
• SPF, DKIM selectors, DMARC, and verification TXT records;
• delegated subzones, CAA, SRV, and other service records; and
• the state to restore if launch verification fails.

Even a new zone needs an exported launch baseline. Memory or a screenshot of one provider screen is not a rollback source.

Preflight

Complete read-only or staged checks before public delegation:

1. Confirm the registration account has the intended owner, contacts, recovery, and renewal controls.
2. Stage the full zone at the DNS provider.
3. Query every intended authority directly for SOA, NS, web, mail, and verification records.
4. Confirm the web service recognizes apex and www and can obtain or serve the intended certificate.
5. Confirm the mail provider has accepted the domain, mailboxes, aliases, and sender identities.
6. Decide whether the first launch is intentionally insecure or includes a reviewed DNSSEC chain.
7. Capture expected HTTP status, redirect, headers, and representative paths.
8. Review the Domain Registration Lookup pathway and DNS Lookup pathway without treating either as a substitute for control-plane evidence.

DNS delegation separates the parent and child administrative scopes [2].

Stop conditions

Stop before public launch if:

• the domain spelling or registrant organization is disputed;
• registrar or DNS account recovery is untested;
• the zone cannot be exported;
• intended authorities disagree or answer non-authoritatively;
• required web, mail, or verification records are missing;
• the web destination does not recognize every production hostname;
• certificate issuance or presentation is unready;
• the email provider has not accepted the domain and required recipients;
• DNSSEC parent and child ownership is unclear; or
• no owner can execute and verify rollback.

During launch, stop adding changes after the first unexplained result.

Ordered steps

1. Register the exact approved domain through the authorized organizational account. Record the transaction and renewal date.
2. Enable account protections, recovery, renewal controls, and registrar lock where supported and appropriate.
3. Create the authoritative zone from the approved inventory and export it.
4. Publish the full intended nameserver set through the registration path.
5. Verify the parent referral and every child authority before publishing application traffic records.
6. Publish the minimum reviewed web, mail, and verification records. Avoid unrelated cleanup or speculative records.
7. Confirm the website certificate, redirects, status, headers, CDN, and origin. HTTP semantics begin after DNS has produced a destination [5].
8. Confirm MX routing, exchanger addresses, approved recipients, and outbound submission. SMTP routing is distinct from website routing [4].
9. Establish DNSSEC only through an ordered parent DS and child signing plan. DNSSEC authenticates DNS data; it does not encrypt queries [3].
10. Record the stable state, monitoring owner, renewal owner, and review date.

Verification

Verify and archive:

1. registration status, renewal, contacts, recovery, and lock;
2. parent NS, glue, and DS;
3. matching SOA, NS, and required RRsets from every authority;
4. named recursive-resolver observations with times and TTLs;
5. DNSSEC secure or intentionally insecure state;
6. apex and www TLS, redirect, status, headers, content, CDN, and origin;
7. inbound and outbound email plus SPF, DKIM, and DMARC results;
8. all required third-party verification and subdelegation paths; and
9. representative user journeys.

Use the owned tool pathways for independent observations, then retain provider logs and control-plane exports as separate evidence.

Rollback

A launch rollback protects the registration while withdrawing or restoring services. Do not cancel or delete the domain as an operational rollback.

• If delegation is wrong, restore the captured prior registrar default or approved nameserver set once.
• If the zone is incomplete, keep authorities online and restore the exported baseline.
• If the website is unready, restore prior or parking web RRsets and keep both destinations available through cache overlap.
• If email is unready, preserve or restore the approved MX receivers and do not remove a working provider while queued messages can retry.
• If a new DS makes validation bogus, use the reviewed DNSSEC recovery sequence while preserving signing through relevant cache lifetimes.

After rollback, repeat registration, authority, resolver, DNSSEC, web, and email verification. Record remaining cache windows and the decision to reschedule.

Next step

Use Connect a domain to a website when the registration and authoritative zone already exist and the next change is specifically the web path.