A CAA record says which certificate authorities are allowed to issue certificates for your domain. Every authority is required to check it before issuing, and to refuse if the record exists and does not name them.
It is one DNS record, it takes two minutes, and it closes a category of attack that nothing else in your control addresses.
What it prevents
Without a CAA record, any certificate authority in the world may issue a certificate for your domain to anyone who can satisfy their validation.
That is normally fine, because validation is meant to be hard to fake. It has been faked, through DNS manipulation, through weaknesses in an authority's own process, through a mistake by a member of their staff.
A certificate issued that way is trusted by every browser, and it lets the holder impersonate your site convincingly.
CAA reduces the exposure from "every authority in the world" to "the ones I named". It does not make issuance impossible; it makes it require a failure by a specific authority you chose.
What it does not do
Worth being clear, because CAA is sometimes described as more than it is.
It does not protect certificates already issued. It does not stop a certificate issued before you added the record. And it does not help if your DNS itself is compromised, since an attacker with control of your zone can simply change the record.
It is one layer, and it is a cheap one.
Adding the record
In cPanel's Zone Editor, add a record of type CAA. Three fields:
Flag, 0 in almost every case. A flag of 128 means an authority must refuse if it does not understand the record, and is rarely what you want.
Tag: issue for normal certificates, issuewild for wildcards, iodef for a reporting address.
Value; the authority's domain.
Add one record per authority you permit. Using the Zone Editor deals with the interface.
Name every authority you actually use
This is where CAA goes wrong, and the failure is delayed.
If your server issues free certificates automatically, that authority must be listed. If a CDN or a load balancer in front of your site issues its own certificate, that authority must be listed too. If you bought a certificate from someone, they must be listed.
Miss one and nothing happens immediately, existing certificates keep working. Then a renewal is refused, weeks or months later, and the connection to a DNS record you added and forgot is not obvious.
Write down which authorities you listed and why.
Wildcards need their own tag
An issue record does not authorise wildcard certificates. If you use one, add an issuewild record naming the authority as well.
The reverse is also useful: if you never want a wildcard for your domain, an issuewild record with a value of ";" forbids all wildcard issuance while leaving normal certificates permitted.
That is a genuinely good default for a domain that has no wildcard, because a wildcard certificate is the most useful kind for an attacker to obtain.
The reporting address
An iodef record gives an address for an authority to contact if it is asked to issue a certificate the policy forbids:
0 iodef "mailto:[email protected]"
Not every authority sends these, and the ones that do are telling you something worth knowing: somebody attempted to obtain a certificate for your domain.
Use an address that is read and that does not depend on the domain in question still working.
How inheritance works
A CAA record applies to the domain and to every subdomain that does not have its own.
So one record at the domain covers everything, which is usually what you want. To allow a different authority for a specific subdomain, add a record on that subdomain. It replaces the parent's for that name instead of adding to it.
That replacement is worth remembering: a subdomain record naming one authority means the parent's list no longer applies there at all.
Check it before you rely on it
Query the record and confirm what is published:
dig CAA example.com +short
Then confirm your renewals still work. The honest test is to force a renewal instead of waiting for the automatic one, because a policy that blocks your own authority does not announce itself. For doing it deliberately, see renewing your certificate.
Give DNS time to propagate before testing. A record queried immediately after adding it may not be visible yet. For that, see understanding DNS propagation.
A sensible starting configuration
For a typical site using free certificates from the server:
0 issue "letsencrypt.org" 0 issuewild ";" 0 iodef "mailto:[email protected]"
That permits normal certificates from one authority, forbids wildcards entirely, and asks to be told about attempts. Add authorities as you genuinely start using them, and not before.
Add it before it can break a renewal
The record restricts who may issue, and it is checked at issuance rather than at use, which produces a specific failure mode.
dig example.com CAA +short dig www.example.com CAA +short dig example.com CAA @1.1.1.1 +short
A record naming an authority you no longer use, or omitting the one your host actually uses, stops the next renewal rather than the current certificate. The site keeps working until the certificate expires, at which point it stops with no warning that connects the two events.
So add the record and then force a renewal deliberately to confirm it still works. Waiting for the automatic run to discover the problem means discovering it at expiry.
Find out which authority your host actually uses
The record has to name the issuer, and people name the one they think is being used rather than the one that is.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | openssl x509 -noout -issuer
Read the issuer from the certificate currently installed. That is the authority to permit, and the identifier used in the record is a specific string rather than a company name.
Where a host uses more than one, or switches between them, the record needs to permit all of them. A panel that falls back to a second issuer when the first fails will be refused by a record naming only the first, and the fallback exists precisely for the moments when things are already going wrong.
Watch what the reports tell you
The reporting field is the part most people leave out, and it is the only way the record tells you anything.
example.com. IN CAA 0 iodef "mailto:[email protected]"
Compliant authorities send a report when they refuse a request because of your record. On a domain nobody is attacking, that report means somebody in your own organisation tried to obtain a certificate through a route you did not expect.
Both readings are useful. Send them to an address on a different domain, monitored by more than one person, and treat the first one as a question rather than an alarm. Monitoring DNS and detecting unauthorised changes deals with the record itself being altered.