# Guided DNS setup (/guides/guided-dns-setup)



Publishing DKIM, MAIL FROM and DMARC records by hand is the step where most domains stall — a typo in a
CNAME, a record added to the wrong zone, or a trailing dot in the wrong place, and the domain never
verifies. Guided setup removes the copying and pasting: Sendly hands the exact record set to a DNS
connect flow that either writes the records into your zone for you or walks you through your own
provider's interface, one record at a time.

Guided setup is powered by [DoDomain](https://dodomain.io), and it also keeps watching your zone after
setup finishes, so a record that quietly disappears months later becomes a notification instead of a
mystery bounce.

<Callout title="Availability" variant="warn">
  Guided setup only appears when it is enabled on the deployment you're using. It is on for Sendly Cloud.
  A self-hosted Sendly needs a `DODOMAIN_SECRET_KEY` (and `DODOMAIN_WEBHOOK_SECRET` for drift monitoring)
  configured — without them no button is drawn at all, and the
  [manual record path](/guides/verifying-domains&#x29; is the only path. If the feature is turned off after a
  session was started, Sendly reports &#x2A;*"Guided DNS setup is not available on this deployment."**
</Callout>

## Starting guided setup [#starting-guided-setup]

<div className="fd-steps [&_h3]:fd-step">
  ### Add the domain [#add-the-domain]

  In your project settings, open the **Domains** tab and add your domain in the **Add Domain** card. Sendly
  creates the SES sending identity, generates the DKIM tokens, and expands the record table for the new
  domain straight away.

  ### Choose the automatic path [#choose-the-automatic-path]

  On a domain you have just added, the record table opens with a callout at the top:

  > **Let us publish these records for you**
  > We'll take you through your DNS provider and add every record below — no copying and pasting.

  Press **Set up automatically** to start. **I'll do it manually** dismisses the callout for that domain and
  leaves you with the copy-paste table.

  You can also start the flow at any time from the **Guided setup** button in the header of the record
  table — it sits next to the **DNS Configuration Required** / **View DNS Records** toggle.

  ### Read the provider hint [#read-the-provider-hint]

  Before you commit, Sendly runs a free pre-flight against your domain's nameservers and prints a small hint
  under the **Guided setup** button:

  | Hint                               | What it means                                                                                                        |
  | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
  | `One-click available · Cloudflare` | Your zone is on a provider Sendly can write every record to. Authorize the connection and you're done.               |
  | `Guided steps`                     | Sendly can't write to this provider, so the flow shows step-by-step instructions for your specific DNS host instead. |

  The hint is deliberate: "one-click" promised and not delivered is worse than never promising it. The
  pre-flight only reads your nameservers — it creates nothing and costs nothing.

  ### Complete the flow [#complete-the-flow]

  The connect flow opens in a sheet over the dashboard, themed to match it. If your browser blocks the
  embed (a content blocker, a strict CSP, an offline tab), Sendly opens the same flow in a new tab instead —
  nothing is lost. When the flow finishes it returns you to your **Domains** settings.

  ### Let Sendly re-check the domain [#let-sendly-re-check-the-domain]

  As soon as the records land, Sendly re-checks the domain against Amazon SES automatically. The **Verified**
  badge flips when SES confirms the DKIM records — not when the connect flow says it published them.
</div>

## What guided setup publishes [#what-guided-setup-publishes]

The record set is the same one the [records table](/guides/verifying-domains#dns-records) shows, in the same
order — there is no second, hidden prescription:

* the **3 DKIM CNAMEs** at `<token>._domainkey.yourdomain.com`
* the **custom MAIL FROM MX and SPF TXT** at `sendly.yourdomain.com`
* the **DMARC TXT** at `_dmarc.yourdomain.com` (`v=DMARC1; p=none;`)
* the **inbound MX at your root domain**, but *only* when your project uses Sendly mailboxes

<Callout title="Your existing email is never taken over" variant="warn">
  The root-domain MX record is the one record in the set that could redirect your company's existing email
  (Google Workspace, Microsoft 365). Guided setup only ever writes it when Sendly mailboxes are configured
  for the deployment — the legacy inbound-email MX stays a copy-paste row you opt into deliberately, and is
  never automated. See [receiving emails](/guides/receiving-emails).
</Callout>

## One-click versus guided steps [#one-click-versus-guided-steps]

Sendly asks DoDomain which *tier* your DNS provider qualifies for, and only the top tier is treated as
automatic:

* **Cloudflare (one-click).** You authorize the connection against your Cloudflare account and the full
  record set — CNAME, MX, TXT — is written into your zone for you.
* **Every other provider (guided steps).** The flow identifies your provider and shows the records with
  instructions written for that provider's control panel. You still paste the values, but into the right
  screen with the right field names.

Providers that support Domain Connect fall into the second group on purpose. Domain Connect's automated
templates can only carry a single CNAME or a verification TXT — they can never write MX, SPF, DKIM or DMARC,
and every record Sendly prescribes is one of those.

## Drift monitoring [#drift-monitoring]

After a successful connection, DoDomain keeps checking the records it published. Sendly's own resolver
sweep runs every six hours; drift monitoring is what watches the zone in between.

When a record that *was* resolving stops resolving:

* an amber **DNS Drift** chip appears in the domain's **DNS Health*&#x2A; row, beside the DKIM / SPF / DMARC /
  MAIL FROM chips. Its tooltip reads: &#x2A;"A record you published stopped resolving. Open the DNS records
  below and re-publish the ones that no longer match."*
* a **Domain DNS Drift Detected** notification is sent to the project's members — in the notification bell
  and as a push, deep-linked to the Domains settings — and to your operators' alert channel.
* a **Re-check DNS** button appears next to **Guided setup** in the record table header.
* **Guided setup** is offered again, even on a domain that is already verified, so you can re-publish the
  missing records the same way you published them the first time.

<Callout title="Drift is not the same as unverified" variant="idea">
  Drift never changes the **Verified** badge. Amazon SES is the only authority on verification, and SES may
  still consider the identity verified at that moment because of DNS caching and TTLs. Drift is an early
  warning that a record went missing — act on it before SES notices and sending starts failing.
</Callout>

### Re-check DNS [#re-check-dns]

**Re-check DNS*&#x2A; asks DoDomain to look at your zone again right now instead of waiting for its next
scheduled pass. It is a request, not an answer: the check runs on their side and the verdict arrives a
moment later, which is why the confirmation reads &#x2A;*"Re-check started — we'll update the status
automatically."** The chip clears itself once the records resolve again.

Asking twice in quick succession is refused with &#x2A;*"This domain was just re-checked. Give DoDomain a few
minutes before asking again."** — a wait, not a failure.

## Troubleshooting [#troubleshooting]

### The Guided setup button isn't there [#the-guided-setup-button-isnt-there]

Three reasons, in order of likelihood:

1. **The domain is already verified and healthy.** There is nothing to guide, so the button is hidden. It
   comes back if the domain drifts.
2. **The deployment doesn't have guided setup enabled.** Self-hosted installs need DoDomain credentials —
   see the callout at the top of this page.
3. **The record table is collapsed.** The button lives in the record table header; expand
   **DNS Configuration Required** / **View DNS Records** to see it.

### "A guided setup session was just started for this domain" [#a-guided-setup-session-was-just-started-for-this-domain]

Each domain can only start one session per minute. This is a double-click guard, not a limit on how many
times you may use the feature — wait a moment and press the button again.

### The sheet didn't open, or opened in a new tab [#the-sheet-didnt-open-or-opened-in-a-new-tab]

The connect flow is an embedded frame, and content blockers, corporate proxies and strict browser settings
can prevent it from mounting. Sendly detects that and opens the same flow as a full page in a new tab. The
flow is identical; finish it there.

### Guided setup finished but the domain still says Pending [#guided-setup-finished-but-the-domain-still-says-pending]

Publishing a record and a receiver *seeing* it are different events. DNS changes can take up to 48 hours to
propagate, and SES will not flip the domain to **Verified** until it reads the DKIM records itself. Use the
refresh button on the domain row to re-check, and see
[records not verifying](/guides/verifying-domains#records-not-verifying) if it stays pending past that.

### "Guided setup did not finish for yourdomain.com" [#guided-setup-did-not-finish-for-yourdomaincom]

The flow was started but ended without publishing. Nothing is broken and nothing was half-written that you
need to undo — start it again, or add the records by hand from the table below the message.

<Cards>
  <Card title="Verifying domains" href="/guides/verifying-domains">
    The full record set, the manual path, and what each record does
  </Card>

  <Card title="Receiving emails" href="/guides/receiving-emails">
    Inbound MX setup for triggering workflows from incoming mail
  </Card>
</Cards>
