DNS CAA Records Lab
By default any publicly trusted certificate authority can issue a certificate for your domain. A CAA record (Certificate Authority Authorization) is a DNS record that narrows that down — it tells CAs which of them you actually authorise, and a CA that is not listed must refuse to issue. Compose your issue, issuewild and iodef records, pick the CAs you use, and get the DNS zone-file lines plus a plain-English read of exactly what the policy permits and denies — then score it against CAA best practices. CAA is checked at issuance, so it shrinks who can mint a certificate for you; it does not stop a client trusting one an already-trusted CA already issued. Nothing is uploaded and no DNS lookup is performed — this runs entirely in your browser.
Allowed certificate authorities (issue)
Wildcard policy (issuewild)
example.com. IN CAA 0 issue "letsencrypt.org" example.com. IN CAA 0 iodef "mailto:security@example.com"
What this permits / denies
- Only Let's Encrypt may issue certificates for example.com. Any other CA must refuse.
- Wildcard (*.example.com) certificates follow the same rule as above — the issue records cover them.
- A CA that receives a request violating this policy is asked to report it to email security@example.com (iodef).
- An issuance policy is defined (allowed CAs, or an explicit deny-all).
- An iodef contact is set for incident reporting.
- Wildcard issuance is considered explicitly.Decide your wildcard policy on purpose: allow the same CAs, restrict to fewer, or block wildcards entirely with issuewild ";".
Honest scope
CAA shrinks the issuance attack surface: it limits which CAs may mint certificates for your domain, so an unauthorised or stray CA is told to refuse. It would not have stopped the eMudhra-style incident, where the CA itself was already trusted — CAA governs who may issue, not whether an already-issued, already-trusted certificate is accepted. Pair it with Certificate Transparency monitoring and short-lived certificates.
What this lab is
- A free, 100% in-browser DNS CAA record builder and explainer: compose issue, issuewild and iodef records, pick the CAs allowed to mint certificates for your domain, and read what the result permits or denies in plain English.
- CAA (Certificate Authority Authorization) is a DNS record that tells public certificate authorities which of them may issue certificates for your domain — a CA that is not listed must refuse.
- It is checked at ISSUANCE, not at connection: CAA limits who can mint a certificate, which shrinks the issuance attack surface, but it does not stop a client from trusting a certificate already issued by an already-trusted CA.
- Best practice: define a policy (allowed CAs or an explicit deny-all), set CAA at the zone apex, add an iodef contact for incident reporting, decide your wildcard policy on purpose, and review CAA on every CA change.
- CAA would not have stopped the eMudhra-style incident (the CA itself was trusted), but it shrinks the set of CAs that can issue for you. Nothing is uploaded, no DNS lookup is performed — copy or export the records.
Why this matters
Most domains leave certificate issuance wide open: with no CAA record, every publicly trusted CA in the world is allowed to issue for you, so a mis-issuance, a social-engineering attack against the wrong CA, or a stray automated request can produce a valid certificate for your domain that you never asked for. A CAA record is a cheap, DNS-level way to say "only these CAs" — the ones you actually use. A CA is required to check CAA before issuing, so anyone else is turned away at the door, and an iodef contact means you get told when someone tries.
The honest limit, and the reason this lab says so plainly: CAA governs issuance, not trust at connection time. It decides who may mint a certificate, not whether a client accepts one that already exists. It would not have stopped a compromise of a CA you already trust — in that case the CA could already issue — which is why CAA belongs alongside Certificate Transparency monitoring (to see what was actually issued for you) and short-lived certificates (to bound how long any bad certificate is useful). Used that way, CAA meaningfully shrinks the issuance attack surface. Set it at the zone apex, keep an iodef contact, decide your wildcard policy deliberately, and review it whenever you add or change a CA — because a stale CAA record silently blocks a new CA at your next renewal. This is general guidance, not legal or compliance advice.
Frequently asked questions
What is a DNS CAA record?
CAA stands for Certificate Authority Authorization (RFC 8659). It is a DNS record that lists which certificate authorities are permitted to issue certificates for your domain. When a CA receives a certificate request, it is required to check your CAA records first: if your domain has CAA records and the requesting CA is not listed, the CA must refuse to issue. A domain with no CAA records leaves issuance open to every publicly trusted CA. CAA records have three main property tags: issue (which CAs may issue regular certificates), issuewild (which may issue wildcard certificates), and iodef (where a CA should report a policy violation).
Does CAA stop someone from using a certificate that was already issued?
No — and this is the most important limit to understand. CAA is enforced by certificate authorities at issuance time: it governs who may MINT a certificate for your domain. It does nothing at connection time and does not affect certificates that have already been issued. So CAA shrinks the issuance attack surface (a stray or unauthorised CA is told to refuse), but it would not have stopped an incident like the eMudhra intermediate-CA compromise, where the compromised CA was already trusted and could already issue. CAA is one layer; pair it with Certificate Transparency monitoring (to see what was actually issued) and short-lived certificates (to bound exposure).
What is the difference between issue and issuewild, and what does the iodef tag do?
The issue tag lists CAs allowed to issue non-wildcard certificates (and, by default, wildcards too). The issuewild tag specifically governs wildcard certificates (*.example.com): if any issuewild record is present it overrides issue for wildcards, so you can allow a CA for normal certs but forbid it from issuing wildcards, or block wildcards entirely with issuewild ";". The iodef tag gives a CA a place to report a request that violates your policy — a mailto: address or an https: URL. An iodef contact turns CAA into an early-warning signal: if someone tries to get a certificate you did not authorise, the CA can tell you. A special value — issue ";" — means no CA may issue at all, useful for a domain that should never have a certificate.
Is this tool making DNS changes or checking my live domain?
No. It is an educational builder that runs entirely in your browser. It composes the CAA record syntax from your choices, explains in plain language what that policy permits and denies, and scores it against CAA best practices — but it performs no DNS lookup, makes no network calls, and publishes nothing. You copy or export the generated zone-file lines and add them to your DNS yourself, after verifying them. CA issuer identifiers (letsencrypt.org, digicert.com, pki.goog, and so on) are the public CAA domains those authorities document. This is general guidance, not legal or compliance advice.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.Educational — general guidance, not legal/compliance advice.