ドメインを入力すると、MX、SPF、DMARC、DKIM、BIMI、MTA-STS、TLS-RPT のレコードごとにカードが一枚。現状、なぜ重要か、直し方の三段構成で、DNS にそのまま貼れるレコード例も付きます。SPF ツリーは include を全部展開し、参照回数を上限 10 回と照らし合わせます。点数なし、登録なし。
ファイルはブラウザから送信されません — 処理はすべてローカルで行われます。
メールが届かない原因の多くは、わずかな設定ミスが起きやすい数本の 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 以外のあなたの情報はブラウザから出ません。結果はカードごとの信号と全体の信号で示します。緑はレコードが正しい、黄は送信はできるがリスクがある、赤は拒否されやすいか、なりすましに無防備という意味です。
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.<ドメイン> を取得し、サブドメインに独自のレコードがなければ 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 のセレクターは外側から列挙できません。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 を出力できるので、チケットにそのまま貼れます。
SPF ツリーを見てください。include、a、mx、ptr、exists、redirect は入れ子の include も含めて一回ずつ数えられ、上限は十回です。まず、もう送信に使っていないサービスの include を削ってください。古いメルマガツールや CRM が定番の原因です。それでも十回を超えるなら、送信サービスの一つを専用サブドメインに移し、そこに独自の SPF レコードを置きます。たとえばメルマガ配信なら news.example.com です。レコードを IP アドレスにフラット化してはいけません。プロバイダーは予告なく IP の範囲を変えるので、フラット化したレコードはそのとき静かに壊れます。
出発点としては十分、到達点としては不十分です。p=none では受信側はレポートを送ってくるだけで、認証に失敗したメールもそのまま配信します。つまり誰でもあなたのドメインを名乗って送信でき、ほとんどの受信側はそれを受け入れます。p=none の期間は rua= のレポートを読んで、まだ整合していない正当な送信元を洗い出し、その後 p=quarantine、最後に p=reject へ進んでください。BIMI のロゴ表示にも quarantine か reject が必要です。ページが p=none を「監視のみ」と表示するのは、まさにこのためです。
いいえ。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 の問い合わせはすべてそうです。ドメイン名は公開情報です。メールもアドレス帳もそれ以外も送られません。アクセス解析に記録されるのはチェックが実行されたことだけで、ドメインは記録しません。
Null MX を公開すべきです。優先度 0、宛先 . の MX レコードを一本だけ置きます（RFC 7505）。これで送信側は、このドメインはメールを受け取らないと分かり、A レコードに向かって何日も再送し続けずにすぐ諦めます。ページは Null MX を MX の欠落ではなく正しい設定として報告します。こうしたドメインでも v=spf1 -all と p=reject の DMARC レコードを置いておけば、誰もそのドメインを名乗って送信できなくなります。
メールヘッダーを貼り付けて経路を確認し、DKIM を検証 →
.eml ファイルを安全に開いて読む →
Outlook なしで .msg ファイルを開く →
TLS 証明書を読み解いて有効期限を確認 →