Browse Team & Site Management

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.

5 min readUpdated 8 Aug 2026

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.

InputUse
example.comMain public domain
www.example.comSeparate www host when required by the plan
help.example.comDocumentation or another approved subdomain

Add the domain

  1. Open the BlockNinja account portal.
  2. Choose Domains.
  3. Select Add Domain.
  4. Enter the hostname in Domain Name.
  5. Under Attach to Site (Optional), choose the intended site or No site (add later).
  6. Review the hostname and attachment, then select Continue only when authorised.
The Add Domain dialog accepts a hostname without www as the example and can leave it unattached. The fictional example.com value is reviewed before the unselected Continue action.
The Add Domain dialog accepts a hostname without www as the example and can leave it unattached. The fictional example.com value is reviewed before the unselected Continue action.

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

  1. Open the new domain's details.
  2. Read the required record type, host/name, and target/value.
  3. Use the portal's copy control where available.
  4. 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.

CheckExpected result
Record typeExactly matches the current portal instruction
Host/nameRepresents the intended root or subdomain once
Target/valueMatches the copied value with no protocol or path added
Unrelated recordsRemain 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

  1. In the CMS, open System Status.
  2. Review DNS Health.
  3. Find the domain by its human-readable hostname.
  4. Compare Current Target and Expected Target privately.
  5. 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

  1. Wait until the domain is Verified and SSL is Secured.
  2. Open the exact HTTPS address in a private browser window.
  3. Confirm the intended site loads without a certificate warning.
  4. Test the main page and one deeper public page.
  5. 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