What Is a CAA Record?

The idea

There are many certificate authorities in the world, and browsers trust all of them. That is a lot of doors. In principle any one of them could issue a certificate for your domain, and a certificate issued in error is a certificate someone can impersonate you with.

A CAA record narrows that down. It is a line in your DNS that says, in effect, "only these authorities may issue for this domain". Authorities are obliged to check it before issuing, and to refuse if they are not on the list.

It is not encryption and it does not change what visitors see. It is a constraint on who can mint an SSL certificate in your name.

What it looks like

The record has three parts: a flag, a tag, and a value. In practice you will use the issue tag, one record per authority you allow.

Name:  @
Type:  CAA
Flags: 0
Tag:   issue
Value: letsencrypt.org

Add one record per allowed authority. The value is the authority's identifier, not a URL. Some DNS panels want the whole thing on one line as 0 issue "letsencrypt.org" instead of separate fields.

The honest caveat

Most security advice is one directional. Add the thing, be safer. CAA is not like that, and we would rather say so up front.

A CAA record that is too strict will break your certificate renewals. Silently, and usually not on the day you added it. It fails months later when a renewal comes due and the authority checks your record, finds itself missing, and declines. Your certificate expires, and every visitor gets a browser warning.

This is a genuinely optional control with a real downside. It is worth adding when you know exactly who issues your certificates and that will not change. It is worth skipping when you do not.

Why guessing is the dangerous part

If you run your own server and requested your own certificate, you know your authority. But most sites today sit on a managed platform or behind a CDN that provisions certificates automatically, and those platforms do not always use one authority. They rotate.

Two confirmed examples make the point:

→Shopify uses letsencrypt.org, pki.goog and ssl.com. Publish a CAA record allowing only Let's Encrypt and you have quietly forbidden two of the three authorities your store actually relies on.
→Webflow uses Let's Encrypt and Google Trust Services. Same trap, different names.
→The lesson: the authority your certificate came from last year is not a promise about next year. If your platform provisions certificates for you, it is entitled to change how, and it does not owe you notice.

If you do add one

A few practical points that keep it from turning into an outage.

→Find out, do not assume. Read your platform's current documentation. If it does not name its authorities, treat that as a reason not to publish a CAA record.
→List every authority in play. Including any CDN, load balancer or email service that provisions its own certificates on your domain.
→Remember subdomains. CAA is inherited down the tree, so a record at your root applies to everything under it unless a closer record overrides it. That is convenient and it is also how you accidentally block a subdomain served by a different platform.
→Write it down. The failure mode is a renewal months from now, long after anyone remembers the record exists. A note in your runbook is worth more than the record itself.

The short version

CAA is a good control for people who control their own certificates and know it will stay that way. For everyone else it is a small hardening win with an outage attached, and no CAA record at all is a perfectly respectable answer.

Certificates are the part actually worth checking regularly. Our free check looks at what your domain is serving today, including how long your certificate has left.