10 common DNS and SSL configuration mistakes for website building beginners. How many have you made?

　　To be honest, I've seen too many beginners build websites, spending countless hours choosing servers, configuring environments, and changing themes, only to encounter all sorts of inexplicable problems after the site goes live: emails won't send, HTTPS won't work, subdomains fail to access… After a long investigation, they find it's nothing serious, just a minor detail in their DNS or SSL configuration that wasn't done correctly. These mistakes have one thing in common: they're not easily noticed during configuration, and once the problem is discovered, they're very difficult to troubleshoot.

　　I. Confusing A Records and AAAA Records

　　This is the most basic but also the easiest to confuse issue. Many beginners only know to add an A record to point the domain name to the server IP, and then the website will open, thinking everything is fine. Until one day a user using an IPv6 network says they can't access your website, and you realize there's something called an AAAA record.

　　An A record points the domain name to an IPv4 address, while an AAAA record points the domain name to an IPv6 address. Many home broadband and mobile networks now default to IPv6 addresses. If you only configure an A record, IPv6 users accessing your domain won't be able to resolve any records and therefore won't be able to open it.

　　The solution is simple: if your server supports IPv6 (most Hong Kong servers and domestic cloud servers support this), ask your service provider for the IPv6 address and add an AAAA record.

　　Second, unknowingly causing a CNAME and A record conflict.

　　You want both example.com and www.example.com to be accessible, so you add a CNAME record for www in the DNS pointing to example.com. This isn't inherently wrong, but some DNS management panels don't allow multiple record types for the same hostname. A more common problem is that you add a CNAME record for example.com itself—this is incorrect because root domains should typically use A records, not CNAME records.

　　The rule is simple: a CNAME record cannot coexist with any other record on the same hostname. In other words, if you set a CNAME record for www.example.com, you cannot set an A record, MX record, or TXT record for www.example.com. The root domain (example.com) should also ideally not use a CNAME record, because the root domain usually requires MX records (for receiving emails) and SOA records (for zone authorization), which conflict with CNAME records.

　　III. Inappropriate TTL Settings: Too Short or Too Long

　　TTL (Time To Live) determines the lifespan of DNS records in the cache. Beginners often go to two extremes: either ignoring it and using the default one day, resulting in a 24-hour delay when changing server IPs; or pursuing the "ultimate," setting all TTLs to 60 seconds, causing a re-query on every access, slowing down website loading.

　　The trade-off for TTL is actually quite simple: Under stable conditions (where frequent record changes are not required), TTL can be set longer, such as 3600 to 86400 seconds, to fully utilize the cache and improve resolution speed. When planning to change IPs, reduce the TTL to 300 seconds 24 hours in advance, and restore it to its original value after the switch is complete. A typical mistake: A novice user changed the server's IP address in the middle of the night and immediately modified the A record in the DNS. They thought, "That'll fix it," but over the next day, some users could access the new site, while others were still redirected to the old server. This is because DNS caches in different regions don't refresh quickly enough. The correct approach is to lower the TTL before changing the IP and wait for the old value to expire before switching.

　　IV. Forgetting to Configure SPF, DKIM, and DMARC: Emails Go to Spam

　　This is one of the most easily overlooked but most directly problematic DNS configuration issues. Many people set up a website and then activate a business email account using the domain, only to find that emails either go unreceived or end up in spam. The reason is simple: you haven't informed the world's mail servers that "emails sent from this domain are legitimate."

　　The SPF record specifies which servers are authorized to use your domain to send emails. Without an SPF record, many receiving servers will consider emails forged and reject them or send them to spam. DKIM provides a digital signature, proving that the email has not been tampered with during transmission. DMARC tells the recipient "what to do if the email fails the SPF or DKIM check."

　　Configuring these three records is actually not complicated. Your email service provider (Tencent Enterprise Mail, Alibaba Enterprise Mail, Google Workspace, etc.) will provide the specific values. You only need to add the corresponding TXT record in your DNS management panel. Spending ten minutes configuring this can save you countless email losses later.

　　V. SSL Certificate Only Configured with www, Not the Root Domain

　　After installing the SSL certificate, opening https://www.example.com works fine, but opening https://example.com results in a "connection not secure" message. This is because your SSL certificate only covers www.example.com, not example.com. Many beginners only fill in one domain name when applying for the certificate, omitting the root domain.

　　There are two solutions: First, fill in both domain names when applying for the certificate; a multi-domain certificate or a wildcard certificate will work. Second, when configuring HTTP to HTTPS redirects, ensure that both methods redirect correctly. A simpler method is to apply for a wildcard certificate (such as *.example.com), which can cover all subdomains; the root domain needs to be added separately.

　　Another related issue: the certificate is installed, but resources referenced on the website (images, CSS, JS) still use http://, causing the browser address bar to display a green padlock next to a yellow triangle—this is called "mixed content." Check your theme settings and plugin settings, and change the addresses of all resources to relative paths or https://.

　　Sixth, the domain name is resolved, but you forget to wait for it to take effect before rushing to troubleshoot elsewhere.

　　This mistake is too common. You add a record in the DNS management backend, then immediately test it in the browser and find it won't open. You then start suspecting server configuration, firewall, ports… After two hours of troubleshooting, you finally discover that the DNS record hasn't actually taken effect yet.

　　The time it takes for DNS resolution to take effect depends on three caches: the local operating system cache, the local recursive DNS server cache, and the TTL value you set. Even the fastest record takes several minutes to take effect on most nodes globally, and some may take several hours. For beginners, I have only one piece of advice: After adding or modifying DNS records, wait at least 10-15 minutes before testing. If it still doesn't work, check on tools like whatsmydns.net to see what the resolution results are from various nodes worldwide.

　　VII. Applying for an SSL Certificate Using an IP Address

　　This mistake sounds absurd, but some beginners do it. They install Nginx on their server, access the website using the IP address, and assume they can apply for an SSL certificate using the IP address. In reality, most Certificate Authorities (CAs) do not issue SSL certificates based on IP addresses. Even if they do, they are much more expensive than domain certificates, and their use cases are very limited.

　　The proper procedure is: first, register a domain name with a domain registrar, point the domain name to your server's IP address, and then use the domain name to apply for an SSL certificate. For free certificates, I recommend Let's Encrypt, which offers free renewal every 90 days and is highly automated. Never try to use a self-signed certificate—the browser will display a large red warning screen, and ordinary users will not click continue.

　　8. Frequent Modification of NS Records Leads to DNS Resolution Interruptions

　　When switching DNS providers, beginners often modify the NS records directly with their domain registrar. The result is intermittent website performance, inability to receive emails, and even complete domain inability to resolve. This is because changes to NS records propagate much more slowly than regular records. Within 24-48 hours after the change, DNS servers worldwide are constantly switching between old and new information, leading to instability.

　　The correct procedure is to run the old and new DNS providers concurrently for a period. First, configure all records on the new DNS provider's end (consistent with the old ones), then add the new NS records to the domain registrar's end, instead of directly replacing them. Wait one or two days to confirm that the new DNS has fully taken over before removing the old NS records. This process is called "DNS migration," and it shouldn't be rushed.

　　9. Enabling DNSSEC Without Maintenance Leads to Complete Domain Crash

　　DNSSEC is a good thing; it prevents DNS cache poisoning and hijacking. However, many beginners simply click the "Enable DNSSEC" button at their domain registrar and then neglect its maintenance. If you switch DNS providers or update your domain records, the original DS records may become incompatible, causing the entire domain to become "unresolvable"—it won't open without any error message, and you won't be able to ping it.

　　DNSSEC requires coordination between your domain registrar (such as Namecheap or GoDaddy) and your DNS provider. If you're unsure what you're doing, it's recommended not to enable DNSSEC yet. Configure it only after you have a deeper understanding of DNS; otherwise, the recovery process will be extremely painful if something goes wrong.

　　10. SSL Certificate Configured, but HTTP Forced Redirection to HTTPS Not Configured

　　This is the most frustrating mistake: the certificate is installed, and https:// opens, but when users enter http:// or directly type the domain name in the browser, it's still transmitted in plaintext via HTTP. You've put a lot of effort into encryption, but users inadvertently use plaintext, rendering your efforts useless.

　　The correct approach is to configure a 301 redirect in the web server (Nginx, Apache) to permanently redirect all HTTP requests to HTTPS.

　　After configuration, test it: Enter http://example.com and see if your browser address bar automatically changes to https://. If so, it's correct.

　　Have you encountered any of these 10 errors?

　　To be honest, I encountered at least half of these errors when I first built my website. Incorrect TXT record configuration led to emails ending up in the spam folder, changing NS records caused the website to be down for half a day, the SSL certificate only had www configured and not the root domain… Each error took several hours to troubleshoot.

　　The common thread in these problems is that during configuration, people often think "just follow the procedure" and don't check carefully; when problems arise, they don't know where to start troubleshooting. Therefore, my suggestion is: create a checklist for your domain management backend, DNS management backend, and SSL certificate management tool, and review it against the checklist after each configuration. Ten minutes of checking can save several days of troubleshooting time later.

　　Does your current domain and SSL certificate have any of the problems mentioned above? Take a few minutes to check them. Just because you haven't noticed some errors now doesn't mean they don't exist—they just haven't caused problems yet.