iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
CAA and TXT records solve different security problems. A CAA (Certification Authority Authorization) record tells certificate authorities which issuers may create certificates for your domain. A TXT record is general-purpose text; in an SSL/TLS issuance workflow, it commonly stores a one-time or service-generated domain-control-validation (DCV) token that proves the requester controls your DNS. Using both gives you issuer authorization and proof of control, but a TXT token by itself does not restrict which certificate authority may issue a certificate.
This guide shows the difference with working record examples, explains how certificate authorities process CAA, and gives a deployment and troubleshooting procedure for direct certificate issuance, CDNs, and managed certificate services.
What is a CAA record?
A CAA record is a DNS policy that names the certificate authorities (CAs) authorized to issue certificates for a domain. RFC 8659 defines it as a way for a domain holder to specify one or more authorized CAs and reduce unintended certificate mis-issuance. The policy is read by a CA before it issues a certificate, not by a browser after the certificate has been issued.
CAA is an authorization control. If your policy lists only one CA, another CA that checks CAA should decline issuance unless the policy permits it. This reduces the number of organizations that can legitimately issue for your name, which in turn narrows the impact of a compromised account, mistaken order, or process error at an unapproved CA.
#1 Best Overall
A basic CAA example
example.com. CAA 0 issue "letsencrypt.org"Here, the flag is 0, the property tag is issue, and the value identifies the permitted issuer. The value must match the CA or managed certificate service you actually use. Cloudflare’s published examples include values such as letsencrypt.org, pki.goog, ssl.com, and sectigo.com; the available and required values can change, so confirm the exact value with your issuing service before publishing it.
Is CAA the same as a TXT record?
No. CAA is a typed authorization record interpreted by certificate authorities, while TXT is an unstructured text record that a service can use for many purposes. In certificate issuance, TXT most often carries a DCV token. The token proves control of the DNS zone; it does not say which CA is allowed to issue.
| Question | CAA | TXT used for DCV |
|---|---|---|
| Primary purpose | Authorize named certificate authorities | Prove control of a domain or hostname with a service-generated token |
| Who reads it | The certificate authority evaluating an issuance request | The CA or certificate platform performing domain-control validation |
| When it matters | Before issuance, during the CA’s policy check | During the validation step before issuance or renewal |
| Typical form | CAA 0 issue "issuer.example" |
_validation.example.com TXT "token supplied by the service" |
| Failure when wrong or missing | An unlisted CA can be blocked from issuing | Validation fails because the token is absent, altered, or at the wrong name |
| Does it replace the other record? | No; it does not prove control by itself | No; it does not restrict the set of authorized CAs |
A domain can publish both record types at the same time. That is the normal arrangement when a certificate service asks you to add a TXT token while you also maintain a restrictive CAA policy.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteHow does a certificate authority process CAA?
A compliant CA checks the relevant CAA record set before issuing. If it does not find a CAA record at the exact name, it walks up the DNS name tree toward the parent until it finds one, as specified by RFC 8659. This means a policy at example.com can affect a certificate request for a host below it when no more-specific CAA policy overrides the search.
- The CA identifies the DNS name covered by the requested certificate.
- It queries for CAA records at that name.
- If no applicable record is found, it checks the parent name and continues upward.
- When it finds a CAA set, it evaluates whether the requested issuer and certificate type are allowed.
- If the policy does not authorize the request, issuance should stop; if the policy allows it, the CA still has to complete all of its other validation and issuance checks.
CAA conformance is necessary but not sufficient for issuance. Passing the CAA check does not waive identity checks, authorization checks, key-usage rules, or the CA’s other requirements. Conversely, CAA is not used by relying parties as a post-issuance certificate-validation mechanism; browsers do not consult it to decide whether an already-issued certificate is valid.
Rank #2
Which CAA records should I publish for a certificate?
Publish one or more issue records for every CA that may issue your ordinary certificates, including an issuer used indirectly by a CDN or managed certificate product. Handle wildcard certificates separately with issuewild when your provider supports that distinction.
Permit one CA for ordinary certificates
example.com. CAA 0 issue "letsencrypt.org"This allows the named issuer for non-wildcard issuance. Do not copy this value unless that is the CA actually used by your service.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Permit a separate issuer for wildcard certificates
example.com. CAA 0 issuewild "letsencrypt.org"issuewild expresses the policy for wildcard certificates. If you need both ordinary and wildcard certificates, document both requirements and verify the CA’s interpretation before relying on them. A wildcard order can fail even when a non-wildcard order succeeds if the wildcard policy does not authorize the issuer.
Permit more than one issuer
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "sectigo.com"Multiple records represent an allowlist. Keep the list as short as operationally practical: every authorized CA is another valid path to a certificate for the name.
Why is a TXT validation record not enough?
A TXT token answers “can this requester demonstrate control of DNS?” It does not answer “which CA should be trusted to issue?” If several CAs are willing to issue after successful DCV, any of them may be able to obtain a certificate unless your CAA policy limits the set.
Rank #3
For example, a platform may ask you to publish:
_acme-challenge.example.com. TXT "service-generated-token"The platform reads the token from authoritative DNS and uses it as evidence that you control the name. Leave the token exactly as supplied, at the exact hostname requested. Adding a CAA record does not replace this step, and adding the TXT record does not replace CAA authorization.
How do I add CAA and TXT records safely?
Use this sequence whenever you are issuing or renewing a certificate through a CA, CDN, or managed certificate product.
- Inventory every issuer. List certificates issued directly by your team and those issued on your behalf by a CDN, load balancer, hosting control panel, or managed certificate product. Record the CA name or the provider’s required CAA value for each one.
- Separate ordinary and wildcard needs. Note which hostnames need individual certificates and which, if any, need a wildcard. Confirm whether the service requires an
issuewildauthorization. - Inspect the DNS hierarchy. Check the exact hostname, its parent names, and any CNAME targets for existing CAA records. A policy inherited from a parent or CNAME target can change the result of an apparently local configuration.
- Publish the CAA allowlist. Add a CAA record for each permitted issuer. Remove obsolete issuers only after confirming that no active certificate or renewal process still depends on them.
- Add the DCV TXT token. Create the TXT record at the hostname supplied by the CA or platform. Preserve capitalization, punctuation, and any leading underscore in the name and preserve the token value exactly.
- Verify from authoritative DNS. Query the authoritative nameservers, not only a local resolver or control-panel preview, and confirm that the CAA and TXT answers are visible with the expected values.
- Complete issuance and test renewal. After the initial certificate is issued, run the service’s renewal test or wait for a controlled renewal window. A policy that works for issuance can still fail later if an issuer changes or a TXT token is removed too soon.
- Document ownership. Record who owns the CAA policy, who can change validation records, which products use each CA, and how emergency changes are approved.
How do CNAME targets affect CAA?
A CNAME can make the effective policy less obvious. Cloudflare warns that CAA records on a CNAME target can apply, so you should inspect the complete CNAME chain rather than checking only the visible hostname. A certificate request for www.example.com, for instance, may depend on a CNAME destination controlled by a CDN or another DNS zone.
- Start with the requested hostname and identify every CNAME hop.
- Check the target name for CAA records and check parent names where the RFC 8659 search would continue.
- Ask the CDN or managed certificate provider which CA it uses and whether it publishes or expects a CAA policy on the target.
- Resolve conflicts before an outage: an inherited policy that omits the provider’s CA can block issuance or renewal.
What happens when CAA or TXT is wrong?
| Symptom | Likely cause | Correction |
|---|---|---|
| “CAA record does not authorize this CA” or an equivalent policy error | The issuer is missing from the applicable issue or issuewild set, or a parent/target policy is being inherited |
Identify the CA actually making the request and add its exact value, or change the service to an already-authorized CA |
| “DNS problem” or DCV timeout | The TXT record is at the wrong hostname, has a typo, or is not visible from authoritative DNS | Copy the service-generated name and value exactly, remove conflicting duplicate entries where the service forbids them, and query the authoritative nameservers |
| Non-wildcard issuance works but wildcard issuance fails | Wildcard authorization was not configured separately | Review the provider’s wildcard requirements and publish the needed issuewild policy |
| A renewal fails after a DNS migration | The new authoritative provider lacks the CAA policy or the service’s TXT automation | Recreate both record types at the new authoritative DNS provider and test renewal before the current certificate expires |
| One hostname behaves differently from another | A more-specific CAA record, a parent policy, or a CNAME target changes the effective record set | Trace each hostname’s DNS path and compare the complete CAA answers |
Do not “fix” a CAA error by deleting every CAA record unless you have assessed the security consequence. Removing the allowlist may make issuance work, but it also removes the issuer restriction that protects the domain from unauthorized issuance by other CAs.
Do CAA records protect certificates after they are issued?
No. CAA is a pre-issuance authorization signal. RFC 8659 states that conformance is necessary but not sufficient for issuance, and relying parties must not use CAA during certificate validation. If a certificate has already been issued, investigate it through certificate-transparency monitoring, CA notification channels, revocation procedures, and your normal incident-response process.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →CAA also cannot prevent mis-issuance by a CA that you authorized. It reduces the set of possible issuers; it does not guarantee that every authorized issuance is appropriate or that an authorized CA can never make an error.
Should I use DNSSEC with CAA?
RFC 8659 strongly recommends DNSSEC for authenticating CAA responses. DNSSEC helps an issuer distinguish an authenticated DNS answer from an altered or incomplete response. You should still publish and maintain CAA when your zone is unsigned, because issuers must apply CAA processing in that situation as well; the absence of DNSSEC does not make the policy optional.
How should teams operate CAA and TXT over time?
Treat CAA as a controlled security policy and TXT validation data as operational material. The two records often have different owners and lifecycles.
- Change control: require review before adding a new CA or removing an existing one.
- Inventory: map each certificate, hostname, CDN, and managed service to its issuing CA and renewal method.
- Short-lived validation data: remove obsolete DCV tokens when the service no longer needs them, while retaining any record required for automated renewal.
- Monitoring: watch certificate-transparency logs or CA notifications where available for unexpected certificates or newly observed issuers.
- Renewal testing: test after DNS migrations, provider changes, CNAME changes, or CAA edits rather than waiting for an expiration incident.
- Runbooks: document the authoritative DNS provider, escalation contact, exact record syntax, and rollback procedure.
When should I use CAA, TXT, or both?
| Situation | Recommended records | Reason |
|---|---|---|
| You want to restrict certificate issuers | CAA | Only CAA expresses an issuer allowlist |
| A CA or platform asks you to prove DNS control | TXT token at the requested name | The token is the platform’s DCV evidence |
| You want issuer restriction and automated issuance | CAA plus the service’s TXT or other DCV record | CAA limits who may issue; DCV proves control to the chosen service |
| You use a CDN or managed certificate service | CAA for the service’s actual CA, plus its required validation records | The service may issue indirectly and can be affected by CNAME-target policy |
| You need a wildcard certificate | Review issuewild as well as the service’s wildcard validation method |
Wildcard authorization can be evaluated separately from ordinary issuance |
What is the practical security trade-off?
The benefit of CAA is reduction of issuance paths, not an absolute guarantee. A restrictive policy can block an attacker or mistake involving an unlisted CA, but it can also block your own renewal if you overlook an issuer used by a third-party service. The safest operational pattern is a complete issuer inventory, a minimal allowlist, exact TXT handling, CNAME-chain inspection, and a renewal test after every material DNS change.
Free tools Windows power users keep installed
One-click scans. No signup required.
TXT validation remains important because a CA needs evidence that the requester controls the domain. It is not a substitute for CAA, and CAA is not a substitute for TXT validation. Together they provide complementary controls: authorization of the issuer and authorization of the requester’s DNS control.
Frequently Asked Questions
Can I publish more than one CAA record for the same domain?
Yes. Multiple CAA records form a policy set, commonly used to allow more than one operational CA. Keep the set limited to issuers that are genuinely required, and remove an entry only after checking every active certificate and renewal workflow.
Do CAA records need to be added at every subdomain?
Not necessarily. A CA can walk up the DNS name tree and use a policy at a parent name when no more-specific CAA set exists. Add a more-specific record only when a subdomain needs a different issuer policy, and verify the resulting hierarchy before issuance.
Why did a certificate renew successfully once and then fail later?
Renewal may be performed by a different CA, a newly introduced managed service, or a changed CNAME target. Compare the issuer making the renewal request and the current DNS chain with the CAA allowlist instead of assuming the original issuance path is unchanged.
Can I use a CAA record to revoke a certificate?
No. Changing or deleting CAA affects future issuance decisions; it does not revoke a certificate already issued. Use the issuing CA’s revocation process and your incident-response procedures for an existing certificate.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
