メール認証・DNS セキュリティ チェッカー — SPF・DMARC・DKIM・CAA・DNSSEC

このツールでは何を確かめますか？

メール認証として SPF・DMARC・DKIM・MX の 4 項目、DNS セキュリティとして CAA・DNSSEC の 2 項目を、DNS から引いたレコードで判定します。判定には総合診断と同じロジックを使います。ただし総合診断は DNSSEC の判定に RDAP（登録情報）も使うため、本ツールで「判定できない」DNSSEC が総合診断では判定できることがあります。

入力はドメイン名のほか、URL（ホスト名だけを取り出します）やメールアドレス（@ より後ろを使います）でも構いません。 日本語ドメインは Punycode（xn-- で始まる形）に変換してから問い合わせます。IP アドレスや localhost は対象外です。

このツールが外部に送るのは DNS の問い合わせだけです。調べるドメインの Web サーバーやメールサーバーには接続せず、 HTTP リクエストも一切送りません。DNSSEC の判定に限り、検証機能を持つ公開リゾルバ（Cloudflare）に DNS over HTTPS で問い合わせます。 結果は保存しません（入力内容は障害調査用のログに 30 日残ります）。

判定基準は？

SPF と DMARC は、レコードが無い・無効になる構成を「問題あり」、置いてはあるがなりすましを止められない設定を「要改善」とします。DKIM はセレクタを列挙できないため、見つからなくても「参考情報」にとどめます。

判定の境目は次のとおりです。総合診断のメール認証・ドメインのカテゴリと同じ実装を使っています。

SPF の DNS ルックアップ数は、include・a・mx・ptr・exists・redirect を、 include 先の中身まで辿って数えます。RFC 7208 は評価中の問い合わせを 10 回までと定めており、超えると PermError になってその送信は SPF で認証されません。 サブドメインが上位ドメインの DMARC レコードを引き継いでいる場合は、sp タグ（無ければ p）で判定します。

仕組みの詳細は SPF・DMARC・DKIM・CAA・DNSSEC の各解説をご覧ください。

DKIM が「見つからない」のは未設定という意味ですか？

いいえ、未設定とは断定できません。DKIM の公開鍵は送信側が自由に決めたセレクタ名の下に置かれ、DNS にはセレクタを一覧する仕組みが無いためです。本ツールはよく使われる 18 種類を試しており、独自の名前は見つけられません。

DKIM の公開鍵は セレクタ._domainkey.ドメイン という名前に置かれます（RFC 6376）。セレクタは送信側が任意に付ける名前で、 Google Workspace なら google、Brevo なら brevo1・brevo2 のように事業者ごとの既定値はあるものの、 独自の名前を使うこともできます。DNS には「このドメインのセレクタを全部教えて」という問い合わせが無いため、外部から DKIM の有無を証明する方法はありません。

そこで本ツールは主要な送信サービスの既定値 18 種類を試し、TXT か CNAME が返ったセレクタを「見つかった」と表示します。 どれにも当たらなければ、判定は減点しない「参考情報」にとどめます。また、存在しないはずのセレクタ名も同時に 1 つ引き、 それにまで応答が返るゾーン（*._domainkey にワイルドカードを置いている等）では、当たった結果を採用しません。

DMARC の新しい仕様（RFC 9989）で何が変わりましたか？

2026 年 5 月の RFC 9989 が RFC 7489 を置き換えました。割合を指定する pct タグが廃止されて段階導入は t=y（テストモード）で行う形になり、存在しないサブドメイン向けの np タグが加わりました。組織ドメインの決め方も DNS ツリーウォークに変わっています。

RFC 9989 は RFC 7489 と RFC 9091 を廃止して DMARC の新しい本体仕様になりました。集約レポートは RFC 9990、失敗レポートは RFC 9991 に分かれています。 本ツールの判定に関わる変更は次のとおりです。

レコード先頭の v=DMARC1 は引き続き必須で、無い・先頭でない・値が違うレコードは丸ごと無視されます。 1 つの名前に DMARC レコードが 2 本以上あると、受信側はその名前のレコードをすべて破棄します。

Gmail・Yahoo の送信者ガイドラインでは何が必要ですか？

2024 年 2 月から、Gmail は全送信者に SPF か DKIM・TLS・正引きと逆引きの整合を求め、個人用 Gmail へ 1 日 5,000 通以上送る送信者には SPF と DKIM の両方・DMARC（p=none 可）・From とのアライメント・ワンクリック登録解除を求めています。Yahoo もほぼ同じ要件です。

Gmail の「大量送信者」は、個人用 Gmail アカウント宛てに 1 日 5,000 通以上送る送信者です。本ツールで確認できるのは SPF・DKIM・DMARC の DNS 側の設定までで、 アライメントや逆引き・TLS・登録解除ヘッダーは実際に送ったメールで確かめる必要があります。

CAA レコードでは何を指定しますか？

そのドメインの証明書を発行してよい認証局を指定します（RFC 8659）。issue で通常の証明書、issuewild でワイルドカード証明書の発行元を、iodef で違反の報告先を指定します。認証局は発行前に CAA を確認する義務があります。

; Let's Encrypt だけに発行を許可し、違反の報告先を指定する
example.co.jp.  CAA  0 issue "letsencrypt.org"
example.co.jp.  CAA  0 iodef "mailto:security@example.co.jp"

; ワイルドカード証明書は Google Trust Services のみ
example.co.jp.  CAA  0 issuewild "pki.goog"

認証局は、証明書の名前から親ドメインへと DNS を遡り、最初に見つかった CAA を適用します。どこにも無ければ、どの認証局でも発行できる状態です。 本ツールは入力したホスト名と登録ドメインの CAA を確認します。フラグの 128（critical）は「認証局が理解できないプロパティなら発行してはいけない」という意味です。

DNSSEC はどうやって確認していますか？

DNSSEC を検証する公開リゾルバ（Cloudflare の DNS over HTTPS）に問い合わせ、検証済みを示す AD フラグが立つかで「署名あり」を判定します。親ゾーンに DS が無いと確かめられたときだけ「無効」とし、どちらとも言えなければ判定不能とします。

DNSSEC は DNS の応答に署名を付け、親ゾーンの DS レコードを通じてルートまで信頼をつなぐ仕組みです（RFC 4033〜4035）。 ゾーンに署名していても、親に DS が登録されていなければ検証の連鎖はつながらず、DNSSEC は効きません。

ドメインの登録情報を返す RDAP にも DNSSEC の有無（secureDNS）を載せる欄がありますが、.jp は IANA の RDAP の一覧に登録されておらず、 JPRS は .jp の登録情報を WHOIS で提供しています。そのため .jp では RDAP から DNSSEC を確かめられません。 本ツールは RDAP を使わず、DNS そのものを検証リゾルバに問い合わせて判定するので、.jp でも他のドメインと同じ基準で確認できます。

よくある結果はどう直しますか？

SPF が無ければ送信に使うサービスの include を並べ、末尾を ~all か -all にした 1 本を TXT で置きます。DMARC は p=none と rua で始め、レポートで正当な送信元を確認してから p=quarantine、p=reject と段階的に強めます。

SPF は 1 つのドメインに 1 本だけです。送信サービスを追加するたびに新しい TXT を足すと 2 本以上になって無効になるので、 既存のレコードに include を足して 1 本にまとめます。include の値は各サービスの案内に従ってください。

; Google Workspace から送る場合（TXT レコード、名前はドメインそのもの）
example.co.jp.  TXT  "v=spf1 include:_spf.google.com ~all"

; ほかの送信サービスも使うなら、その案内にある include を同じ 1 本に並べる
example.co.jp.  TXT  "v=spf1 include:_spf.google.com include:（サービスの指定値） ~all"

; メールを一切送らないドメイン
example.co.jp.  TXT  "v=spf1 -all"

DMARC は、いきなり p=reject にすると、SPF・DKIM の設定が漏れている正当なメール（請求書の送信システム等）まで届かなくなります。rua に届く集約レポートで送信元を洗い出してから強めてください。強める前に t=y を付けると、1 段弱いポリシーで様子を見られます。

; 1. 監視から始める（レポートだけ受け取る）
_dmarc.example.co.jp.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.co.jp"

; 2. 正当な送信元が SPF / DKIM を通っているとレポートで確認できたら
_dmarc.example.co.jp.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.co.jp"

; 3. 最終形
_dmarc.example.co.jp.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.co.jp"

CAA が無い場合は、今使っている認証局の識別子で issue を 1 行置くのが最小の対策です。 証明書を自動更新しているなら、その発行元（Let's Encrypt など）を必ず含めてください。含め忘れると更新が止まります。