How DNS Certificate Authorization Works for Websites

Certification Authority Authorization (CAA) is a DNS record that tells certificate authorities (CAs) which issuers may create TLS certificates for your domain. A CA checks the applicable CAA policy before issuing a certificate, walking from the requested hostname toward the DNS root until it finds a CAA record set. If that set authorizes a different CA, issuance stops. If no CAA record set exists, CAA places no issuer restriction.

CAA reduces the chance that an unintended CA can issue for your names, but it is not a certificate validator and it cannot revoke an already-issued certificate. You still need the CA’s normal domain-control and policy checks, renewal monitoring, and a plan for DNS changes.

CAA in one minute

• Record form: CAA <flags> <tag> <value>.
• Issuer control: the issue property names a CA authorized to issue ordinary certificates.
• Scope: each DNS name and wildcard in a certificate request must satisfy the applicable policy.
• Lookup: the CA searches the exact name, then parent labels, until it finds a CAA RRset.
• Timing: a new policy affects future issuance after DNS TTL and resolver caches expire; an older certificate can remain valid.

The mechanism is specified by RFC 8659. Let’s Encrypt gives a practical overview in its CAA documentation.

How a CA evaluates CAA

1. Identify every name in the request

A certificate can contain several Subject Alternative Name (SAN) entries, such as example.com, www.example.com, and api.example.com. A wildcard such as *.example.com is a separate name for authorization purposes. The issuer must evaluate each FQDN and wildcard; authorizing a parent does not automatically make an unrelated delegated zone safe.

2. Walk up the DNS tree

For www.example.com, the search starts at www.example.com, then example.com, then com. The first CAA RRset found controls the name. A record at example.com is inherited by names below it unless a lower label publishes its own CAA RRset. A CAA record at a sibling, such as shop.example.com, does not control api.example.com.

3. Apply the properties

An issue property authorizes an issuer domain. Multiple issue records form an allow-list: each named CA is permitted. If a restrictive set exists and the requested issuer is absent, the CA must deny issuance, subject to a certificate-policy exception. The flags field is an unsigned integer from 0 through 255; use 0 for normal records unless your CA documents another value.

RFC 8659 also defines property tags for wildcard-specific authorization and incident reporting. Providers expose these as tags such as issuewild and iodef; use the exact issuer domain and syntax published by your selected CA or DNS provider. Unknown or non-restrictive tags do not, by themselves, restrict issuance.

Publishing a policy

First decide which CA(s) your organization actually uses for issuance and renewal. Obtain the issuer-domain value from that CA’s current documentation; the value is provider-specific. Then add CAA records at the narrowest DNS name that should share the policy.

Authorizing one CA for a zone

; BIND-style zone file
example.com. 3600 IN CAA 0 issue "letsencrypt.org"

In a hosted DNS editor, enter type CAA, name @ (or the provider’s equivalent for the zone apex), flag 0, tag issue, and the issuer value from the CA documentation. Do not include the quotes if the editor adds them automatically.

Authorizing more than one CA

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "pki.example-ca.test"

Use multiple records only when both issuers are intentional and your renewal automation can use either. Removing one later can break unattended renewals that still request that CA.

Separate wildcard policy

If you issue wildcards, check whether your CA and policy need a wildcard-specific property. A typical pattern is:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"

Do not copy this issuer value blindly. Confirm the exact tag support and value with the CA. A wildcard request still has to satisfy the authorization visible at the relevant DNS name.

Reporting contact (optional)

An iodef property can publish a URI for reports about certificate-policy violations. It does not authorize an issuer and is not a substitute for alerting on your own certificate inventory. Follow the RFC and provider documentation for the accepted URI format.

Delegated subdomains and inheritance

CAA follows DNS hierarchy, but delegation changes where the authoritative answer lives. If dev.example.com has its own nameservers, query the authoritative servers for that child zone. A CAA RRset at example.com may no longer be the first visible set for names inside the delegated zone. Publish an explicit policy in each delegated zone when different teams or CAs operate there.

An empty issuer value in an issue record is commonly used to state that no CA is authorized at that label. Because this can stop every renewal, use it only as a deliberate deny policy and document the change.

Verify what the internet sees

Check both the exact hostname and its parents. The +trace option helps identify delegation; a normal query through several recursive resolvers shows what clients are likely to cache.

# Exact name and parent
dig CAA www.example.com
dig CAA example.com

# Ask public recursive resolvers
dig @1.1.1.1 CAA www.example.com
dig @8.8.8.8 CAA www.example.com

# Follow delegation when results look unexpected
dig +trace CAA www.example.com

Record the answer, the responding server, and the TTL. If the exact name returns no CAA but the parent returns an RRset, the parent policy controls the name. If all levels return no CAA, CAA imposes no restriction and the CA proceeds to its other checks.

For planned issuance, request every SAN and wildcard you intend to use, then read the CA’s diagnostic. A CAA denial usually means the visible RRset does not name that issuer, a parent RRset is controlling the name, or a cached answer has not expired.

DNS TTL, rollout, and renewal timing

CAA changes are DNS changes. Lowering the TTL shortly before an edit can reduce the waiting period, but recursive resolvers may retain an earlier answer until its old TTL expires. Some CA policies also require the issuer to re-check CAA during a defined window; Let’s Encrypt’s published policy says its check must be made for each SAN name and that issuance occurs within the CAA record TTL or eight hours, whichever is greater. Plan changes ahead of a renewal window and keep the same policy in infrastructure-as-code and DNS.

1. Publish the intended RRset with a documented TTL.
2. Query authoritative servers, then multiple recursive resolvers.
3. Run a staging or test issuance if your CA offers one.
4. Monitor the first production renewal and retain the CA response.
5. After a CA migration, remove the old issuer only after all automation uses the new one.

What CAA does not do

• It does not prove that a presented certificate is valid. Browsers validate the certificate chain, hostname, dates, and other rules; they do not use the current CAA record as a validation input.
• It does not revoke certificates. A certificate issued while an older policy was active can remain valid after you publish a new policy. Revoke or replace it through the CA when necessary.
• It does not replace domain-control validation, key protection, certificate transparency monitoring, or renewal alerts.
• It does not guarantee issuance. CAA authorization is necessary but not sufficient; the CA must still complete its other policy and domain-control checks.

Troubleshooting CAA errors

Symptom	Likely cause	Fix
“CAA record does not authorize this CA”	The issuer is absent from the first RRset found.	Add the issuer’s documented value, or use the CA named by the existing policy. Query the exact name and each parent.
Works at the apex, fails for www	A lower-label RRset or delegated zone has a different policy.	Query www directly and inspect child-zone nameservers. Align or remove the conflicting RRset.
Wildcard issuance is denied	Wildcard authorization is separate or the CA does not support the configured wildcard tag.	Read the CA’s current wildcard CAA instructions and publish the exact supported property.
Policy change is not recognized	Authoritative DNS is updated, but recursive caches still hold the previous RRset.	Check TTLs at authoritative and recursive servers; wait for expiry before retrying.
No CAA records are returned	No RRset exists in the name’s ancestry, or the query is sent to the wrong DNS service.	Confirm the domain’s authoritative NS records and query them directly. Decide whether an unrestricted policy is acceptable.
Renewal broke after removing a CA	Automation still requests the removed issuer.	Update the ACME client or certificate manager first, verify a test renewal, then remove the old issue record.
Different tools show different answers	Split-horizon DNS, propagation, or resolver caching.	Compare authoritative answers, resolver answers, and the network location used by the CA.

Operational checklist

• Inventory every certificate SAN and wildcard, including internal automation.
• Choose one or more intended CAs and copy their issuer-domain strings from current documentation.
• Publish issue records at the correct authoritative zone.
• Review wildcard and delegated-subdomain behavior separately.
• Query authoritative and recursive DNS, recording TTLs.
• Test issuance before the next renewal deadline.
• Monitor renewal failures and certificate transparency after a policy change.
• Keep CAA records, DNS ownership, and certificate-manager configuration under change control.

Or skip the browser setup

If you need a visual record of a DNS management page, certificate error, or documentation URL, ScreenshotNeo captures it with one HTTP request. It accepts the cookie or consent banner like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before the capture; each step can be turned off. Only clean shots are billed: bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies the result with X-Page-Verdict and X-Billed headers.

See the ScreenshotNeo API documentation for all options. This minimal call returns a WebP image:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

For DNS documentation workflows, you can add full-page capture, a CSS selector, dark mode, any viewport or one of 12 device presets, retina scale, custom CSS or JavaScript, click and wait actions, blocked resource types, headers, cookies, a user agent, timezone, geolocation, caching with a chosen TTL, signed links, asynchronous jobs with signed webhooks, bulk capture of up to 100 URLs, PDF output, and usage reporting. An MCP server exposes take_screenshot, get_page_info, and capture_pdf to Claude, Cursor, and other MCP clients. There are 1,000 free shots each month with no card; paid plans start at $5 for 3,000. Create a free ScreenshotNeo account.

FAQ

Can I publish CAA only for www?

Yes. A record at www.example.com controls that name and descendants, while other names continue to use the first RRset found in their own ancestry. Document the difference so SAN requests do not accidentally mix policies.

Does adding a second issue record make issuance more secure?

It broadens authorization. Add a second issuer only when you need it for a documented migration, backup, or separate certificate workflow.

Will changing CAA invalidate my current certificate?

No. CAA governs issuance authorization at the time a CA checks it. Existing certificates require separate replacement or revocation actions.

Why did a CA still reject issuance when its name is present?

CAA is only one prerequisite. Check the exact SAN and wildcard names, DNS visibility, domain-control validation, account limits, and the CA’s diagnostic.

How often should I query CAA?

Query on every policy change and before major renewals. Continuous monitoring is useful for detecting accidental additions, removals, or unauthorized DNS changes.