DNS Lookup Online: Check A, MX, TXT and NS Records in Seconds
CodexFuse Team · 2026-10-28T15:35:10.053Z · 9 min read min read
Free DNS lookup: check A, MX, TXT and NS records for any domain in seconds, with plain-language explanations.
A dns lookup is a check that asks the public Domain Name System for the records published for a domain name, and shows where that domain currently points for its website, email, and verification services. It reads the internet's address book for a name, so you can see what is actually live rather than what you assume is live.
Most website and email failures are records pointing at the wrong server, an old record never removed, or a new record not yet spread.
What a DNS lookup actually shows you
DNS is a set of record types, each with one job. A lookup returns whichever type you ask for, and each type answers a different question.
| Record type | What it answers | Typical use |
|---|---|---|
| A | Which IPv4 address serves this name? | The website's server |
| AAAA | Which IPv6 address serves this name? | The website over IPv6 |
| MX | Which server receives mail for this domain? | Business email routing |
| TXT | What text rules are published here? | SPF, DKIM and ownership verification |
| NS | Which nameservers are authoritative? | Who controls the zone |
Checking only the A record tells you nothing about email. A site can load perfectly while mail fails, because the MX record points somewhere else entirely. Always check the record that matches the symptom.
Start from the symptom. Website not loading? Check A and AAAA first. Mail bouncing? Check MX, then TXT for SPF. Verification failing? Check TXT. This keeps a five-minute check from turning into an hour of guessing.
Why does the same domain show different DNS answers in different places?
Different answers usually mean caching, not a fault in the check itself. Records carry a time-to-live value, so resolvers keep an old answer until that timer expires, and different locations expire at different times. Your office may see the new server while a customer abroad still sees the old one.
Propagation therefore has a visible clock. A record with a TTL of 3600 seconds can take around an hour to be seen consistently, while a TTL of 300 seconds typically refreshes within about five minutes. Lowering the TTL a day or two before a planned move shortens that window.
Also check the exact hostname that is failing — www and non-www names can differ.
A worked example: the dental clinic whose email stopped after a move
The scenario (fictional): Northbridge Dental Clinic in Leeds moves its website to a new host on a Monday morning. The website works by lunchtime. By Tuesday, patients report that appointment emails bounce, and the clinic's inbox receives nothing from its contact form.
What the lookup showed: The A record pointed to the new host, 203.0.113.45, which explained why the website loaded. The MX record still pointed to mail.oldprovider.example, the previous host's mail server, switched off after the move. The TXT record contained an SPF rule naming only the old provider, so mail from the new contact form also failed authentication checks at some receivers.
What they did, in order:
- Confirmed the target first: they wrote down where mail was supposed to go before changing anything.
- Fixed MX, then TXT: they updated MX to the current provider, then updated SPF to include the new sending service.
- Checked again after the TTL: with a TTL of 3600 seconds, they re-ran the check after around an hour and confirmed MX and TXT had changed.
- Tested end to end: they sent test messages from the contact form and an outside mailbox, and confirmed both arrived.
How do you run a DNS lookup on CodexFuse?
You run it in three steps on the free DNS Lookup tool: enter the hostname you want to check, pick the record type that matches your symptom, and run the check to see the published records instantly. No software to install, and no account step before the check itself.
The tool page is deliberately short: enter a hostname, pick a record type — A, AAAA, MX, TXT, or NS — and look up. That suits how the check is used in a hurry, when you need one answer about one name. If you have just changed a record, note the TTL and re-check after it expires rather than concluding the change failed.
Do not edit records from a lookup result alone if you are unsure which provider should receive mail or traffic. A wrong MX change can stop email for a whole domain, and a wrong A change can take a site offline. Confirm the intended target first, then make one change at a time.
How to read the results without guessing
Use these checks to judge whether a result is good:
- Match the answer to the intention: does the A record point to the host you pay for, and does MX point to the provider holding your mailboxes?
- Look for leftovers: an old A record, a second MX record, or a stale TXT entry from a previous provider often causes intermittent failures.
- Check email authentication: SPF lives in TXT, and DKIM or DMARC entries should be present and current if your provider uses them.
- Compare www and non-www: if one loads and the other does not, the two names usually have different records.
If you use a VPN, a related check is worth running: a DNS leak test shows whether your queries escape the tunnel you think protects them.
CodexFuse is a fully managed, all-in-one IT platform on credits: its team can check your A, MX and TXT records, move your hosting and business email properly, and confirm the fix — so a DNS mix-up does not become a lost week of enquiries.
Get Started with CodexFuseWhat should you do when a result looks wrong?
When a result looks wrong, confirm the intended target, change only the record that is wrong, and re-check after its TTL expires before making further changes. Changing several records at once makes it impossible to tell which change fixed the problem.
Work from the symptom. If the site does not load, verify the A record and whether the server itself responds — DNS can be correct while the server is down. If mail bounces, verify MX, then SPF in TXT, then ask the receiving provider what rejection it logged. If verification fails, compare the exact TXT value character by character; a missing quote or extra space is enough to fail.
Also confirm you are editing the authoritative zone, shown by the NS record — edits elsewhere change nothing.
Before a move, read the startup owner's emergency guide to website migration — it covers the order of operations that prevents exactly this kind of email outage.
What this tool does not do
A lookup is a diagnostic, not a repair. The DNS Lookup tool shows published records; it does not edit them, check whether a server responds on a port, or prove mail will be delivered — only that routing records point somewhere.
It also cannot see private or internal DNS, which can override public records on one machine or network. Treat any single result as a snapshot, and confirm after the TTL when stakes are high.
When the fix is bigger than one record: moving to managed hosting and email
Many DNS problems are really fragmentation problems: domain at one company, hosting at another, email at a third, and nobody responsible for the whole picture. Each move becomes a hand-off, and each hand-off is a chance for an MX or TXT record to be left behind.
The managed alternative puts hosting, business email, security, and backups under one roof, so one team owns the DNS picture end to end. On CodexFuse that is a concrete workflow. You start an account and add credits on a pay-as-you-go basis — no subscription to cancel if needs change — then ask the team to handle the migration. They confirm where the website should point, where mail should route, and which TXT authentication records your provider needs, make changes in the right order, and re-check after the TTL rather than assuming the move worked because the homepage loaded.
Before touching a live site, a CMS detector check tells you what the site actually runs, and a disposable email checker helps spot throwaway addresses in signups. Use this decision rule: if you only need one answer about one domain, run the free check and act on it. If you fix DNS after every provider change, a managed, all-in-one setup is the fix, not a convenience.
Next step: run a free DNS check on your own domain today — A, MX, and TXT — and if anything points to a provider you no longer use, fix that record before it costs you enquiries. If the whole setup feels fragmented, move your hosting and business email to CodexFuse, on credits, fully managed, and let one team own the DNS picture for you.
Frequently Asked Questions
What does this check do?
A dns lookup queries public DNS for a domain's published records — such as A, MX, TXT, and NS — and shows where that domain points for its website, email, and verification. It is a diagnostic check, not an edit.
Is the CodexFuse DNS Lookup tool free?
Yes. The tool page states it is free with unlimited use: enter a hostname, pick a record type, and look up. Repeat the check after a DNS change to confirm propagation.
Why does my website work but my email does not?
Because they use different records. The website depends mainly on the A record, while email depends on MX and on TXT authentication records such as SPF. One can be correct while the other points to an old provider.
How long does a DNS change take to spread?
It depends on the record's TTL. A TTL of 300 seconds typically spreads within about five minutes, while a TTL of 3600 seconds can take around an hour. Re-check after the TTL rather than assuming a change failed.
Can a DNS lookup fix my DNS?
No. A lookup only shows published records. Fixing DNS means editing the records in the authoritative zone — the panel indicated by the NS record — and then re-checking to confirm the change.