CAA Record Generator

Build CAA records for the certificate authorities you actually use, including wildcard policy and incident reporting.

Free, no sign-up · By 1990Company · Updated September 26, 2026

Domain

Usually the apex. CAA set here also applies to every subdomain without its own CAA records.

TTL (seconds)

Certificate authorities allowed to issue

Let's Encryptletsencrypt.org Google Trust Servicespki.goog DigiCert (incl. RapidSSL, GeoTrust, Thawte)digicert.com Sectigo (incl. ZeroSSL)sectigo.com GlobalSignglobalsign.com Amazon (AWS Certificate Manager)amazon.com SSL.comssl.com

Other issuer domains (comma-separated)

Wildcard certificates

Allowed from the same authorities (no issuewild needed) Not allowed from anyone (issuewild ";")

Incident report address (optional)

An email address or https URL for the iodef tag. Many CAs never send reports, so do not rely on it for monitoring.

Advanced: pin Let's Encrypt to one ACME account

ACME account URI (RFC 8657 accounturi) Allowed validation methods (validationmethods)

Applied to the Let's Encrypt record only. A wrong account URI blocks your own renewals.

Zone file records

Dashboard fields

Most DNS dashboards (Cloudflare, Route 53, others) ask for these separately. Enter the value without quotes.

Name	Flags	Tag	Value

Verify after publishing

What a CAA record does

A CAA record lists the certificate authorities allowed to issue certificates for a domain. Every publicly trusted CA must check it before issuing (RFC 8659 and the CA/Browser Forum Baseline Requirements). If the domain publishes CAA records and none of them names the CA, the CA must refuse. If there are no CAA records at all, any CA may issue.

CAA does not affect certificates that already exist, and browsers never look at it. It only narrows who can issue the next certificate — which is exactly what you want when someone tricks a CA into validating your domain.

How CAs look up the policy

The CA starts at the exact name in the certificate and climbs toward the root until it finds CAA records. A policy on example.com therefore covers api.example.com unless that name has CAA records of its own, and a record on a subdomain replaces the parent's policy for that subtree instead of adding to it. If the name is a CNAME, the CA also considers the alias target, so a restrictive policy in a platform's zone can block issuance for your name.

issue, issuewild, and iodef

Tag	Meaning
`issue`	CAs allowed to issue any certificate for the name, including wildcards when no `issuewild` exists.
`issuewild`	Overrides `issue` for wildcard certificates only. `issuewild ";"` forbids wildcards entirely.
`iodef`	Where a CA may report a refused request. Support is optional for CAs.

Before you publish: list the CAs you already use

The common failure is locking out an issuer you forgot about: the CDN that renews your edge certificate, a hosting platform, a load balancer, or a mail service with its own certificate. Inspect the certificates currently served on your important hostnames first (the certificate inspection guide shows how) and include every issuer you find.

Cloudflare is a special case worth knowing: when Universal SSL is active and you add any CAA record, Cloudflare automatically adds issue and issuewild records for the CAs it uses — Let's Encrypt, Google Trust Services, SSL.com, and Sectigo — so its edge certificates keep renewing. That does not apply to Advanced Certificate Manager certificates. The Cloudflare preset above adds the same authorities so you can see the complete policy.

Finding a CA's identifier

The value is a domain name the CA publishes in its documentation, not the CA's company name. The list above uses each CA's documented value; several CAs accept more than one (AWS Certificate Manager accepts amazon.com, amazontrust.com, awstrust.com or amazonaws.com; Sectigo also accepts comodoca.com). Any one documented value is enough.