A business can have a perfectly designed website, a working mail system, and a valid domain registration, yet one incorrect DNS change can make part of that setup disappear from the internet. DNS is rarely visible to customers, but it sits underneath almost every routine online interaction: opening a website, sending email, verifying a service, or connecting a subdomain.
For Canadian businesses, understanding DNS does not mean becoming a network engineer. It means knowing what the important records do, recognizing risky changes, and knowing which records deserve extra care when a domain, website, email platform, or hosting provider changes.
DNS is the directory behind your domain
The Domain Name System translates human-readable names such as example.ca into information that internet services can use. When someone visits a website, the browser needs to discover where that domain is hosted. When someone sends email, the sending system needs to discover which servers are authorized to receive messages for the domain.
That information is stored in DNS records. Different records answer different questions, and several may work together for the same domain.
1. A record: where the website lives
An A record connects a domain or hostname to an IPv4 address. If www.example.ca needs to point to a server at a particular IPv4 address, an A record is one of the records involved.
This is one of the records businesses are most likely to encounter when connecting a domain to web hosting. Changing it can redirect traffic to a different server, so an apparently small DNS edit can take a website offline or send visitors somewhere unexpected.
2. AAAA record: the IPv6 destination
An AAAA record performs a similar job for IPv6 addresses. As more networks and services support IPv6, businesses may have both A and AAAA records for the same hostname.
The important operational point is simple: changing only the A record does not necessarily change where IPv6-capable clients are sent. If both records exist, they should be reviewed together during a hosting migration or infrastructure change.
3. CNAME: an alias for another hostname
A CNAME record points one hostname to another hostname rather than directly to an IP address. It is commonly used for services such as www, application subdomains, or third-party platforms.
For example, a business might use a CNAME when a SaaS provider asks it to connect portal.example.ca to a hostname supplied by the provider. The provider can then manage the underlying destination without requiring the business to maintain a fixed IP address.
CNAME records have specific DNS rules, so they should not be treated as interchangeable with A records. A common mistake is trying to create a CNAME where another record already exists for the same name.
4. MX: the records that direct business email
MX records, or Mail Exchange records, tell mail systems which servers should receive email for a domain. If your business uses a hosted email service, the provider normally supplies the MX values that need to be published.
This record deserves special attention during email migrations. A website can continue working while email is broken, which makes a DNS mistake particularly easy to miss until employees stop receiving messages.
Before changing MX records, document the existing configuration and confirm the replacement values with the email provider. Do not delete mail-related records simply because their purpose is not immediately obvious.
5. TXT: small text records with important jobs
TXT records store text-based information associated with a domain. In business environments, they are frequently used for verification and email security.
A service may ask you to publish a TXT value to prove that your organization controls a domain. Email systems also use TXT records for mechanisms such as SPF and domain verification.
Because multiple TXT records can exist for a domain, avoid replacing an entire set simply because one new verification record is required. The existing records may support completely different services.
6. SPF: which servers may send email
SPF, or Sender Policy Framework, is published as a TXT record. It identifies systems that are authorized to send email on behalf of a domain.
For a business using several legitimate sending platforms—such as its normal mail provider, a website form service, and a marketing platform—SPF needs to account for the services that actually send mail.
SPF is easy to damage by creating multiple competing SPF policies for the same domain. Businesses should maintain one coherent SPF policy rather than adding separate SPF records whenever another provider is introduced.
7. DKIM: a cryptographic signature for outgoing email
DKIM, or DomainKeys Identified Mail, allows an email system to attach a cryptographic signature that receiving systems can use to verify that the message was authorized by the sending domain.
DKIM commonly relies on DNS records containing public-key information. The private key stays with the sending system; the corresponding public information is published through DNS.
For businesses, DKIM is part of a broader email-authentication setup rather than a replacement for SPF. When changing email platforms, make sure the new provider's DKIM configuration is published and tested before retiring the old setup.
8. DMARC: the policy layer for email authentication
DMARC, or Domain-based Message Authentication, Reporting and Conformance, builds on SPF and DKIM. It gives domain owners a way to publish a policy for messages that fail authentication checks and can provide reporting about email activity.
DMARC is particularly useful when a business wants greater visibility into how its domain is being used for email. It can also expose legitimate systems that were forgotten during an email or marketing-platform migration.
The practical lesson is that email authentication should be managed as a system. Changing one record without understanding the relationship between SPF, DKIM, and DMARC can create delivery problems.
9. NS: which DNS servers are authoritative
NS records, or Name Server records, identify the authoritative DNS servers for a domain. They determine where the internet should look for the domain's DNS information.
This is a higher-level change than editing a single A or MX record. Switching name servers can move control of the entire DNS zone from one provider to another. That can be necessary during a DNS provider migration, but it is not a change to make casually.
Before changing NS records, make sure the new DNS provider already contains all required website, email, verification, security, and application records. Otherwise, the domain can appear to have lost services immediately after the delegation changes.
10. CAA: controlling who can issue SSL/TLS certificates
CAA, or Certification Authority Authorization, lets a domain specify which certificate authorities are permitted to issue certificates for it.
For businesses using HTTPS, CAA can add another control around certificate issuance. But it also introduces a possible failure point: if a business restricts certificate issuance to specific authorities and later uses a different certificate provider, the restriction may prevent the new certificate from being issued.
That makes CAA a good example of a DNS record that should be documented rather than copied blindly from another domain.
One domain can depend on many DNS records
These records are easier to understand when viewed as a system rather than ten isolated settings.
A and AAAA can direct web traffic to IPv4 and IPv6 destinations.
CNAME can connect a hostname to another hostname.
MX directs incoming email.
TXT, SPF, DKIM, and DMARC can support verification and email authentication.
NS determines which DNS servers are authoritative.
CAA can restrict certificate issuance.
That dependency is why DNS changes should be handled as infrastructure changes, not as isolated form-field edits.
What Canadian businesses should document before changing DNS
Keep a current record of the domain registrar, DNS provider, hosting provider, email provider, important subdomains, and the purpose of unusual DNS records. Include the person or team responsible for approving changes.
When moving a website or email service, lower-risk planning matters more than making the DNS change quickly. Review the complete zone first, reproduce required records at the destination, check TTL settings where appropriate, and test the services after the change.
For organizations managing several domains or applications, Domain & Cloud Hosting can help centralize domain, hosting, monitoring, and infrastructure requirements rather than treating each service as a separate task.
DNS is also part of the wider security picture. Businesses reviewing their online infrastructure should consider related controls covered in website security and HTTPS protection and their broader Managed IT Services requirements.
DNS mistakes are often small changes with large consequences
The most dangerous DNS mistake is not necessarily an obviously complicated one. It can be deleting a TXT record during an email update, replacing an MX record without checking the mail provider, pointing an A record to an old server, or changing name servers before the new DNS zone is ready.
For that reason, businesses should treat DNS access as infrastructure access. Use appropriate account security, limit administrative access, document changes, and keep a known-good record of the zone configuration.
If your website, email, hosting, or domain setup needs a technical review, Request a Free Project Proposal from HB Technology Solutions. A DNS review is often a small task compared with the cost of discovering a broken configuration after customers or employees are already affected.
