CAAレコードが「動作しない」と感じる場面は、大きく3つに分かれます。証明書の発行が CAA を理由に拒否される場合、CAA で制限したはずなのに思った効果が出ない場合、DNS の管理画面で CAA を登録できない・意図した形で保存されない場合です。この記事では、まず CAA が何をする仕組みで何をしないのかを確認し、症状ごとに起きやすい原因の順に、確かめ方と直し方を説明します。
CAA の基本的な書き方や追加の手順は別の記事で扱っているため、ここでは「設定したのに期待どおりにならない」状態からの切り分けに絞ります。
CAA がすること・しないこと
CAA（RFC 8659）は、ドメインの所有者が「このドメインの証明書を発行してよい認証局」を DNS で宣言する仕組みです。公的な認証局は、証明書を発行する直前に CAA を確認することが業界の基準（CA/Browser Forum の Baseline Requirements）で求められています。
誤解されやすいのは、CAA が効く場面です。
- CAA を確認するのは認証局だけです。 ブラウザは CAA を見ません。CAA に載っていない認証局の証明書でも、すでに発行されていればブラウザでは有効な証明書として扱われます。
- 発行済みの証明書には影響しません。 CAA を追加しても、それ以前に発行された証明書が無効になることはありません。
- 効くのは発行の時点です。 証明書の更新も新規の発行と同じ扱いのため、更新のたびに確認されます。
「CAA を入れたのにブラウザで別の認証局の証明書が表示される」という場合、多くは CAA を入れる前に発行されたか、CDN などが CAA に載っている認証局で発行した証明書です。CAA が壊れているわけではありません。
まず現状を取り出す
どの症状でも、最初に「認証局から見える CAA」を確かめます。管理画面の表示ではなく、DNS の応答を見るのが要点です。
# 公開リゾルバー経由で見る
dig CAA example.com +short
dig CAA www.example.com +short
# 権威 DNS に直接聞く（キャッシュの影響を除く）
dig NS example.com +short
dig @ns1.example-dns.net CAA example.com +short
# 応答の状態（NOERROR / SERVFAIL など）も見る
dig CAA www.example.com認証局は、証明書の対象の名前から親のドメインへ順に CAA を探し、最初に CAA が見つかった階層の内容だけを使います（ツリーの遡り）。www.example.com の証明書なら、www.example.com、example.com の順に確認し、www.example.com に CAA があれば example.com の CAA は見ません。どの階層に CAA があるかを先に把握しておくと、以降の切り分けが早くなります。
症状1：証明書の発行が CAA を理由に拒否される
Let's Encrypt では、エラーに CAA が発行を妨げている旨と、対象のドメイン名が表示されます。ほかの認証局でも、発行の申請画面や通知で CAA が理由であることが示されるのが一般的です。メッセージに出ているドメイン名が、遡りで最初に CAA が見つかった階層とは限らない点に注意して、上の手順で階層を確かめます。
原因1：使う認証局の識別子が CAA に無い
最も多い原因です。issue の値は認証局ごとに決まった識別子（Let's Encrypt なら letsencrypt.org）で、認証局が公開している値と一致している必要があります。認証局を変えた、レンタルサーバーやCDNが自動で発行する証明書の認証局が変わった、といったときに起きます。使っている認証局の識別子は、その認証局のドキュメントで確認します。
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "使う認証局の識別子"issue は複数行並べられます。新しい認証局を追加するときは、既存の行を消さずに行を足します。
原因2：ワイルドカード証明書で issuewild が優先されている
ワイルドカード証明書（*.example.com）の発行では、issuewild があると issue は使われません。issue に認証局を載せていても、issuewild に別の認証局しか無ければ拒否されます。逆に issuewild ";" と書くと、ワイルドカードの発行をすべて禁止します。ワイルドカードを使う場合は issuewild の内容も確かめます。
原因3：サブドメインや CNAME の先に別の CAA がある
www.example.com が CDN などへの CNAME になっている場合、CAA の問い合わせも CNAME をたどり、行き先の名前の CAA が返ることがあります。行き先に CAA があれば、その内容で判断されます。また、サブドメインに個別に CAA を置いていると、親ドメインの CAA は参照されません。dig CAA の応答に CNAME が含まれていないか、サブドメイン側に CAA が無いかを確かめます。
原因4：accounturi や validationmethods が合っていない
CAA には、発行を許すアカウントや認証方式を絞る追加のパラメータ（RFC 8657 の accounturi・validationmethods）を書けます。ACME のアカウントを作り直した、別のサーバーから発行した、認証方式を HTTP-01 から DNS-01 に変えた、といったときに条件から外れて拒否されます。パラメータを書いている場合は、今の発行の条件と一致しているかを見直します。
原因5：CAA の問い合わせ自体が失敗している
dig CAA が SERVFAIL やタイムアウトになる場合、認証局は CAA を確認できず、発行を拒否することがあります。DNSSEC の署名の期限切れや DS レコードの不整合、権威 DNS の一部が CAA の問い合わせに正しく応答しない、などが典型例です。dig +cd CAA example.com（検証を無効にした問い合わせ）で応答が返るなら DNSSEC の問題を疑い、DNSViz などで署名の状態を確かめます。
症状2：CAA の制限が効いていないように見える
- 発行済みの証明書が残っている。 先に書いたとおり、CAA は発行済みの証明書には影響しません。不要な証明書は、発行した認証局で失効の手続きを取ります。
- CAA に載っている認証局が発行している。 CDN やホスティング事業者は、提携する複数の認証局を使い分けることがあります。CAA に載せた認証局のどれかであれば、発行は正当です。
- CAA が引けていない。 管理画面で登録したつもりでも、権威 DNS が別の事業者だった、という場合があります。
dig NSで今の権威 DNS を確かめ、そこで登録します。 - 発行されたことに気付けない。 想定外の発行を見つけたい場合は、Certificate Transparency（CT）のログを検索できるサービスで、自分のドメインの証明書を定期的に確かめる方法が使えます。
iodefを書くと違反の報告先を宣言できますが、報告を送るかどうかは認証局によって異なるため、監視の手段としては CT のほうが頼りになります。
症状3：CAA を登録できない・意図どおりに保存されない
- DNS サービスが CAA に対応していない。 古い管理画面やレンタルサーバーの簡易 DNS では、CAA の種類を選べないことがあります。対応していない場合は、CAA に対応した DNS サービスへの移行を検討します。
- 入力の形式が違う。 管理画面によって、フラグ・タグ・値を別々の欄に入れる形式と、1行にまとめて入れる形式があります。値の引用符を自動で付ける画面に引用符付きで入れると、二重の引用符で保存されることがあります。保存後は
dig CAA +shortで、0 issue "letsencrypt.org"のような形になっているかを確かめます。 - フラグに 128 を入れている。 フラグ 128 は「このタグを理解できない認証局は発行してはならない」という意味です。通常の
issueやissuewildでは 0 を使います。 - ゾーンファイルの構文エラー。 BIND などでゾーンファイルを直接書いている場合は、
named-checkzoneで構文を確かめてから読み込み直します。
直したあとに確かめること
- 権威 DNS と公開リゾルバーの両方で、
dig CAAの内容が意図どおりになっている。 - 古い CAA がキャッシュに残っている間は、TTL の分だけ待つ。認証局によっては、CAA を確認した結果を一定時間使い回すことが基準で認められています。
- Let's Encrypt なら、ステージング環境（
certbot --dry-runなど）で発行を試してから本番で発行する。本番での失敗が続くと、発行の回数制限に当たることがあります。
CAA の変更は、証明書の自動更新に直接影響します。変更の前に今の CAA を控え、証明書の期限に余裕がある時期に作業してください。認証局の識別子や回数制限の内容は変わることがあるため、各認証局のドキュメントで最新の情報を確認します（2026年10月現在）。
まとめ
- CAA を確認するのは発行の時点の認証局だけで、ブラウザや発行済みの証明書には影響しません。この前提で症状を見直すと、故障ではないケースを先に除けます。
- 発行が拒否される場合は、認証局の識別子、
issuewildの優先、サブドメインや CNAME の先の CAA、追加パラメータ、問い合わせの失敗（DNSSEC など）の順に確かめます。 - 調べるときは管理画面ではなく
dig CAAで、権威 DNS と公開リゾルバーの応答を見ます。 - 想定外の発行の監視には、
iodefより Certificate Transparency のログを使うほうが頼りになります。