domainsecuritycheck

← Record Studio

CAA

CAA records (RFC 8659) declare which certificate authorities may issue certificates for your domain. A compliant CA must check CAA before every issuance (RFC 8659 §3), so a tight allow-list markedly reduces the risk of mis-issuance. It is not a hard block: CAA works only as far as issuers observe it (RFC 8659 §5), and after a CAA check a CA may still issue within the record’s TTL or 8 hours, whichever is greater (CA/Browser Forum BR §4.2.2.1) — so a tightened policy is not effective instantly. Keep watching Certificate Transparency as well.

Need to pin issuance to a specific ACME account or validation method? Use the ACME binding (RFC 8657) fields below to add accounturi= and validationmethods= to your issue/issuewild rules – for example 0 issue "letsencrypt.org; validationmethods=dns-01". Until 15 March 2027 processing these parameters is a SHOULD in the CA/Browser Forum Baseline Requirements (§4.2.2.1.2), and RFC 8657 §5.2 says not to assume support without an explicit statement from the CA; from 15 March 2027 every publicly trusted TLS CA must process them.

CAs look for CAA by climbing the DNS tree from the certificate’s name upwards and stop at the FIRST name that carries any CAA RRset (RFC 8659 §3). Publishing at the registrable domain (example.com) therefore also covers www and every other subdomain that publishes none of its own. A CAA RRset on a subdomain REPLACES the parent’s set for that name — the two are never merged, so repeat every rule that should still apply, iodef and contact properties included. Careful: a set that stops the climb but carries no issue/issuewild rule — only contactemail or iodef, say — leaves issuance for that name unrestricted (RFC 8659 §3). And where a subdomain’s DNS is delegated to someone else, CAA cannot restrict what they publish there (RFC 8657 §5.7).

An email address becomes a mailto: URL.

Publishes a domain contact for CAs. Its one specified use, domain-contact validation (CA/Browser Forum BR §3.2.2.4.13), is being retired: SHOULD NOT be used since 15 March 2026, MUST NOT from 15 March 2028. For mis-issuance reports use the iodef field above. Enter a bare address — no mailto: (unlike iodef).

A phone contact that CAs may look up. Its one specified use, phone-based domain validation (CA/Browser Forum BR §3.2.2.4.17), is being retired: SHOULD NOT be used since 15 March 2026, and from 15 March 2027 CAs MUST NOT rely on it. For mis-issuance reports use the iodef field above. Use international format with a leading + and country code — a Global Number per BR Appendix A.1.2; this form removes the spaces (they are allowed either way) and adds no tel: prefix.

Allowed certificate authorities

Tick, per CA, which issuance types it may perform. Use the search box to filter the list by CA name or domain. issue authorizes TLS/other certificates — including wildcards, unless you also add an issuewild rule, which then governs wildcards (RFC 8659 §4.3). issuemail is separate: it governs S/MIME (email) certificates (RFC 9495) and is not covered by issue/issuewild. To block wildcards entirely, use “Forbid wildcard issuance” below. The flag column sets the flag on every record of that CA at once: 0 (normal) or 128 (critical). Critical means a CA that does not know or does not support that property tag must refuse ALL issuance for the name (RFC 8659 §4.1) — and that cuts both ways: 128 on issuemail can block your TLS certificates at a TLS-only CA, 128 on issue can block your S/MIME certificates at an S/MIME-only CA (RFC 9495 §6). Publicly trusted TLS CAs must process issue/issuewild/iodef in any case (CA/Browser Forum BR §4.2.2.1). Leave it at 0.

Comma-separated CAA identifiers of additional CAs allowed to issue TLS/other certificates.

Additional CAs allowed to issue wildcard certificates. If any issuewild rule is present it governs wildcards; otherwise the issue rules do.

Additional CAs allowed to issue S/MIME (email) certificates (RFC 9495).

ACME binding (RFC 8657) — optional

Pins issuance to a specific ACME account and/or validation methods. These parameters are appended to the issue/issuewild rules above (not to issuemail). Until 15 March 2027 processing them is a SHOULD (CA/Browser Forum Baseline Requirements §4.2.2.1.2), and RFC 8657 §5.2 says not to assume support without an explicit statement from the CA; from 15 March 2027 every publicly trusted TLS CA must process them.

The account URL issuance is locked to — it must be YOUR account at the CA selected above. A property whose accounturi that CA does not recognize, for instance an account at a different CA, is unsatisfiable: the CA must then refuse issuance, renewals included (RFC 8657 §3, §5.8). Only meaningful when you allow a single CA — copy it from that CA’s own ACME client or dashboard. CAs that do not use ACME account URLs define their own accounturi format (CA/Browser Forum BR §4.2.2.1.2); then use what that CA documents.

Tick the validation method(s) a CA may use (validationmethods) — these are the three ACME challenge labels. Careful: as soon as one box is ticked, every method NOT ticked is forbidden. A method that also has an ACME label stays covered even when it is run outside ACME — the CA SHOULD accept any label that represents it (CA/Browser Forum BR §4.2.2.1.2). But methods with no ACME equivalent, such as the email- and phone-based ones, carry only ca-tbr-<n> labels that this form cannot produce; if you validate that way, leave all boxes unticked. All unticked = any method allowed.

Signed HTTP Exchanges (SXG) — advanced

Authorizes SXG-signing certificates — certificates carrying the CanSignHttpExchanges extension used to sign Signed HTTP Exchanges, e.g. prefetchable content served under your origin URL. A conforming CA may only issue such a certificate when this parameter sits on its own issue/issuewild rule (draft-yasskin-http-origin-signed-responses §4.2). The parameter is not CA-specific: Google Trust Services (pki.goog) and DigiCert (digicert.com) both require it, and this form appends it to the rules of those CAs. Defined only in expired IETF drafts (draft-yasskin-*), never standardized as an RFC, and Chromium-only — leave it off unless you actually serve Signed Exchanges.

Records are built in your browser; “Load current record” has our server look up your domain’s DNS. Record Studio · Verify the result with the domain security check