CAA records for self-hosted sites: let Let’s Encrypt and Cloudflare issue certificates without surprises

CAA records are one of those DNS settings that sound more exotic than they are. They do not encrypt traffic. They do not replace TLS. They simply tell public certificate authorities which issuers are allowed to create certificates for your domain.

That matters on a self-hosted VPS because the certificate path is often split across layers. Coolify or Traefik may request a Let’s Encrypt certificate for the origin. Cloudflare may issue an edge certificate for the public hostname. A mail server may use its own certificate for SMTP, IMAP, or webmail. If CAA records are added too aggressively, the site can look secure today and then fail the next renewal.

Goal: use CAA records as a small safety rail, not as a mysterious DNS spell that breaks your next Coolify or Cloudflare certificate renewal.

What CAA records actually do

The IETF’s RFC 8659 defines CAA as a DNS resource record that lets a domain holder specify which certificate authorities are authorized to issue certificates for that domain. Let’s Encrypt’s CAA documentation explains the practical motivation clearly: without CAA, any public CA can attempt issuance if it validates control of the domain; with CAA, you narrow the set of acceptable issuers.

The common tags are:

• issue — which CA may issue normal certificates.
• issuewild — which CA may issue wildcard certificates.
• iodef — where CAs can send incident or violation reports, if supported.

For a small self-hosted site, issue is the one that matters most. It is also the one most likely to break renewals if you forget a certificate issuer that your stack actually uses.

The self-hosted certificate map

Before adding CAA records, write down who issues certificates for each layer:

If all public web traffic is proxied through Cloudflare but your origin still uses Let’s Encrypt, the DNS policy needs to allow both the edge path and the origin renewal path. Do not assume “visitors only see Cloudflare” means Let’s Encrypt is no longer involved.

A safe starting shape

For many self-hosted domains that use Cloudflare DNS/proxying and Let’s Encrypt on the origin, a conservative starting point looks like this:

example.com.  CAA 0 issue "letsencrypt.org"
example.com.  CAA 0 issue "pki.goog"
example.com.  CAA 0 issue "digicert.com"
example.com.  CAA 0 issuewild ";"
example.com.  CAA 0 iodef "mailto:[email protected]"

The exact issuer list should match the platform you use. Let’s Encrypt covers the common ACME origin-certificate path used by many reverse proxies. Cloudflare edge certificates may involve certificate authorities such as Google Trust Services or DigiCert depending on the certificate product and account state. If you use a different host, CDN, or managed platform, check that provider’s current documentation before restricting CAA.

The issuewild ";" line means “do not issue wildcard certificates unless another explicit wildcard issuer is allowed.” Only use it if you do not need wildcard certificates. If you do use wildcard certificates, replace it with the wildcard issuer you actually use.

What not to do

• Do not copy another site’s CAA records blindly. Their issuer set may not match your Cloudflare, Coolify, mail, or DNS setup.
• Do not add only one CA if two layers issue certificates. A proxied web app can still need both an edge certificate and an origin certificate.
• Do not forget mail hostnames. If mail.example.com inherits restrictive CAA records from example.com, your mail TLS renewal path must still be allowed.
• Do not publish operational secrets in examples. CAA records are public DNS. Keep examples generic and never include account IDs, tokens, private hostnames, or mailbox passwords.
• Do not treat CAA as a firewall. It reduces certificate mis-issuance risk; it does not hide your origin or protect a weak app.

How inheritance can surprise you

CAA is checked up the DNS tree. If a CA is evaluating app.example.com and there is no CAA record there, it may find the CAA policy at example.com. That is usually what you want: one policy for the zone. It becomes surprising when a subdomain uses a different platform.

For example, the apex domain might be a Coolify app using Let’s Encrypt, while docs.example.com is hosted elsewhere and needs another CA. If the apex CAA policy allows only Let’s Encrypt, that other platform may fail certificate issuance. The fix is not to delete CAA entirely; it is to add the issuer that the subdomain actually needs, or place a more specific CAA record where appropriate.

Verification commands

Use DNS queries before and after every change. These examples use placeholders so the pattern is safe to share publicly.

# Show CAA records at the apex
 dig +short CAA example.com

# Show whether a subdomain has its own CAA policy
 dig +short CAA app.example.com

# Check the public certificate currently served
 echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
   | openssl x509 -noout -issuer -subject -dates

# Check the proxied public hostname still responds
 curl -I https://example.com/

# If Coolify exposes a health endpoint, verify it after cert changes
 curl -fsS https://example.com/health || true

The most important test is not just “does DNS show the CAA record?” It is “can the systems that renew certificates still renew them?” After a DNS change, watch the next renewal window or trigger a staging/test certificate where your tooling supports it.

Coolify-specific checklist

1. List every public hostname configured on the Coolify application.
2. Confirm whether Coolify/Traefik is requesting Let’s Encrypt certificates for those hostnames.
3. Confirm whether Cloudflare is proxying the same hostnames and issuing edge certificates.
4. Add CAA records only after the issuer map is clear.
5. Keep DNS examples generic in documentation and blog posts.
6. Verify live HTTPS, RSS, sitemap, and canonical URLs after deploy.

This fits the same operating habit as the Cloudflare DNS checklist, the Coolify static-site deploy checklist, and the Docker Mailserver multi-domain guide: make the public DNS shape explicit, then verify each dependent service instead of trusting the dashboard.

The practical rule

If you are unsure, start with no CAA record rather than a wrong restrictive one. Once you know the certificate issuers for your origin, edge, and mail paths, add the narrowest records that still allow all legitimate renewals. CAA is useful when it reflects your real architecture. It is risky when it reflects a copied snippet.

For a self-hosted VPS, the win is small but real: fewer certificate authorities are allowed to issue for your domain, and your DNS documentation becomes a little more intentional. Just keep the issuer map current as you add Coolify apps, Cloudflare tunnels, mail domains, and managed services.