"CAA record prevents issuance" — Causes & Fix

A certificate authority refuses to issue a certificate because a CAA record on your domain does not authorize it. Here is exactly why it happens and how to fix it.


The error "CAA record prevents issuance" (also seen ascaa: Domain … has no CAA record being the good case, andCAA record for example.com prevents issuance being the failure) means a certificate authority checked your domain's CAA record and found that it is noton the list of CAs allowed to issue certificates. To comply with the CA/Browser Forum rules, the CA must refuse. The fix is to publish a CAA record that authorizes the CA you are using — or remove the over-restrictive record entirely.

What the Error Looks Like

Depending on your ACME client (certbot, acme.sh, Caddy, Traefik, cert-manager) the wording varies, but the cause is the same:

text
# Let's Encrypt / certbot Problem for "example.com": Error creating new order :: CAA record for example.com prevents issuance # acme.sh [example.com] Verify error: DNS problem: CAA record for example.com prevents issuance # Generic ACME urn:ietf:params:acme:error:caa Certification Authority Authorization (CAA) records forbid this CA from issuing

See which CAs your domain authorizes

Why It Happens

A CAA record lets a domain owner declare which Certificate Authorities are permitted to issue certificates for that domain. When a CA receives an order, it queries your CAA records and climbs the DNS tree — from the exact name up through each parent domain — looking for a relevant issue (or issuewild) property. If it finds CAA records but none authorize that CA, issuance is forbidden.

1. The CAA record lists a different CA

The most common cause. Your domain has a CAA record allowing, say, DigiCert, but you are trying to issue with Let's Encrypt:

text
; This forbids Let's Encrypt — only DigiCert is authorized example.com. 3600 IN CAA 0 issue "digicert.com"

2. A typo in the CA identifier

CAA values are exact domain strings. letsencrypt.com (wrong) does not authorize Let's Encrypt — the correct identifier is letsencrypt.org. A single wrong character blocks issuance.

3. A wildcard certificate with no issuewild

If you request a wildcard (*.example.com) and the domain has an issuewildrecord that excludes your CA — or an issue record but a restrictiveissuewild ";" — the wildcard is refused even when a normal certificate would succeed.

4. Issuance is blocked entirely

A CAA value of ";" is a deliberate "no CA may issue" instruction. If this was published by mistake (or by a previous admin), every CA will refuse.

text
; Forbids ALL certificate authorities from issuing example.com. 3600 IN CAA 0 issue ";"

5. A parent domain restricts the subdomain

CAA is inherited. If example.com has a restrictive CAA record and you are issuing forapp.example.com (which has no CAA of its own), the CA climbs to the parent and applies its policy. A subdomain cannot escape a parent's CAA unless it publishes its own CAA record.

6. A stale record still in DNS cache

You may have already fixed the record, but the CA is still seeing the old value because of the TTL. Wait for the TTL to expire before retrying (see verification below).

No CAA record at all is fineA domain with no CAA record permits any CA to issue — that is the default and it never causes this error. This error only appears when a CAA record exists and is too restrictive. Adding a wide-open CAA record is not required for issuance to work.

How to Diagnose It

First, see exactly what CAA records the CA is seeing. Use the ShowDNS CAA Lookup to check your domain (and its parent), or query directly with dig:

bash
# Check the exact name you're issuing for dig CAA example.com +short # Example output — only DigiCert is allowed: # 0 issue "digicert.com" # Also check the parent, since CAA is inherited dig CAA app.example.com +short dig CAA example.com +short

Compare the authorized identifier(s) against the CA you are actually using. If your CA is not listed, that is the problem.

Look up your domain's CAA records

CA Identifiers for Common Providers

Use the correct issue value for your certificate authority:

Certificate AuthorityCAA identifier
Let's Encryptletsencrypt.org
ZeroSSL / Sectigosectigo.com
Google Trust Servicespki.goog
DigiCertdigicert.com
GlobalSignglobalsign.com
Amazon (ACM)amazon.com, amazontrust.com, awstrust.com, amazonaws.com
Buypassbuypass.com
When in doubt, check your CA's documentationCAs occasionally use more than one identifier or change them. If issuance still fails after adding what you believe is correct, confirm the exact CAA value on the CA's official documentation page.

How to Fix It

Option A — Authorize your CA (recommended)

Add an issue record for your CA. You can have multiple issue records to allow several CAs at once. For example, to allow Let's Encrypt:

text
; Allow Let's Encrypt to issue standard certificates example.com. 3600 IN CAA 0 issue "letsencrypt.org" ; Allow multiple CAs — just add more issue records example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 issue "sectigo.com"

Option B — Authorize wildcard issuance

For a wildcard certificate, add an issuewild record. Note that a presentissuewild takes precedence over issue for wildcard requests:

text
; Allow Let's Encrypt for both normal and wildcard certificates example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"

Option C — Remove the over-restrictive record

If the CAA record was published in error and you do not need to restrict CAs, deleting it returns the domain to the default "any CA may issue" behavior and clears the error.

Adding an optional incident-reporting address

While fixing CAA, it is good practice to add an iodef tag so a CA can notify you of unauthorized issuance attempts. It does not affect whether issuance succeeds:

text
example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
Set CAA on the same name the CA climbs toIf you publish CAA at the apex (example.com) it covers subdomains that have no CAA of their own. But if a subdomain like app.example.com has its own CAA records, the CA usesthose and stops climbing. Make sure the record you edit is the one actually in effect for the name you are issuing.

Verify the Fix

Verify CAA records for your domainConfirm the authorized CA is now live before you retry issuance.
Check CAA records now

CAA changes only take effect once the old record's TTL expires from resolver caches. After publishing, confirm the new value is live before you retry issuance:

bash
# Confirm the new record is being served dig CAA example.com +short # Expected: 0 issue "letsencrypt.org" # Then re-run your ACME client, e.g. certbot renew --force-renewal # or acme.sh --issue -d example.com --force

You can also re-check with the CAA Lookup tool to confirm the authorized CA now appears. If the old value still shows, wait for the TTL (commonly 300–3600 seconds) and check again before retrying — repeated failed ACME orders can hit rate limits.

Frequently Asked Questions

Do I need a CAA record for Let's Encrypt to work?

No. A domain with no CAA record allows any CA, including Let's Encrypt. You only need to add one if a restrictive CAA record already exists, or if you deliberately want to limit which CAs may issue.

What is the difference between issue and issuewild?

issue controls all certificate issuance for the domain, including wildcards when noissuewild is present. issuewild controls only wildcard certificates and, when present, overrides issue for those requests. If you want wildcards from a CA, make sure it is authorized in issuewild (or that no issuewild record exists).

I fixed the record but still get the error — why?

Almost always DNS caching. The CA is still seeing the old CAA value until the previous record's TTL expires. Confirm the new value with dig CAA yourdomain +short from a fresh resolver, wait out the TTL, and retry. Also double-check you edited the CAA on the correct name — a subdomain with its own CAA is not affected by changes at the apex.

Can I allow more than one certificate authority?

Yes. Publish multiple issue records, one per CA. Each authorized CA that appears in the set is permitted to issue; all others are refused.

Does CAA affect certificates I already have?

No. CAA is checked only at issuance time. Existing valid certificates continue to work, and browsers do not check CAA. It only matters when a CA is asked to issue or renew a certificate.

Related