mark_email_read メールDNSチェッカー(SPF、DKIM、DMARC) star

メール認証の仕組み

3つのDNSレコードが連携することで、あなたのドメインになりすました偽のメールが送信されるのを防ぎます。SPF(Sender Policy Framework)は、そのドメインの代わりにメールを送信することが明示的に許可されているサーバーの一覧をDNSに公開します — 受信側のサーバーは、接続してきたIPアドレスをこの一覧と照合します。DKIM(DomainKeys Identified Mail)は、送信するすべてのメッセージに暗号署名を付加します。受信側のサーバーはDNSから公開鍵を取得し、メッセージが送信中に改ざんされていないことを検証します — これはSPFだけでは検出できないことです。DMARC(Domain-based Message Authentication, Reporting and Conformance)はこの2つを結び付けます:SPFやDKIMが失敗した場合に受信サーバーが何をすべきか(何もしない、迷惑メールに振り分ける、完全に拒否する)を指示し、さらに集計レポートを要求することで、なりすまし犯を含め、実際に誰があなたのドメインを名乗ってメールを送っているのかを把握できるようにします。

具体例:これら3つのレコードのいずれもない場合、攻撃者は[email protected]から送られたように見えるメールを送信でき、ほとんどのメールサーバーは受信者に何の警告も表示せずそのまま受信トレイに配信してしまいます。上記のチェックツールにドメインを入力すると、MX、SPF、DKIM(一般的なセレクターを自動的に試行)、DMARCをDNS over HTTPS経由で照会し、何が欠けているのかを正確に示します:SPFレコードが全く存在しない、p=noneで止まったままのDMARCポリシー(監視のみで実質的な保護効果はゼロ)、競合する2つのSPFレコード(検証を完全に破壊する規格違反)、SPF文字列の末尾にallメカニズムが欠けている、といった具合です。

知っておくべきこと

ブランドの評判や受信トレイへの到達率(デリバラビリティ)を気にする人にとって、この3つのレコードすべてを正しく設定することは任意ではありません — SPF、DKIM、DMARCのいずれかに不備があるドメインは、なりすましの標的になりやすいだけでなく、Gmail、Yahoo、Outlookのような大手プロバイダーが送信者を信頼する前に完全な認証をますます求めるようになっているため、正規のメール自体が迷惑メールに振り分けられるリスクも高くなります。順序を守れば導入は安全です:まずSPFを公開し、次にメールプロバイダー経由でDKIM署名を追加し、その後p=noneから始めるDMARCを追加します — こうすることで実際のメールを危険にさらすことなく集計レポートを確認でき、マーケティングツールやCRM、チケットシステムといったすべての正規の送信元が確認・整合されてから初めて、隔離(quarantine)や拒否(reject)へ移行します。

• 1つのドメインが持てるSPF TXTレコードは1つだけです — 複数のサービス(Google Workspace、マーケティングプラットフォーム、CRMなど)を使っている場合は、別々のレコードを公開するのではなく、それぞれのincludeメカニズムを1つの文字列にまとめてください。
• DKIMセレクターはプロバイダーごとに異なります:Google Workspaceは多くの場合「google」の下に公開し、Microsoft 365は「selector1」または「selector2」を使います — 自動チェックで何も見つからない場合は、プロバイダーの正確なセレクター名を調べて手動で入力してください。
• このツールはDNS設定のみを監査します。ブラックリストの状態やメッセージ内容のスキャンは行いません — これらは、正しく設定されたDNSという土台の上に成り立つ別のレイヤーのメール到達性の話です。