A useful DNS support request identifies the name, expected result and last confirmed change. These details help separate a provider error, wrong delegation, cached answer and application problem without repeating changes unnecessarily.
IN THIS ARTICLE
01 Record the intended change
Write down the full hostname, record type, old value if known, new value and the service you are connecting. For a mail issue, include the MX destination and affected address. For a website issue, state whether the root domain, www or a different subdomain fails.
02 Check the manager
- Confirm the domain is in the correct client account.
- Refresh DNS records and inspect the current value.
- Open History & requests and note the last operation's status, time and reference.
- Read any zone lock, quota, permission or provider error.
- Run the propagation check for the exact hostname and type.
- Compare the public nameservers with the DNS service you are editing.
What evidence helps support diagnose the failing DNS answer?
For a website, include the URL and whether the browser shows a certificate error, wrong page, timeout or application error. For mail, include the test time, sender domain, recipient domain and returned delivery error. A message saying only that DNS is not working hides useful distinctions.
If you recently moved nameservers, enabled DNSSEC, changed a hosting package or edited an external DNS panel, mention it. Those actions can explain why the records displayed here differ from the answers visitors receive.
03 Send only the information needed
Do not send account passwords, API tokens, private keys, complete billing records or unrelated email content. A redacted screenshot can show the visible status, but include the error as text where possible. If you have a previous zone export, tell support that it is available and provide it through the secure ticket attachment option when relevant.
04 While the issue is being investigated
Keep the previous DNS service available during a planned migration and avoid repeatedly deleting/recreating the zone. If a change is still applying, wait for its final status or ask support to investigate the specific operation. Repeated retries can make the timeline harder to understand. When the records are confirmed correct but the service still fails, continue testing the web server, mailbox or application behind them.