Your CAA record trusts every account at a CA
Most CAA records say one thing: this CA may issue for my domain. issue "letsencrypt.org" and you feel covered. That line does exactly what it says and no more. It tells Let's Encrypt it may issue certificates for your domain. It says nothing about who at Let's Encrypt gets to ask.
That gap is where the risk lives. A CAA record that names a CA is a permission handed to millions of accounts. Yours is just one of them. Anyone holding a Let's Encrypt account who can pass a validation challenge for your domain walks straight through it. RFC 8657 fixes that. And as of a CA/Browser Forum ballot that passed this year, every public CA is about to be required to honour the fix.
What issue actually authorizes
CAA is a DNS record type. It carries property tags, and the two that matter here are issue and issuewild. An issue record lists a CA that may issue normal certificates for the name. An issuewild record does the same for wildcards, and it takes precedence over issue when it is present.
Here is the part that trips people up. Records of the same tag are additive. If any matching record permits issuance, issuance is permitted. So this pair:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "sectigo.com"
means both CAs may issue. There is no way to express "only under these conditions" by adding more permissive lines. You narrow the permission by making the lines themselves narrower. That is exactly what RFC 8657 lets you do.
accounturi pins issuance to one account
RFC 8657, published back in 2019, adds two parameters you can append to an issue or issuewild value. The first is accounturi. It restricts issuance to a single ACME account, named by its account URL:
example.com. IN CAA 0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
Now Let's Encrypt only issues for example.com when the order comes from account 1234567890. Every other Let's Encrypt account in the world is refused, even though the CA itself is still authorized. The account URL is tied to your ACME account key, and nobody can forge an order from your account without that key.
Think about what that closes. Someone who briefly controls your DNS or can answer an HTTP challenge, through a dangling record, a transient BGP hijack, a compromised load balancer, could previously get a real certificate from any CA your CAA allowed. Set accounturi and passing the challenge is no longer enough. They also need your account key. That key lives in your infrastructure and never travels over the network. The bar moves from "control the domain for ten minutes" up to "control the domain and steal a private key." Those are very different attackers.
validationmethods locks down how you get validated
The second parameter is validationmethods. It restricts which challenge types a CA may use to validate you. The tokens are the ACME method names: http-01, dns-01, and tls-alpn-01.
example.com. IN CAA 0 issue "letsencrypt.org;validationmethods=dns-01"
If your renewals only ever use DNS-01, this line says so, and the CA refuses to validate example.com any other way. That matters because your validation surface is wider than you think. Maybe you issue everything through DNS-01, but port 80 on some forgotten host still answers, and HTTP-01 against it would succeed. Pinning the method shuts that door. An attacker who can serve a file over HTTP-01 gets nothing when your record only permits DNS-01.
You can combine both parameters on one line, separated by semicolons:
example.com. IN CAA 0 issue "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
Only your account. Only over DNS-01. That is about as tight as public CAA gets.
Finding your account URI
You cannot pin what you cannot name. So get your account URL first. It is specific to the CA and to the client, so where it lives depends on what you run.
certbot prints it directly:
sudo certbot show_account
# Account URL: https://acme-v02.api.letsencrypt.org/acme/acct/1234567890
The same value sits in the account registration on disk if you would rather read it there:
sudo cat /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/*/regr.json
cert-manager records the account URI in the Issuer status once it registers:
kubectl get clusterissuer letsencrypt-prod -o jsonpath='{.status.acme.uri}'
acme.sh and lego keep their account state under their own data directories, and both surface the registered account through their account commands. Whatever you run, the number on the end of that URL is your account ID, and the full URL is what goes into the record verbatim.
Writing and checking the record
Add the record at your DNS provider, then confirm it resolves before you trust it:
dig +short CAA example.com
You should see your issue line come back with the parameters intact. A few things are worth getting right on the first pass.
If you issue wildcards, remember issuewild overrides issue for wildcard requests. Put the same parameters on your issuewild record, or your wildcard renewals run under whatever that line permits:
example.com. IN CAA 0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
example.com. IN CAA 0 issuewild "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
If more than one account legitimately issues for the domain, say staging alongside production, or a CDN that gets its own cert, add one issue line per account. They are additive, so every named account is allowed and nobody else is. What you must not do is leave a bare issue "letsencrypt.org" sitting next to your pinned line. The bare line permits every account. The additive rule means it wins. Your careful binding then does nothing at all. This is the single most common way people believe they are protected when they are not.
CAA records apply down the tree, so a record on example.com covers api.example.com unless that subdomain carries its own CAA records. Pin high and you cover a lot in one place. For the wider set of CAA gotchas around wildcards, Wildcard Certificates: Why DNS-01 Validation Keeps Breaking digs into those.
Why this stops being optional in 2027
Let's Encrypt has honoured accounturi and validationmethods since December 2022. The catch was always that most other public CAs did not, so account binding was a Let's Encrypt feature rather than a property you could rely on across the board. If your CAA allowed a second CA, that second CA might ignore the parameters and issue for anyone.
That is what changed. In May 2026 the CA/Browser Forum passed ballot SC098v2, which adds a requirement that every publicly trusted CA process the RFC 8657 CAA parameters. The effective date is 15 March 2027. After that, an accounturi in your CAA record is not a hint one CA happens to respect. It is a rule the whole trusted set must enforce. Now it is worth deploying everywhere.
The primary source is the ballot SC098v2 page at the CA/Browser Forum. The parameter syntax comes from RFC 8657 and the Let's Encrypt CAA documentation.
The failure mode: pin it wrong and renewals stop
Account binding is a control with teeth, and teeth bite both ways. The instant your CAA names an account, any renewal from a different account fails validation. Quietly, from the CA's side, because a refused order reads as a policy denial and not an outage. You find out when a certificate expires.
The scenario to plan for is account key loss. Your account URL is derived from your account, and your account is anchored to your account key. Delete the cert-manager account-key Secret, wipe the certbot accounts directory, lose the laptop with ~/.acme.sh on it, and your client does the helpful thing. It registers a brand new account with a brand new URL. That URL is not in your CAA record. Every pinned domain now refuses issuance until you restore the old account or update the record. This is why the account key stopped being a throwaway, something I got into in Your ACME Account Key Just Became Production-Critical. Where's Yours?.
So treat the CAA record and the account key as one object. Back up the key. Write the account URL down next to the DNS record that pins it. And put the record itself under monitoring. A dig in CI that fails the moment the pinned account ID vanishes from your zone is a lot cheaper than an expiry alert three weeks later. The same monitoring that catches expiries catches this drift, which is the discipline behind Domain Monitoring for Digital Agencies: A Practical Guide.
Pinned right, this is one of the highest-value DNS records you will ever add. Pinned and forgotten, it is a scheduled outage with your name on it. The whole difference is whether you treat the account behind it as production infrastructure or as a file some tool wrote once.
Frequently asked questions
Does accounturi protect me if an attacker fully takes over my DNS?
Not completely. An attacker who owns your DNS can rewrite or delete the CAA record itself and then pin their own account. What accounturi defends against is the far more common case: someone who can pass a single validation challenge through a dangling record or a brief routing hijack, but who does not control your zone wholesale and does not hold your account key. That still covers a large share of real mis-issuance paths.
Do I still need accounturi if I use DNSSEC and MPIC? They solve different problems. DNSSEC protects the integrity of your DNS answers, and multi-perspective validation makes localized hijacks harder to pull off, but neither one restricts which account may issue once validation passes. Account binding is the only one of the three that ties issuance to your specific ACME identity, so it stacks with them rather than replacing either.
Will pinning my account break issuance from my CDN or a second tool?
It will if that CDN or tool uses a different ACME account than the one you pinned, which it almost always does. Add an extra issue line for each additional account that legitimately issues for the domain. Every named account is allowed, because CAA records of the same tag are additive.
What happens on 15 March 2027 if I do nothing?
Nothing breaks. SC098v2 requires CAs to enforce the parameters you set. It does not require you to set any. If your records carry no accounturi or validationmethods, issuance behaves exactly as it does today. The date only matters if you want the binding, and that is when every trusted CA has to respect it instead of just Let's Encrypt.
