Team & Site Management
Connect a domain and verify DNS and SSL
Add a public domain through the BlockNinja account portal, make the required DNS change, and verify domain and SSL status safely.
Goal
Connect an approved public domain to the correct BlockNinja site, make only the DNS change requested by the account portal, and confirm that both domain verification and SSL complete.
Before you begin
- Use a BlockNinja account Owner or Manager with access to the site.
- Have authorised access to the domain's DNS provider.
- Confirm the exact public domain and human-readable site name.
- Record the current DNS values before changing them.
- Schedule a safe change window when the domain already serves traffic.
Hazard: DNS changes can interrupt an existing website or email. Never copy a target from documentation, another tenant, or an old screenshot. Use the value shown for your domain in the current account portal.
Choose the domain form
Decide whether you are connecting the main domain, a www host, or another subdomain. Enter only the hostname requested by the form—without a protocol, path, or trailing slash.
| Input | Use |
|---|---|
| example.com | Main public domain |
| www.example.com | Separate www host when required by the plan |
| help.example.com | Documentation or another approved subdomain |
Add the domain
- Open the BlockNinja account portal.
- Choose Domains.
- Select Add Domain.
- Enter the hostname in Domain Name.
- Under Attach to Site (Optional), choose the intended site or No site (add later).
- Review the hostname and attachment, then select Continue only when authorised.

Read the domain status
The Domains list can show whether a domain is Pending or Verified, whether SSL is Secured, and whether it is Primary, a Subdomain, or Unattached. These labels answer different questions: verification proves the DNS path; SSL confirms encrypted public service; attachment associates the domain with a site.
Copy the current DNS instruction
- Open the new domain's details.
- Read the required record type, host/name, and target/value.
- Use the portal's copy control where available.
- Paste into a private change record and compare it character by character.
Targets are environment-specific. Do not put them in a public guide, screenshot, ticket title, or chat message.
Make the DNS change
At the authorised DNS provider, add or update only the requested record. Preserve mail, verification, and unrelated service records. Provider interfaces often display the root host as @ or an empty name; follow the provider's own convention.
| Check | Expected result |
|---|---|
| Record type | Exactly matches the current portal instruction |
| Host/name | Represents the intended root or subdomain once |
| Target/value | Matches the copied value with no protocol or path added |
| Unrelated records | Remain unchanged |
Wait for verification
Return to Domains and select Refresh. DNS updates can take time because providers and resolvers cache earlier answers. A Pending state immediately after the change is not proof of failure. Do not repeatedly rewrite a correct record while propagation is in progress.
Verify in CMS System Status
- In the CMS, open System Status.
- Review DNS Health.
- Find the domain by its human-readable hostname.
- Compare Current Target and Expected Target privately.
- Use Copy expected target only for the domain you are repairing.
Never expose targets, raw instance identifiers, or unrelated tenant domains in public evidence.
Confirm SSL and public routing
- Wait until the domain is Verified and SSL is Secured.
- Open the exact HTTPS address in a private browser window.
- Confirm the intended site loads without a certificate warning.
- Test the main page and one deeper public page.
- Check desktop and a 390-pixel-wide viewport for redirects or overflow.
Automatic SSL begins only after the platform can validate the domain. Do not weaken browser security or install an untrusted certificate as a workaround.
Choose primary and attachment deliberately
Attach the domain to the intended site only. If a Primary control is available, change it after the new domain is verified and the redirect plan has been reviewed. An Unattached domain is useful during preparation but should not be mistaken for a working public route.
Recover from a problem
- Pending for longer than expected: compare the live record with the current instruction and check for duplicate host labels.
- Current and expected targets differ: correct the authorised DNS record; never edit other domains to make the table look uniform.
- Wrong site opens: review the domain's site attachment before changing DNS again.
- Certificate warning: stop public launch, confirm Verified status, then wait for SSL rather than bypassing the warning.
- Existing service broke: restore the recorded previous DNS value and escalate with the change record.
- Domain was entered incorrectly: remove or correct only the unlaunched entry after approval.
Record the handoff
Record the public hostname, human-readable site name, DNS provider, change time, verification time, SSL result, reviewer, and rollback owner. Do not record account credentials, raw identifiers, private targets, or unrelated domains.
Completion check
The intended hostname is attached to the intended site, the portal shows Verified and Secured, private DNS-health comparison matches, HTTPS opens without warning, and a second operator has confirmed both routing and rollback evidence.
Publication gate: keep this guide private until a named reviewer has replayed domain addition with an approved development domain and verified SSL without exposing environment-specific values.
Related guides
Set your site identity and contact details
Set the public site name, description, contact details, localisation, and safe AI guidance, then verify where each value appears.
Back up and restore your site
Create an encrypted full-site backup, protect its password, verify completion, and preview a destructive restore before deciding whether to proceed.
A page is not visible
Route a missing or stale page through publication state, Full URL, Site Status, Menus, audience access, and site health without destructive retries.