CAA records: choose which CAs may issue SSL for your domain

A CAA record tells certificate authorities which of them you authorize to issue SSL/TLS certificates for your domain. The safe order is to identify every certificate service you use, choose a policy, publish it at the authoritative DNS provider, and check the next issuance path—not simply copy a popular CA's name into DNS.

No CAA record at the exact hostname does not necessarily mean there is no policy: a parent name or an alias can supply one. If no applicable restriction exists, CAA does not limit the issuing CA; the CA still has to validate the domain and satisfy its other issuance requirements. Let's Encrypt's CAA guide explains the distinction.

This guide covers public website TLS certificates, commonly called SSL certificates, in cPanel, Cloudflare and DNS zone files. It does not configure S/MIME certificates or a private PKI. The examples use reserved example domains; they are instructions to adapt, not results from a test of your site.

What a CAA record controls

CAA is an additional issuance check, not a website-security guarantee. It cannot prevent a permitted CA from making a mistake, protect a stolen private key, or replace certificate-expiry monitoring. Browsers do not use CAA to validate an existing certificate. RFC 8659, sections 1 and 5

A record's data has three fields, such as 0 issue "letsencrypt.org":

• Flags: use 0 for an ordinary policy. The critical bit is represented by 128 in a zone file; an unknown critical property prevents issuance. It is not a setting for making an ordinary allow-list “more secure.”
• Tag: issue controls ordinary issuance; issuewild provides a separate wildcard policy; iodef supplies a reporting destination.
• Value: the CA's published identifier, not its brand name, or a reporting URI for iodef. Quote the value in a zone file; DNS dashboards often provide separate fields instead.

Read the tags together, not as independent on/off switches:

• issue authorizes the named CA for non-wildcard certificates and, if no issuewild exists in the applicable set, for wildcard certificates too.
• issuewild applies only to wildcards and overrides issue for that purpose. An issuewild-only set does not restrict non-wildcard issuance.
• iodef can contain mailto:security@example.com or an HTTPS reporting endpoint. It does not grant or deny issuance, and reports are not guaranteed. Use a monitored address, understanding that DNS makes it public. CA/Browser Forum, section 4.2.2.1

Multiple allow entries are additive. 0 issue ";" authorizes nobody, but it does not cancel another issue entry that authorizes a CA. A deny-all policy must not retain competing allow entries. RFC 8659, section 4.2

Which policy applies to a subdomain?

For shop.example.com, the lookup starts there and moves upward if it finds no CAA records. The first CAA record set found replaces—not merges with—the parent policy. For *.example.com, the CAA search starts at example.com, without the *. prefix.

This has a surprising consequence: an iodef-only record set on shop.example.com stops the search and does not inherit the restrictive issue records at example.com. Check the whole applicable set, not just whether a CAA row exists. RFC 8659, section 3

CNAME aliases can change the answer

Each CAA lookup follows DNS aliases. If blog.example.com is a CNAME to a hosted platform and the alias lookup returns CAA records, that set is relevant. You cannot publish an ordinary CAA record alongside a CNAME at the same DNS name. Let's Encrypt: where to put CAA

Do not “fix” an alias by deleting it. Ask the platform which policy and CA its custom-domain service requires. If the alias lookup yields no CAA set, the RFC continues at the parent of the original queried name; it does not simply climb the alias target's parent tree. RFC 8659 lookup algorithm

Existing HTTPS can work while renewal is broken

Changing only CAA does not revoke an already issued certificate. A wrong policy can therefore stay unnoticed until a later issuance or renewal fails. Treat a working padlock as evidence of today's served certificate, not proof that the renewal configuration is healthy.

The DNSSEC check that matters for renewal

You do not have to publish CAA records to obtain a public certificate. But a CA still needs to resolve the relevant DNS queries: a failed lookup is different from a successful lookup with no CAA answer.

Since 15 March 2026, the CA/Browser Forum's TLS requirements mandate DNSSEC validation for CAA queries from the CA's primary network perspective. DNSSEC-validation failures cannot be treated as permission to issue. The current requirements consolidate this in section 4.2.2.2. TLS Baseline Requirements

That is not a requirement to enable DNSSEC on every domain. An unsigned domain is different from a signed domain whose chain fails validation. If DNSSEC is enabled, a stale registrar DS record, bad signature or other validation problem needs diagnosis—not a guessed extra CAA entry.

Before you change DNS

• Find the authoritative DNS provider. It may be your host, Cloudflare or your registrar. Editing an inactive copy of the zone changes nothing publicly. See how domain records and nameservers fit together if you are unsure who controls the zone.
• Inventory certificate services. Include the website, www, public origin certificates behind a CDN, and custom domains used by stores or support platforms. Record the intended renewal CA and whether each service needs a wildcard.
• Choose your checking method. The commands below use a Unix-like shell with dig and OpenSSL installed. They read public DNS and certificate data; they do not change DNS or certificates. Without a terminal, use your panel's certificate details and ask your DNS provider for the equivalent lookup output.
• Save the existing state. Export or capture the exact CAA records, names and TTLs before editing. Include current public query results, since providers can publish records not shown in the dashboard. A rollback should restore this state, not indiscriminately delete CAA.
• Check expiry and ownership. Know when each certificate expires, who receives failures, and who can repair DNS. If a certificate is close to expiry and you do not know its renewal path, resolve that first rather than introduce a new restriction.

Limit the change. Keep A, AAAA, MX, TXT, NS and DNSSEC settings unchanged for a CAA-only edit. A policy mistake mainly threatens future issuance; an accidental broader DNS change can affect live web and email services immediately.

Step 1: identify the CA that must issue next

The current issuer is a starting point. The renewal job's configured CA is the deciding fact: a host or CDN may be migrating to a different CA.

Inspect the current public certificate

Replace both occurrences of example.com with your hostname. This connects to HTTPS and prints the presented certificate's issuer and validity dates. It deliberately leaves connection errors visible:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -issuer -dates

-servername sends SNI so a shared server knows which hostname you want. issuer= identifies the issuer; notAfter= is the expiry date. The issuer name may describe an intermediate CA rather than directly giving its CAA identifier. Confirm the mapping in the CA's documentation. This is certificate inspection, not a complete trust or hostname-validation test. OpenSSL s_client, OpenSSL x509

Repeat for www.example.com and each important HTTPS hostname. A failed connection is not a CAA diagnosis. If you use a CDN, this command normally shows its edge certificate, not the certificate on the origin server.

Check the configured renewal service in cPanel

Open Security → SSL/TLS Status and inspect the certificate details and AutoSSL status for each domain. Some cPanel installations show this as a tab under SSL/TLS Certificates. The interface can show AutoSSL errors and the last run; availability depends on your host's settings. cPanel SSL/TLS Status

Ask the host which CA AutoSSL is configured to use and whether a provider change is planned. Do not derive the future policy solely from an old certificate or assume every cPanel server uses the same CA.

Separate Cloudflare edge and origin certificates

Cloudflare's edge and your origin are separate certificate endpoints. Check the selected Cloudflare certificate product, then inventory any publicly trusted origin certificate independently. Its CA may need authorization as well.

• For Universal SSL, Cloudflare documents adding CAA permissions automatically when you add any CAA record to the zone.
• Those automatically added records are visible in DNS queries, not the dashboard. Inspect the published answer before deciding how restrictive your policy actually is.
• For Advanced Certificate Manager, do not assume that automation applies: Cloudflare's documentation says it does not automatically add the required CAA records for advanced certificates.
• Partner CAs can change. Use Cloudflare's current CAA documentation and the actual certificate configuration rather than freezing a copied partner list into your operating procedure.

Allowing the right CA is only one prerequisite. CAA cannot prove that Cloudflare, your host or an ACME client will successfully renew and deploy the next certificate.

Write a small certificate inventory

For each service, record: hostname(s), edge or origin, current issuer, intended renewal CA, wildcard requirement, expiry, and the team responsible. Leave unknowns explicit and resolve them before tightening the policy.

• Include an origin's public TLS certificate even if visitors never see it directly. Do not confuse a provider-specific private origin certificate with a publicly trusted browser certificate.
• Include custom-domain services such as shop.example.com and help.example.com. The service operator—not the application brand alone—must tell you which CA and CAA values it needs.

Example, not a customer incident: a site has a current Let's Encrypt certificate, but its host has configured the next renewal through Sectigo. Restricting CAA to Let's Encrypt would not stop today's HTTPS; it would obstruct that intended renewal. The inventory catches the mismatch before expiry.

Step 2: get the exact CAA identifiers

Copy identifiers from the CA or certificate service's current documentation. These are examples for the services you actually use, not a recommendation to authorize all five:

• Let's Encrypt: letsencrypt.org. Official CAA guide
• Google Trust Services: pki.goog. Google's CAA configuration
• Sectigo: sectigo.com; its documentation also recognizes trust-provider.com and usertrust.com. You do not need every alias just to authorize the same CA. Sectigo's CAA identifiers
• DigiCert: digicert.com for TLS certificates. DigiCert CAA documentation
• SSL.com: ssl.com. SSL.com's validation troubleshooting guide confirms the authorization requirement. Check any vendor-specific instructions for your certificate product.

The names printed in a certificate chain are not a safe substitute for these identifiers. Do not use a reseller's domain, an intermediate certificate's nickname, or a guessed spelling.

Advanced accounturi and validationmethods parameters can limit accounts or validation methods. Leave them out of a first basic policy unless you have a documented requirement and have checked CA support, account changes and recovery. They are defined separately in RFC 8657.

Step 3: publish a policy that matches the inventory

For a domain using only Let's Encrypt, the following illustrative zone-file records allow that CA and optionally publish a reporting address. Replace the example domain and mailbox. Add a separate issue entry for each additional CA you intentionally authorize.

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

This policy also permits Let's Encrypt wildcards because it has no separate issuewild policy. Omit iodef if you do not maintain a reporting mailbox. Do not add a reporting endpoint you do not control.

Option A: cPanel Zone Editor

Use this only if the cPanel-managed zone is authoritative. Take the backup described above; do not use Reset Zone for a CAA change.

1. Open Domains → Zone Editor.
2. Choose Manage for the domain.
3. Choose Add Record → CAA, or add a row and select the CAA type.
4. Set Name to the intended DNS name, such as example.com.. Check the saved result for an accidentally duplicated domain suffix.
5. Set Issuer Critical Flag to 0 / Non-critical.
6. Set Tag to issue.
7. Set Value to the CA identifier, such as letsencrypt.org; do not paste an entire zone-file line into this field.
8. Save the record, then confirm the stored name, type, TTL, tag and value.

Repeat for the other intended CAs. For a reporting record, choose iodef and supply the complete mailto: or HTTPS URI. Interface labels can vary with version and host configuration. cPanel Zone Editor

The dashboard showing the row proves it was saved there; the DNS checks below establish whether the authoritative service publishes it. If a change is wrong, restore the previous CAA state rather than reset the entire zone.

cPanel documents its critical-flag control as 0 or 1, while the DNS presentation format uses 128 for the critical bit. For this ordinary setup choose the UI's non-critical option and verify that public DNS shows 0.

Option B: Cloudflare DNS

1. Open the correct zone's DNS → Records page.
2. Choose Add record.
3. Set Type to CAA.
4. Enter the intended domain or hostname in Name.
5. Choose the tag corresponding to issue, issuewild or iodef.
6. Enter the CA identifier or reporting value in its own field; use a non-critical record for this basic setup.
7. Save, repeat for other required records, and inspect public DNS.

Check the complete DNS answer, including provider-added records. An issuewild ";" entry will not override automatic wildcard allow entries beside it.

If the required restrictions conflict with the certificate product's documented behavior, resolve that with the provider. Do not switch off working certificate services merely to make an example policy look exact.

For a delegated subdomain zone, inspect applicable parent policies too. Editing only the subdomain's dashboard does not establish what the whole lookup will return.

Option C: a registrar's editor or a zone file

This example permits two CAs for non-wildcard certificates, Sectigo alone for wildcards, and no issuance at internal.example.com where that record is applicable. The name “internal” here is an ordinary subdomain of a public domain, not a private-PKI instruction.

example.com.          3600  IN  CAA  0 issue "letsencrypt.org"
example.com.          3600  IN  CAA  0 issue "sectigo.com"
example.com.          3600  IN  CAA  0 issuewild "sectigo.com"
example.com.          3600  IN  CAA  0 iodef "mailto:security@example.com"
internal.example.com. 3600  IN  CAA  0 issue ";"

In an editor with separate boxes, enter flags, tag and value separately. If it expects one combined value, the corresponding Sectigo entry is:

0 issue "sectigo.com"

If you need a different DNS-server format, the SSLMate CAA Record Helper can generate one. Review the result against your inventory; a generator cannot know future CA migrations or every service you use. Self-managed DNS operators should validate and deploy the zone through their established change procedure.

Choose wildcard permissions deliberately

Before adding issuewild, identify whether the CDN, host or custom-domain service needs a wildcard. A certificate request can contain both a wildcard and ordinary names; each name must be allowed.

• Same CA policy for both: use the intended issue entries and no separate issuewild entries.
• Different wildcard CA policy: add issuewild for each wildcard CA you want. This replaces the issue list for wildcard checks, not for ordinary names.
• No wildcard issuance: keep the intended issue entries and make 0 issuewild ";" the only issuewild entry in the applicable set. Another wildcard allow entry would still authorize its CA.

No issuance at a particular name: make 0 issue ";" the only issue entry and ensure no issuewild allows wildcard issuance. Recheck child policies and aliases before assuming a parent restriction covers every service.

Step 4: verify DNS, then verify the renewal path

DNS verification and renewal verification answer different questions. Start with the public record, allow existing cache lifetimes to expire, and keep a timestamped note of the answers. See DNS propagation and caching for the background; changing your own resolver does not force a CA's cache to refresh.

Check answers, errors and authoritative servers

Run the short query for a compact record list:

dig CAA example.com +short

For the simple Let's Encrypt example, an illustrative answer is shown below. It is not a measured result for your domain:

0 issue "letsencrypt.org"
0 iodef "mailto:security@example.com"

An empty +short result is inconclusive. Rerun the full query and inspect status, the answer and authority sections. NOERROR with no CAA answer is different from SERVFAIL, NXDOMAIN or a timeout. An empty result at one hostname does not check all parent policies.

dig CAA example.com
dig CAA shop.example.com
dig CNAME shop.example.com
dig NS example.com +short

Next query each authoritative nameserver directly to compare the published state with cached recursive answers. Replace ns1.example.net with a real authoritative server for the zone; if the hostname is in a separately delegated subdomain, use that zone's servers. A direct authoritative answer is not itself a DNSSEC validation test.

dig @ns1.example.net CAA example.com +norecurse

Check DNSSEC and the names in the certificate order

For a recursive check using Cloudflare's DNSSEC-validating resolver:

dig @1.1.1.1 CAA example.com +dnssec

+dnssec requests DNSSEC data; it does not make dig validate signatures. With a validating resolver, ad signals an authenticated answer. NOERROR alone does not establish that a domain is signed or validated, and an unsigned domain may correctly lack ad. ISC dig documentation, Cloudflare DNSSEC FAQ

Repeat the checks for every hostname in the order, following aliases and inspecting parents when needed. Use DNSViz to investigate a DNSSEC failure. One successful lookup from your machine does not reproduce every network perspective used by a CA.

Test safely; do not force repeated live reissues

Use the certificate service's documented test workflow. For an ACME client, prefer its staging or dry-run procedure first; review any hooks or server changes the client may run. Let's Encrypt recommends staging to reduce production rate-limit problems. Staging certificates are not browser-trusted and must not replace your live certificate. See also our renewal workflow guide.

A staging success is not a promise of production renewal: accounts and configuration can differ, especially with accounturi restrictions. With a managed panel, ask the host to run its supported check and inspect the result; do not repeatedly force reissues or wait until expiry to find out.

After the next authorized production renewal, check its success log and inspect the certificate actually served at every relevant endpoint. A new certificate issued but not deployed is still an operational failure. Keep expiry alerts and a responsible owner; repeat the policy review whenever DNS, a CDN, a hosting service or a CA changes.

Troubleshooting: match the symptom to the next check

The CA explicitly says the CAA policy forbids issuance

Check: identify the CA, exact requested names and wildcard status in the failed order or AutoSSL/ACME log. Do not assume the failed CA matches today's live issuer.

Compare: examine the applicable issue or issuewild entries and any account or validation-method parameters. Check both the bare name and wildcard when the order requests both.

Repair: authorize the intended service in the relevant policy only after confirming that choice. Preserve other deliberate restrictions and retest DNS before retrying. Adding issue cannot repair a restrictive issuewild set for a wildcard order.

Only one subdomain fails

Check: compare shop.example.com with the working name. Look for a nearer CAA set, CNAME chain, separate delegation, or a different certificate service.

Interpret: a child set can replace the parent; an alias lookup can return a platform's policy. Either can make the same parent-domain edit work for one name but not the other.

Repair: change only records you control and understand. Do not automatically delete child records or the CNAME. Ask the platform to confirm its required CA or correct its policy when the relevant records belong to it.

SERVFAIL during a CAA lookup

Check: keep the full resolver output and compare it with the authoritative servers. Run DNSViz. DNSSEC validation is a common cause, but SERVFAIL can also reflect authoritative-server faults or outages.

Interpret: a validation failure is not an empty allow-all policy. The CA's mandatory DNSSEC validation cannot be bypassed by simply adding an issue row.

Repair: send the DNS provider the exact name, query type, timestamp, resolver, error and DNSViz result. Ask it to check the chain and signed negative answers as well as positive records. Coordinate any registrar DS correction with the DNS operator; do not disable DNSSEC or remove DS records blindly. Let's Encrypt's CAA error guidance

Timeout or NOTIMP

Check: query every authoritative server, not just the one that happens to answer. An unreachable server or firewall filtering CAA queries can produce intermittent failures.

Repair: ask the DNS operator to fix reachability or unsupported-type handling. A server with no CAA data should not answer a legitimate CAA query with NOTIMP; successful no-data responses are different from lookup errors. Do not work around a DNS failure by repeatedly ordering production certificates.

CAA is missing from the DNS editor

Check: confirm that you are editing the authoritative provider and that your account has the necessary DNS features enabled.

Interpret: an editor lacking a CAA input is not the same as a nameserver being unable to answer CAA queries correctly.

Repair: ask the provider for its supported way to publish CAA. If a DNS migration is necessary, plan it separately with all records and DNSSEC handled deliberately; changing nameservers is not a one-record shortcut.

A misspelled tag or identifier

Check: compare the published value with the CA's official identifier, including spelling and parameters.

Interpret: an unknown non-critical tag does not enforce the intended restriction. A valid issue tag with the wrong identifier does not authorize your CA, although another matching allow entry may. An unknown critical property can block issuance.

Repair: correct the specific row and verify the published set again. Do not add broad permissions simply to hide an unexplained typo.

Origin renewal works, but a CDN or hosted service fails

Check: treat the edge, origin and third-party custom-domain orders as separate renewal paths. Each may request different names or use different CAs.

Repair: confirm the service's documented CA and wildcard requirements, then adjust the appropriate policy. Keep working origin authorization unless there is a deliberate reason to remove it.

Rollback and escalation

If a CAA-only change causes an unintended block, restore the captured previous CAA records and TTLs, then verify the authoritative and recursive answers. Restoring an originally empty set may remove restrictions; deleting a child set may expose a parent policy. Record that consequence rather than treating deletion as universally safe.

If the policy is correct but renewal still fails, continue with the provider's validation, account, deployment and scheduler checks. CAA is not an email-authentication setting; SPF, DKIM and DMARC solve a different problem.

What to send your host or DNS provider

A useful support request contains the hostname, intended CA, wildcard requirement, expiry date, current CAA response and exact error. Do not include private keys, API tokens or unredacted account secrets. You can adapt this:

“Please confirm the CA and wildcard requirements for the next certificate renewal on example.com, including our CDN and custom-domain services. We want CAA to authorize those services without removing other intended restrictions. The attached DNS response and renewal error are from [UTC timestamp]. Please confirm the applicable CAA set, DNSSEC result, safe test method and who will verify that the renewed certificate is deployed.”

The finish line is not a saved DNS row. It is an understood policy, verified DNS, a tested renewal path and someone watching the outcome before expiry.

For the cPanel-specific procedure, continue with Add CAA in cPanel and verify the AutoSSL renewal path.