DMARC チェッカー は、ドメイン名を入れると、そのドメインのメール認証の設定(SPF、DKIM、DMARC)を診断するツールである。設定はすべて DNS に書かれているので、診断の中身は DNS を何十回か引いて、返ってきた文字列を読むことに尽きる。
ところが、このツールのサーバーは DNS を一度も引いていない。入力されたドメイン名を受け取ることもない。問い合わせは全部、利用者のブラウザから出ている。ブラウザの JavaScript には DNS を引く命令がないのに、である。
ブラウザには DNS を引く手段がない
DNS は、ドメイン名から IP アドレスやメールの設定などを引くための仕組みである。ふつうの問い合わせは、UDP という軽い通信方式で、DNS サーバーの 53 番ポートに小さなパケットを投げて行う。
Web ページの JavaScript が使える通信は、HTTP(fetch)、WebSocket、WebRTC あたりに限られている。任意の相手に UDP のパケットを投げる手段は、ブラウザには用意されていない。ブラウザ自身は裏で DNS を引いているが、その結果を JavaScript から受け取る窓口もない。
そこで使うのが DNS over HTTPS(DoH)である。DNS の問い合わせを HTTPS の要求に包んで送る方式で、RFC 8484 として標準化されている。HTTPS なら fetch で送れる。
JSON で答えてくれる公開 DNS
RFC 8484 の DoH は、DNS のパケットをそのまま HTTP の本文に入れてやり取りする。これをブラウザで扱うには、パケットを組み立てて分解するコードが要る。Google Public DNS と Cloudflare の DNS は、それとは別に、問い合わせを URL のパラメータで受け取り、答えを JSON で返す窓口も公開している(Google の説明、Cloudflare の説明)。DMARC チェッカーが使っているのはこちらである。
たとえば gmail.com の DMARC の設定は、次の URL で引ける。
https://dns.google/resolve?name=_dmarc.gmail.com&type=TXT返ってくる JSON から要る部分を抜き出すと、こうなる(2026年9月17日に取得)。
{
"Status": 0,
"Answer": [{
"name": "_dmarc.gmail.com.",
"type": 16,
"data": "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
}]
}
Status の 0 は「正常に答えた」、type の 16 は TXT
レコード(任意の文字列を置けるレコード)を表す。data
の中身が、gmail.com の管理者が DNS に置いた DMARC の設定そのものである。
別のサイトの API を、ブラウザから呼んでよいのか
ここで一つ引っかかる。dmarc.otasuke.app のページが、dns.google という別のサイトに要求を送り、その応答を読んでいる。ブラウザは本来、これを許さない。
ブラウザには、あるサイトのページが別のサイトの応答を読むことを原則として禁じる決まりがある。許されるのは、応答する側が「どのサイトから読まれてもよい」と明示したときだけで、この取り決めを
CORS(オリジン間リソース共有)と呼ぶ(MDN の解説)。明示の方法は、応答に Access-Control-Allow-Origin
というヘッダーを付けることである。
dns.google と cloudflare-dns.com は、JSON の応答にこのヘッダーを値
*(どこからでも可)で付けている。開発前の調査では、ほかの公開 DNS も試した。Quad9
は JSON の窓口を持たず、AdGuard と NextDNS は CORS
のヘッダーを返さなかった。ブラウザから直接使える候補は、この二つしか残らなかったことになる。
ページの側でも、行き先を絞っている。CSP(Content Security
Policy、ページが通信してよい相手をブラウザに伝えるヘッダー)で、DNS
の問い合わせ先として許しているのは https://dns.google と
https://cloudflare-dns.com の二つだけである。
一回の診断で、何回 DNS を引くのか
一つのドメインの診断で、問い合わせは数回では済まない。回数が膨らむ理由は、設定ごとに違う。
SPF(そのドメインを名乗ってメールを送ってよいサーバーの一覧)は、include:
で別のドメインの SPF を読み込める。メール配信サービスを使っていると、その先でさらに
include:
が続く。チェッカーはこれを一つずつ辿って中身を取りに行く。受信側が辿る回数には上限があり、RFC 7208
は DNS を引く仕組みの数を 10 までと定めている。チェッカーは辿りながらこの数を数え、10
を超えていれば失敗と判定する。
DMARC の設定は _dmarc.ドメイン名
に置かれる。サブドメインに設定がなければ、上位のドメインに遡って探す。2026年に DMARC
の仕様を改めた
RFC 9989
はこの遡り方を「DNS Tree Walk」として定め、問い合わせを最大 8
回に制限している。チェッカーも左のラベルを一つずつ外しながら、同じく最大 8 回まで引く。
いちばん回数を食うのが DKIM(送信時に付ける電子署名)である。DKIM の公開鍵は
セレクタ名._domainkey.ドメイン名
に置かれるが、セレクタ名は送信者が自由に決められ、DNS
に一覧を尋ねる方法もない。仕方がないので、よく使われる名前を片端から試す。固定の候補が
google、selector1、default など 15 個あり、SPF や MX(メールの受信サーバー)から SendGrid や
Mailchimp などの利用がわかれば、そのサービスが使うセレクタ名を足す。
これに MX、BIMI、MTA-STS、TLS-RPT、ネームサーバーの確認が加わる。同じ名前と種類の問い合わせは一度しか送らないようにしたうえで、一回の診断あたり 80 回を上限にしてある。SPF の入れ子が深すぎるなどして上限に届いたら、そこで打ち切り、「レコードが複雑なため、一部を確認できませんでした」と表示する。
問い合わせはまず Google に送る。5 秒以内に応答がないか、エラーが返ってきたら、同じ問い合わせを Cloudflare に送り直す。どちらにも届かなかったときは、ネットワークや DNS フィルタで DoH が遮断されている可能性がある、と画面に出す。送った問い合わせは、結果の末尾に「問い合わせログ」として一覧で残る。
「見つからない」と「設定がない」は違う
候補のセレクタ名をすべて試して DKIM の鍵が一つも見つからなくても、そのドメインが DKIM を設定していないとは言えない。
送信サービスが独自の名前を使っていれば、試した名前に当たらないだけで、鍵は別の場所にちゃんとある。だからチェッカーは、この場合を「失敗」ではなく「未確認」と表示し、自分宛てに送ったメールのヘッダーで
DKIM-Signature の s=
を確かめ、そのセレクタ名を入力するよう案内している。外から DNS
を引くだけの診断は、名前を知っているものしか確かめられない。
サーバーを持たないことで、手放したもの
入力したドメイン名が、このツールのサーバーに届くことはない。サーバーの仕事は、HTML と JavaScript のファイルを配ることだけである。
一方で、ドメイン名は Google と Cloudflare には届く。問い合わせの中身がドメイン名そのものだからで、そこでの扱いは両社のプライバシーポリシーに従う。「どこにも送らない」ツールではない。送る先を、利用者が名前を知っている公開 DNS に限っている、というのが正確なところである。
ブラウザから確かめられないこともある。MTA-STS(メールサーバー間の通信の暗号化を強制する仕組み、RFC 8461)は、DNS のレコードに加えて、そのドメインの Web サーバーに置いたポリシーファイルで設定する。チェッカーは DNS のレコードまでは読むが、ポリシーファイルは取りに行かず「未確認」とする。実際にメールを送るときに暗号化が使われているかどうかも、DNS には書かれていないので、同じく「未確認」になる。
冒頭で、サーバーは DNS を一度も引いていないと書いた。代わりに、利用者のブラウザが Google と Cloudflare に数十回の HTTPS 要求を送っている。どの名前を何回引いたかは問い合わせログに全部出るので、この記事の説明が本当かどうかは、画面で確かめられる。