📧 メール認証チェック
ドメインを入れるだけで MX・SPF・DMARC・MTA-STS・TLS-RPT を取得し、設定の妥当性を診断します。
完全無料
登録不要
サーバー処理
ログ・DB 保存なし
レート制限あり
5 言語対応
ダークモード
📚 メール認証の基本
• SPF: 「このドメインからメールを送信できる IP/ホスト」を TXT で宣言
• DKIM: メール本文にデジタル署名を付加して改竄を検出（セレクタが必要なため自動検出不可）
• DMARC: SPF/DKIM の結果に対するポリシー宣言（none / quarantine / reject）
• MTA-STS: 受信側が「TLS 必須」を表明する仕組み
• TLS-RPT: TLS 配送失敗のレポート受信先
📖 この診断で分かること
この診断は DNS だけを見て、MX・SPF・DMARC・MTA-STS / TLS-RPT の設定状況を確認します。DKIM は含まれません — DKIM の公開鍵はセレクタ名を知らないと引けず、セレクタは DNS からは列挙できないためです。またここが全部緑でもメールが受信箱に届くとは限りません。到達率を決めているのは主に送信 IP とドメインの評判で、認証設定はその前提条件にすぎません。
| 判定項目 | 何を見ているか | 引っかかったときの対処 |
|---|---|---|
| SPF が pass でも差出人は偽装できる | SPF が検証するのは封筒の送信者（Return-Path）で、受信者に表示される From: ヘッダーは一切見ていません。攻撃者は自分が管理するドメインで SPF を正しく設定したうえで、From: だけをあなたの会社名にできます。SPF 単独では、なりすましを止められないということです。 |
この穴を塞ぐのが DMARC の アライメントで、From: のドメインと SPF / DKIM が通ったドメインが一致することを要求します。SaaS 経由で送っている場合、既定の Return-Path は業者のドメインなのでアライメントが取れません。各サービスの「カスタム Return-Path」「送信ドメイン認証」の設定で、bounce.example.com のような自ドメインのサブドメインに変更してください。 |
| DMARC が p=none のまま | p=none は「認証に失敗しても何もしないでください」という宣言です。設定してある、という事実だけがあって、なりすましは 1 通も止まっていません。レコードが存在するので診断ツールでは緑になり、対策済みだと誤解されやすい状態です。 |
rua=mailto:… で集約レポートを受け取り、2〜4 週間かけて正規の送信元を全部洗い出します。マーケティングツール、請求システム、社内の古いスクリプトなど、把握していない送信元が必ず出てきます。すべて認証を通したうえで p=quarantine; pct=10 から始め、段階的に 100 へ、最後に p=reject にします。 |
| 転送されると SPF が必ず壊れる | メーリングリストや自動転送を経由すると、送信元 IP が転送サーバーのものに変わるため SPF は必ず fail します。これは設定ミスではなく仕組み上の性質です。DKIM は本文とヘッダーの署名なので、転送側が書き換えなければそのまま残ります。 | DKIM を必ず設定してください。DMARC は SPF と DKIM のどちらか一方が通ればよいので、DKIM があれば転送されても認証が維持されます。SPF だけで p=reject に上げると、転送されたメールが一斉に弾かれます。件名に接頭辞を付けるタイプのメーリングリストは DKIM も壊すため、その場合は ARC に対応した受信側に頼るしかありません。 |
メールを受け取らない「送信専用ドメイン」でも設定は必要です。MX を空にするのではなく Null MX（0 .、RFC 7505）を置き、v=spf1 -all と p=reject を宣言しておくと、そのドメインを騙る迷惑メールを明確に拒否できます。もう一つ実務で嵌まりやすいのが送信サービス側の認証はドメイン名の完全一致で扱われる点で、example.com を認証しても mail.example.com からの送信は別扱いとして弾かれることがあります。当サイトも実際にこれで送信が止まり、親ドメインの差出人に統一して解決しました。