CAA Records and Your Blog Host: Which Record Applies, and Which CA to Allow

If your blog host says the domain is connected but the HTTPS certificate never shows up, and your DNS zone has a CAA record, that record probably doesn't name the certificate authority your host uses. A CAA record lists the CAs allowed to issue certificates for a name. Every public CA has to check it before issuing, and when your host's CA isn't on the list, the request is refused. Often the only sign you'll see is a domain stuck on "pending".

The fix is to add one line, but you need two facts first: which CAA record actually applies to your blog's hostname, and which CA your host issues from. The second one is less obvious than it should be. Some hosts don't document their CA, and for one major host the docs and the certificates it actually issues disagree. I checked both, using live DNS queries and Certificate Transparency logs, on October 11, 2026.

Find the CAA record that applies to your blog's hostname

A CA doesn't just look at your apex domain. RFC 8659 has it start at the exact hostname on the certificate, follow any CNAME, and stop at the first CAA record set it finds. If there's nothing at that name, it moves up one label of your name and tries again. Let's Encrypt's CAA page gives the order for www.community.example.org as that name, then community.example.org, then example.org, "stopping at the first CAA record it finds".

For a blog, that leads to three different outcomes depending on how you connected the domain:

• An apex domain set up with A records has no CNAME to follow, so the CAA records on your own apex are the ones that count.
• A www or blog subdomain that CNAMEs to a host target which publishes its own CAA records gets the host's records. Yours are never reached, and you can't edit the host's.
• A subdomain that CNAMEs to a target with no CAA records sends the lookup back up your own tree, to example.com. The target's parent domain is never consulted.

That last case is easy to get wrong. www.taniarascia.com is a CNAME to tania.netlify.app, which has no CAA records. The parent zone netlify.app does have one, and it only allows DigiCert, through one specific account. Even so, Let's Encrypt issued a certificate for www.taniarascia.com on August 16, 2026, because the lookup went to taniarascia.com and not to netlify.app.

To see what a CA will see, query the exact hostname first and then each parent until something comes back:

dig CAA www.example.com +noall +answer
dig CAA example.com +noall +answer

If dig isn't installed, Google's public resolver answers the same question over HTTPS:

curl -s "https://dns.google/resolve?name=www.example.com&type=CAA"

An empty answer at every level means no CAA restriction applies, and any CA may issue. In that case CAA isn't the reason your certificate is stuck. If the record you find lists only CAs your host doesn't use, you've found the problem.

The certificate authority each blog host uses

The table combines each host's documentation with what I observed on October 11, 2026. "Target CAA" is what the host's CNAME target returned when I queried it. Where a host publishes CAA there, those records govern any subdomain you point at it, whatever your own zone says. The last column is the value I'd put in your own record for an apex domain, or for a subdomain whose target has no CAA.

Host	What the docs say	Target CAA (observed)	Allow in your record
GitHub Pages	Requires a CAA record with the value letsencrypt.org if you use CAA	*.github.io: letsencrypt.org, digicert.com, sectigo.com	letsencrypt.org
Netlify	Let's Encrypt, with an optional accounturi that limits issuance to Netlify's account	None on yoursite.netlify.app	letsencrypt.org
Vercel	Let's Encrypt: authorize it with 0 issue "letsencrypt.org"	cname.vercel-dns.com: letsencrypt.org, pki.goog, sectigo.com, globalsign.com	letsencrypt.org
Cloudflare Pages	Let's Encrypt, Google Trust Services and SSL.com, as both issue and issuewild	Your own zone	letsencrypt.org, pki.goog, ssl.com
Ghost(Pro)	Automatic SSL; no CA or CAA guidance	yoursite.ghost.io: certainly.com, letsencrypt.org, digicert.com, sectigo.com	Not documented; ask support before restricting an apex
WordPress.com	Let's Encrypt	Custom domains I checked carry Google Trust Services certificates	letsencrypt.org and pki.goog
Substack	No CA documented	None on target.substack-custom-domains.com; a custom domain I checked carries Google Trust Services certificates	pki.goog, plus letsencrypt.org to be safe
Squarespace	Let's Encrypt	Not checked	letsencrypt.org
Blogger	Requires a record for letsencrypt.org if you use CAA	Not checked	letsencrypt.org
Wix	CAA records are not supported; remove them for a pointed domain	Not checked	No CAA record

Three rows need more explanation. WordPress.com's support page says its certificates come from Let's Encrypt, and its own error text reads "This domain has CAA DNS records that do not allow Let's Encrypt to issue a certificate." But the current certificates for the custom domains I looked up, including longreads.com, were issued by Google Trust Services in July and September 2026. Each of those certificates covers 42 or 43 names, including tls.automattic.com, which matches the batching the same support page describes. I found no current Let's Encrypt certificate for those names. Until the docs and the logs agree, allowing both letsencrypt.org and pki.goog is the record that works either way.

Substack doesn't document which CA it uses. Its custom-domain target has no CAA records, so the lookup comes back to your zone, and the Google Trust Services certificates on www.slowboring.com from August 2026 show which CA is in use for that domain now. The target resolves to Cloudflare addresses, which suggests it can switch among Cloudflare's CAs. That is an inference, and it's why I'd add letsencrypt.org too.

Ghost(Pro) is the case I can't resolve from public sources. A www subdomain is covered by the CAA on the ghost.io target, and the certificate on www.404media.co was issued by Certainly, Fastly's CA, in September 2026. For an apex on Ghost's A record, Ghost doesn't say which CA it uses, so the safe move is to ask Ghost support before restricting the apex, or to leave it unrestricted.

Write the CAA record

CAA authorizations are additive, so you add one issue line per CA and keep the CAs you already rely on for other names under the same domain. A zone with a WordPress.com blog at the apex, following the table above, would look like this:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "pki.goog"
example.com.  3600  IN  CAA  0 iodef "mailto:[e-mail]"

The iodef line is optional. It tells CAs where to report certificate requests that violate your policy. issuewild applies only to wildcard certificates, and when one is present, the issue lines are ignored for wildcards. Adding issuewild ";" blocks wildcards entirely. Before you add it, confirm that nothing in the zone, including a CDN in front of another site, relies on a wildcard certificate.

Records you place on a subdomain override the apex for that subdomain and everything below it. That's how you allow a host for blog.example.com without loosening the policy on example.com. The opposite also happens, and it's the usual way a stale record breaks a new host: a record added years ago at the apex for one CA now covers every subdomain that has no record of its own.

The accounturi parameter from RFC 8657 restricts issuance to one ACME account. Netlify publishes its Let's Encrypt account URI for exactly this use, and none of the other hosts in the table document one. An accounturi the CA doesn't recognize makes the line unsatisfiable, so only add one your host has published.

If you use Cloudflare DNS with Universal SSL turned on, Cloudflare adds CAA records automatically for its own CAs as soon as you add any CAA record to the zone. Those records don't appear in the dashboard. Check with dig to see the full set a CA receives.

When the CAA lookup itself fails

A correct record still won't help if CAs can't read it. Under the CA/Browser Forum Baseline Requirements, CAs have checked CAA from several network locations since 2025. Since March 15, 2026, they must also perform DNSSEC validation on CAA lookups, and a validation error such as SERVFAIL "MUST NOT be treated as permission to issue." A zone with broken DNSSEC, often left over from changing DNS providers without removing the old DS record at the registrar, can now block issuance even with no CAA record at all. If dig returns SERVFAIL for your CAA query, fix DNSSEC before changing any records.

Resolvers keep serving your old CAA record until its TTL runs out. Lower the TTL before you edit, then wait at least that long before you ask the host to retry the certificate.

When deleting the CAA record is the better fix

If nobody can say why a CAA record exists, deleting it is a legitimate answer. With no CAA anywhere in the tree, any public CA can issue for the name, which is the default for most domains. CAA earns its place when you've decided which CAs may issue for your domain and you watch the iodef reports or Certificate Transparency alerts. A record copied from an old tutorial and forgotten gives you none of that, and it will break the next host move.

I learned most of this while wiring custom domains on JustBlogged. Certificates there come from Let's Encrypt once DNS points at the host, so a restricted zone only needs letsencrypt.org allowed.