Add to Preferred Sources
Website DNS basics for business owners start with one practical fact: the Domain Name System is the layer of the internet that translates "yourbusiness.co.za" into the server address where your site actually lives. Every time you launch, redesign, or move a business website in Johannesburg — or anywhere in South Africa — DNS is what makes your site reachable, your business email deliverable, and your domain-verified tools (Google Workspace, Search Console, payment gateways) actually connected.
Most South African business owners encounter DNS at exactly the wrong moment: when something breaks. The domain shows "server not found", emails start bouncing, or the new website isn't visible even though the developer says it's live. All of these are DNS events — and understanding the handful of record types behind them puts you in a position to diagnose the problem in minutes, not wait hours for someone to explain what "propagation" means.
This guide covers what each DNS record type controls, how propagation behaves specifically across South African ISPs, and a decision table that maps your common business situation — new website, email setup, switching hosts — to the exact DNS change it requires.
Quick Answer
DNS (Domain Name System) connects your domain name to your website, email, and business tools through a set of records you manage at your domain registrar. The essential records for any South African business are the A record (your website's server address), MX records (your email servers), and TXT records (for email authentication and domain verification). Changes to these records take anywhere from 30 minutes to 48 hours to spread across South African ISPs — because Telkom, Vodacom, MTN, Afrihost, and Rain each run their own DNS servers and refresh their caches at different times. Understanding DNS basics for business owners means knowing which record to change, who changes it, and how long to expect before the change takes effect.
Jump to a section
Launching a new site and not sure which DNS records need to change?
Share your domain and hosting details — we'll map out which records to update and in what sequence so your go-live doesn't turn into a 48-hour propagation wait.
Get a DNS reviewWhat DNS Does for Your Website and Email
DNS (Domain Name System) is the internet's directory — it translates a human-readable domain name into the IP address of the server that holds your site. When someone visits yourbusiness.co.za, a DNS lookup happens in milliseconds: the device queries a DNS resolver, which traces the hierarchy from root servers down to the authoritative nameservers for your domain, then returns the correct server address. The browser connects, and your website loads.
For a South African business, this matters at three specific moments. First, when you launch or move a website — the DNS record pointing your domain to the new server must be updated or visitors reach the wrong place. Second, when you change or add an email provider — email servers are found via DNS, and a missing or incorrect record means email bounces. Third, when you connect a third-party tool that needs to verify your domain ownership — Google Search Console, Google Workspace, Xero, and most booking or payment platforms do this via a DNS record you add once.
In South Africa, .co.za domains operate under a dual governance structure: ZADNA (the ZA Domain Name Authority) is the statutory regulator mandated under the Electronic Communications and Transactions Act 2002, and the ZA Central Registry (ZACR) maintains the central database of all registered .co.za names. You register your domain through one of ZACR's more than 300 accredited registrars — and your registrar's control panel is typically where you manage DNS records.
Who actually manages your DNS?
Your domain registrar handles DNS by default. However, if you've pointed your domain's nameservers to your web hosting provider in South Africa, DNS records may instead sit inside your hosting account's control panel. Before making any DNS change, check which nameservers your domain is currently using — your registrar's interface will show this. Changes made in the wrong control panel have no effect.
Website DNS Basics for Business Owners: What Each Record Does
DNS records are the individual instructions inside your domain's configuration. There are over a dozen types, but five cover every scenario a South African business owner is likely to encounter. Here is what each one controls, and when you need it.
| Record Type | What It Controls | Common Business Use Case |
|---|---|---|
| A record | Maps your domain to a specific server's IPv4 address | Pointing yourdomain.co.za to your web server after a redesign or hosting switch |
| CNAME record | Creates an alias from one hostname to another | Connecting a subdomain (shop.yourdomain.co.za) to a Shopify-hosted URL or third-party platform |
| MX record | Directs inbound email to the correct mail server | Setting up or switching to Google Workspace or Microsoft 365 for business email |
| TXT record | Stores text-based verification and authentication data | Domain verification for Google Search Console; SPF, DKIM and DMARC email authentication |
| NS record | Names the authoritative nameservers responsible for your domain | Delegating DNS control to a new hosting provider or switching registrars entirely |
A record note: An A record maps to an IPv4 address (e.g., 105.20.1.42). If your host provides an IPv6 address instead, that goes into an AAAA record — but most South African hosting environments use IPv4.
CNAME limitation: A CNAME cannot share a name with any other record type at the same hostname. This means your root domain (yourdomain.co.za, without any prefix) cannot be a CNAME — you need an A record there. Subdomains like www., shop., or app. can be CNAMEs. Trying to set a CNAME on your root domain while keeping MX records for email will break one or the other.
MX priority: MX records include a priority number. Lower numbers mean higher priority. Google Workspace uses priority 1 for its primary mail server and higher numbers for backups. Your email provider's setup documentation will give you the exact values to enter.
Key takeaway
The most common DNS error South African business owners make is treating nameserver changes and individual record changes as interchangeable. They are not. Changing an NS record hands control of your entire DNS zone to a new provider and wipes any records not already configured there. Changing an A record or MX record updates a single pointer while leaving everything else intact. Confirm which type of change your developer is proposing before authorising it.
How DNS Propagation Works Across South African ISPs
DNS propagation is the time it takes for a record change to spread across all the resolvers and caches on the internet. It is not instant — and in South Africa, the delay has a specific mechanism that business owners need to understand. Each DNS server stores a cached copy of records for a period defined by the record's TTL (Time to Live) value. When the TTL expires, the server re-queries for fresh data. Until that expiry, it serves the old record.
South African ISPs including Telkom, Vodacom, MTN, Afrihost, and Rain each run their own DNS servers. They do not synchronise cache refreshes with each other. This is why, after a DNS change, one employee on a Vodacom connection might reach your new website while a colleague on Afrihost still sees the old one. Both results are technically correct according to the server each person is querying — the difference resolves as each server's TTL expires.
| Record Type | Typical SA Propagation Window | Notes |
|---|---|---|
| A record | 30 minutes–24 hours | Faster with a low TTL set before the change |
| CNAME | 30 minutes–24 hours | Same cache mechanism as A records |
| MX record | 1–24 hours | Email delivery begins as the record propagates to each ISP |
| TXT record | 1–24 hours | Domain verification may trigger quickly in some tools once propagated |
| NS record (nameserver) | Up to 48 hours | Full delegation to a new host or registrar can take the full window |
The TTL lever — and why timing matters: TTL is the single biggest variable in how quickly a DNS change takes effect. A TTL of 3,600 means any cached record is considered valid for one hour before servers re-query. The South African practitioner guide at Truehost's .co.za DNS guide recommends reducing your A record TTL to 300 seconds (five minutes) at least 48 hours before a hosting migration. That way, when you update the record, most ISP resolvers pick up the change within minutes rather than hours. After the migration is confirmed stable, restore the TTL to 3,600–7,200 seconds for normal operation.
The critical point: lower your TTL 48 hours before the change, not at the moment of the change. If your current TTL is 14,400 seconds (the common default — four hours), servers need to process that TTL expiry before they see your new shorter value. A last-minute reduction does nothing for the first propagation window.
To check propagation status, use a DNS checker tool such as dnschecker.org or whatsmydns.net. These tools query DNS servers in multiple locations, including South African resolvers, and show which ones have picked up your updated record and which are still serving the old one.
When to Change DNS Settings: A Decision Table
Most DNS changes map predictably to a specific business event. The table below covers the seven scenarios South African business owners encounter most often — what record changes, who typically makes the change, and what propagation to expect.
| Your Situation | Record to Change | Who Does It | Typical SA Propagation |
|---|---|---|---|
| New website going live on a new host | A record — point to new server IP | Developer or registrar | 30 min–24 hours |
| Switching web hosting providers | A record (single pointer) OR NS records (full delegation) | Developer | A record: up to 24 hrs; NS: up to 48 hrs |
| Setting up Google Workspace or Microsoft 365 | MX records + TXT for SPF and DKIM | Developer or you via registrar | 1–24 hours |
| Verifying domain in Google Search Console | TXT record (one-time verification value) | You or developer via registrar control panel | 1–24 hours |
| Adding a subdomain (shop., app., book.) | CNAME or A record for the new subdomain | Developer | 30 min–24 hours |
| Connecting a third-party tool (Calendly, HubSpot, Xero) | CNAME or TXT — per the tool's setup guide | You or developer via registrar | 30 min–24 hours |
| Switching email providers while keeping your web host | MX records only — do NOT change NS | Developer or you via registrar | 1–24 hours |
The last row carries a specific warning. When switching email providers, many South African developers change nameservers — believing this hands full control to the new provider. It does, including the MX records, which the new provider typically does not have pre-configured. Email breaks for the full propagation window. The correct sequence is to add the new email provider's MX records in the system that controls your current nameservers, verify email is flowing correctly, and only then plan any nameserver migration as a separate project.
The Email Authentication Records That Protect Your South African Business Domain
Covering website DNS basics for business owners fully requires a section on email authentication — the records that protect your domain's reputation. These DNS TXT records tell receiving mail servers whether an email claiming to come from yourbusiness.co.za is legitimate. Without them, your business email is more likely to land in spam folders, and your domain can be impersonated by anyone sending phishing emails in your name. Three records work together to close these gaps.
SPF (Sender Policy Framework) lists the IP addresses and mail servers that are authorised to send email from your domain. A typical Google Workspace SPF record looks like: v=spf1 include:_spf.google.com ~all. Only one SPF record is allowed per domain — if you have two, both fail.
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each outgoing email, verified by the recipient's server against a public key you publish as a DNS TXT (or CNAME) record. Your email provider generates the key pair; you add the public key to your DNS zone. Each email provider has its own DKIM key, so if you use two sending services, you need two DKIM records.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a policy record that instructs receiving servers what to do when SPF or DKIM fail — monitor only (p=none), quarantine to spam (p=quarantine), or reject outright (p=reject). Start with p=none and review the weekly reports your domain receives before tightening to a stricter policy.
Key takeaway
If your business email is landing in spam folders or customers report suspicious emails "from" your domain, check your DNS first: look for SPF, DKIM, and DMARC TXT records. A domain with no DMARC record is open to spoofing — anyone can send an email that appears to come from your address. Adding all three records is a standard step in any website security checklist for small businesses and takes under an hour once your email provider gives you the values.
Not sure whether your domain's email authentication records are in place?
Send us your domain name and we will check your SPF, DKIM, and DMARC configuration — and flag any gaps that could be hurting your deliverability or leaving your domain open to spoofing.
Get an email DNS checkWhy South African Businesses Choose Growth Pulse Media
When we build or redesign a website, DNS configuration is part of the go-live plan — not a task added at the last minute. We map every record that needs to change before the launch date: A records, MX records, SPF, DKIM and DMARC TXT records, and any third-party tool verifications already in use. We lower TTL values in the days before a migration and monitor propagation across South African ISPs to confirm the site is live and reachable before we call a project complete.
Our web design service includes DNS handover documentation — a record map of every configuration change made during the build, so you retain full control and understanding of your own infrastructure after launch. This matters most when the relationship with a previous developer ends and you need to know exactly what is pointed where.
Dirk van Greuning founded Growth Pulse Media after scaling a South African ecommerce business, which means every DNS migration plan has been shaped by real operational deadlines, not just technical checklists. We work in-house with a limited client load, so when a DNS change is scheduled, a senior team member monitors it — not an account manager watching a ticket queue. Translating website DNS basics for business owners into a practical go-live sequence is one of the first conversations we have when planning a new business website with any client.
Who This Is NOT For
Some DNS tasks are genuinely accessible to non-technical business owners: adding a Google Search Console TXT record, for example, involves copying a single value and pasting it into your registrar's control panel. However, A record changes during a live hosting migration, DKIM key configuration, and nameserver delegation require technical precision. A single typo in a DKIM value means email authentication fails silently — there is no error message, just email landing in spam. If you're not comfortable reading a DNS zone file, delegate these changes.
DNSSEC (Domain Name System Security Extensions) adds cryptographic signing across the entire DNS resolution chain and is a separate, more advanced topic beyond record management. South African businesses with stricter website security requirements may need to evaluate DNSSEC alongside their broader infrastructure review.
Many South African small businesses register a domain, host their site, and manage email through a single provider. In this setup, DNS is managed in one control panel and your provider's support team handles technical migrations. This guide is most valuable when DNS and hosting are at different providers — which is typical for businesses that have grown beyond a basic shared plan.
Before changing any DNS record, confirm you have access to your own registrar account. Losing DNS control to a former supplier is one of the most common infrastructure problems South African business owners face when changing web partners. Recover your registrar credentials first — then plan any changes.
Moving to a new hosting provider and need DNS handled without the 48-hour outage risk?
Tell us your go-live date and current setup. We will build a DNS migration sequence — including TTL preparation — that cuts propagation risk to a minimum.
Plan your DNS migrationFrequently Asked Questions: Website DNS for Business Owners
How long does DNS propagation take in South Africa?
A record and CNAME changes typically propagate across South African ISPs in 30 minutes to 24 hours, depending on the TTL set before the change. MX and TXT records take 1–24 hours. Nameserver changes take up to 48 hours because the delegation must register through the .co.za registry before flowing through to individual resolvers. South African ISPs including Telkom, Vodacom, MTN, Afrihost, and Rain each maintain separate DNS caches and do not synchronise — so propagation varies by ISP and can look inconsistent within the same office.
Can I change DNS records myself, or do I need a developer?
Some changes are accessible to non-technical business owners: adding a Google Search Console TXT record, for example, means copying a single string from Google and pasting it into your registrar's DNS control panel. Higher-risk changes — pointing a new A record during a live hosting migration, configuring DKIM for email authentication, or delegating nameservers to a new provider — are worth delegating to a developer. Errors in these records can take your website or email offline for the full propagation window with no straightforward rollback.
What is the difference between changing an A record and changing nameservers?
Changing an A record updates a single pointer — your domain's IP address — while leaving all other records (MX, TXT, CNAME) exactly where they are. Changing nameservers delegates control of your entire DNS zone to a different provider. When nameservers change, any records not already configured at the new provider are absent — they are not migrated automatically. This is the most common reason email breaks during a hosting switch: the developer changes nameservers, but the new provider has no MX records pre-loaded in the zone.
How do I check whether my DNS changes have propagated in South Africa?
Use a DNS propagation checker such as dnschecker.org or whatsmydns.net. Enter your domain and select the record type you changed (A, MX, TXT, or NS). The tool queries DNS resolvers in multiple locations, including South African servers, and shows which ones have your updated record and which are still serving the old one. Wait until the South African resolver entries show the correct record before treating the change as complete.
Why can some people in my office see the new website while others still see the old one?
Each person's device queries the DNS server assigned by their ISP or network. Telkom users, Vodacom users, and Afrihost subscribers each query a different resolver — and those resolvers update their caches at different times based on the record's TTL. Until each resolver's cache expires and refreshes with the new record, different people will see different results. This is normal DNS propagation behaviour, not a configuration error, and it resolves on its own as TTLs expire — typically within 24 hours of the change.
Get Your DNS Configured Correctly From the Start
Growth Pulse Media handles DNS setup and migration in-house — A records, MX records, SPF, DKIM, DMARC, and subdomain configuration — as part of every website build we deliver. We work with South African hosting environments, .co.za registrars, and Google Workspace, and we include a DNS record map in every handover so you retain full control of your own infrastructure. No obligation — we'll get back to you within 24 hours.
Talk to a South African web design specialist