AutoSSL Skips the www or mail Subdomain? Check Where Its DNS Actually Points

AutoSSL ran, the main domain has a valid certificate, but https://www.example.com throws a browser warning, or a mail client complains that the certificate for mail.example.com does not match. The usual reaction is to click 'Run AutoSSL' again and wait. That rarely changes anything, because in most of these cases AutoSSL is doing its job: it will not put a name on a certificate unless it can prove the server controls that name. The cause is almost always in DNS, and you can usually find it in a few minutes. The sections below follow the shape of a post-mortem: what the impact looks like, how to investigate, the point where the cause becomes obvious, what to do right away, and what to change so it does not come back.

Impact: the main domain is covered, one name is not

The symptom is a partial certificate. The certificate is real and trusted, but its list of covered names (the Subject Alternative Names, or SANs) includes example.com and leaves out www.example.com, mail.example.com, or another subdomain. Browsers and mail clients check that list, so any name missing from it gets a mismatch warning even though 'the site has SSL'. This is confusing from the customer side, because the padlock works on one URL and fails on another that looks almost the same. On the support side, the first useful step is to confirm which names the served certificate actually covers instead of trusting the control panel summary. In cPanel, the SSL/TLS Status page lists each domain and subdomain with its own status. From a terminal, openssl s_client piped into openssl x509 -noout -ext subjectAltName prints the SAN list of whatever the server returns for a given hostname. Once you know a name is missing, the next question is why AutoSSL left it out.

Investigation: start with the AutoSSL log, not the button

AutoSSL keeps a log for each run, broken down per cPanel user and per domain. In WHM it usually sits under SSL/TLS, then Manage AutoSSL, on the Logs tab. The files are typically stored under /var/cpanel/logs/autossl/ as well, though the exact layout can vary between versions. In cPanel, the SSL/TLS Status page often shows a short reason next to each uncovered name. What you are looking for is the domain control validation (DCV) result for the missing name. DCV is how a certificate authority confirms you control a domain before issuing for it. With HTTP-based validation, a token file is placed in the site's document root and then requested over plain HTTP using the domain name. The request goes wherever public DNS sends it. If DNS sends it to a different machine, the token is not there and validation fails. Depending on the cPanel version and the AutoSSL provider, you will see one of two patterns in the log. Either AutoSSL checks DNS locally first and skips the name because it does not resolve to this server, or it attempts validation and records a failure from the HTTP request. The wording differs, but both point to the same place: where the name resolves. A log entry that says the name 'does not resolve' or resolves to an IP address that is not local is the most direct clue you will get. Note the IP it mentions, if it shows one.

The discovery: dig shows a different answer than the server

The deciding check is comparing what public DNS returns for each name against the IP address the account actually uses on the server. Query every relevant record type, because a single wrong record is enough to break validation.

BASH

# What public DNS returns for each name
dig +short A example.com
dig +short A www.example.com
dig +short AAAA www.example.com
dig +short CNAME www.example.com
dig +short A mail.example.com

# Find the authoritative nameservers, then ask one directly (bypasses resolver caches)
dig +short NS example.com
dig @ns1.example.net +short A www.example.com   # replace ns1.example.net with a name from the NS output

TEXT

Illustrative output format
$ dig +short A example.com
203.0.113.10
$ dig +short A www.example.com
198.51.100.25
$ dig +short AAAA www.example.com
2001:db8::25

In that illustrative case, the root domain points at the server but www points somewhere else. Validation for www lands on another machine, and AutoSSL correctly leaves it off the certificate. For the server side of the comparison, use the IP shown for the account in WHM. If the server sits behind NAT, the public IP that DNS should point to is not the private address the OS reports, so check both. The mismatch usually falls into one of these patterns. A leftover record from a previous host or site builder. The root domain was updated during a migration, but www or mail was set as a separate A record and never changed. A CNAME pointing www at an external platform has the same effect. A stale AAAA record. The A record is correct, but an old IPv6 record still points at the previous host. Let's Encrypt prefers IPv6 when an AAAA record exists, so validation can fail even though everything looks right over IPv4. This is easy to miss if you only query A records. A proxied record. If the name sits behind a CDN or reverse proxy, DNS returns the proxy's IPs, not your server's. HTTP validation may still pass through the proxy to the origin, or it may be blocked by forced HTTPS redirects, caching, or security rules. Some AutoSSL versions also skip the name early because it does not resolve locally. Mail subdomains generally should not be proxied at all, since most proxies only carry web traffic. A missing record. If dig returns nothing for mail.example.com, there is nothing to validate, and AutoSSL cannot cover it. The zone you are looking at is not the zone the world uses. This one causes a lot of confusion. The cPanel Zone Editor shows the correct records, but the domain's nameservers point to an external DNS provider. The local zone has no effect on public resolution. The dig +short NS result settles it: if those nameservers are not yours, the records that matter live with that provider. This also means DNS-based validation on the server cannot help, because the server cannot publish records in a zone it does not host.

Mitigation: get a clean certificate back today

The short-term fix depends on one question: should this name be served by this server? If yes, correct the record at the authoritative DNS provider, which is wherever the NS records point. That means fixing the A record, removing or correcting the AAAA record, or creating the missing record. Wait out the old record's TTL (time to live, the number of seconds resolvers may cache an answer), confirm with dig against the authoritative nameserver and a public resolver, then run AutoSSL for that user only. Running it for the whole server is unnecessary. If no, because www intentionally lives on another platform or mail is hosted with a separate provider, exclude that name from AutoSSL in the cPanel SSL/TLS Status page. AutoSSL then stops trying to cover a name it can never validate, and the logs stop reporting a failure that is expected. The other platform is responsible for its own certificate. For external mail, mail clients should connect to the provider's own hostname rather than mail.example.com on your server. For proxied names, there are two reasonable options. You can switch the record to DNS-only briefly so validation reaches the origin, then decide whether to proxy again. Or you can let the proxy present its own edge certificate to visitors and secure the origin connection separately. Which is better depends on how the proxy is configured, so treat this as a trade-off rather than a default. Issuance can also be blocked by a CAA record (a DNS record that limits which certificate authorities may issue for the domain) that does not allow AutoSSL's provider. That is a different check with its own fix, covered in Fixing CAA Failures When Switching from Manual SSL to ACME Clients.

The lasting fix: one clear owner for every name

The root cause is rarely AutoSSL. The real problem is that nobody has a clear picture of where each hostname is supposed to point. Migrations are a common trigger: the root domain gets updated, and www, mail, autodiscover, or an old IPv6 record gets left behind. A split setup, where DNS is hosted in one place, the website in another, and mail in a third, makes this easy to get wrong. The durable fix is plain bookkeeping. First, decide which DNS provider is authoritative and treat it as the only place records are edited. If DNS is external, accept that the local cPanel zone is just a reference copy, and make sure nobody edits it expecting changes to take effect. Then keep a short list of every hostname the domain uses, with the system that serves it and whether this server should hold a certificate for it. Include AAAA records on that list, not just A records. After any migration or nameserver change, run the dig checks above for every name on the list, not only the root domain. This matters more as certificate lifetimes get shorter. Per CA/Browser Forum Ballot SC081v3, maximum public TLS validity drops to 200 days from March 15, 2026, then to 100 days in 2027 and 47 days in 2029. Shorter lifetimes mean more frequent renewals, so a DNS mismatch that once surfaced yearly will surface far more often. That is one more reason to rely on automated monitoring of certificate coverage rather than memory, as discussed in Why Manual SSL Renewal Tracking Fails as Certificate Lifetimes Shrink to 47 Days. When AutoSSL leaves out a subdomain, skip the rerun and check two things: what the log says about that name, and what dig returns for its A, AAAA, and CNAME records against the authoritative nameserver. If the answer is not this server's IP, either fix the record or exclude the name on purpose. Then keep a list of who owns each hostname so the next migration does not repeat the problem.