Defaults.Exposed › Fixes › CAA records
How to fix CAA records
A CAA record is a short instruction in your domain settings that names which certificate companies are allowed to issue the 'padlock' security certificate for your website. With it switched on, no other company can quietly create a valid certificate in your name.
Bottom line for your business: Without a CAA record, almost any of the hundreds of certificate companies worldwide can issue a genuine, fully-trusted padlock certificate for your domain — letting a scammer stand up a flawless, fully 'secure'-looking clone of your site to harvest your customers' logins and card details, with nothing on screen to warn them.
What this can cost you
- A scammer obtains a real certificate for a copy of your site, so it shows the green padlock and HTTPS — your customers see nothing wrong, type in their passwords and card numbers, and you only learn about it when the chargebacks and angry calls start.
- Your customers get phished through a pixel-perfect look-alike of your login page; the fallout — refunds, support load, reputation damage — lands on your brand even though your real site was never touched.
- A prospect's security or procurement team runs a quick check on your domain before signing, sees no CAA protection, and quietly marks you down as 'weak on the basics' — putting a deal at risk over a setting that takes five minutes to add.
- One of the world's certificate companies is compromised (this has happened repeatedly — DigiNotar, Comodo, Symantec), and because you never said who is allowed to act for you, your domain is exposed to whichever one turns out to be the weakest link.
Why it matters. Right now the door is wide open: any certificate company on Earth can vouch for a site claiming to be yours, whether you've ever dealt with them or not. A CAA record locks that door so only the provider you chose can issue certificates — it's the simplest, cheapest defence there is against someone impersonating your business online.
CAA records, in plain words
Every secure website has a certificate — the thing behind the padlock in the browser and the “https” at the front of your address. Those certificates are handed out by specialist firms called certificate authorities (CAs): names like Let’s Encrypt, DigiCert, Sectigo, Google Trust Services. When your browser sees a valid certificate, it shows the padlock and tells your customer the connection is genuine and secure.
Here’s the part most business owners have never been told: by default, hundreds of these certificate authorities around the world are each allowed to issue a certificate for your domain — whether you’ve ever heard of them or not. A CAA record (Certification Authority Authorization) is a one-line note you add to your domain’s DNS settings that says, in effect, “only these providers are allowed to issue certificates for me.” Every legitimate certificate authority is required by the rules of the industry to check that note before issuing — and to refuse if they’re not on your list.
It’s the difference between an unlocked front door anyone can walk through, and one where only the people you’ve chosen hold a key. And it costs nothing to add.
What this can cost you
The risk a CAA record closes off is convincing impersonation. When a scammer can get a real certificate for a copy of your site, the usual warning signs disappear — there’s no broken padlock, no “not secure” banner, no certificate error. Everything looks right, which is exactly what makes it dangerous.
- The flawless fake. A scammer registers a look-alike address (or compromises a route to your customers), gets a genuine certificate, and stands up a perfect clone of your login or checkout page — padlock and all. Customers enter passwords and card numbers as normal. The first you hear of it is a wave of chargebacks, fraud reports, and angry phone calls.
- The phishing campaign in your name. Attackers send “please confirm your account” emails that link to their certificated clone of your site. Because the page looks fully secure, more people fall for it. The cleanup — notifying customers, refunds, support hours, the awkward public explanation — all lands on you, even though your real servers were never touched.
- The deal that stalls on a checklist. A larger customer’s security or procurement team scans your domain before signing. “No CAA record” shows up as a red or amber item next to your name. It’s a small thing technically, but it reads as “doesn’t cover the basics,” and it can slow or sink a contract you’d otherwise have won.
- Caught out by someone else’s breach. A certificate authority you’ve never dealt with gets compromised — this is not hypothetical; DigiNotar, Comodo and Symantec have all had serious incidents. Because you never restricted who could act for you, the attacker can get a valid certificate for your domain through that weak CA. A CAA record would have refused them.
- The wildcard blind spot. Even businesses that are careful about their main site often forget subdomains. Without an
issuewildrule, an attacker who can get a wildcard certificate effectively gets a key to every subdomain you’ll ever have at once.
None of these require a sophisticated attack on your servers. They exploit the fact that, with no CAA record, the wider certificate system is simply too trusting on your behalf.
What it actually is, and what “good” looks like
A CAA record lives in your domain’s DNS — the same settings that point your domain at your website and email. Each record has three parts: a flag, a tag, and a value. The tags that matter are:
issue— names a certificate authority allowed to issue normal certificates for your domain. You can have several, one per provider you legitimately use.issuewild— controls wildcard certificates (one certificate covering every subdomain, e.g.*.example.com). If you don’t use wildcards, the recommended setting blocks them entirely.iodef— an optional contact address where you’ll be notified if a certificate authority rejects a request because of your CAA policy. This is your early-warning that someone tried.
What “good” looks like: at least one issue (or issuewild) record is present, naming the provider(s) you actually use, with wildcards either restricted to a named provider or blocked. That’s the bar this check measures — it looks up your domain’s CAA records across several independent resolvers and passes when it finds a real issue or issuewild policy in place. A domain with no CAA records at all is treated as the open door it is.
Does this affect my grade? Yes. A missing CAA record is a scored item and is flagged at medium severity — it’s a genuine gap, not just a nice-to-have, because it leaves a real impersonation route open. Adding the record closes the gap and clears the finding.
How to fix it (free, ~5 minutes)
Hand this section to whoever manages your domain or website — the fix is free. It’s a small DNS change, not a rebuild. We only charge if you later want us to keep watching that the record stays in place; adding it costs nothing.
Step 1 — Find out which certificate authority you actually use. This is the one step worth getting right, because listing the wrong provider can block your next renewal. Common cases:
- Let’s Encrypt — used by many hosts and control panels (cPanel, Plesk) →
letsencrypt.org - Cloudflare (if it issues your edge certificate) →
letsencrypt.org,digicert.com,comodoca.com,pki.goog, andssl.com(Cloudflare uses multiple back-end CAs; list the ones its dashboard shows, or its full set, so renewals never break) - Google Workspace / Google Trust Services →
pki.goog - DigiCert →
digicert.com - Sectigo / Comodo →
sectigo.com(andcomodoca.com) - Microsoft 365 / Azure — Microsoft typically uses DigiCert for managed certificates →
digicert.com(confirm in your portal)
If unsure, look at your current certificate in the browser (click the padlock → certificate details → “Issued by”) to see who issued it.
Step 2 — Log in to your DNS provider. This is wherever your domain’s records live — usually your registrar, your web host, or Cloudflare. Find the DNS records section and choose to add a new record of type CAA (some interfaces label it type 257).
Step 3 — Add an issue record for each provider you use. For Let’s Encrypt, for example:
example.com. CAA 0 issue "letsencrypt.org"
Add one issue line per legitimate provider. Most DNS dashboards give you separate boxes for the flag (0), tag (issue), and value (the CA’s domain) so you don’t type the whole line by hand.
Step 4 — Control wildcard certificates. If you don’t use wildcards, block them outright so no one can quietly get one:
example.com. CAA 0 issuewild ";"
If you do use wildcards, name the provider instead: 0 issuewild "letsencrypt.org".
Step 5 — (Recommended) Add a notification address. So you’re told whenever a CA rejects an attempt — your early warning that someone tried:
example.com. CAA 0 iodef "mailto:[email protected]"
Step 6 — Save and verify. Run dig CAA example.com (or use any online DNS lookup tool) and confirm your records appear. Changes can take anything from a few minutes to a few hours to spread across the internet. Your existing certificate and all renewals keep working throughout — CAA only governs new issuance.
Platform quick notes: On Cloudflare, DNS → Records → Add record → type CAA. On Google Workspace, you manage DNS at your registrar (or Cloud DNS if you use it) — add the CAA records there with pki.goog. On Microsoft 365, CAA isn’t set in the M365 admin centre; add it wherever your domain’s DNS is hosted, listing your managed-certificate CA (commonly DigiCert). On common hosts (GoDaddy, Namecheap, Blacknight, etc.), it’s in the same DNS panel where your A and MX records live.
Common mistakes
- Listing the wrong CA — or forgetting one. The biggest real-world risk isn’t security, it’s blocking your own renewals. If you use more than one issuer (e.g. one for the main site and another behind Cloudflare), list them all. When in doubt, list a few you trust rather than too few.
- Setting
issuebut ignoring wildcards. A domain that restricts normal certificates but says nothing about wildcards still leaves the more powerful wildcard route open. Always setissuewildtoo — either to your provider or to";"to block it. - Putting CAA on the wrong name. CAA is read by the certificate authority for the exact name being certified, walking up the tree. Setting it at the top of your domain (the “apex,” e.g.
example.com) is the right move — it covers subdomains by default unless a subdomain sets its own. - Assuming your platform already did it. Cloudflare, Google and Microsoft manage certificates but do not add CAA records for you. Unless you added them, your domain is still open.
- Treating it as one-and-done with no monitoring. A later DNS migration, a registrar change, or a “tidy-up” of records can silently drop your CAA protection. It’s worth checking it’s still there after any DNS change.
The technical layer (hand this to your IT person)
CAA is defined in RFC 8659 and enforced under the CA/Browser Forum Baseline Requirements — every publicly-trusted CA is required to check CAA at issuance time. Records take the form <flags> <tag> <value>, with tags issue, issuewild, and iodef. A non-empty issue or issuewild policy is what satisfies this check; the presence of iodef alone does not (it’s reporting, not authorization).
A solid baseline at the apex:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild ";"
example.com. CAA 0 iodef "mailto:[email protected]"
Notes for the implementer:
- CAA tree-climbing: CAs evaluate CAA from the requested FQDN upward to the apex, stopping at the first name with a CAA record set. A record at the apex therefore protects all subdomains unless a subdomain publishes its own, which it can — useful if a specific subdomain uses a different issuer.
- The
;value inissuewildmeans “no CA may issue wildcards” — an explicit deny. Use it whenever wildcards aren’t part of your setup. - The
0flag is the issuer-critical flag;0(non-critical) is correct for normal use. Avoid setting the critical bit unless you fully understand it, as a misunderstood critical tag can cause conforming CAs to refuse issuance. - Multiple issuers: several
issuerecords are allowed and additive — list every CA legitimately in your stack (including the back-end CAs your CDN/edge provider uses) to prevent renewal failures. - Verification:
dig CAA example.com +short, or check via the CA/Browser Forum CAA test tools. This check itself queries CAA over several independent resolvers (local DNS, then Google, Cloudflare and Quad9 DNS-over-HTTPS as fallback) and accepts the first authoritative answer, so a single resolver outage won’t produce a false “no CAA” result. - DNSSEC pairing: CAA tells CAs who may issue; DNSSEC stops the CAA answer itself from being forged in transit. They’re complementary — for high-value domains, run both.
Set it up on your host
Step-by-step for popular providers:
FAQ
I'm not technical — can I deal with this myself?
You don't need to understand the detail, but the fix is a small change inside your domain's DNS settings, so it's best handed to whoever manages your website or domain. Send them the 'How to fix it' section below — it's a five-minute, no-cost change. We only ever charge if you later want us to keep watching that the record stays in place; the fix itself is always free.
Will adding this break my website or my certificate?
No — as long as you list the certificate provider you actually use, everything keeps working exactly as before. A CAA record doesn't touch or replace your existing certificate; it only governs who is allowed to create new ones. The single way to cause trouble is to leave your real provider off the list, which can block your next automatic renewal — the steps below are written specifically to avoid that.
If certificates are issued automatically these days, why do I still need this?
Automatic certificates are fine and convenient — the problem is that the system is open to everyone by default, including someone pretending to be you. A CAA record simply names who's allowed, turning an open door into one with your own lock on it. It works alongside automatic issuance, not against it.
Does this affect my Google ranking or my grade on this report?
It affects your security grade here — a missing CAA record is a scored item, marked as a medium-severity gap, because it leaves a real impersonation route open. It isn't a direct Google ranking factor, but the impersonation and phishing it prevents are exactly the kind of incidents that do damage trust and traffic. Either way it's a quick, free win.
What's the difference between 'issue' and 'issuewild'?
An 'issue' record controls normal certificates for your domain and its subdomains. An 'issuewild' record controls wildcard certificates — the single certificate that covers every possible subdomain at once (like *.example.com). Wildcards are more powerful and therefore riskier in the wrong hands, so it's good practice to control them separately: if you don't use wildcards, block them outright.
We use Cloudflare / Google Workspace / Microsoft 365 — does that already cover this?
Not automatically. Those platforms manage your certificates for you, but unless you have explicitly added CAA records, your domain still tells the world 'any authority may issue.' The good news is the fix is the same simple DNS change on all of them, and where Cloudflare or your host issues your certificate, you simply list that provider. The platform notes in the fix section below cover the common cases.