Low

CAA records: choosing who may issue certificates for your domain

A small, optional DNS record that stops anyone but your chosen provider from creating a security certificate in your name.

7 minute read · Email and domain

The short version

A security certificate proves a website is really yours. There are dozens of companies that can issue one, and by default *any of them* can issue a certificate for your domain to anyone who can pass their checks. A CAA record is one line in your DNS that says "only this provider may issue certificates for my domain". It is optional, takes a minute, and removes a whole category of impersonation risk. This guide also covers DNSSEC, which protects the DNS itself — including the CAA record — from being tampered with.

Why you would want to restrict certificate issuers

Every certificate authority (CA) checks that the person asking for a certificate controls the domain, usually by asking them to place a file on the website or a record in DNS. Those checks are generally good — but there are many CAs, their checks differ, and a weakness or a mistake at *any one of them* can lead to a certificate for your domain being issued to someone else. It has happened to major companies. With a fraudulently issued certificate, an attacker can set up a convincing copy of your site that shows a genuine padlock.

CAA (Certification Authority Authorization) lets you shrink that exposure from "every CA in the world" to "the one I actually use". Before issuing, every CA is required to check for a CAA record and refuse if it is not listed. It also stops someone inside your own organisation — or a developer with DNS access — from quietly getting a certificate from a provider you do not know about.

What the record looks like

A CAA record names a CA by its domain. If your certificates come from Let's Encrypt (as most free hosting certificates do), the record is:

yourbusiness.co.uk.  CAA  0 issue "letsencrypt.org"

You can list more than one issuer by adding more records. Common ones: letsencrypt.org, sectigo.com (used by many cPanel AutoSSL hosts), digicert.com, pki.goog (Google Trust Services, used by Cloudflare), amazon.com, globalsign.com. If you use Cloudflare's proxy, Cloudflare manages its own CAA records for its edge certificates and will add them for you.

Two other useful forms: issuewild controls who may issue *wildcard* certificates (*.yourbusiness.co.uk), and iodef gives an address a CA should notify if someone requests a certificate that CAA forbids:

0 issuewild ";"
0 iodef "mailto:security@yourbusiness.co.uk"

The ";" value for issuewild means "nobody may issue wildcards", which is right if you do not use them.

The one thing to get right

If you add a CAA record that does not include the CA your host or certificate provider actually uses, your next renewal will fail — silently, until the certificate expires. So before adding one, find out who issues your current certificate: click the padlock in your browser, open the certificate details, and look at "Issued by". Then check whether your host uses more than one CA for fallback (cPanel AutoSSL, for example, may use Sectigo or Let's Encrypt depending on the host's configuration) and list all of them.

No CAA record is a perfectly normal, safe default — it is why we rate the missing record as low severity. The real risk with CAA is adding one that is wrong. Check your issuer first.

DNSSEC: protecting the DNS itself

Everything above — SPF, DMARC, CAA, and the address of your website — lives in DNS. DNS was designed without any way to verify answers, so an attacker who can tamper with DNS responses (on a hostile network, or by poisoning a resolver's cache) can send your visitors to a different server entirely, or remove your CAA record from view while they request a certificate. DNSSEC adds digital signatures to your DNS records so resolvers can verify they are genuine and unaltered.

It works as a chain of trust: your DNS provider signs your zone, and a small fingerprint of the signing key — a DS record — is placed at the registry for your domain extension (Nominet for .uk). Resolvers check the signature against the DS record, and the DS record against the registry's own signature, all the way to the root of the DNS.

Turning it on is usually a toggle at your DNS provider or registrar (Cloudflare, Spaceship and most registrars offer it). Two things to know:

The DS record and the zone must match. If DNSSEC is switched off at your DNS provider but a DS record is left at the registry — which can happen when moving nameservers or after a half-completed change — validating resolvers (Google, Cloudflare, most ISPs) will refuse to resolve your domain *at all*. Your site goes dark for a large share of visitors and certificate issuance fails, while it still appears to work from resolvers that do not validate. If you move nameservers, disable DNSSEC first and re-enable it afterwards.
It is not encryption. DNSSEC proves records are authentic; it does not hide them. That is what it is meant to do.

What VigilScan checks

We look up CAA records on your domain and report whether any exist and which issuers they allow. We also check whether your domain is DNSSEC-signed by asking validating resolvers whether the answer was authenticated, and we specifically test for the broken state — a DS record at the registry with no matching signed zone — because that one causes outages that are hard to diagnose from the inside.

Common questions

Is a missing CAA record something I need to fix urgently?

No. It is a worthwhile hardening step, not a vulnerability. Add it when you have confirmed which certificate authority you use, so the record does not break your renewals.

Should I turn on DNSSEC?

For most business sites, yes, provided your DNS provider manages it for you (they handle the key rotation and DS record automatically). Do it at a quiet time, check the site still resolves from Google's resolver (dns.google) afterwards, and remember to disable it before any nameserver change.

My site went down for some people but not others after a DNS change. Could this be DNSSEC?

Very likely. "Works for some, fails for others" after a nameserver or provider change is the classic sign of a stale DS record. Check whether DNSSEC is enabled at your registrar and whether your current DNS provider is actually signing the zone; the two must agree.

Not sure if this affects your site?

Run a free check — it takes about 90 seconds and tells you exactly where you stand.

Check my website