Add CAA Records in cPanel to Control Who Issues Your SSL

A CAA record is a small DNS record that lists which certificate authorities (CAs) are allowed to issue SSL certificates for your domain. In cPanel you add it in Zone Editor, with the Tag set to issue and the Value set to your CA's domain, such as letsencrypt.org. Done right, it takes about ten minutes and tells every other public CA not to issue for your name.

Here is the surprising part. Without a CAA record, any public CA may issue a certificate for your domain, as long as it validates that someone controls the domain. That means a validation mistake at any one of those CAs could affect you, even if you have never used that CA in your life.

By the end of this guide you will be able to add CAA records in cPanel, allow the right CA for AutoSSL, check the result with dig, and fix the common errors.

What a CAA record actually is

CAA stands for Certification Authority Authorization. It is a DNS record type, defined today in RFC 8659 (published November 2019, which replaced the older RFC 6844). It lets the domain owner say: "only these CAs may issue certificates for my names."

Think of it like a note at your building's front desk: "Only these couriers may collect parcels for flat 4B." Anyone else is turned away.

A CAA record has three parts. Let's Encrypt describes the general form as CAA <flags> <tag> <value>.

• Flags: a number that should almost always be 0. In raw zone syntax, 128 sets the "critical" bit (more on that below).
• Tag: what the record controls. The main ones are issue, issuewild and iodef.
• Value: usually one CA identifier, like letsencrypt.org, sometimes followed by extra parameters.

This is what a complete record looks like in standard zone file format.

example.com.    CAA 0 issue "letsencrypt.org"

Why this matters: Let's Encrypt checks CAA records before every certificate it issues. So this record is read every time anyone asks for a certificate for your domain, including your own server.

The three tags in plain words

• issue: names a CA that may issue normal certificates (and wildcards too, unless you add issuewild).
• issuewild: names a CA that may issue wildcard certificates, like *.example.com. When a wildcard is requested and issuewild records exist, they take precedence over issue.
• iodef: gives a contact (a mailto: address or an http/https URL) where a CA can report a request that broke your policy. It does not restrict anything by itself.

How the CA decides

The CA looks for CAA records on the exact name in the certificate first. If there are none, it climbs to the parent name, then the next parent, and so on, stopping at the first CAA set it finds. RFC 8659 says the climb goes up to, but not including, the DNS root.

That has two practical effects:

• A CAA record on example.com also covers www.example.com, shop.example.com and every other subdomain that has no CAA of its own.
• A CAA record on a subdomain overrides the parent. Let's Encrypt puts it this way: the CA respects the CAA record closest to the domain name.

Records with the same tag add up. If you have two issue records, one for each of two CAs, either CA may issue. And according to Let's Encrypt, CAA checking follows CNAME redirects, just like other DNS lookups.

Heads up: no CAA record at all means no restriction. RFC 8659 also says a set that contains only iodef records, or only tags the CA does not recognise, does not restrict issuance either. If you want protection, you need at least one issue record.

Before you start

Risk is low if the CA name is right. If it is wrong, your next renewal fails, while your current certificate keeps working until it expires.

Checklist:

• cPanel login for the account that owns the domain, with the Zone Editor feature enabled. Your host can turn this interface off in WHM, so ask them if you cannot see it.
• Your DNS really lives in cPanel. If your domain's nameservers point somewhere else (for example Cloudflare), records you add in cPanel do nothing. If you are not sure what nameservers are, our guide on how a host maps to a domain explains the basics.
• Know which CA issues your certificates today. In cPanel, open SSL/TLS Status and look at your current certificates. The cPanel docs say AutoSSL uses the Let's Encrypt provider by default, but your host may have chosen another provider.
• A terminal with `dig` (Linux and macOS usually have it), or any online DNS lookup tool that supports CAA.
• Time: about 10 minutes, plus a little waiting for DNS caches.
• A backup of your current records (Step 1 below).

Quick tip: if a CDN or another service requests certificates for your domain or a subdomain, its CA needs to be allowed too.

How to add CAA records in cPanel

These steps follow the official cPanel Zone Editor documentation, which at the time of writing (14 October 2026) is marked valid for cPanel version 136 and later. The official docs do not give a click path to it, so look for Zone Editor in your cPanel home screen.

Step 1: Back up the zone first

Here is an honest note: the cPanel Zone Editor docs do not describe an export or download button for the zone. The only export and copy buttons in that interface are for DNSSEC keys. There is also a Reset DNS Zone option, and the docs warn it "erases any modifications that you made to your zone records", so do not click it as a backup step.

So make your own simple backup:

1. Open Zone Editor in cPanel.
2. Click Manage next to your domain.
3. Copy the whole record table (Name, TTL, Type, Record) into a text file, or take screenshots of every page of it.

Then save what the public internet sees right now. This command saves your current CAA answer (often empty) into a file.

dig +short CAA example.com > caa-before.txt

This one saves the nameservers, so you can confirm later that you edited the right DNS server.

dig +short NS example.com > ns-before.txt

What you should see: ns-before.txt lists your host's nameservers. If it lists another provider, stop and add the records there instead (see the Variants section).

Step 2: Check for existing CAA records

On the Manage page, use the record type filter or type in the filter box to show only CAA records. The cPanel docs say you can filter the list by name or by record type.

If CAA records already exist, read them before adding anything. The cPanel docs advise that conflicting CAA records should be removed, or replaced with one for the CA you want.

Heads up: the cPanel WHM documentation for AutoSSL says that when AutoSSL runs, a preflight check adds a CAA record in the domain's zone file before it orders a new certificate. So if you see a CAA record you do not remember adding, it may have come from AutoSSL. Do not delete it without understanding which CA it allows.

Step 3: Add the issue record

On the Manage page:

1. Click Add Record, or click the arrow next to it and choose the record type.
2. Choose CAA as the type.
3. In the Name field, enter your domain. The cPanel docs say the system automatically appends the domain name to the record name.
4. Set Issuer Critical Flag to 0.
5. Set Tag to issue.
6. Set Value to your CA's domain, for example letsencrypt.org.
7. Click Save Record.

After saving, the record appears in the Manage Zone table. In standard zone syntax, the result is equivalent to this line.

example.com.    CAA 0 issue "letsencrypt.org"

Why the flag stays at 0: cPanel shows the Issuer Critical Flag as 0 (non-critical) or 1 (critical). In raw zone files the critical setting is written as 128, which is why you see that number in other guides. A critical record tells CAs to refuse issuance if they do not understand the tag. For the standard tags there is nothing to gain, and Let's Encrypt says the flag should almost always be 0.

Step 4: Add more CAs if you need them

If more than one CA issues certificates for your domain, add one issue record per CA. Remember, they are additive: any CA on the list may issue.

This example allows Let's Encrypt plus a second, made-up CA identifier for illustration only. Replace ca.example.net with your real CA's documented identifier.

example.com.    CAA 0 issue "letsencrypt.org"
example.com.    CAA 0 issue "ca.example.net"

Quick tip: always take the identifier from your CA's own documentation. A typo here does not show an error in cPanel. It only shows up later, as a failed renewal.

Step 5: Decide about wildcards

If you never use wildcard certificates, you can skip issuewild. Your issue records already cover wildcards when no issuewild record exists.

If you want different rules for wildcards, add a CAA record with Tag set to issuewild. For example, to forbid wildcard certificates from every CA while still allowing normal ones, RFC 8659 uses the value ; (a semicolon on its own) to mean "no CA may issue".

example.com.    CAA 0 issue "letsencrypt.org"
example.com.    CAA 0 issuewild ";"

In cPanel that is one more CAA record with Tag issuewild and Value ;.

Step 6: Add a reporting address (optional)

An iodef record tells CAs where to send reports about requests that broke your policy. In cPanel, choose Tag iodef and put a URL in Value. The RFC example uses a mailto: address.

example.com.    CAA 0 iodef "mailto:security@example.com"

Step 7: Lock down subdomains that should never get certificates

Because a subdomain's CAA record overrides the parent, you can block issuance for one name only. This is useful for a hostname used only for internal mail routing, for example. RFC 8659 shows this pattern.

nocerts.example.com.    CAA 0 issue ";"

In cPanel, enter the full subdomain name in Name (like nocerts.example.com), Tag issue, Value ;.

Advanced: limit validation methods or accounts

Let's Encrypt supports two optional parameters after the CA domain, separated by a semicolon:

• validationmethods: limits which ACME challenge types may be used. Let's Encrypt recognises http-01, dns-01 and tls-alpn-01.
• accounturi: limits issuance to one specific ACME account. Let's Encrypt account URIs end with your account ID.

This example allows Let's Encrypt to issue only through the http-01 challenge.

example.com.    CAA 0 issue "letsencrypt.org; validationmethods=http-01"

Heads up: only use these parameters if you run your own ACME client and know exactly how it validates. Get it wrong and renewals stop.

Variants: other DNS panels

The record is the same everywhere. Only the form changes.

cPanel Zone Editor

Covered above: Zone Editor, then Manage, Add Record, type CAA, then the fields Issuer Critical Flag, Tag and Value, and Save Record. One limit from the cPanel docs: if your server uses the MyDNS nameserver software, it does not support the CAA record type. Ask your host which DNS server they run if the CAA option is missing.

Cloudflare DNS

If your nameservers point to Cloudflare, add the record there. From Cloudflare's docs (last updated 21 April 2026):

1. Open the DNS Records page for your domain in the Cloudflare dashboard.
2. Select Add record and set Type to CAA.
3. Enter your domain in Name.
4. Choose a Tag and enter the CA in CA domain name.
5. Select Save, and repeat for each CA.

Heads up: Cloudflare says it adds CAA records automatically when you have Universal SSL and add any CAA record to your zone, so it can keep issuing its edge certificates. These extra records do not appear in the dashboard, but dig shows them. So on Cloudflare, dig may show more CAs than you added yourself. That is expected. If you also run a Cloudflare origin certificate on your cPanel server, our note on Cloudflare error 526 with a cPanel origin certificate covers that part.

Any other DNS panel

If your DNS is at a registrar or another provider, look for a record type called CAA. The fields usually match the three parts: flags, tag, value. If the panel has no CAA option, ask the provider. Even if the panel cannot create CAA records, Let's Encrypt says the provider's servers must still answer CAA lookups with NOERROR, or certificate checks can fail.

How to check it worked

Resolvers cache answers, so start with the command line.

This command shows your current CAA records in short form.

dig +short CAA example.com

What you should see: one line per record, for example 0 issue "letsencrypt.org". If the answer is empty, the record has not reached that resolver yet, or it was saved on a DNS server that is not authoritative for your domain.

This command shows the full answer, including the status code.

dig CAA example.com

What you should see: status: NOERROR in the header and your CAA lines in the ANSWER SECTION. A SERVFAIL, NOTIMP or a timeout is a problem (see Troubleshooting).

To skip caches, ask your authoritative nameserver directly. Replace ns1.example.com with a name from your ns-before.txt file.

dig CAA example.com @ns1.example.com

To check a subdomain that has no CAA record of its own, query it too. An empty answer there is normal, because the CA will climb to the parent.

dig +short CAA www.example.com

Finally, the real test: let a renewal happen. In cPanel, open SSL/TLS Status. The cPanel docs say the Certificate Status column shows errors from the AutoSSL logs and the last time AutoSSL ran for each domain, and you can filter for Has AutoSSL Problems. After the next AutoSSL run, your domains should show as active, with no CAA errors.

Made-up example: Amina runs a small bakery site on cPanel. She adds issue "letsencrypt.org" and checks with dig. Everything looks fine. Two weeks later, her mail. subdomain shows Has AutoSSL Problems. The cause: years ago she had added a CAA record on mail.example.com for an old paid CA. That record overrode her new parent record. She deletes the old record, and the next AutoSSL run succeeds. The lesson: always check subdomains for their own CAA records.

Troubleshooting

Renewal fails with a CAA error after you added records

Symptom: AutoSSL or your ACME client reports that CAA records forbid the CA from issuing. Likely cause: the CA your host actually uses is not in your issue list, or the identifier has a typo. Fix: check your certificate's issuer in SSL/TLS Status, add an issue record with that CA's documented identifier, and let AutoSSL run again.

Only wildcard certificates fail

Symptom: normal certificates renew, but *.example.com fails. Likely cause: an issuewild record exists and does not list your CA. When issuewild records are present, they win for wildcard requests. Fix: add your CA to issuewild, or remove issuewild if you want wildcards to follow your issue records.

One subdomain fails while the main domain works

Symptom: www or the bare domain is fine, but one subdomain fails. Likely cause: that subdomain, or a parent between it and your domain, has its own CAA records, which override yours. A CNAME can do the same thing, because CAA checking follows CNAMEs to the target's records. Fix: run dig CAA on the failing name and fix or remove the record that answers first.

SERVFAIL when looking up CAA

Symptom: dig CAA example.com shows status: SERVFAIL. Likely cause: Let's Encrypt says this most often means DNSSEC validation failed. Fix: test the domain in a DNSSEC debugger such as dnsviz.net, and check that all your nameservers are online. Without DNSSEC, Let's Encrypt says the second most likely cause is a nameserver returning NOTIMP (see below), and outages at your nameservers can also cause it.

NOTIMP or "CAA not supported"

Symptom: the lookup returns NOTIMP, or your DNS provider says it does not support CAA. Likely cause: the authoritative server answers unknown record types with an error. Let's Encrypt calls returning NOTIMP for unrecognised query types a violation of RFC 1035, and says the server only needs to return NOERROR. Fix: ask the provider to correct this, or move DNS to a provider that handles it. On cPanel, check whether the server uses MyDNS, which does not support CAA.

Lookups time out

Symptom: dig CAA hangs and times out, while A records resolve fine. Likely cause: Let's Encrypt says a common cause is a firewall in front of the nameserver that drops queries for unknown types. Fix: ask your DNS provider or host to check their firewall rules.

Cloudflare shows CAA records you did not add

Symptom: dig lists extra CAs like pki.goog or sectigo.com. Likely cause: Cloudflare adds them automatically for Universal SSL once you have any CAA record. Fix: nothing to fix. Leave them, or your Cloudflare edge certificates may fail.

Pro tips and when to ask for help

Keep the list short: each CA you allow is one more place a validation bug could matter.

Plan for shorter certificate lifetimes. Let's Encrypt announced on 2 December 2025 that its default certificates move from 90 days to 64 days on 10 February 2027, and to 45 days on 16 February 2028. More renewals means more CAA checks, so a broken CAA record will hurt you sooner. Let's Encrypt recommends ACME Renewal Information (ARI), automatic renewal and monitoring that alerts you when renewals fail.

CAA protects issuance, not traffic. Once your certificate works, make sure visitors actually use it. Our guide to redirecting HTTP to HTTPS with .htaccess covers that step.

Ask your host when: you cannot see Zone Editor, the CAA type is missing, you do not know which CA AutoSSL uses on your server, or dig shows NOTIMP or timeouts from their nameservers. If you are newer to how hosting and DNS fit together, what web hosting is is a gentle starting point.

The one message worth forwarding

Copy this and send it to your host, developer or whoever manages your DNS:

"Hi, I want to add CAA records for example.com so only our chosen certificate authorities can issue SSL certificates. Can you confirm which CA AutoSSL (or our SSL setup) uses for this domain and its subdomains, including any CDN or email services? I plan to add a CAA record with tag issue and that CA's domain in cPanel Zone Editor, with the critical flag at 0, and then check it with dig +short CAA example.com. Please tell me if anything on our side would need an extra CA added."

The takeaway: one issue record naming your real CA, checked with dig and confirmed by a successful renewal, is all most sites need.