For domain owners and authorised administrators
Use actual provider values and preserve existing services. This guide explains decisions and checks without publishing a universal zone or assuming who hosts your DNS.
Step 1 of 9
In this guide
Record the domain symptom and recent change
Record the domain symptom and recent change
Record the exact affected hostname or email domain, error, time and recent approved change. Check spelling and distinguish the bare domain, www and other subdomains. Is only the website affected, only sending/receiving email, or several services? Does it fail for more than one person or network? Avoid repeatedly sending the same message or creating more changes while the cause is unclear.
A browser cannot-find-server message suggests a lookup path to investigate; a certificate warning, server error or missing web page can occur after a name resolves. Likewise, an Outlook sign-in or mailbox quota fault is not automatically a DNS fault. Use the actual error and service rather than treating every connection problem as propagation.
If nameservers, ownership, mail routing or content changed without authority, contact the genuine registrar/DNS and security owner promptly through a known channel. Preserve relevant evidence. Do not follow an unexpected renewal email, disclose account codes or bypass a certificate warning to continue troubleshooting.
Record the exact name, service, error and change. Separate lookup, website and mailbox failures, and escalate unauthorised changes promptly.
Next: Identify registration, authoritative DNS and service ownersIdentify registration, authoritative DNS and service owners
Identify registration, authoritative DNS and service owners
Identify the registrar responsible for registration, the nameservers currently delegated for the domain, the authoritative DNS host, and the website/email providers. These can be different organisations. Use existing authorised account records or the responsible administrator; do not assume the dashboard containing an editable zone is the zone the internet currently uses.
Confirm registration and account/service status through the genuine provider. Expiry, verification or a provider hold can need its own resolution; a transfer lock is not the same as a DNS hold. ICANN explains domain status codes; ask the registrar to interpret the actual extension and status rather than unlock or transfer a domain as an experiment.
Before any record or delegation change, preserve the existing zone, settings, relevant service instructions and a specific rollback plan with the authorised owner. Inventory website, mail, verification, subdomain and other service dependencies. Use secure access without sharing passwords or recovery codes. Do not cancel the old DNS or email service just because a new account has been created.
Find the actual delegated DNS host and responsible service owners, confirm status and preserve the existing configuration. An editable zone or transfer lock is not proof of the cause.
Next: Compare authoritative records with the intended serviceCompare authoritative records with the intended service
Compare authoritative records with the intended service
Have the DNS owner compare the records served by the authoritative nameservers with the approved configuration and recent change. Website address/alias records, mail-routing records and verification/authentication records have different purposes. The bare domain and www need their own intended handling. Do not copy an example address from an article or another customer’s domain.
Compare authoritative answers with the actual resolver path used by affected visitors. Record the hostname, record type, answer/error, resolver and time. Missing or wrong authoritative data is different from an older cached answer. A green result from one online checker does not establish every service or visitor, and private internal names should not be submitted to public tools.
If the zone was moved, review whether required records were transferred and whether the delegated nameservers are correct. DNSSEC trust records also need coordinated handling. Do not replace the whole zone, switch public resolvers, disable validation or change nameservers merely because one lookup failed.
Compare exact authoritative records, intended provider values and the affected resolver path. Preserve all service dependencies and distinguish wrong source data from cached results.
More checks6 detailed checks
Resolve lookup, delegation and validation failures
Resolve lookup, delegation and validation failures
Use the preservation and owner checks before repairs. Confirm the exact requested name has the intended records in the live authoritative zone, and that delegation reaches the correct functioning nameservers. Ask the provider to investigate missing names, unreachable authoritative service or inconsistent zone data. A working www address does not prove the bare domain is configured correctly.
A non-existent-name result and SERVFAIL are different. SERVFAIL can have several causes, including a DNSSEC trust mismatch after a provider change. DNSSEC provides a chain of trust for DNS data; it is not the same as website TLS encryption. Have the registrar/DNS operator assess the actual delegation and signing chain using supported procedures.
Do not disable validation, remove trust records or bypass security globally as a generic fix. A coordinated provider migration can require specialist sequencing and verification. If resolution is correct but the site returns a certificate or application error, route that to the hosting/website owner instead of continuing to edit unrelated DNS records.
Repair the identified authoritative/delegation problem with the owner. Keep DNSSEC and hosting faults distinct; an error code does not justify a blanket security or zone reset.
Next: Verify website, mail and record the remaining scopeReview mail routing and authentication after domain changes
Review mail routing and authentication after domain changes
After preserving the current zone, identify the intended active mail provider and compare its actual required records with the authoritative answers. A nameserver change can leave mail records behind at the old host even when the new website works. Separate incoming delivery, outgoing rejection/authentication and an app’s connection/sign-in symptom.
MX records guide incoming mail routing; changing them does not move historical messages or create the destination mailboxes. Confirm all required recipients, aliases and supported shared/special arrangements are ready before a planned cutover. Use the provider’s actual targets and agreed design; multiple old/new targets are not a safe migration or backup strategy by default.
Have the mail owner review required service discovery and sending authentication, including all legitimate senders. Do not add competing SPF policies, replace the entire TXT set, disable protections or delete old mailboxes to silence an error. Preserve a minimal relevant bounce/error privately for the responsible provider. If migration is intended, use the migration planning guide for data and cutover scope.
Check the intended incoming path, prepared recipients and legitimate sending services. Routing changes do not migrate old mail, and a working website is not mail verification.
Next: Verify website, mail and record the remaining scopePrepare a custom Microsoft 365 email domain
Prepare a custom Microsoft 365 email domain
Confirm the organisation controls the exact domain and is using its intended Microsoft 365 tenant with an authorised administrator. Preserve current DNS and plan the mail/data transition first. Adding a domain, proving ownership, assigning addresses and changing mail routing are separate actions; none should be assumed to complete the others.
Use the tenant’s current domain setup instructions and exact verification value. Microsoft explains where to obtain the required DNS values. Publish the required verification at the actual authoritative host; do not invent the token or use a generic example. TXT ownership verification alone does not redirect incoming mail.
Prepare the required users/mailboxes, addresses and migration arrangement before applying the approved routing records. Review any automatic DNS-change proposal for its full effects on existing services. Follow the current Microsoft connection guidance with your administrator; do not blindly replace existing mail or authentication records. Keep the old source available until agreed acceptance and retention requirements are met.
Use the correct tenant and exact authoritative verification values, then prepare recipients and a controlled routing transition. Domain verification is not mail migration or cutover.
Next: Verify website, mail and record the remaining scopeAllow for record caching without blind waiting
Allow for record caching without blind waiting
If authoritative data is correct, the DNS owner can compare affected recursive answers and the relevant cache lifetimes. Previously received positive or non-existent-name answers can remain cached. Lowering a new record’s TTL does not retroactively remove an earlier negative answer, and clearing one device does not clear every upstream resolver.
Do not promise that all changes finish in a fixed number of hours or wait indefinitely on a wrong zone. Record what changed, the prior relevant lifetimes, current answers and the next evidence-based recheck. The responsible provider should investigate persistent errors, inconsistent authoritative answers or a validation fault rather than repeatedly reset the clock with more edits.
Use the network’s approved resolver configuration, particularly on managed networks where internal and public answers can legitimately differ. Do not bypass filtering, validation, VPN or private DNS settings to make a public checker agree. Website content caches and browser cookies are separate layers; clearing them does not publish a missing DNS record.
Use correct authoritative data and relevant cache evidence to set a recheck. Avoid fixed propagation guarantees, repeated edits and network/security bypasses.
Next: Verify website, mail and record the remaining scopeVerify website, mail and record the remaining scope
Verify website, mail and record the remaining scope
Check representative public names and normal website access from the agreed contexts, with a valid certificate and expected content. Have the authorised owner compare relevant authoritative and recursive records, including validation where applicable. Record times, context and any remaining differing results. Do not enter private accounts through a warning or submit real leads/orders as a website test.
For mail, agree harmless test messages with the intended participants and confirm actual receipt and reply on the required incoming/outgoing paths. Review relevant provider delivery/authentication evidence where authorised. Do not send unsolicited mail or expose private message headers. A Sent item, one successful address or working Outlook sign-in does not establish every recipient, sender or client.
Record which names, mailboxes, services and contexts were checked, unresolved items, owners and the next recheck. Keep historical data/source services according to the migration/retention plan. If a change causes a new fault, use the agreed rollback and assess the actual dependency rather than delete accounts or repeatedly overwrite records.
Verify intended website and agreed mail paths with minimal safe evidence, recording unchecked services and follow-up. Saved records and one successful test are not whole-domain acceptance.
Back to the symptom checkerGet help from the responsible domain and mail owners
Get help from the responsible domain and mail owners
Contact the genuine registrar for registration/status/access issues, the authoritative DNS operator for delegation/records/signing, and the relevant website or mail provider for its service. They may need a coordinated handover. Give the exact public name, affected service, error, time and approved change, with private data removed. Do not send passwords, MFA/recovery codes or unrestricted account exports.
Our domain name management and Microsoft 365 setup pages can start a scoped discussion. Agree authority, preservation, records, service readiness, rollback and verification before work. A generic DNS reset or provider transfer is not a substitute for diagnosis.
For unexpected access/ownership changes or suspected redirection, keep the incident route active even if one service starts working. For planned data movement, keep the migration acceptance separate from DNS resolution. Record the responsible next action and limitations rather than claim all mail and web services are restored after a single lookup.
Route each problem to the responsible owner with minimal evidence and clear authority. Keep incident, registration, migration and service acceptance distinct.
