CAA

CAA records (RFC 8659) declare which certificate authorities may issue certificates for your domain. CAs are required to check CAA before every issuance, so a tight allow-list blocks mis-issued certificates at the source.

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". From 15 March 2027 every publicly trusted CA must honour these parameters (CA/Browser Forum Baseline Requirements).

Domain

Violation reports (iodef, optional)

An email address becomes a mailto: URL.

Contact e-mail (contactemail, optional)

Publishes a domain contact a CA may use for domain-contact validation (CA/Browser Forum BR §3.2.2.4.13) and to reach you about mis-issuance. Enter a bare address — no mailto: (unlike iodef).

Contact phone (contactphone, optional)

A phone contact a CA may use for phone-based domain validation (CA/Browser Forum BR §3.2.2.4.17). Use international format with a leading + and country code — an RFC 3966 “Global Number”; spaces are removed and there is 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 each record’s flag: 0 (normal) or 128 (critical) — leave it at 0 unless you specifically need it.

Other issue CAs

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

Other issuewild CAs

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

Other issuemail CAs (S/MIME)

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

Forbid all TLS issuance (0 issue ";") – for domains that never need certificates

Forbid wildcard issuance (0 issuewild ";")

Forbid S/MIME issuance (0 issuemail ";")

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). From 15 March 2027, publicly trusted CAs must honour them (CA/Browser Forum Baseline Requirements §4.2.2.1.2).

Account URI (accounturi)

The ACME account URL that issuance is locked to. Only meaningful when you allow a single CA — copy it from your ACME client or CA dashboard.

dns-01

http-01

tls-alpn-01

Tick the validation method(s) a CA may use (validationmethods). Leave all unticked to allow any method.

Signed HTTP Exchanges (SXG) — advanced

Authorize SXG-signing certificates (cansignhttpexchanges=yes)

Lets Google Trust Services (pki.goog) issue certificates with the CanSignHttpExchanges extension, used to sign Signed HTTP Exchanges — e.g. prefetchable content served under your origin URL. It is appended to a selected pki.goog issue/issuewild rule only. 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.

Runs entirely in your browser. Record Studio · Verify the result with the domain security check