SPF・DMARC チェッカー

ドメインを入力して診断を押してください。SPF レコードを読み取って include と redirect をすべて展開し、_dmarc.ドメイン の DMARC レコードを読み、よく使われる DKIM selector を探索し、MX ホストを名前解決します。レコードごとに判定が出て、MTA-STS・TLS-RPT・BIMI も同じ実行で確認します。

RFC 7208 は評価中に DNS 問い合わせを伴う項目を最大 10 個までと定めています（include・a・mx・ptr・exists と redirect 修飾子）。include は再帰的に数えられるため、事業者をいくつか使うだけで合計が静かに 10 を超えます。評価は最初に一致したメカニズムで止まるので、この合計は 1 通ごとの判定ではなく最悪値です。10 回目より先に到達する送信経路は恒久的エラーとなり DMARC 上は SPF 失敗として扱われますが、より早く一致する送信元はそのまま通ります。超過したレコードが一見まったく正常に見えるのに一部の送信元だけで失敗するのは、このためです。

まず、もう使っていない事業者の include を削除します。たいていはこれで足ります。事業者が安定したアドレス範囲を公開しているなら、include を ip4・ip6 メカニズムに置き換えます。これらは枠を消費しません。一部のメールを独自の SPF レコードを持つサブドメインへ移せば、枠を 2 つに分けられます。include をアドレスに展開（フラット化）する方法もありますが、事業者が予告なく範囲を変えるため保守が必要です。

-all はハードフェイルで、一覧にないサーバーは未認可とみなされ、受信側は拒否できます。~all はソフトフェイルで、未認可ではあるものの配送はしてマークを付けます。取りこぼしの送信元を洗い出している段階では ~all が妥当で、最終的に目指すのは -all です。?all は中立で何も主張しないため、これで終わるレコードはレコードがないのとほとんど変わりません。

DNS にはドメインが公開している selector を一覧する手段がないからです。DKIM 鍵は selector._domainkey.ドメイン に置かれるため、selector 名が分からなければ照会先が決まりません。本ツールは主要事業者が使う名前を探索しますが、独自のもの（Amazon SES が発行するランダムな selector を含む）は指定が必要です。そのドメインから届いたメールの DKIM-Signature ヘッダーにある s= タグから取得し、selector 欄に追加してください。

p=none は監視のみで、受信側は何もせずレポートだけを送ります。始点としては正しいものの何も保護しないため、目的地ではなく通過点です。p=quarantine は失敗したメールを疑わしいものとして扱わせ、通常は迷惑メール扱いになります。p=reject は拒否します。一般的な流れは、レポートが安定するまで none、その後 quarantine、最後に reject です。

もっとも多い原因は認可レコードの欠落です。rua の宛先が対象ドメインと別のドメイン（監視ベンダーなど）にある場合、その側が 自分のドメイン._report._dmarc.相手のドメイン にレコードを公開して受け入れを表明する必要があります。これがないと、仕様に沿ったレポート送信側は何も告げずにレポートを破棄するため、「誰も送っていない」状態と区別がつきません。本ツールは外部宛先ごとにこのレコードを確認します。

いいえ。ウェブページから SMTP 接続を開くことはできず、ブラウザーからポート 25 には到達できません。そのため MX セクションは設定のみを確認します。レコードの存在と優先度を読み、各宛先を名前解決し、典型的な不備（アドレスレコードのない宛先、ホスト名であるべき箇所の CNAME、裸の IP アドレス）を指摘します。相手側のサーバーが応答するかどうかは、SMTP を話せるツールが必要です。

SPF が通ることと DMARC が通ることは別です。DMARC はアライメントも要求します。SPF に通ったドメインが、受信者に見える From アドレスと一致していなければなりません。事業者経由で送ると、SPF は事業者自身のドメインで通る一方 From ヘッダーは自社ドメイン、という形になりアライメントが不成立になりがちです。自社ドメインで DKIM 署名すれば解決します。DKIM のアライメントは独立に判定されるためです。レピュテーションや本文、リスト品質は認証の外側の話です。

MTA-STS は、自ドメイン宛の配送で TLS を必須とするよう送信サーバーに指示し、日和見的 TLS が残すダウングレード攻撃の余地を塞ぎます。TLS-RPT はそれが失敗したときの報告を求めるものです。BIMI は表示に対応した受信側向けにロゴを公開する仕組みで、DMARC が強制ポリシーであることが前提です。3 つとも任意で、公開していなくても何ら問題ありません。

できます。SPF と DKIM は入力された名前をそのまま照会するため、メールを送るサブドメインは確認する価値があります。DMARC は異なり、サブドメインにレコードがなければ受信側は組織ドメインのレコードへフォールバックし、その sp タグを適用します。本ツールは入力された名前だけを読むため、サブドメインで DMARC が空という結果は、実際には親ドメインのポリシーが効いていることを意味する場合が多いです。

答える問いが違います。DNS ルックアップツールはレコードそのものを見せるもので、任意のタイプ・任意のリゾルバーに対応し、委任の追跡もできます。こちらは特定のレコード群を評価します。SPF は 1 行を表示するのではなくチェーンを展開して上限に照らし、DMARC と DKIM はそれぞれの規則に沿って読み解きます。何が公開されているかを見たいなら前者、正しいかどうかを知りたいなら後者です。