DNS Management for Canadian Businesses: A Practical Guide to Records, TTL, and Common Mistakes

DNS is the system that translates your domain name into the IP address of your server, routes email to the right mail server, and tells browsers and mail clients how to reach your online presence. For most businesses, DNS works silently in the background until something changes and it does not. Understanding the records your Canadian domain needs prevents outages during migrations and makes troubleshooting straightforward when something does go wrong.

The records every Canadian business website needs

The A record is the foundation. It maps your domain name to an IP address. You need an A record for your root domain (@ or yourdomain.ca) and usually a separate A record for www. Both should point to your web server's IP address. If you use Cloudflare as a proxy, both point to Cloudflare's IP and Cloudflare handles the connection to your actual server. If you do not use Cloudflare, both point directly to your hosting server's IP.

MX records (Mail Exchanger) tell other mail servers where to deliver email sent to your domain. If you host email on your own server, your MX record points to your server's hostname, typically mail.yourdomain.ca. If you use Google Workspace or Microsoft 365 for email, your MX records point to Google's or Microsoft's mail infrastructure, with specific hostnames and priority values they provide in their setup documentation. Having incorrect MX records means incoming email bounces or disappears. This is one of the more damaging DNS errors because it is not immediately obvious and can lose email for hours before someone notices.

CNAME records create aliases. The www subdomain is commonly set up as a CNAME pointing to the root domain rather than a separate A record. Subdomains for specific services are often CNAMEs pointing to external hostnames, for example pointing shop.yourdomain.ca to a Shopify storefront. TXT records hold text data and are used primarily for email authentication (SPF and DKIM), domain ownership verification for Google Search Console and similar services, and DMARC policy publication.

TTL: what it is and how it affects you during a migration

Time to Live (TTL) is the number of seconds that DNS resolvers are allowed to cache a record before checking for an updated value. A TTL of 3600 means resolvers cache the record for one hour. During that hour, any change you make to the record will not reach users whose resolvers have a cached copy. After the TTL expires, resolvers fetch the current value.

Before a server migration or any DNS change you plan in advance, lower the TTL of the relevant records to 300 seconds (5 minutes) at least 24 hours before you make the change. This way, when you update the record, the change propagates to most users within 5 minutes rather than up to an hour. After the migration is stable, raise the TTL back to 3600 or higher. A higher TTL reduces the load on authoritative DNS servers and makes your site load marginally faster for users with cold DNS caches, since resolvers can serve cached answers immediately without a lookup round trip.

The three DNS records that affect email deliverability

SPF (Sender Policy Framework) is a TXT record that lists the IP addresses and hostnames authorized to send email from your domain. A minimal SPF record for a site sending email through a cPanel or Webuzo mail server on the same IP as the web server looks like: v=spf1 a mx ~all. The a includes your A record's IP, mx includes the IP of your MX record host, and ~all tells receiving servers to treat mail from other sources as a soft fail. If you also send through a third-party service like Mailchimp, SendGrid, or Google Workspace, each requires an include statement added to your SPF record. DKIM is a TXT record containing a public key that receiving servers use to verify the cryptographic signature on outgoing messages. cPanel and Webuzo generate the DKIM key pair and provide the TXT record value you need to add to DNS. Without DKIM, your messages are more likely to be filtered as spam by major providers. DMARC is a TXT record at the hostname _dmarc.yourdomain.ca that tells receiving servers what to do with messages that fail SPF and DKIM. Even a policy of p=none with a reporting address (rua=mailto:[email protected]) is better than no DMARC record at all, because the reports tell you what is sending email using your domain and whether authentication is working.

Common DNS mistakes Canadian businesses make

Adding a CNAME record for the root domain (@ or yourdomain.ca) instead of an A record is a frequent error. The DNS specification does not allow CNAME records at the zone apex. Some DNS providers implement a non-standard workaround called CNAME flattening or ALIAS records, but if yours does not, the record will not work correctly. Always use an A record for the root domain pointing directly to an IP address.

Forgetting to update MX records when changing email providers is another common problem. If you switch from a server-hosted mail setup to Google Workspace or Microsoft 365 and update the MX records but forget to remove the old MX records, the priority settings determine which server receives email. If the old server has a lower priority number (which means higher priority in MX record terms), email continues going to the old server. Remove the old MX records when adding new ones.

Adding SPF records as multiple TXT entries instead of a single record causes SPF failures. RFC 7208 requires a single SPF record per domain. If you have two TXT records that both start with v=spf1, receiving servers will return a PermError and your email will fail authentication. Combine all SPF directives into a single record.