# Email DNS Check > ドメインを入れるだけで SPF・DKIM・DMARC・MX・BIMI・MTA-STS をブラウザから確認。SPF の 10 回制限をツリーで表示し、直し方も記録例つき。点数は出しません。 - URL: https://bytescope.dev/ja/email-dns-check/ - Locale: ja · Also: [en](https://bytescope.dev/en/email-dns-check.md) · [zh-Hant](https://bytescope.dev/zh-Hant/email-dns-check.md) - Runs: ファイルはブラウザから送信されません — 処理はすべてローカルで行われます。 - Requires: Any modern browser (Chrome, Edge, Firefox, Safari), desktop and mobile. - Updated: 2026-09-08 ## What it does メールが届かない原因の多くは、わずかな設定ミスが起きやすい数本の DNS レコードに行き着きます。気づかないうちに参照回数の上限を超えた SPF、何年も `p=none` のままの DMARC、失効した鍵や短すぎる鍵の DKIM。この DMARC チェック、SPF レコード確認、DKIM レコード確認ツールは、それらのレコードをブラウザから直接読みます。ドメインを入力してください。URL やメールアドレスをそのまま貼っても、ページがドメインを取り出し、国際化ドメインは punycode に変換して両方の表記を見せます。使っている DKIM セレクターがあれば、それも入力できます。ページはレコード名、`example.com`、`_dmarc.example.com`、`selector._domainkey.example.com` などを Cloudflare の公開 DNS-over-HTTPS サービスに問い合わせ、失敗したら Google に切り替えます。そのサービスには名前とあなたの IP アドレスが見えます。DNS リゾルバーとはそういうものです。メールは一通も送らず、IP 以外のあなたの情報はブラウザから出ません。結果はカードごとの信号と全体の信号で示します。緑はレコードが正しい、黄は送信はできるがリスクがある、赤は拒否されやすいか、なりすましに無防備という意味です。 ### SPF の 10 回制限を、ツリーで説明する RFC 7208 は、SPF の評価一回につき DNS を参照する機構を最大十個までと定めています。`include`、`a`、`mx`、`ptr`、`exists`、`redirect` はすべて数えられ、入れ子の include も加算されます。超えると受信側は `permerror` を返し、多くは SPF がないのと同じ扱いになります。ページは `include:` と `redirect=` を再帰的にツリーに展開し、各ノードに参照回数の印を付けるので、どの include が一番高くつくかが見えます。`a`、`mx`、`ptr`、`exists` は上限に数えますが解決はしません。その参照先が回数を変えることはないからです。参照先にレコードがない include は void lookup として数え、こちらの上限は二回です。ほかにも、`v=spf1` が複数ある（permerror）、`+all` や `?all`（誰でも送れてしまう）、非推奨の `ptr`、構文エラー、include のループを指摘します。ループとみなすのは、自分の祖先の経路に同じドメインが現れる場合だけです。二つの枝から同じ include を参照するのは正当で、受信側と同じく二回として数えます。上限を超えているときの対処は、もう使っていないサービスの include を外すか、送信サービスを専用のサブドメインに移すことです。SPF フラット化、つまり include を今日解決した IP アドレスに置き換えることは、意図的に勧めません。それらのアドレスは予告なく変わり、メールプロバイダーが IP の範囲を変えた日にフラット化したレコードは壊れるからです。 ### DMARC：p=none から、本当に守ってくれるポリシーへ ページは `_dmarc.<ドメイン>` を取得し、サブドメインに独自のレコードがなければ RFC 7489 の定めどおり組織ドメインに戻って探します。組織ドメインの判定には Public Suffix List を使います。報告するのはポリシー（`p=`）、サブドメインのポリシー（`sp=`）、`pct=`、整合モードの `adkim=` と `aspf=`、レポート送付先の `rua=` と `ruf=` です。`p=none` は「監視のみ」と印を付けます。受信側はレポートを送るだけで何もしないので、ドメインはまだなりすまされ放題です。`pct` が 100 未満なら、失敗したメールの一部にしか対処されません。`rua=` が別ドメインのメールボックスを指しているときは、承認レコード `<ドメイン>._report._dmarc.<レポート先ドメイン>` を探し、なければレポートは送られないと警告します。勧める道筋は、メールを壊さない順番です。`p=none; rua=mailto:…` から始め、正当な送信元がすべて整合するまでレポートを読み、それから `quarantine`、最後に `reject` へ進みます。 ### DKIM、MX、BIMI、MTA-STS、TLS-RPT DKIM のセレクターは外側から列挙できません。DNS には `*._domainkey` の下にある名前を一覧する手段がないからです。そのためページは、入力されたセレクターに加え、よく使われる名前の一覧（`google`、`selector1`、`selector2`、`k1`、`s1`、`s2`、`default`、`dkim`、`mail` など）を試します。「見つからない」はこれらの名前の下に見つからなかったという意味で、DKIM が未設定という意味では決してありません。見つかった鍵は、長さ（RSA 1024 ビット未満は赤、1024 は黄）、`p=` が空（鍵の失効）、`t=y` のテストモード、構文を確認します。MX は優先度順にアドレス付きで並べ、MX がない場合と MX が CNAME を指している場合は指摘しますが、Null MX（`0 .`、RFC 7505）は「このドメインはメールを受け取らない」という正しい宣言として扱い、エラーにはしません。BIMI（`default._bimi`）は形式を確認し、`l=` のロゴと `a=` の証明書の URL を表示しますが、ロゴ自体は取得しません。カードでは、BIMI は DMARC が `quarantine` か `reject` のときにしか効かないことも注記します。MTA-STS（RFC 8461）と TLS-RPT（RFC 8460）は DNS の層だけを確認します。ブラウザは CORS のため `https://mta-sts.<ドメイン>/.well-known/mta-sts.txt` を取得できないので、ポリシーの URL はリンクとして表示し、あなた自身が開く形です。 ### 緑の信号が意味すること、意味しないこと 表示されるレコードは、Cloudflare または Google のリゾルバーが今この瞬間に見ているものです。数分前に変えたレコードは TTL のあいだキャッシュに残っていることがあるので、変更が失敗したと決めつけず、TTL が切れてから確認し直してください。緑はレコードが正しく設定されているという意味で、メールが受信トレイに届くという意味ではありません。それを決めるのは送信者の評判、本文、送信量で、どれも DNS からは見えません。同じ理由で数値のスコアは出しません。87 点のような数字は精密そうに見えて何も意味しないからです。特定のメールが弾かれた、迷惑メールに入ったという場合は、そのヘッダーをメールヘッダー解析のページで開いてください。経路をたどり DKIM を検証し、概要カードから送信ドメイン付きでこのページに戻ってこられます。どちらのページも Markdown レポートと JSON を出力できるので、チケットにそのまま貼れます。 ## Limits Does not send test mail, flatten SPF or fetch MTA-STS policy files and BIMI logos; it checks the DNS records only. ## FAQ ### SPF の DNS 参照が 10 回を超えています。どう直せばいいですか？ SPF ツリーを見てください。`include`、`a`、`mx`、`ptr`、`exists`、`redirect` は入れ子の include も含めて一回ずつ数えられ、上限は十回です。まず、もう送信に使っていないサービスの include を削ってください。古いメルマガツールや CRM が定番の原因です。それでも十回を超えるなら、送信サービスの一つを専用サブドメインに移し、そこに独自の SPF レコードを置きます。たとえばメルマガ配信なら `news.example.com` です。レコードを IP アドレスにフラット化してはいけません。プロバイダーは予告なく IP の範囲を変えるので、フラット化したレコードはそのとき静かに壊れます。 ### DMARC は p=none で十分ですか？ 出発点としては十分、到達点としては不十分です。`p=none` では受信側はレポートを送ってくるだけで、認証に失敗したメールもそのまま配信します。つまり誰でもあなたのドメインを名乗って送信でき、ほとんどの受信側はそれを受け入れます。`p=none` の期間は `rua=` のレポートを読んで、まだ整合していない正当な送信元を洗い出し、その後 `p=quarantine`、最後に `p=reject` へ進んでください。BIMI のロゴ表示にも `quarantine` か `reject` が必要です。ページが `p=none` を「監視のみ」と表示するのは、まさにこのためです。 ### DKIM チェックが「見つからない」と出ます。DKIM が未設定ということですか？ いいえ。DKIM レコードは `<セレクター>._domainkey.<ドメイン>` にあり、DNS にはセレクターを一覧する手段がないので、ページは入力された名前とよく使われる名前を試すことしかできません。プロバイダーのセレクターがその一覧になければ、入力してください。プロバイダーの DKIM 設定画面か、あなたが送ったメールの `DKIM-Signature` ヘッダーの `s=` タグに書いてあり、メールヘッダー解析のページでも表示されます。「見つからない」は試した名前の下になかったという意味で、それ以上ではありません。 ### レコードを変更したばかりなのに、まだ古い内容が表示されます。 DNS の応答はレコードの TTL のあいだキャッシュされ、ページが読むのは Cloudflare のリゾルバー（失敗時は Google）が今持っている内容です。数分前に編集したレコードは TTL が切れるまで、多くは一時間、ときには一日、キャッシュから返され続けます。TTL が過ぎてから確認し直してください。 ### 全部緑なのに、メールがまだ迷惑メールに入るのはなぜ？ 正しいレコードは必要条件であって十分条件ではないからです。受信側はドメインと送信 IP の評判、本文の内容、受信者の反応、送信量の急な変化も重く見ます。どれも DNS からは見えず、だからこそこのページは配信スコアを出しません。迷惑メールに入った具体的な一通から始めてください。そのヘッダーをメールヘッダー解析のページで開けば、受信サーバーが実際にどの検査を行ったか、DKIM が `From` ドメインと整合していたか、迷惑メールフィルターのヘッダーに何が書かれているかが分かります。 ### なぜ点数が出ないのですか？ 数字は見かけだけの精密さになるからです。検査の重みはドメインによって違います。MX がないのはメールを受け取るドメインには致命的ですが、受け取らないドメインには正しい状態ですし、`p=none` は DMARC を導入し始めたドメインには妥当な第一歩でも、何年も送信してきたドメインには穴です。代わりにページはカードごとの信号と全体の信号を出します。緑、黄（送れるがリスクあり）、赤（拒否されやすい、またはなりすましに無防備）。そのうえで各カードが何を変えるべきかを示します。 ### チェックを実行すると、ブラウザから何が出ていきますか？ 入力したドメインのレコード名、つまりドメイン自体と `_dmarc.`、`_domainkey.`、`_bimi.`、`_mta-sts.`、`_smtp._tls.` の名前に対する DNS 問い合わせだけで、送り先は Cloudflare の DNS-over-HTTPS サービス、Cloudflare が失敗したときは Google です。これらのサービスには名前とあなたの IP アドレスが見えます。DNS の問い合わせはすべてそうです。ドメイン名は公開情報です。メールもアドレス帳もそれ以外も送られません。アクセス解析に記録されるのはチェックが実行されたことだけで、ドメインは記録しません。 ### メールを一切受け取らないドメインにも MX レコードは必要ですか？ Null MX を公開すべきです。優先度 0、宛先 `.` の MX レコードを一本だけ置きます（RFC 7505）。これで送信側は、このドメインはメールを受け取らないと分かり、A レコードに向かって何日も再送し続けずにすぐ諦めます。ページは Null MX を MX の欠落ではなく正しい設定として報告します。こうしたドメインでも `v=spf1 -all` と `p=reject` の DMARC レコードを置いておけば、誰もそのドメインを名乗って送信できなくなります。 ## Related tools - [Email Header Analyzer](https://bytescope.dev/ja/email-header-analyzer.md) — メールヘッダーを貼り付けて経路を確認し、DKIM を検証 → - [EML Viewer](https://bytescope.dev/ja/eml-viewer.md) — .eml ファイルを安全に開いて読む → - [MSG Viewer](https://bytescope.dev/ja/msg-viewer.md) — Outlook なしで .msg ファイルを開く → - [Certificate Decoder](https://bytescope.dev/ja/certificate-decoder.md) — TLS 証明書を読み解いて有効期限を確認 →