DNS Settings

| Field | Value ||---|---|| Audience | public || Page type | reference || Area | integrations || Updated | 2026-05-21 |

DNS Settings — the domain-level records that make a site live, verifiable, and connected.

DNS Settings is the SG-Dashboard area that governs domain-level truth for a SGEN site. The settings here decide which address visitors reach the site on, whether the address is enforced over HTTPS, and which external services can prove they own the relationship with the site.

A site can look complete inside the editor and still fail in production. The reason is almost always domain truth. If the preferred address is wrong, if HTTPS is not enforced, if verification records are missing — search engines, mail providers, and connected analytics will treat the site as unverified or unreachable. DNS Settings is where the site's live identity is set, before anything that depends on it can work.

This page is the Reference definition of the DNS Settings area. It covers the records SGEN expects, the controls SG-Dashboard surfaces, the dependencies that break when domain posture is incomplete, and the order of operations for a clean go-live.

What is this for?

Read this page when you want the structural definition of DNS Settings — what records the platform expects, what each control in SG-Dashboard does, and which downstream features fail when DNS posture is incomplete or wrong.

The page is a Reference definition. It states the rules and the dependency map. Per-domain configuration walk-throughs and registrar-specific record syntax live in the matching Guide pages.

Good use cases

• You are preparing a SGEN site for go-live and want to know which DNS records must be in place first.
• You are diagnosing why search, mail, or an integration is reporting the site as unverified.
• You are scoping a migration from another platform and want to confirm DNS handover before content cutover.
• You are explaining to a stakeholder why a domain change is not a minor edit.
• You hit a "the site loads but the integration says it cannot reach us" question and need to know where domain truth is set.

What NOT to use this for

• Per-registrar instructions for editing records — open the relevant Guide.
• Email sending configuration — open Email and SMTP Reference.
• Analytics or Search Console connection walkthroughs — open the matching integration Reference.
• Per-release shipped change — open What's New or Changelog.

How this connects to other features

• Integrations Overview — DNS Settings sits at the connection layer. Most integrations depend on a clean domain posture before they can connect at all.
• Email and SMTP — sending reputation depends on domain-level records (SPF, DKIM, DMARC where applicable) that originate at the DNS layer.
• Google Search Console — domain ownership is verified through DNS or HTML file, and the preferred domain set here becomes the canonical reported to Google.
• SG-Admin Overview — content editing happens in the admin, but the address that content is published under is decided in DNS Settings.

Before you start

You need the following before changing DNS Settings on a live site:

• Registrar access for the domain (or a contact who can apply DNS changes within minutes if needed).
• The exact preferred-domain form the site will run under — apex (example.com) or www (www.example.com). Pick one and keep it.
• A short maintenance window if the site is already live and the change will alter the public address.
• A rollback plan: the previous record values written down before you change them.

Where to find it

DNS Settings lives in SG-Dashboard under the advanced settings group, alongside Site Manager and Stage and Live. The exact menu position is documented in the platform's current navigation; in the admin/SG-Dashboard split, DNS sits on the SG-Dashboard side because it governs operational, dashboard-controlled site identity.

Steps

The steps below cover a typical go-live: a SGEN site that has been built and tested on a non-production address and is ready to take over the production domain.

1. Confirm the preferred domain in SG-Dashboard

Open SG-Dashboard, go to DNS Settings, set the preferred domain to the exact form you will run under. Choose one: apex (example.com) or www (www.example.com). Both are valid; one must be canonical and the other must redirect to it.

The preferred domain is the address SGEN treats as the public identity of the site. It is the address used in canonical tags, in sitemaps reported to search, and in links the platform constructs back to itself.

2. Apply the DNS records at the registrar

Apply the records SGEN reports for the chosen preferred domain. The platform reports the exact target values for the records it requires; copy them into the registrar exactly as shown. Records typically include an apex address record (or alias-style record at the apex where the registrar supports one), a www record, and the verification record SGEN issues for the site.

Wait for propagation. Most registrars report propagation within minutes to an hour; some take longer. The DNS Settings area surfaces verification status so you can confirm the records are visible to SGEN.

3. Enable Force HTTPS

Once the verification record is live and SGEN can confirm the domain points at the platform, enable Force HTTPS in DNS Settings. The platform handles certificate provisioning for the configured preferred domain.

With Force HTTPS on, any request to the unencrypted address is upgraded to the encrypted equivalent. Visitors, search crawlers, and integrations that probe the site all see the encrypted form. The unencrypted address stops being a separate surface and becomes a redirect into the canonical address.

4. Verify the go-live posture

After the records propagate and Force HTTPS is on, walk the verification checklist:

• The preferred domain loads and serves the SGEN site on HTTPS.
• The non-preferred form (apex if you chose www, or www if you chose apex) redirects to the preferred form.
• The unencrypted address redirects to the encrypted address.
• The verification status in DNS Settings reads as verified.
• Connected integrations that depend on the domain (Search Console, GBP, analytics, email sending) report the site as reachable on the new address.

What success looks like

A site whose DNS posture is complete behaves as follows:

• Visitors reach the site on one canonical address, encrypted, with no warning interstitials.
• Search engines record the preferred domain as canonical and do not split ranking signal between apex and www forms.
• Email sending — where the site sends transactional or marketing mail — passes the receiving server's domain-alignment checks.
• Integrations that verify domain ownership (Search Console, analytics, GBP) all report a verified state.
• The DNS Settings area in SG-Dashboard reports every record as verified.

What to do if it does not work

DNS-layer problems show up in many places. The list below names the common failure modes and where to look first.

• The site does not load on the new domain. Check the apex and www records at the registrar against the values SGEN reports. A single character difference is enough to break the route. Wait at least an hour for propagation before assuming the records are wrong.

• The site loads but the browser warns about the certificate. Force HTTPS may be on while the verification record is still pending. Resolve verification first; the certificate issues automatically once the domain is verified.

• Both apex and www show the site, but they show as separate addresses to search. One form has to be canonical and the other has to redirect. If both serve the site directly, the preferred domain redirect is not set; reopen DNS Settings and re-apply the preferred-domain choice.

• An integration reports the site as unreachable after a domain change. The integration is holding the old address. Reconnect the integration after the DNS change is verified; the reconnect updates the address the integration uses to probe the site.

• Email delivery drops after a domain change. Domain-alignment records (SPF, DKIM, DMARC where applicable) were not carried over to the new domain. Open Email and SMTP Reference and re-apply the records for the new domain.

• Search Console reports a verification failure. The verification method used at the old domain may not transfer. Re-verify domain ownership using the method (DNS TXT or HTML file) supported on the new domain.

Examples

Example 1 — A new site going live for the first time

A new business site is built on a non-production address. The team has bought yoursite.example at a registrar and is ready to switch.

1. The team sets the preferred domain in DNS Settings to yoursite.example (apex form).
2. SGEN reports the records to apply at the registrar — an apex record, a www record, and a verification TXT.
3. The team applies the records at the registrar. Within an hour, DNS Settings reports the verification record as visible and the apex record as pointing at SGEN.
4. The team enables Force HTTPS. SGEN provisions the certificate within minutes.
5. The team walks the verification checklist; everything reads as verified. They then update the customer-facing references (printed materials, social profiles, Google Business Profile) to the new address.

Example 2 — A site moving from another platform to SGEN

A business is migrating bakery.example from a legacy platform. The site is live on the legacy platform and needs to switch addresses with minimum downtime.

1. The team builds and tests the SGEN site until content matches the legacy site.
2. They set the preferred domain in DNS Settings to bakery.example and copy the records SGEN reports.
3. They lower the TTL on the existing records at the registrar a day before cutover; this shortens the propagation window when records change.
4. At cutover, they change the apex and www records to the SGEN-reported values.
5. Within the shortened TTL, visitors start reaching SGEN. The team enables Force HTTPS once verification reports green and walks the verification checklist.
6. They re-apply email domain-alignment records (SPF, DKIM, DMARC) for the new sending posture and reconnect Search Console and analytics so the address change is recorded.

Example 3 — A site whose preferred domain choice changes

A site has been running on www.shop.example for a year. A new SEO advisor recommends switching the canonical form to the apex shop.example. The site has search ranking and inbound links built up against the www form.

1. The team reopens DNS Settings, changes the preferred domain to the apex form.
2. The platform now treats shop.example as canonical and redirects www.shop.example to it.
3. The team monitors search behavior over the following weeks. Search engines re-crawl, recognize the redirect, and re-attribute ranking signal to the new canonical address.
4. Inbound links to www continue to work through the redirect; the team does not need to chase down every external link.

Constraints and boundaries

DNS Settings governs domain-level record truth. It is not a substitute for other operational areas:

• It does not configure email sending. Email and SMTP holds the sending posture; DNS Settings holds the records that prove the site owns the domain it sends from.
• It does not configure analytics. The analytics integration connects to the site once the domain identity is valid; analytics interpretation happens elsewhere.
• It does not configure search behavior. Search Console connects to the site once domain ownership is proven; ranking behavior is interpreted in the SEO area.

A routing or verification problem belongs in DNS Settings even when the visible symptom shows up in search, mail, or an integration. The dependency direction is one-way: integrations and downstream systems depend on a clean domain layer, never the other way round.

Public boundary

This page is intentionally public-safe. It does not name internal hostnames, internal verification token formats, or the registrar accounts the platform uses for non-production domains.

Related reading

• Integrations Overview — connection layer that depends on DNS posture.
• Email and SMTP — sending domain alignment.
• Google Search Console — domain ownership and canonical reporting.
• SG-Admin Overview — content editing area separate from domain governance.

Vocabulary cross-reference

• Preferred domain is the canonical form of the address (apex or www) that SGEN treats as the public identity of the site.
• Force HTTPS is the setting that upgrades unencrypted requests to encrypted and serves the site only on the encrypted form.
• Verification record is the registrar-side record that proves to SGEN the domain points at the right platform.
• Apex is the domain without a subdomain prefix — for example, example.com.
• WWW form is the www subdomain prefix — for example, www.example.com.
• Propagation is the time it takes for a DNS change to become visible to the global resolver network.
• Domain alignment is the receiving-server check that a sending domain has authorised the sender; supported by domain-level records.

Maintenance discipline

When DNS Settings changes across releases — new record type added, new verification flow, new preferred-domain control — update this Reference and the matching Guide so the public surface and the procedure stay aligned.

When the platform's certificate provisioning behavior changes, update the Force HTTPS section and the "what success looks like" checklist.

When a new integration depends on a domain-level record, add it to the "how this connects to other features" list and to the dependency callouts in the Examples.

---

Go-live order of operations

DNS Settings is the first item on a clean go-live, because almost every other item depends on a verified domain. The order below is the recommended sequence; skipping a step typically surfaces as a problem two or three steps later, where the cause is harder to trace.

1. Set the preferred domain in DNS Settings. Without this, SGEN does not know which form to treat as canonical.
2. Apply records at the registrar. Until the records propagate, nothing downstream connects.
3. Verify the verification record. SGEN reports verified state in DNS Settings; if it does not, do not proceed.
4. Enable Force HTTPS. Visitors and crawlers see one encrypted address; the certificate provisions automatically.
5. Connect Search Console. Ownership verification reuses the DNS verification or HTML file.
6. Connect analytics. The analytics integration needs to know which domain it is measuring.
7. Configure email sending posture. SPF, DKIM, and DMARC records belong at the DNS layer; align them once the domain is verified.
8. Connect Google Business Profile. Per-location records reference the now-verified domain.
9. Re-run the verification checklist. Every integration should report green before the site is announced.

Why DNS is the load-bearing layer

A domain setting is not minor because the user sees it rarely. It is load-bearing because every downstream system uses the domain as the proof that the site is the site it claims to be.

• Search engines use the domain to record canonical addresses and to attribute ranking.
• Mail receivers use the domain to verify that sent mail is authorised by the domain owner.
• Integrations use the domain to confirm they are connected to the right site, not an impostor.
• Visitors use the domain as the brand surface. A change here is a change visitors will notice.

DNS governance treats live identity and routing as first-order operational law, not a miscellaneous technical appendix.

## Related reading

Topic
Integrations Overview
Email and SMTP
Google Search Console
SG-Admin Overview

Scope

This Reference covers the platform-level shape of dns settings: what the surface is responsible for, how it relates to neighboring surfaces, and the structural boundaries that hold across releases. Operator how-to and per-release change land on the linked operator-facing or changelog surfaces, not here.

Reference shape

A minimal payload that this surface accepts or emits looks like:

{"site": "yoursite.example","surface": "dns-settings","actor": "hello@yoursite.example","timestamp": "2026-04-22T14:03:00Z"}

Use this shape when scripting against the surface or when reading audit logs that reference it.