この診断の仕組み
診断する 10 項目
メール認証は、なりすまし対策の SPF・DKIM・DMARC、受信時の暗号化を求める MTA-STS、その失敗を知らせる TLS-RPT、ロゴを表示する BIMI の 6 項目です。DNS 基盤は、メールの受け口である MX、ネームサーバー(NS)の冗長性、応答の改ざんを防ぐ DNSSEC、証明書を発行できる認証局を絞る CAA の 4 項目です。
判定の読み方
項目ごとに「良好」「注意」「問題」「未設定」「確認できず」のどれかを表示します。「問題」は受信側や認証局が設定を無効として扱う、またはメールや名前解決が失敗する状態、「注意」は動いてはいるものの保護が弱いか将来壊れやすい状態です。「未設定」は任意の仕組みを使っていないことを示し、それだけでは減点しません。どの項目が重要かはドメインの使い方で変わるため、総合点は出していません。
DNS はブラウザから直接問い合わせる
DNS レコードは、ブラウザから Google Public DNS と Cloudflare DNS の DNS over HTTPS(HTTPS 経由で DNS を引く公開 API)に直接問い合わせます。Google が応答しないときは Cloudflare に切り替えます。SPF・DKIM・DMARC の判定は、姉妹ツールの DMARC チェッカーと同じ基準です。送った問い合わせは、結果の末尾の「問い合わせログ」で確認できます。
MTA-STS のポリシーファイルだけはサーバー経由で取得する
MTA-STS のポリシーファイル(https://mta-sts.ドメイン/.well-known/mta-sts.txt)は、ブラウザのセキュリティ制限(CORS)のため直接読めません。そこでこのファイルに限り、当サイトのサーバー(Cloudflare Workers)が取得してブラウザに返します。サーバーに送るのはドメイン名だけで、取得先はこの URL に固定し、リダイレクトは追わず、64 KiB と 10 秒で打ち切ります。MTA-STS の TXT レコードがないドメインでは、サーバーへの通信は発生しません。
DNSSEC は公開 DNS の検証結果で判定する
DS と DNSKEY を問い合わせ、公開 DNS が付ける検証済みの印(AD フラグ)を見ます。検証に失敗したドメインには公開 DNS がサーバーエラー(SERVFAIL)を返すため、検証を止めた問い合わせ(CD フラグ付き)で応答が得られるかを比べ、「設定がない」のか「検証に失敗している」のかを区別します。署名を自前で検証しているわけではありません。
MX はホスト名の解決までを確認する
MX のホスト名が IP アドレス(A / AAAA)まで解決できるか、Null MX(RFC 7505 の「メールを受け取らない」宣言)か、CNAME を指していないかを確認します。メールサーバーへの SMTP 接続は行わないため、サーバーが実際にメールを受け付けるかはわかりません。
修正例の作り方
「問題」と「注意」の項目には、DNS の管理画面に入力する形(ホスト名・種別・値)で修正例を示し、それぞれコピーできるようにしています。既存のレコードがある場合は、そのタグや include を残したまま、問題の箇所だけを直した値を作ります。レポートの送り先や認証局のように診断からは決められない値は仮の値を入れ、置き換える箇所を例の下に書いています。
この診断の限界
診断できるのは、DNS に公開されている設定と MTA-STS のポリシーファイルだけです。実際に送ったメールが認証に通るか、受信側がどう扱うか、証明書が正しく発行されるかは、サーバーの構成や受信側・認証局の判断で変わります。設定を変えた直後は、DNS のキャッシュが切れるまで古い結果が出ることもあります。
よくある質問
- 入力したドメインは保存されますか
- 保存しません。DNS の問い合わせはブラウザから Google Public DNS と Cloudflare DNS に直接送ります。例外は MTA-STS のポリシーファイルで、MTA-STS の TXT レコードがあるドメインに限り、ファイルを取得するためにドメイン名を当サイトのサーバーへ送ります。取得したファイルも保存しません。詳しくはプライバシーポリシーをご覧ください。
- 総合点が表示されないのはなぜですか
- どの項目がどれだけ重要かは、ドメインの使い方で変わるからです。たとえばメールを送らないドメインでは DKIM がなくても問題になりませんが、点数にするとほかのドメインと同じだけ減点されてしまいます。そこで項目ごとに判定し、直すべき項目には修正例を付けています。
- 修正例のレコードをそのまま登録してよいですか
- 一部の値は仮のものです。DMARC や TLS-RPT のレポート送り先、CAA の認証局、SPF の include などは、例の下の説明に置き換える箇所を書いています。登録する前に、送信サービスや DNS 事業者の案内とあわせて確認してください。
- MX が「良好」なのにメールが届きません
- この診断はメールサーバーに SMTP で接続していません。MX のホスト名が IP アドレスまで解決できることを確かめているだけなので、サーバーの停止、ファイアウォール、受信側の迷惑メール判定などによる不達は検出できません。
- DNSSEC が「未設定」なのは問題ですか
- DNSSEC は任意の仕組みで、国内でも導入していないドメインが多数あります。未設定よりも深刻なのは、レジストラに登録した DS とゾーンの鍵が食い違って検証に失敗している状態です。この場合、検証するリゾルバを使う利用者からはドメインの名前が引けなくなるため「問題」と判定します。
- CAA を設定すると証明書の更新に失敗しませんか
- CDN やホスティングサービスが証明書を自動で発行している場合、その発行元の認証局を CAA に含めないと更新に失敗します。設定する前に、いま使っている証明書の発行元をブラウザの証明書表示などで確認してください。
- DKIM が「確認できず」になります
- DKIM の公開鍵はセレクタ名がわからないと問い合わせできません。よく使われるセレクタで見つからなかった場合は、自分宛に送ったメールのヘッダで DKIM-Signature の s= を確認し、「詳細設定」から指定してください。
- サブドメインも診断できますか
- できます。SPF、DKIM、MX、MTA-STS、TLS-RPT、BIMI は入力したサブドメイン自身を確認します。DMARC と CAA はサブドメインになければ上位のドメインをたどり、NS と DNSSEC はサブドメインを含むゾーン(たとえば example.jp)を確認します。
- DMARC チェッカーとは何が違いますか
- DMARC チェッカーは SPF / DKIM / DMARC に絞り、SPF の参照先の展開や Gmail・Outlook の送信者要件との照合まで詳しく表示します。ドメイン健康診断は、MTA-STS などの受信側の設定と DNS 基盤まで対象を広げ、項目ごとの判定と修正例を示します。
- 結果を共有できますか
- 診断後の URL(?domain=...)を共有すると、開いた人のブラウザで改めて診断します。結果そのものは保存していません。
判定基準と出典
判定は次の仕様に基づきます。結果の各項目の末尾からも参照できます。