DNS Records Explained for Business Owners

The directory nobody checks until something vanishes

Nobody thinks about DNS until an email stops arriving or a website goes dark after a routine domain renewal — and by the time that happens, whatever record caused it has usually been sitting there, wrong, for weeks. DNS (the Domain Name System) is the internet's directory service: it translates a human-readable name like yourbusiness.com.my into the technical addresses that computers actually use to find your website, your mail server, and everything else attached to your domain. Understanding the handful of record types that make it up is one of the highest-leverage half-hours a business owner can spend on their own infrastructure.

Registrar, zone, and records — three different things

A domain registrar is the company you paid to register the domain name itself; that purchase gives you the right to control what's called the DNS hierarchy under that name. A DNS zone is where the actual records for your domain live — it might be hosted by your registrar, your web host, or a separate DNS provider entirely (Microsoft Learn — DNS zones and records). These are frequently three different companies, which is exactly how domains end up half-controlled by nobody in particular after a website project ends or a freelancer moves on.

A and AAAA records: where the website itself lives

An A record maps a hostname to an IPv4 address — the "93.184.x.x"-style address that's still the backbone of most internet routing. An AAAA record does the same job for IPv6, the newer, much larger address format written in hexadecimal. Get either of these wrong, or leave one pointing at an old server after a migration, and visitors are sent to a server that either doesn't answer or serves the wrong thing entirely.

CNAME: an alias, not a destination

A CNAME record doesn't point to an IP address at all — it points to another domain name, and tells DNS to look up that name's records instead. It's how www.yourbusiness.com is commonly aliased to yourbusiness.com, or how a subdomain gets pointed at a third-party service like a help desk or landing-page tool without you needing to track that provider's changing IP addresses yourself.

MX: where email actually goes

MX (Mail Exchanger) records tell the wider internet which mail servers are authorised to receive email for your domain. Each MX record carries a priority number — lower numbers are tried first — so a domain can list a primary mail server and one or more fallbacks. Get the MX records wrong, missing, or pointed at a mail platform you switched away from months ago, and incoming mail either bounces back to the sender or silently vanishes into a server nobody is checking. This is one of the most common causes of "we never got that email" that turns out to have nothing to do with spam filters.

TXT: the record that does almost everything else

A TXT record simply stores arbitrary text against a domain name. Originally that was for human-readable notes, but TXT records are now the mechanism behind most domain verification (proving to Google, Microsoft or another platform that you control the domain) and — critically — email authentication. Under RFC 7208, the standard that defines it, SPF records must be published using the TXT record type; a separate, dedicated "SPF" record type was deprecated and modern DNS providers no longer support it (Microsoft Learn).

SPF, DKIM and DMARC: the anti-spoofing trio

These three mechanisms work together to stop someone else from sending email that appears to come from your domain — a common tactic in phishing.

SPF (Sender Policy Framework) lets you publish, as a TXT record, the list of mail servers authorised to send email on behalf of your domain, so a receiving server can check whether an incoming message actually came from one of them.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing mail; the receiving server retrieves your public key from DNS and verifies the signature matches, confirming the message wasn't altered in transit.

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of both. It tells receiving mail servers what to do when a message fails SPF or DKIM, and it requires "alignment" — the domain that passed authentication must match the domain the recipient actually sees in the From address, which is what stops an attacker from passing SPF on some unrelated domain while spoofing yours in the visible sender field.

When these are missing or misconfigured, one of two things typically happens: legitimate marketing or transactional email starts landing in spam (or gets rejected outright by stricter mail providers), or — if they're entirely absent — the domain is left easier to spoof convincingly in a phishing attempt against your own customers.

NS records: the real control point

An NS (Name Server) record specifies which servers are authoritative for your domain — meaning, whichever party controls those nameservers controls where every other record for that domain ultimately resolves. This is the reason NS records matter more than any individual A or MX record: change who holds the nameservers, and you can redirect the website, the email, and everything else attached to the domain, all at once, without touching a single other record.

For a Malaysian .my domain, MYNIC is the .my registry; registration itself runs through MYNIC-accredited registrars, and that registrar is where your login and account live. MYNIC does not host DNS, and a .my domain supports up to six nameserver entries (MYNIC). Whoever has login access to that MYNIC account — or to whichever registrar account holds an international domain — effectively has final say over the entire domain, regardless of who built the website or manages hosting.

Why domain control matters more than which host you pick

A domain with no transfer protection can, in principle, be moved to another registrar by anyone who obtains the account credentials or an authorisation code. Registrar transfer locks (visible in WHOIS records as a status like clientTransferProhibited) block transfer requests outright until deliberately removed, and a small number of registries offer an even stronger "Registry Lock" that requires manual, out-of-band verification — a phone call or secure passphrase — before any change goes through. Separately, DNSSEC cryptographically signs DNS responses so a resolver can verify they haven't been tampered with in transit, protecting against spoofing and cache-poisoning attacks that DNS wasn't originally designed to resist (IBM).

TTL, and why "it hasn't updated yet" is normal

Every DNS record carries a TTL (Time to Live) value, in seconds, that tells other servers how long they're allowed to cache that record before checking again (Microsoft Learn). A record with a one-hour TTL can take up to an hour to update everywhere; a record with a 24-hour TTL can take up to a day. In the worst case, some resolvers ignore TTL guidance and cache longer than they should, which is why changes can occasionally take up to 48 hours to be visible everywhere. Lowering the TTL a day or two before a planned change — a server migration, a mail provider switch — is standard practice specifically to make the eventual cutover faster.

A short checklist worth actually doing

Know, in writing, who holds the login to your domain registrar account and who controls your DNS zone — and make sure it isn't locked inside one departing employee's or one agency's personal account. Check that a transfer lock is active. Confirm your MX, SPF, DKIM and DMARC records match your current email provider, not a previous one. None of this requires deep technical skill to check, only the will to actually look.

If you'd rather have someone document and monitor this properly, JagaWeb Care (RM450/month) includes exactly this kind of ongoing custody check — or start with an Essential System Review (RM1,500, currently RM999 until 16 September 2026) to get a clear written picture of what your DNS actually looks like today.