CAA
A CAA record names which certificate authorities are allowed to issue a certificate for a domain at all. Without one, any publicly trusted certificate authority is free to issue a certificate for it, whether that domain's owner ever asked them to or not, which is exactly the gap CAA closes.
| Name | Type | Value |
|---|---|---|
| (apex) | CAA | 0 issue "letsencrypt.org" |
| (apex) | CAA | 0 issuewild ";" |
| (apex) | CAA | 0 iodef "mailto:security@example.com" |
Shown here as three separate records to demonstrate all three tags at once, not because every domain needs all three. issue is the one that actually matters most of the time; issuewild and iodef are optional additions, worth having but not required for CAA to do its basic job.
Three tags, three different jobs
issue authorises a named certificate authority to issue an ordinary certificate for this exact name. issuewild does the same specifically for wildcard certificates, and can be set to ";", an explicitly empty value that means no wildcard certificate is authorised from anyone, at all. iodef names an address a certificate authority should notify if it receives a request that violates the policy, a paper trail rather than something that blocks anything itself.
That leading 0 isn't really "priority"
The number at the start of the value is officially called Flags, not priority, and in practice it's almost always left at 0, the only bit currently defined (marking a tag as "critical", meaning a certificate authority that doesn't understand the tag must refuse to issue rather than ignore it) is rarely used. Some panels nonetheless ask for this number in a field labelled "Priority", reusing the same generic numeric field their form already has for MX and SRV records rather than building CAA its own. If a panel does that, the 0 still goes there, the field's real meaning for this record type just isn't what its label says.
A domain can carry more than one CAA record, one per authorised authority, and different names within the same domain can have different policies. Where a name has no CAA record of its own, the search continues upward to its parent, all the way to the apex, so a single apex record commonly covers an entire domain unless a specific subdomain needs its own.
Refusing wildcards at the certificate layer
The issuewild ";" value is the certificate-issuance equivalent of never creating a wildcard DNS record in the first place, covered on the Interface page: both exist to stop an unrecognised name from quietly working when it shouldn't. Setting it closes off a wildcard certificate even in the unlikely event a wildcard DNS record did exist, belt and braces rather than relying on one protection alone.
Not a substitute for anything else
CAA restricts who's allowed to issue a certificate; it doesn't check whether a certificate that was already issued is actually correct, current, or the one a visitor's connection ends up trusting. It works entirely by narrowing the field of certificate authorities before a request ever gets that far, which is a different job to what TLSA/DANE does afterwards.
Building one
Expert Tools' CAA check verifies an existing record against the certificate authorities actually in use, rather than leaving that to be discovered the day a renewal unexpectedly fails.