メールがメールサーバーを見つける仕組み
送信者
you@gmail.com
MX検索
誰が受け取る?
メールサーバー
優先度10が最初
受信トレイ
配信完了
優先度の数値が小さいものが優先され、大きいものはバックアップ
メールのDNSレコード:MX、SPF、DKIM、DMARC
メールは、それぞれ異なる役割を持つ複数のDNSレコードに依存しています。MXレコードは、送信側のメールシステムに、そのドメイン宛ての受信メッセージの配送先を伝えます。SPFは、どの送信システムが許可されているかというポリシーをTXTデータとして公開します。DKIMは、DNSに公開された公開鍵を使い、受信側が暗号署名を検証できるようにします。DMARCは、アラインメントに失敗したメッセージを受信側がどう評価するか、またレポートをどこに送るかを指示します。これらの仕組みは互いに補い合います。MXレコードが1つ正しく設定されていても、送信メールが認証されるわけではなく、有効なSPFレコードがあっても、受信側の配送が設定されるわけではありません。
受信の配送経路はMXから始まる
送信側のメールサーバーは、受信者のドメインのMXレコードを問い合わせ、優先度の値が付いた1つ以上のメールエクスチェンジャーのホスト名を受け取ります。複数の宛先がある場合は、優先度の数字が小さいほうが優先されますが、配送システムが再試行や可用性のロジックを適用することもあります。次に、その宛先ホスト名に対しても、それぞれアドレス解決が必要です。ドメインにMXレコードがない場合、メールの動作がほかのDNSの規則にフォールバックすることもありますが、暗黙のフォールバックに頼るのは、意図した設定を公開するよりも、たいてい分かりにくくなります。MXの値は、メールプロバイダーの最新の設定手順と照合し、メールに使うルートドメインが正確であることを確認してください。
| レコード/仕組み | メールでの目的 |
|---|---|
| MX | 受信メールのエクスチェンジャーホストへの振り分け |
| TXTのSPF | 許可された送信元の記述 |
| TXTのDKIM公開鍵 | 署名ドメインの署名を受信側が検証するための鍵 |
| TXTのDMARC | 認証のアラインメントに関するポリシーとレポートの設定 |
| PTR | 送信インフラの健全性の観点で期待されることがある逆引き名 |
SPFは該当するドメインのTXTレコードとして公開され、接続してきた送信者に対して評価されます。参照回数の上限と構文の規則があるため、互いに独立した複数のSPF文字列を別々のTXTレコードにコピーすると、permerrorが発生することがあります。DKIMレコードは通常、送信側が指定するセレクター固有の名前の下に公開され、セレクターが欠けていると、署名を検証できなくなることがあります。DMARCは _dmarc の下にある既定の名前を使い、より厳しいポリシーを検討する前に、監視モードで始めることができます。値を自分で作り上げてはいけません。そのドメインの代理でメールを送信することを許可しているすべてのメールプラットフォームから入手してください。
メール認証にアラインメントが必要な理由
DMARCは、設定されたアラインメントのモードに従って、メッセージの表示上のFromドメインが、SPFまたはDKIMで認証されたドメインとアラインしているかを確認します。これにより、受信側は、ドメインが許可された形で使われているものと、単にそのドメインからだと名乗っているだけのメッセージとを区別しやすくなります。認証されたエンベロープ送信者が表示上のFromドメインとアラインしていなければ、SPFには合格してもDMARCには不合格になることがあります。また、公開された鍵が欠けている、あるいは誤っている場合は、DKIM署名が失敗することがあります。メールプラットフォームでは複数の送信サービスを使っていることが多いため、ポリシーを厳しくする前に、正規の送信元をすべて洗い出しておく必要があります。
- SPFを編集する前に、そのドメインのメールを送信しているシステムをすべて一覧にします。
- プロバイダーが発行したDKIMセレクターを公開し、セレクター名が正確であることを確認します。
- 監視の準備状況に見合ったポリシーで、DMARCのレポートを開始します。
- プロバイダーの移行後は、MXの優先度と、宛先のアドレス解決を確認します。
- 集計レポートを確認し、ポリシーを強制に切り替える前に、不明な送信元を調査します。
移行後にレコードを確認する
メールプロバイダーを移行するときは、古いDNS設定をエクスポートしてから、新しいMX、SPF、DKIM、DMARCのレコードを、新しいプロバイダーの設定チェックリストと照合します。プロバイダーによっては、メールのレコードに加えて、ドメイン確認用のTXTレコードが必要です。古い送信システムは、正規のトラフィックを送り続けている間だけ許可したままにし、不要になった許可は、監視したうえで慎重に削除してください。DNSのTTLによるキャッシュのため、すべての受信側が変更を同時に目にするわけではありません。公開されている応答を確認し、代表的な受信システムにテストメッセージを送りますが、配送の結果は、評判、内容、受信側のフィルタリングにも左右されることを忘れないでください。
DNSの検索で分かるのは、レコードが公開されて見えるかどうかです。それだけでは、メッセージが受信トレイに届くことの証明にはなりません。個々の仕組みについては、MXレコードのガイドと、SPF、DKIM、DMARCの解説をご覧ください。DNSチェッカーを使って特定の名前とタイプを確認し、そのうえで、管理されたテストメッセージを送り、プロバイダーのログを確認して検証します。チェックリストの中で配送経路と認証を分けておくと、メールの変更ははるかに安全になります。
メールのDNSを変更する前に棚卸しをする
多くの組織には、正規の送信元が複数あります。メールボックスのプロバイダー、マーケティングプラットフォーム、チケット管理システム、会計アプリケーション、監視サービスが、すべて同じドメインとして送信している場合もあります。ベンダーごとに、送信ドメイン、SPFの要件、DKIMセレクター、担当者を記載した棚卸し表を作成してください。各ベンダーが、表示上のFromドメインを使うのか、委任されたサブドメインを使うのかも確認します。この棚卸し表は、安全なDMARCポリシーの土台になります。レポートによって、メインのメール管理者が存在を知らなかったシステムが判明することが多いからです。ベンダーは、最新のドキュメントと実際のテストメッセージで検証し、不要になった送信元の削除は、そのトラフィックがもう必要ないとチームが確認してから行います。
ドメインの公開DNSアドレスを調べたい場合は、Domain IP Lookupツールをお試しください。
このテーマの無料ツール
関連記事
メールがメールサーバーを見つける仕組み
送信者
you@gmail.com
MX検索
誰が受け取る?
メールサーバー
優先度10が最初
受信トレイ
配信完了
優先度の数値が小さいものが優先され、大きいものはバックアップ
MXレコードの確認方法とメール配送のテスト
ドメインのMXレコードを確認し、優先度の値を理解し、メール交換サーバーのホストを名前解決して、よくあるメール配送の問題を調べます。
性質の異なる2つの場面
dig / nslookup
プロトコルを詳細に確認、スクリプト可、オフライン可
ウェブベースのツール
セットアップ不要、一括検索、共有可能
digとnslookup、ウェブ版DNSツールの使い分け
ターミナルのツールがなくなることはなく、ウェブ版ツールもそれを置き換えようとはしていません。両者は、まったく異なる場面に向いています。
適切なエクスポート形式の選び方
CSV
スプレッドシートでの分析、絞り込み、ピボットテーブル
JSON
スクリプトや自動差分パイプライン
一括DNS検索結果のエクスポートと分析
数千件のドメインを名前解決した後、本当に重要なのはエクスポートしたデータをどう使うかです。その段階の実践ガイドです。