DNS is the layer that makes your domain trustworthy to Gmail, Outlook, and every other inbox provider. When it is misconfigured, mailboxes stop sending, warmup stalls, and campaigns silently fail. This guide walks you through diagnosing and fixing DNS issues after your domain is already connected. If you have not connected a domain yet, see the domain setup guide first, this one picks up from there.
Read the section below before you change anything. It is the single most common way a DNS "fix" turns into a real outage.
InboxKit connects a domain in one of two ways, and the fix for almost every DNS problem depends on knowing which one applies to you.
Way 1: InboxKit-managed nameservers. You pointed your domain's nameservers at InboxKit (something like ns1.inboxkit-dns.com / ns2.inboxkit-dns.com). InboxKit now owns your DNS entirely and auto-configures SPF, DKIM, DMARC, and MX in the backend.
Way 2: Cloudflare-managed. Your domain's nameservers already point at Cloudflare. InboxKit does not need you to change anything, it connects via the Cloudflare API (once you add your Cloudflare API key under Settings > Registrar Credentials) and writes the required records into your existing Cloudflare zone automatically.
Go to Domains and open the domain in question.
Look at the nameservers currently shown. If they read ns1.inboxkit-dns.com / ns2.inboxkit-dns.com, you're InboxKit-managed. If they read something like xxxx.ns.cloudflare.com, you're Cloudflare-managed.
If you're not sure whether that domain currently has live, working email on it (an existing Google Workspace or Microsoft 365 setup you still rely on), stop and check that first. This is the check that matters most.
Changing nameservers replaces the domain's entire DNS configuration, not just the InboxKit-related records. If a domain still has an active Google Workspace or Microsoft 365 mailbox on it and you (or a support instruction) point its nameservers at InboxKit, the existing mail setup's MX and authentication records get wiped out and that mailbox stops receiving mail immediately. This has happened: a customer had live Google Workspace email running on a domain, switched its nameservers to InboxKit's while trying to connect it, and their existing Workspace email stopped receiving mail the same day. The only way back was to restore the original nameservers, or commit to fully migrating that domain's mail into InboxKit.
The rule: never change a domain's nameservers, in either direction, without first confirming what is currently running on that domain. If there is live email you need to keep, either leave the nameservers alone, or plan a proper migration (disconnect the domain from the old Workspace/tenant, connect it to InboxKit, then create fresh mailboxes) rather than switching nameservers as a quick fix.
If your domain is Cloudflare-managed and something in InboxKit tells you to change nameservers, that instruction is wrong for your setup. You do not need to touch nameservers on a Cloudflare domain. Connect your Cloudflare API key instead (Settings > Registrar Credentials > Add Registrar > Cloudflare) and let InboxKit write records via the API.
Jump to the section that matches what you're seeing:
Symptom | Go to |
Domain stuck on "Not Connected" after updating nameservers | Nameserver propagation and verification |
Domain's NS Status shows "Moved" | Nameserver status shows "Moved" |
SPF, DKIM, or DMARC shows red or "MISS" | SPF, DKIM, or DMARC shows red or "MISS" |
Only 5 of 7 DNS records are present, DKIM never turns green | DKIM stays unverified past the propagation window |
"Already in use with another Google Workspace" or Microsoft tenant error | Domain stuck in a previous Google Workspace or Microsoft tenant |
Your domain is on Cloudflare and you're being told to change nameservers | Before you touch anything |
A third-party checker disagrees with InboxKit's dashboard | Verifying with third-party tools |
Symptom: you connected a domain, updated the nameservers at your registrar, but the domain still shows "Not Connected" in InboxKit.
Checks, in order:
Confirm you updated the nameservers within 12 hours of connecting. If you connected the domain in InboxKit more than 12 hours ago and never updated the nameservers at your registrar, the connection has expired. Go to Domains, remove the domain, and re-add it under Connect Existing to get a fresh set of nameservers.
Confirm you copied the exact nameservers InboxKit generated, not your registrar's or another provider's default ones. It's easy to accidentally re-enter what was already there. Go to the domain in InboxKit, click Manage (or More), and re-copy the two nameservers shown.
Confirm there are no typos or extra spaces in the nameserver fields at your registrar.
Give it time. Propagation typically takes 2 to 48 hours, most domains finish in 4 to 8 hours. Click Check (or Refresh) on the domain in InboxKit to re-poll the current status rather than assuming it's stuck.
If your registrar shows "locked" domain settings, unlock the domain first, some registrars block nameserver changes while a domain is locked.
Escalate to support when: the domain still shows "Not Connected" more than 48 hours after you've confirmed the nameservers are correct and saved at the registrar. Include the domain name and a screenshot of the nameservers shown at your registrar.
Symptom: a domain that was previously working now shows NS Status "Moved," and mailboxes or warmup on that domain have quietly stopped working even though other parts of the dashboard still look fine.
What it means: the domain's live nameservers no longer match what InboxKit has on record. This usually happens when a registrar-side change, renewal, or transfer silently reset the nameservers back to the registrar's default. It is a common, easy-to-miss cause of stalled warmup and mailbox connectivity, worth checking any time sending "just stopped" with no obvious error.
How to find every affected domain: go to Domains, open Filters, select NS Status, and filter to "Moved." This surfaces every domain with the mismatch in one view instead of checking domains one at a time.
How to fix it:
Open the domain, click Manage to regenerate its nameservers.
Go to Settings > Registrar Credentials and connect your registrar account (auto-sync is supported for registrars like GoDaddy and Porkbun; it is not available for every registrar, so if yours isn't listed, you'll need to update nameservers manually at your registrar instead).
Once connected, go to Domains, select the affected domains, open Bulk Actions, and choose Sync Nameservers. This updates all selected domains automatically instead of one at a time.
Allow 12 to 48 hours for the resynced nameservers to propagate.
If auto-sync fails for a domain that should be supported, the most common causes are: the domain isn't actually registered with the connected registrar (double-check it wasn't transferred), the domain is locked at the registrar (unlock it first), or the registrar is rate-limiting bulk requests (retry in smaller batches of domains rather than all at once).
Escalate to support when: sync keeps failing for a domain you've confirmed is unlocked and registered with the connected, supported registrar.
Symptom: the DNS tab for a domain shows SPF, DKIM, or DMARC as red or "MISS," usually right after connecting a domain, adding mailboxes, or making any nameserver change.
What to know first: you do not add these records yourself in the vast majority of cases. Once your domain is connected and mailboxes are created on it, InboxKit configures SPF, DKIM, DMARC, and MX automatically in the backend. A red status here is almost always a propagation delay, not a configuration you need to fix by hand.
Checks, in order:
Open the DNS tab for the domain and click Refresh to recheck the current status, rather than relying on a screen you loaded a while ago.
Give it time. Propagation after any domain or nameserver change can take anywhere from a few minutes up to 24 to 48 hours, most complete in 4 to 8 hours.
If you're checking manually, confirm the record type (TXT vs. CNAME), the host name (usually @), and that there are no extra spaces or typos in the value shown, in case you're looking at a record you added yourself for something unrelated.
If a third-party tool (a sequencer's own verification, or a DNS checker) shows a different result than InboxKit's dashboard, see Verifying with third-party tools below before assuming InboxKit is wrong.
Escalate to support when: records are still red 48 hours after the domain or nameserver change, or a third-party tool keeps disagreeing with InboxKit's dashboard for more than 24 hours after you've confirmed propagation should be complete.
Symptom: you're seeing only 5 DNS records instead of the usual 7, and DKIM specifically never turns green no matter how long you wait past the normal propagation window.
What's actually happening: the two missing records are almost always the DKIM selector1 and selector2 CNAME records. These are generated by Google Workspace itself, not by InboxKit, and they only appear once the domain has been fully freed from any previous Google Workspace it was linked to. If your domain shows this pattern, check first whether you're also seeing an "already in use with another Google Workspace" message, see Domain stuck in a previous Google Workspace or Microsoft tenant below. That is very often the root cause here, and it is not something you (or InboxKit) can force by re-adding the record manually, even if your domain is Cloudflare-managed and you technically have access to the DNS zone.
What to do:
Confirm whether the domain has ever been connected to a Google Workspace before, under a previous owner, a former employee, or an old cancelled setup.
If yes, submit the Google Domain Recovery form (see the next section) to free the domain.
Once freed, the mailbox reactivates and all 7 records, including both DKIM selectors, populate automatically. You don't need to (and can't) add them by hand.
Escalate to support when: the domain has been confirmed freed from any previous Workspace for more than 48 hours and the DKIM selector records still haven't appeared. Include the domain name and confirmation of when the Google recovery form was submitted or approved.
Symptom: you see an error like "already in use with another Google Workspace" or "Already in use in another Google Workspace. Remove from there," or, on Microsoft/Azure mailboxes, sign-in or provisioning fails because the domain is still attached to an existing Microsoft 365 tenant. A newly purchased mailbox stuck on "Scheduled" or "Processing" for many hours often traces back to this same cause.
Why it happens: the domain was previously connected to a Google Workspace or Microsoft tenant, sometimes by a former owner, sometimes from your own account if a workspace was cancelled without being properly deleted. Google and Microsoft won't let a second Workspace/tenant claim a domain that's still linked to another one, even a defunct one.
How to fix it (Google):
Ask yourself first: has this domain ever been used with InboxKit before (an old, cancelled workspace on your own account)? If so, tell support before you do anything else, this can often be freed directly from the backend, faster than the form route.
Otherwise, submit the Google Domain Recovery form: toolbox.googleapps.com/apps/recovery/domain_in_use. If you're unsure how to fill it out, ask support for the walkthrough.
Google typically releases the domain within 24 to 48 hours after the form is submitted.
If you still have access to the old Workspace, it's faster to just delete it from the admin console yourself (Admin console > Subscriptions) rather than waiting on the recovery form.
How to fix it (Microsoft/Azure): the domain needs to be fully detached from the existing Microsoft tenant before it can be reconnected. If you have access to the old tenant, remove the domain from it there. If you don't, you'll need to request a domain release through Microsoft support, InboxKit cannot force this from its side. If you're blocked and need mailboxes running quickly, setting the domain up with Google as the provider instead avoids the tenant-release wait entirely.
Escalate to support when: the Google recovery form link 404s, the domain was previously an InboxKit customer's own workspace, or 48 hours have passed since submitting the form with no resolution. For Microsoft/Azure, escalate once you've confirmed the domain is detached from the old tenant but InboxKit still won't provision on it.
It's reasonable to double-check InboxKit's dashboard with an outside tool, tools like DNS Checker, EasyDMARC, or MXToolbox are all fine for a second opinion. But know what you're looking at:
If a third-party tool shows green/pass and InboxKit shows red/MISS (or the reverse), this is very often a caching or sync delay on whichever tool you're looking at, not a real misconfiguration. Give both sides another look after an hour or two before concluding something is broken.
If your sequencer's own DNS verification shows "MISS" while both InboxKit and outside checkers show the records resolving correctly, that's usually the sequencer's own cache or verification cadence, not your actual DNS. It will typically catch up on its own; if it doesn't, that's worth raising with the sequencer's support team in parallel.
DKIM alignment issues that only show up as delivery problems (not as a red badge) are sometimes caused by the sending domain in the message headers not matching the signing domain, or by something in the sending path (like email forwarding) altering the signature. If your records all show green everywhere but you're still seeing authentication-related bounces, mention this explicitly when you contact support, it points to a different kind of check than a simple record-presence issue.
Self-serve the checks above first, most DNS issues resolve within the normal propagation window without anyone needing to intervene. Contact support when:
Any of the "Escalate to support when" conditions above are met.
You're not sure whether your domain is Cloudflare-managed or InboxKit-managed, and there's live email on it you can't afford to lose. Ask before making any nameserver change.
A DNS status has been wrong for longer than the stated propagation window (48 hours in almost every case above) and a Refresh/Check hasn't updated it.
You're getting conflicting instructions between what you see in the dashboard and what a sequencer or third-party tool is telling you, and it's been more than 24 hours.
Include this when you reach out, it's what support will ask for anyway, so providing it up front gets you a faster answer:
The exact domain name(s) affected.
What you're seeing (a screenshot of the DNS tab, or the exact error text) and when it started.
Whether this domain has ever been connected to a Google Workspace or Microsoft 365 tenant before, under this account or a previous one.
Whether the domain is Cloudflare-managed or InboxKit-managed (check the nameservers shown on the domain page).
What you've already tried (nameserver update, Refresh/Check, waiting a specific number of hours) and when.
If relevant, your sequencer platform and any conflicting result it's showing you.
