Most WordPress site owners focus on HTTPS, strong passwords, and keeping plugins up to date. Those are all sensible priorities. But there is one DNS-level security measure that is almost universally overlooked: CAA records. They take about five minutes to set up, cost nothing, and add a meaningful layer of protection against a specific class of certificate-related attacks.
What Is a CAA Record?
A CAA (Certificate Authority Authorization) record is a type of DNS record that tells the world which Certificate Authorities (CAs) are permitted to issue SSL/TLS certificates for your domain.
Think of it as a whitelist. Without CAA records, any of the hundreds of publicly trusted CAs in existence can technically issue a certificate for your domain — whether you asked them to or not. CAA records close that door by declaring: only these specific CAs are authorized to issue certificates for this domain.
CAA is defined in RFC 8659 and has been mandatory for all CAs to check since September 2017, following a CA/Browser Forum requirement. That means every CA that follows industry standards must verify your CAA records before issuing a certificate — and must refuse to issue one if the records say they are not authorized.
Why Does This Matter?
SSL certificates are the foundation of trust on the web. When visitors see the padlock in their browser, they are trusting that the certificate was issued legitimately to the rightful domain owner. But the certificate issuance process has historically had weaknesses.
Over the years, there have been documented cases of CAs issuing fraudulent or mistaken certificates for domains they had no business touching. These incidents have enabled man-in-the-middle (MitM) attacks, where an attacker intercepts traffic between your visitors and your site — even over HTTPS — because they possess a certificate that browsers consider valid.
CAA records reduce this risk significantly. Even if an attacker somehow tricks a CA into attempting to issue a certificate for your domain, a CA that checks CAA records and finds it is not authorized will decline. The attacker walks away empty-handed.
The Structure of a CAA Record
A CAA record has three parts: a flag, a tag, and a value.
yourdomain.com. IN CAA 0 issue "letsencrypt.org"The flag is almost always 0. A value of 128 would make the tag “critical” (meaning a CA that does not understand the tag must refuse to issue), but 0 is the correct value for standard deployments.
The tag determines what the record controls. There are three main tags:
issue— authorizes the named CA to issue standard (DV, OV) certificates for the domain.issuewild— authorizes the named CA to issue wildcard certificates (e.g.,*.yourdomain.com). If omitted, theissuerecord also covers wildcards.iodef— provides a URL or email address where CAs should report policy violations or unauthorized issuance attempts. This is useful for monitoring.
The value is the CA’s domain name, or a contact address in the case of iodef.
Practical Examples
If your site uses Let’s Encrypt (which is free and the most common choice for WordPress sites), your CAA records should look like this:
yourdomain.com. IN CAA 0 issue "letsencrypt.org"
yourdomain.com. IN CAA 0 issuewild "letsencrypt.org"
yourdomain.com. IN CAA 0 iodef "mailto:security@yourdomain.com"If you use a paid certificate from a provider like Sectigo, DigiCert, or ZeroSSL, use their respective CA domain instead:
yourdomain.com. IN CAA 0 issue "sectigo.com"
yourdomain.com. IN CAA 0 issue "digicert.com"
yourdomain.com. IN CAA 0 issue "zerossl.com"You can authorize multiple CAs by adding multiple issue records. This is useful if you use different certificates for different subdomains, or if your hosting provider manages certificates on your behalf through a different CA than the one you use for the root domain.
If you are unsure which CA issued your current certificate, you can check it in your browser by clicking the padlock and viewing the certificate details, or use a tool like crt.sh to search certificate transparency logs for your domain.
How to Add CAA Records
CAA records are added through your DNS provider — the service where your domain’s nameservers are managed. This is typically your domain registrar (such as Namecheap, GoDaddy, or Cloudflare), though some hosting providers also manage DNS for you.
The exact steps vary by provider, but the general process is:
- Log in to your DNS provider’s control panel.
- Navigate to the DNS management section for your domain.
- Add a new record with type CAA.
- Set the host/name field to
@(representing the root domain) or leave it blank, depending on your provider’s interface. - Fill in the flag (
0), tag (issue,issuewild, oriodef), and value (your CA’s domain). - Save and repeat for each record you want to add.
If your DNS provider does not offer a dedicated CAA record type in their interface, you can often add it as a generic record. Some older control panels may not support CAA records at all — in that case, switching to a more modern DNS provider like Cloudflare (which is free) is worth considering.
A useful tool for generating the correct record syntax is SSLMate’s CAA Record Generator, which walks you through the options and produces ready-to-copy record values.
What Happens If You Get It Wrong?
The main practical risk when adding CAA records is accidentally blocking your own certificate renewals. If you add a CAA record authorizing only Let’s Encrypt, but your hosting provider’s automated renewal system uses a different CA, the renewal will fail and your certificate will expire.
To avoid this, make sure you know which CA is responsible for issuing and renewing your certificate before you publish CAA records. If your hosting provider manages certificates for you automatically (which is common with managed WordPress hosts), check their documentation or contact their support to find out which CA they use.
Also keep in mind that CAA records are not inherited by subdomains in the way you might expect. If you have a CAA record on yourdomain.com and you want it to also apply to sub.yourdomain.com, you should either add the same records to the subdomain or confirm that your DNS provider propagates them correctly. Most do, but it is worth verifying.
The iodef Tag: Turning CAA Into a Monitoring Tool
The iodef tag is often ignored, but it adds a useful monitoring dimension. When a CA receives a certificate request for your domain and finds it is not authorized by your CAA records, some CAs will send a notification to the address specified in your iodef record.
This means you could receive an alert any time someone — an attacker or even a misconfigured automated system — tries to obtain a certificate for your domain from an unauthorized CA. It is not a guarantee of notification (not all CAs implement iodef reporting), but it is a useful signal to have.
yourdomain.com. IN CAA 0 iodef "mailto:security@yourdomain.com"Verifying Your CAA Records
Once you have added your records, you can verify they are live using a DNS lookup tool. From a terminal:
dig CAA yourdomain.comOr use an online tool like Google’s DNS Toolbox or MXToolbox. You should see your CAA records listed in the answer section within a few minutes to a few hours, depending on DNS propagation time.
Summary
CAA records are a small DNS addition with a clear security benefit. They do not replace HTTPS, strong passwords, or keeping your WordPress installation updated — but they do close a specific gap that those measures do not address: the risk of a certificate being issued for your domain without your knowledge or consent.
Setting them up takes a few minutes, and once they are in place you do not need to think about them again (unless you switch certificate providers). If you are already running HTTPS and you care about the integrity of your site’s encryption, adding CAA records is a sensible next step.
Trusti Radar checks for the presence of CAA records as part of its DNS security scan. If your domain is missing them, it will flag this as a low-severity finding and link you back here for context.