SPF/DKIM/DMARCレコードチェッカー
ドメインを入力するだけでSPF・DMARC・DKIMレコードをリアルタイムに検索し、なりすましメール対策の設定状況を診断します。
Tips
- SPF・DKIM・DMARCはこの順番で設定するのが定石です。まずSPFとDKIMを整備し、最後にDMARCで受信側への指示を明確化しましょう。
- DMARCは最初からp=rejectにせず、まずp=noneでレポートを収集し、正当な送信経路をすべて把握してから段階的に強化すると事故を防げます。
- SPFのinclude先が多いドメインは「10レイヤー・255文字制限」に達しDNSルックアップが失敗することがあるため、不要なincludeは定期的に整理しましょう。
- このツールは代表的なDKIMセレクターのみを試すため、「見つからない」と出ても実際に使われているセレクターが違うだけの場合があります。
- Gmail・Outlookなど主要な受信サーバーは2024年以降SPF・DKIM・DMARCの整備を大量送信者に義務化しているため、メルマガ配信を行うドメインは特に優先して確認しましょう。
よくある質問
必須ではありませんが、3つ揃えることで初めて「送信元の正当性を証明し（SPF/DKIM）、失敗時の扱いを受信側に指示できる（DMARC）」という一貫した防御になります。1つだけでは効果が限定的なため、順番に整備することをおすすめします。
そうとは限りません。DKIMのセレクター名は送信サービスごとに自由に決められるため、このツールが試す代表的な名称（default・google等）に一致しない場合は「見つからない」と表示されます。正確に確認するには、送信元メールサービスの管理画面かメールヘッダーのDKIM-Signature行を確認してください。
おすすめしません。正当な送信経路（メルマガ配信サービスや業務システムなど）を把握しきれていない状態でreject にすると、正規のメールまで拒否されるリスクがあります。まずp=noneで数週間レポートを収集し、問題がないことを確認してから段階的にquarantine・rejectへ強化するのが安全です。
最終的には-all（Fail、明確な拒否）が推奨されますが、SPFの設定に自信がない移行期には~all（SoftFail、疑わしいとして扱う）を使い、正当なメールが誤って弾かれないことを確認してから-allに切り替える方法が安全です。
いいえ。入力されたドメインへのDNS問い合わせはその場限りで行われ、取得したレコード情報をサーバー側に保存することはありません。
余談ですが ― なりすましメール対策の三本柱ができるまで
SPF・DKIM・DMARCはそれぞれ別の時期・別の背景で生まれた技術です。最初に登場したSPF（2003年ごろ）は「どのIPアドレスからならこのドメイン名でメールを送ってよいか」を宣言する仕組みで、迷惑メール業者が送信元アドレスを詐称する手口への対抗策として広まりました。しかしSPFはメール転送（フォワーディング）に弱く、転送されると送信元IPが変わってしまい認証が壊れるという弱点がありました。
その弱点を補ったのがDKIM（2007年ごろに標準化）です。SPFのようにIPアドレスで判断するのではなく、メール本文とヘッダーの一部に電子署名を付与し、受信側がDNSに公開された公開鍵で署名を検証する仕組みのため、転送されても署名さえ壊れなければ認証が通ります。
ただしSPFとDKIMはあくまで「認証に失敗した」ことを検出できるだけで、失敗したメールをどう扱うか（配送する・迷惑メール扱いにする・拒否する）は受信サーバー任せでした。この「受信側への指示」を統一する目的で2012年に策定されたのがDMARCです。DMARCはさらに、認証結果を送信ドメインの管理者にレポートとして送り返す仕組み（rua=）も備えており、自社ドメインが不正利用されていないかを継続的に監視できるようになりました。
2024年にGoogleとYahooが大量送信者（1日5,000通以上）向けにSPF・DKIM・DMARCの整備を事実上の必須要件としたことで、この三本柱は一部の大企業だけでなく、メルマガやシステム通知メールを送るあらゆる事業者にとって無視できない基礎知識になりました。