ホーム›ガイド›メールセキュリティ
メールセキュリティ · 理解する
はい。メールシステムを変えずに、Microsoft 365、Google Workspace、Exchange、その他のサーバーの保護を強化できます。ドメインのMXがゲートウェイを指し、ゲートウェイがメールを分析してから現在のサーバーに配信します。ユーザーは自分のメールボックスをそのまま使えます。DNSの管理担当者とメールシステムの管理者が、それぞれ1つずつ設定を行います。
メールシステムの変更と保護の変更は、別のプロジェクトです。前者では、メールボックス、履歴、予定表、スマートフォン上のアカウントを移します。後者が変えるのは、受信メールの経路だけです。
この経路は、MXという1つのDNSレコードで決まります。MXは、自社ドメイン宛てのメールをどこに配信するかを送信側サーバーに示します。MXがゲートウェイを指していれば、ゲートウェイが受信し、分析したうえで、メールボックスのサーバーに渡します。これは次のいずれにも当てはまります。
このガイドは、メールボックスをそのまま使うケースを扱います。サーバーも変更する場合は、Microsoft 365からの移行とGoogle Workspaceからの移行のガイドをご覧ください。
| 設定 | 場所 | 担当者 |
|---|---|---|
| ドメインのMXレコード | レジストラやDNSホスティング事業者のDNSゾーン | DNSの管理担当者、またはその委任を受けた委託先 |
| メールシステムへのゲートウェイの登録 | Microsoft 365、Google Workspace、またはサーバーの管理コンソール | メールシステムの管理者 |
| SPF、DKIM、DMARC | DNSゾーン | DNSの管理担当者（ドメイン名義で送信するサーバーを洗い出した後） |
| ドメインと配信先サーバー | ゲートウェイ | 設定を準備するゲートウェイの提供事業者 |
サードパーティサービスによるフィルタリングに関するMicrosoftのドキュメントは明確です。ドメインのMXはそのサービスを指し、サービスがその後Exchange Onlineに配信します。Microsoftは、サービスを経由せずに届いたメールを拒否できる「パートナー」型の受信コネクターを推奨しています。また、独自の分析がゲートウェイのアドレスではなく本当の送信者を評価するよう、コネクターの拡張フィルタリングを有効にすることも推奨しています。サードパーティサービスのアドレスについて単にフィルタリングをバイパスすることは推奨していません。
Googleは「受信メールゲートウェイ」を説明しています。MXがゲートウェイを指し、管理者がコンソールでそのIPアドレスを登録します。Gmailはこれを利用して、ヘッダーから送信者の実際のアドレスを特定します。SPFとGmailのスパム評価は、このアドレスに依存します。ゲートウェイを経由しないメールを拒否することもできます。Googleは、登録されたゲートウェイ経由で受信したメールには送信者のDMARCポリシーを適用しないと明記しています。その場合、このチェックはゲートウェイの役割となります。
これらのコンソールの画面は変わるため、このガイドでは再現していません。設定の際は、ページ下部に挙げた公式ページに従ってください。
グループ企業でよくあるケースです。親会社はMicrosoft 365、子会社はGoogle Workspace、3社目は従来のサーバー。この3つの前段に、1つのゲートウェイを置くことができます。
仕組みはドメインごとのルーティングです。各ドメインのMXがゲートウェイを指します。ゲートウェイは、ドメインごとに、分析後にメールを渡すサーバーを把握しています。分析は共通で、配信先だけが変わります。
メリット：同じフィルタリングポリシー、またはドメインごとに異なる設定を適用でき、すべての判定を1か所で確認できます。準備が必要な点：メールボックスが2つのサーバーに分かれているドメインの場合は、アドレスごとに配信先を把握する必要があります。このケースは切り替え前に検討します。
変わらないもの：アドレス、メールボックス、履歴、メールソフト、Webメール、スマートフォン。メールシステムに組み込まれたフィルターも引き続き機能します。アクセス権や社内の共有設定も、プラットフォームのもののままです。
変わるもの：
将来、メールボックスのサーバーも変更する場合、ゲートウェイはそのまま使い続けられます。変わるのは配信先サーバーだけです。その際は、SPF、DKIM、DMARCを含め、メールを中断なく移行する方法のガイドが参考になります。
切り戻しは簡単です。元のMXに戻すだけです。移行と同様に、判断権限を持つ担当者を決めて準備しておきます。
ゲートウェイが見るのは、そこを通過するメールだけです。同じプラットフォーム内の2つのメールボックス間でやり取りされ、外部に出ないメッセージ、オンラインストレージで共有されるファイル、ユーザーのログインは見えません。
そのため、Microsoft 365やGoogle Workspaceの内部設定（アクセス権、二要素認証、ログインアラート、自動転送ルール）の代わりにはなりません。盗まれたアカウントは、まずメールシステム側の問題です。その切り分けはスパム、フィッシング、マルウェア、侵害されたアカウントで説明しています。
最後に、メールボックスのサーバーの技術的なアドレスを知っている送信者は、MXを経由せずに直接配信しようとすることがあります。Microsoft（パートナーコネクター）とGoogle（ゲートウェイ経由以外のメールの拒否）が提供するロックは、このためのものです。
アドレスは変わりません。ただし、隔離通知を受け取る可能性があることは伝えておいてください。隔離、誤検知、報告をご覧ください。
いいえ。Microsoftは、独自の分析をバイパスするのではなく、有効のまま本当の送信者を評価できるよう設定することを推奨しています。
MXの変更自体は、DNSキャッシュの更新に応じて反映されます。準備期間は、ドメインとサーバーの数によります。Klytic MTAについては、次のセクションをご覧ください。
ゲートウェイが送信メールも中継する場合に限ります。その場合、SPFとDKIMでそれを考慮する必要があります。SPF、DKIM、DMARCをご覧ください。
それは別の判断基準を伴う別の決定です。欧州のビジネスメールの選び方で扱っています。
Klytic MTAは、Microsoft 365、Google Workspace、Exchange、Klytic Mail、その他のサーバーなど、お使いのメールシステムの前段に置かれます。Klyticのメールボックスは前提としません。
Klytic MTAは、現在のメールシステムのアクセス権やアカウントを管理するものではなく、Microsoft 365やGoogle Workspaceに組み込まれたセキュリティツールと同等であることを約束するものでもありません。それらの前段に追加されるものです。
このページは考え方を説明するものです。MicrosoftやGoogleのコンソールは変わるため、具体的な操作については各社の公式ドキュメントを優先してください。
2026年10月に参照。
