Front Sentinel

Front Sentinel / guides

How to set up a CAA record for your dApp domain

A CAA record lists the certificate authorities that may issue TLS certificates for your domain. Public CAs must check it before they issue. If your record names only the CA you actually use, an attacker who briefly takes over your web server's IP or a subdomain has to get past that one CA instead of picking whichever is easiest.

Checked 23 October 2026 against RFC 8659, RFC 8657 and CA documentation.

26 / 100top DeFi domains publish CAA
15 / 26of those allow five or more CAs
13 / 26set an iodef contact
25 / 26allow Let's Encrypt

From our October 2026 survey of the 100 largest DeFi protocols by TVL.

What CAA protects against, and what it doesn't

To get a certificate, someone has to prove control of the domain to a CA, usually by serving a file over HTTP or answering a DNS challenge. If an attacker can do that once, for example through a BGP hijack of your server's prefix or a dangling subdomain, they can get a valid certificate and serve a fake frontend over HTTPS. Since 2017 the CA/Browser Forum has required every public CA to check CAA first and refuse if it isn't listed (RFC 8659).

CAA lives in your DNS, so it does nothing once the attacker controls your nameservers or registrar account: they rewrite the record and get their certificate. That case needs registry lock (see the registry lock guide), DNSSEC, and certificate transparency monitoring that tells you about a new certificate on the day it is logged.

Find out which CAs you use

Before you restrict anything, list every certificate issued for your domain in the last year or so. Search crt.sh for %.yourdomain.com and note the issuers. Typical sources:

Write the record

A domain served from your own server with certbot needs two lines:

yourdomain.com.  CAA  0 issue "letsencrypt.org"
yourdomain.com.  CAA  0 iodef "mailto:security@yourdomain.com"

This is the record frontsentinel.com uses, plus issuewild because we don't use wildcard certificates either way:

frontsentinel.com.  CAA  0 issue "letsencrypt.org"
frontsentinel.com.  CAA  0 issuewild "letsencrypt.org"

A CA checks the name it is issuing for, then walks up to the parent until it finds a CAA record, and it follows CNAMEs (Let's Encrypt's notes). A subdomain that points by CNAME to a hosting platform is therefore governed by the platform's CAA, if it has one, and not by yours.

Tighter: accounturi and validationmethods

RFC 8657 lets you pin issuance to your own ACME account and to specific challenge types. Let's Encrypt supports both:

yourdomain.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"

With this, a hijacked HTTP path doesn't help the attacker: Let's Encrypt only issues to your account key, using a DNS challenge. Your account ID is in your ACME client's config (for certbot, under /etc/letsencrypt/accounts/). Keep that key backed up, because losing it means editing CAA before you can renew.

If you use Cloudflare

When Universal SSL is on and you add any CAA record, Cloudflare silently adds issue and issuewild records for the CAs it uses, and these don't appear in the dashboard. Run dig yourdomain.com caa +short to see the real record. This is one reason so many DeFi domains in our survey allow five to ten CAs: the record exists, but it narrows things much less than it seems to.

If you keep the Cloudflare proxy, the CA list is Cloudflare's to manage, and certificate transparency monitoring matters more.

Check it

Know when a certificate is issued for your domain

Front Sentinel reads certificate transparency logs, your CAA record, nameservers and registry statuses on a schedule and alerts your team in Telegram, email or webhooks when any of them change. One domain is free.

Scan your domain   Monitor a domain