CAAレコード 設定方法｜発行元の調べ方・書き方と設定しなくてよい場合

• CAAレコード 設定は任意です。このドメインと上位の名前のどこにもCAAが無ければ、認証局はCAAを理由に証明書の発行を断りません
• 設定するなら、いま使っている証明書の発行元をサブドメインの分まですべて調べてから書きます。書き漏らした発行元は、そのCAAがかかる名前の証明書を次に発行や更新するときに断られます
• AWSのACMで取った証明書なら 0 issue "amazon.com"、Let's Encryptなら 0 issue "letsencrypt.org" の形で書きます

いまの状況に合う行から読み始めてください。

この記事で使う言葉です。

CAAレコードを設定しなくてよい場合

発行できる認証局を絞る予定が無いなら、CAAレコードは設定しなくて構いません。RFC 8659 セクション3 は、認証局が発行の前にCAAを確かめ、見つかったCAAに合わない発行は、CPまたはCPSに定めた例外を除いてしないと定めています。CAAが見つからなければ、CAAによる制限はかかりません。AWSもACMの案内で、CAAの設定は、任意だと書いています（Certification Authority Authorization (CAA) problems）。

ここでの「CAAが無い」は、診断したドメインだけを指していません。認証局は、名前の左側のラベルを1つずつ外しながら上位へたどり、最初に見つかったCAAを使います（RFC 8659 セクション3）。shop.example.com にCAAが無くても example.com にあれば、shop.example.com の証明書には example.com のCAAがかかります。

CAAを置いていなくてもCAAの問い合わせにDNSサーバーが正しく答えないと発行が止まることがあります。Let's Encryptは、CAAを置いていないドメインでもCAAの確認でエラーになることがあると書いています（Certificate Authority Authorization (CAA) の「CAA errors」）。エラーで止まったときは、CAAのエラーで証明書の発行や更新が止まったときを見てください。

CAAレコードで決まること

CA/Browser Forumの基準は、公開されたサイト向けの証明書を発行する認証局に、発行の過程でRFC 8659に沿ってCAAを取得して処理することを求めています（Baseline Requirements 2.3.1 の 4.2.2.1）。

RFC 8659 セクション1 は、CAAが表すのは現在の許可だけだとしています。ブラウザなど証明書を使う側については、証明書の検証にCAAを使ってはならないと定めています。CAAを追加しても既に発行された証明書がブラウザで使えなくなることはありません。

書く場所は、ふつうはドメイン本体 (example.com) です。Let's Encryptは、登録したドメインに置けばそのドメインと配下のサブドメインに効くと案内しています（同じページの「Where to put the record」）。shop.example.com に別のCAAを置けば shop.example.com とその配下の名前では、より近い名前に別のCAAが無い限り shop.example.com のCAAが使われます（RFC 8659 セクション3 の、上位へたどる手順）。

ステップ 1/4：いま使っている証明書の発行元をすべて調べる

CAAに書いていない認証局は、発行を断ります。いまサイトやサブドメインで使っている証明書の発行元が1つでも漏れるとその証明書の次の更新が止まります。書く前に発行元を洗い出してください。

1つのアドレスの発行元を見る

macOSやLinuxのターミナルなら、次のコマンドで見られます。ターミナルを使わないときは、下の crt.sh の一覧で発行元の欄を見てください。sitekensa.com の部分を自分のドメイン名に置き換えてください。

$ echo | openssl s_client -connect sitekensa.com:443 -servername sitekensa.com 2>/dev/null | openssl x509 -noout -issuer
issuer=C=US, O=Amazon, CN=Amazon RSA 2048 M04

これは2026-10-23に、ACMの証明書をCloudFrontで配信している sitekensa.com で実行した結果です。O= の後ろが発行元の組織名です。同じ日に letsencrypt.org と wikipedia.org で実行すると O=Let's Encrypt が出ました。

サブドメインを含めて洗い出す

www、shop、mail のように、サブドメインごとに別のサービスで証明書を取っていることがあります。ドメイン本体にCAAを置くとサブドメインの証明書にもかかります。

crt.sh は、Certificate Transparencyという公開の記録に登録された証明書を検索できるサイトです。ドメイン名を入れるとそのドメインとサブドメインの証明書が発行元と一緒に一覧で出ます。2026-10-23に sitekensa.com で引くと sitekensa.com と www.sitekensa.com を含む証明書が発行元 O=Amazon で出ました。一覧には過去に発行されたものも並びます。いま使っているかどうかは、サイトや契約しているサービスの画面で確かめてください。

この一覧に出るのはこれまでに発行された証明書です。CAAが効くのはこれから発行される証明書なので、いまも使っている名前の証明書の発行元を書きます。名前ごとにいちばん新しい証明書の発行元を見て、使うのをやめたサービスの古い証明書の発行元は書かなくて構いません。

次の更新で使われる認証局と、これから使い始めるサービスの発行元は、証明書を管理している相手に確かめてください。制作会社などに任せているなら、「このドメインとサブドメインの証明書をどの認証局で発行しているか」「次の更新でも同じ認証局か」「CAAの issue に書く値は何か」を聞きます。ACMを使っていると聞いているなら、下の表のACMの行がその候補です。

サブドメインを別のサービスへCNAMEで向けている場合は、向け先の名前のCAAが先に見られます。認証局はCNAMEを追った先でCAAを引き、そこに無ければ、元の名前から上位へたどります（RFC 8659 セクション3）。向け先にもその間の名前にもCAAが無ければ、ドメイン本体に置いたCAAがそのサブドメインにかかるので、そのサービスの発行元も書いておく必要があります。

CNAMEで向けているサブドメインがあるかは、DNSの管理画面のレコードの一覧で、種別がCNAMEの行を探せば分かります。バリュードメインの従来の画面なら、テキスト欄の各行の先頭の語が種別です。見つけた行の向け先のサービスに、そのサブドメインの証明書を発行している認証局とCAAに書く値を確かめてください。その認証局の issue の行も、ステップ 2/4 で一緒に書きます。確かめるのはサイトやサービスで使っている名前の行で、ACMの検証のために足した、名前が _ で始まる行は飛ばして構いません。管理画面を見られないときは、制作会社などに同じことを聞いてください。

発行元の名前から、書く値を決める

CAAに書くのは認証局ごとに決まっているドメイン名です。発行元の組織名と同じとは限りません。

CP/CPSは、認証局が発行の方針と運用を公開している文書です。レンタルサーバーの無料SSLやCDNの証明書では、どの認証局から発行されているかを事業者の案内で確かめてから、その認証局の名前を探してください。

ステップ 2/4：書く値を決める

CAAレコードの中身は、フラグ・タグ・値の3つを半角スペースで区切った1行です（RFC 8659 セクション4.1.1）。

0 issue "amazon.com"

認証局が2つ以上あるなら、1行に1つずつ書きます。同じタグの行は足し合わされ、どれか1行に書かれた認証局は発行できます（RFC 8659 セクション4.2）。CloudFrontのACMとLet's Encryptを併用しているなら、次の2行になります。

0 issue "amazon.com"
0 issue "letsencrypt.org"

issue と issuewild の組み合わせ

issue だけを書けば、ワイルドカード証明書にもその許可が使われます。Let's Encryptは、ワイルドカードとそうでない証明書で許可を変えたいときだけ issuewild を使えばよいと案内しています。ACMも、issuewild が無くACMの issue があればワイルドカード証明書を発行できると書いています。

RFC 8659 セクション4.3 は、組み合わせごとの効き方を例で示しています。どの例も、サブドメインにそれより近いCAAが無い場合の話です。

表の ca1 と ca2 は、ステップ 1/4 で決めた値に置き換えて読んでください。issuewild の行があるとワイルドカード証明書には issue の行が使われなくなります（同じセクション）。

0 issue ";" は、どの認証局にも発行を許可しない書き方です（RFC 8659 セクション4.2）。値の書き間違いにも注意が要ります。同じセクションは、issue の値が決められた形に合わないときは発行者の名前が空の行と同じに扱うと定めているので、; の行と同じ働きになります。ほかに正しい issue の行があれば、そちらの認証局は発行できます。

報告先の iodef

iodef のタグには、断られた発行の申し込みを知らせる先 (mailto: のメールアドレスなど) を書けます（RFC 8659 セクション4.4）。発行を制限する働きはありません。Baseline Requirements の 4.2.2.1 は、CAAで発行を阻んだ申し込みを iodef の連絡先へ送ることを認証局が「すべき」(SHOULD) こととしていて、義務にはしていません。ACMの案内には、iodef は、現在使われていないと書かれています。知らせが届く前提で運用しないでください。

ステップ 3/4：DNSの管理画面にCAAを追加する

追加するのは、ネームサーバーを持っている事業者の管理画面です。どこか分からないときは、SiteKensaの診断に「DNSの管理場所」として出ます。ネームサーバーが2社に分かれていると出たら、ネームサーバーが一致しない・2社が混ざっているときを先に読んでください。

入れる値は次のとおりです。

フラグ・タグ・値を別々の欄に分けて入れる画面もあります。その場合は 0、issue、amazon.com を欄ごとに入れます。種別の選択肢にCAAが無い画面では追加できないので、事業者に問い合わせてください。

バリュードメインの場合

2026-10-23に、バリュードメインで取得した検証用の .com ドメイン1件で確かめた書き方です。DNS設定の画面は従来のコントロールパネルと One Panel の2つがあり、どちらで作業しても同じ設定を編集します。同じ日に、従来の画面で保存した行が One Panel の一覧に並ぶことを確かめました。使い慣れたほうを開いてください。

• 従来のコントロールパネル: https://www.value-domain.com にログインしてコントロールパネルを開き、ホームの「管理ドメイン」の件数、対象ドメインの行の「DNS/URL」の順に押します
• One Panel: https://one.value-domain.com/panel を開き、左のメニューの「ドメイン」「ドメイン管理」、対象のドメイン名、「DNS設定」、一覧の右上の鉛筆のアイコンの順に押します

画面の図は、バリュードメインのSPFの設定ガイドにあります。開いた画面で、次のように書きます。

• 従来のコントロールパネル: DNS設定のテキスト欄には、そのドメインのレコードがすべて並んでいます。既存の行は消さずに残し、末尾に caa @ 0 issue "amazon.com" の1行を書き足して保存します。値の " もそのまま書きます。この書き方で保存し、ネームサーバーと 1.1.1.1・8.8.8.8 から 0 issue "amazon.com" が返ることを確かめました
• One Panel: 編集画面で行を追加し、タイプを CAA、名前を @、コンテンツを 0 issue "amazon.com" にします。この書き方は公式マニュアルと画面の表示で確かめました。One Panel での保存は試していません

この確認で確かめたのはDNSに置けて外から引けることまでです。証明書の発行は試していません。

ステップ 4/4：外から引いて、書いた値が返るか確かめる

Windowsなどで dig が無いときは、SiteKensaの診断で確かめます。ドメイン名を入れて診断し、CAAの項目を見てください。

• 「CAAで証明書を発行できる認証局を制限しています」と出て、説明に書いた認証局の名前 (例: amazon.com) が並べば、診断が問い合わせる公開のDNS (Google と Cloudflare) から引けています。詳細を開けば見つかった行が 0 issue "amazon.com" の形で出ます
• 「CAAは設定されていません」と出たら、同じ診断に出る「DNSの負のキャッシュ時間は最大○秒です」を見ます。保存してからその秒数が過ぎていなければ、反映を待っている可能性があるので、時間を置いてもう一度診断します
• その秒数が過ぎても出ないときは、管理画面で書いた行を見直します。種別がCAAになっているか、名前が @ か、値の " が抜けていないかを確かめてください

macOSやLinuxでは、dig で引きます。上のバリュードメインの確認で実行した結果です (ドメイン名は伏せています)。

$ dig +short CAA example.com @8.8.8.8
0 issue "amazon.com"

書いた行がすべて、書いたとおりに返れば、問い合わせた 8.8.8.8 からは引けています。行の順番は入れ替わることがあります。

何も出ないときは、+short を外して status: の行を見てください。CAAを置いていない sitekensa.com では、次のように出ます。下は出力のうち、見る2行だけを抜き出したものです。

$ dig CAA sitekensa.com @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7499
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

status: NOERROR で ANSWER: 0 なら、その名前にCAAはありません。追加した直後なら反映を待っている可能性があります。待つ時間の目安は、このステップの先頭の診断に出る「DNSの負のキャッシュ時間は最大○秒です」の秒数です。保存してからその秒数が過ぎても変わらなければ、書いた行を見直してください。待ち方はDNSの設定が反映されないときにあります。status: が SERVFAIL や REFUSED なら、CAAの問い合わせに正常な答えが返っていません。まだ証明書を発行していないときも、CAAのエラーで証明書の発行や更新が止まったときの最後の段落の手順で、ネームサーバーの事業者に応答を確かめてもらってください。

Windows Server 2022 の nslookup では、CAAを種別に指定できませんでした。2026-09-01にコマンドプロンプトで nslookup -norecurse -type=CAA を実行するとCAAではないアドレスの一覧が出て、その後ろに unknown query type: CAA と出ました。Windows 11 では試していません。どちらでも、このステップの先頭の診断で確かめてください。診断はドメインから登録したドメイン本体まで上位へたどってCAAを探します。

CAAのエラーで証明書の発行や更新が止まったとき

ACMでは、「One or more domain names have failed validation due to a Certification Authority Authorization (CAA) error」と出ます。AWSの日本語の案内では「CAA (Certification Authority Authentication) エラーにより、1 つまたは複数のドメイン名の検証に失敗しました。」と訳されています。

AWSは、CAAの値にステップ 1/4 の表の4つのどれかを入れるよう案内しています。ドメインの検証が済んだ後でこのエラーが出たなら、CAAを直してから証明書をもう一度リクエストする必要があります（Certification Authority Authorization (CAA) problems）。

ほかの認証局でも、まずステップ 4/4 のやり方で、証明書の名前とその上位の名前のCAAを引いてください。その認証局の値が無ければ、ステップ 2/4 の形で1行足します。

CAAを置いていないのに止まったときは、ステップ 4/4 の status: を見ます。Let's Encryptは、DNSの事業者がCAAに対応している必要は無く、知らない種別の問い合わせに NOERROR で答えればよいとしています。同じページは、SERVFAILの原因として、DNSSECの検証の失敗とネームサーバーの障害を挙げています（Certificate Authority Authorization (CAA) の「CAA errors」）。DNSSECの検証の失敗はこの記事では扱いません。ネームサーバーの事業者に、CAAの問い合わせへの応答を確かめてもらってください。

DNSSECの検証の失敗かどうかを見分ける手順は、DNSSECの記事にあります。

戻し方

追加したCAAの行を消せば、そのCAAによる制限は無くなります。上位の名前にも別のCAAが無いかは、ステップ 4/4 で確かめてください。消した後も、消す前の値が反映を待つあいだ残ることがあります。

既にあった行を書き換えたときは、消すのではなく書き換える前の行に戻します。書き換える前に、元の行を控えておいてください。

診断の表示ごとにすること

SiteKensaの診断は、CAAの項目に次のどれかを出します。CAAを引いた名前と見つかった行も表示されます。

設定したら、もう一度診断してCAAの項目が変わったかを確かめてください。