メールの受信トレイは単なる仕事の場ではなく、ほかのすべてに通じるマスターキーです。銀行のパスワードを再設定する場合もメール、CRMを再設定する場合もメール、クラウド基盤のアカウントを復旧する場合もメールを使います。攻撃者が一つの受信トレイを掌握すると、そこから会社全体へ被害が広がる可能性があります。
残念ながら、ビジネスメールを運用する企業の多くは、以下の設定の少なくとも半分が正しく構成されていないか、設定自体がありません。一方、修正のためにセキュリティチームや$50,000の企業向け契約が必要なわけではありません。およそ二時間を確保し、実際に作業を進めれば対応できます。
ここで示すのは基本設定です。将来の理想像ではなく、最低限の対策です。このリストの全項目を確認できない場合は、対処すべきリスクが残っています。
企業が実際に侵害される仕組み
国家の支援を受ける攻撃者やゼロデイ攻撃ばかりを心配する必要はありません。機密システムを扱っていない限り、高度で高コストな攻撃が投入される可能性は高くありません。中小企業のメールインシデントの90%に関係するとされる三つのリスクは、もっと身近なものです。
クレデンシャルスタッフィング: 攻撃者は、LinkedIn 2012、Adobe 2013をはじめ、その後の多数の侵害で流出したパスワードデータベースを入手し、メールサーバーに対してスクリプトを実行します。現在も使っているパスワードが流出データに含まれていれば、システム自体を技術的に破らなくても侵入される可能性があります。
気付かれにくい転送ルール: 侵入に成功した攻撃者は、すぐにアカウントを荒らすとは限りません。「件名に『請求書』または『振込』が含まれていたら、attacker@gmail.comへコピーを送り、既読にする」という目立たないルールを作り、数か月にわたり監視します。発覚した時点では、すでに支払いが傍受されているかもしれません。
なりすまし: 何者かがceo@yourcompany.comから経理担当者へ、至急の送金を求めるメールを送ります。正規のメールに見えても、DNSが適切に設定されていなければ、受信サーバーは偽装を判定するための十分な情報を得られず、警告を付けない場合があります。
この三つはいずれも、適切な対策で発生リスクを大きく下げられます。以下で対策を説明します。
企業向けセキュアメール: アカウント保護の最低基準
ここが防御の境界です。この層が破られれば、DNS設定だけでは保護できません。
1. MFAを例外なく必須にし、フィッシング耐性を高める
パスワードだけでは十分なセキュリティになりません。分かるのは文字列を知っているということだけで、本人であることまでは確認できないためです。多要素認証によって、追加の本人確認が可能になります。
Google Authenticator、Microsoft Authenticator、Authyなどの認証アプリを最低基準とし、フィッシング耐性が必要なアカウントにはYubiKeyのようなハードウェアキーを使用します。ただし、SMSによる2FAを主要な方法にしないでください。SMSは利用できますが、攻撃者が通信事業者をだまして電話番号を自分の端末へ移すSIMスワップ攻撃に弱いためです。必要な場合も予備手段に限定します。
管理者レベルでMFAを必須にしてください。任意にしてはいけません。一人でも省略すれば、そこが最も弱い箇所になり得ます。
TrekMailはすべての管理者アカウントで2FAをサポートしています。アカウントのセキュリティ設定から有効にしてください。詳しい手順は二要素認証ガイドで確認できます。
2. レガシー認証を直ちに無効化する
これは2026年現在も見落とされやすい脆弱性です。「レガシー認証」とは、最新のMFAフローに対応せず、ユーザー名とパスワードだけを求める基本的なSMTP AUTHなどの方式を指します。
問題は、すべてのアカウントで2FAを有効にしていても、許可されたレガシープロトコル経由で接続されると、攻撃者に回避される可能性があることです。第二要素を要求しないクライアントには、新しいMFA設定が適用されません。
テナント単位でレガシー認証をブロックします。例外が必要になり得るのは、メール送信が必要なプリンター、スキャナー、旧式の端末です。その端末を分離し、長く複雑で定期的に変更するパスワードを設定した専用サービスアカウントを割り当てます。複合機からスキャンをメール送信するためだけに、一般利用者のアカウントをレガシープロトコルへ公開しないでください。
注: TrekMailは意図的にPOP3をサポートしていません。端末の紛失時に復旧できない可能性があるローカルだけのメール保存を避けるための設計判断です。すべてのクライアント接続では、サポート対象のIMAPを使用します。
3. 認証情報を共有しない
三人がパスワードをメッセージで送り合って使うinfo@company.comアカウントは、単なる不便ではありません。セキュリティインシデントにつながりかねません。誰かが退職したときに変更していますか。多くの場合はしていません。最後にログインした人が分かりますか。分かりません。
解決策は、委任アクセスまたは共有メールボックスです。各利用者が自分の認証情報でログインし、共有フォルダーへのアクセス権を得ます。監査証跡を残せるほか、アクセス権を個別に取り消せるため、パスワードの共有は不要です。
利用者単位の料金体系は、この対策と相性がよくありません。一席が$15-$30/月なら、費用を抑えるために認証情報を共有するチームが出てきます。TrekMailは席数ではなく共有ストレージに基づく定額制なので、5人でも50人でも席数による価格は変わりません。全員に個別アカウントを用意し、$6/月を節約するためにパスワードを共有するのはやめましょう。
管理とアクセス制御
緊急用アカウント
スマートフォンを海に落としたり、主要なIDプロバイダーで障害が起きたりした場合、停止した仕組みに依存せずに復旧する手段が必要です。クラウド内だけに存在する緊急用の管理者アカウントを一つ作成します。たとえばadmin-recovery@yourdomain.comを用意し、30文字のランダムなパスワードを設定します。パスワードは紙に書き、物理的な金庫に保管してください。
さらに、このアカウントでログインが発生したら、ほかのすべての管理者へ直ちに通知するアラートを設定します。このアカウントを使う機会はほとんどないはずです。予期しないログインがあれば、すぐに調査してください。
職務の分離
Webの閲覧、リンクのクリック、ニュースレターの購読に使う日常のメールアカウントには、グローバル管理者権限を付けるべきではありません。スーパー管理者としてログイン中にフィッシングリンクを開けば、攻撃者に広範な権限を渡すおそれがあります。
別の管理者アカウントを作成し、設定を変更するときだけログインします。それ以外は標準利用者として操作してください。これは過剰な警戒ではなく、システム管理者なら初日から勧める基本的な運用衛生です。
企業向けセキュアメール: メール真正性の最低基準 (SPF、DKIM、DMARC)
この三つのDNSレコードは、なりすましを抑止する技術的な仕組みです。GoogleとYahooは2024年から大量送信者にこれらを求めており、ビジネスメール全般でも重要性が増しています。未設定なら、送信元を確認したうえで構成してください。
各層の詳しい実装手順は、メールドメイン設定ガイドで解説しています。
SPF: 承認済み送信者の一覧
Sender Policy Frameworkは、ドメインのメールを送信できるIPアドレスを明示するDNS TXTレコードです。一覧にないサーバーからのメールは、レコードに指定された修飾子に従って判定されます。
v=spf1 include:_spf.trekmail.net -allここでは二点を正しく設定します。
第一に、末尾は-all、hard failにし、~all、soft failにはしません。soft failは「正規の送信元を確定できていないので、受け入れも検討してほしい」という弱い方針です。正規の送信元をすべて確認した後でhard failを使用してください。
第二に、SPFには10回のDNSルックアップ制限があります。同じレコードにGoogle Workspace、Mailchimp、Salesforce、Zendeskを含めると、上限を超えてSPFで気付きにくいエラーが起きる可能性があります。複数の送信サービスを扱う場合は、SPF flatteningツールを慎重に使い、結果を検証してください。
DKIM: 改ざんを検出できる封印
DomainKeys Identified Mailは、すべての送信メッセージに暗号署名を追加します。秘密鍵を持つメールサーバーがメールに署名し、受信者のサーバーはDNSで公開された公開鍵を使って検証します。
SPFがあっても必要なのは、転送によってSPFアラインメントが崩れる場合があるためです。メッセージが転送されると送信元IPが変わり、SPFに失敗する可能性があります。DKIM署名はメッセージヘッダーとともに移動し、転送後も有効性を維持できる場合があります。両方が必要です。
TrekMailは有料プランでDKIM鍵の生成とローテーションを自動管理します。公開鍵がDNSへ公開され、すべての送信メッセージが署名されるため、手動設定は不要です。必須DNSレコードガイドに、追加される内容と場所が記載されています。
DMARC: ポリシーを適用する層
DMARCは、SPFとDKIMのいずれからも認証とアラインメントを満たす結果が得られないときの処理を受信メールサーバーへ伝えます。また、自社ドメインとして送信している送信元のレポートを受け取れます。これにより、使われていないと思っていたマーケティングツールがまだ代理送信していることも発見できます。
最初は監視モードにします。この段階を省略しないでください。
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comこのレコードは「自社として送信している送信元を報告し、まだ何もブロックしない」という意味です。二週間から四週間分のレポートを集め、すべての送信元を調査します。正規の送信元がすべて認証に成功することを確認してから、適用ポリシーへ移行します。
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com最終的には次の設定にします。
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com事前に調査せずp=rejectへ直接移行すると、請求書やマーケティングメールなど、完全に構成されていない正規の送信元までブロックする可能性があります。段階的に進めてください。DMARCの文書に、段階的な導入手順が記載されています。
転送とキャッチオールの安全対策
外部への自動転送をブロックする
このルールは、前述した気付かれにくい情報持ち出し攻撃の防止に役立ちます。メールサーバーで外部ドメインへの自動転送を禁止してください。
従業員がすべての業務メールを個人のGmailアカウントへ自動転送する正当な業務上の理由は、ほとんどありません。複数の場所からアクセスする必要があるなら、複数端末でIMAPを設定してください。IMAPはその用途に対応しています。すべてを外部アドレスへひそかにコピーする転送ルールは、それ自体が情報流出経路になります。
キャッチオールの問題
キャッチオールアドレスは、実在しないアドレスを含め、ドメイン内のあらゆる宛先へのメールを受信します。便利に見えますが、スパム送信者にも悪用されます。攻撃者はa@yourdomain.com、aa@yourdomain.com、ab@yourdomain.comなどを使った辞書攻撃を仕掛けます。これらに返信した場合や、宛先がスパムトラップだった場合は、ドメインの評判が損なわれる可能性があります。
明確な運用上の理由がない限り、キャッチオールは無効にします。必要な場合は毎日監視し、厳格にフィルタリングしてください。TrekMailのProプランは、スパムフィルタリングを備えた外部キャッチオールのルーティングに対応していますが、キャッチオール設定ガイドでも、設定後に放置せず継続的に管理する必要があると説明しています。
12項目のセキュリティ基準チェックリスト
以下の全項目を確認できれば、専任ITチームがありながら未対応の企業を含む、多くの組織より堅牢な構成になっている可能性があります。
| # | 対策 | 防止に役立つこと |
|---|---|---|
| 1 | すべてのアカウントでMFAを必須化 | クレデンシャルスタッフィング、パスワード流出 |
| 2 | レガシー認証をブロック、利用者の基本SMTP AUTHを禁止 | 旧式プロトコル経由のMFA回避 |
| 3 | 認証情報を共有せず、委任アクセスだけを使用 | 追跡不能なアクセス、退職者によるアクセス |
| 4 | 日常利用と分離した専用管理者アカウント | フィッシングから管理者侵害に至る連鎖 |
| 5 | 緊急復旧アカウントを作成しオフラインで保管 | 復旧手段のないロックアウト |
| 6 | SPFレコードを設定し、末尾を-allにして、ルックアップを10回以内に制限 |
IPベースのなりすまし |
| 7 | DKIMを有効化し、鍵を毎年ローテーション | メッセージ改ざん、転送時の認証失敗 |
| 8 | RUAアドレスを指定し、DMARCを最低でもp=noneに設定 |
検知できないなりすまし、送信元を把握できない状態 |
| 9 | サーバー側で外部への自動転送をブロック | 受信トレイルールによる気付かれにくいデータ持ち出し |
| 10 | キャッチオールを無効化または厳格にフィルタリング | 辞書攻撃、スパムトラップへの露出 |
| 11 | オフボーディング手順を用意 (パスワード再設定 → セッション無効化 → 端末消去) | 退職後も残るアクセス権 |
| 12 | 外部送信サービスを監査 (CRM、請求、マーケティング) | 不明な送信元のDMARC失敗、正規メールのブロック |
印刷して、オンボーディングの運用手順書へ追加し、六か月ごとに確認してください。
利用者単位の料金がセキュリティ問題になる理由
明確にしておくべき点があります。一般的な$6-$30/席という利用者単位の料金体系は、セキュリティ対策を削る金銭的な圧力を生みます。利用者が増えるたびに費用がかかると、個別アカウントを作らずinfo@のパスワードを共有しがちです。委託先には個別の認証情報が与えられず、移行費用を避けるため退職者のアカウントが残ることもあります。
安全なビジネスメールには分離が必要です。すべての人に個別のIDを割り当て、サービスボットにも専用アカウントを用意します。これがなければ、信頼できる監査証跡を残せません。
TrekMailの定額制では、人数ではなく共有ストレージに対して料金が発生します。メールボックスが五つでも五百でも、席数を理由に価格は変わりません。そのため、新しい人が加わるたびに予算を議論せず、従業員、委託先、サービスアカウントのそれぞれへ分離された認証情報を割り当てられます。
プランは$3.50/月からで、最大50ドメイン、各ドメイン100利用者に対応します。通常規模のチームなら、一人当たり一ドルを大きく下回る場合があります。すべての有料プランには、カード登録が必要な14日間の無料トライアルがあります。
次に行うこと
上のチェックリストを確認し、足りない項目を率直に洗い出してください。多くの企業では、最初の確認で少なくとも三つか四つの不足が見つかります。珍しいことではなく、修正できます。
労力に対する効果が高い順に、次の対策を進めます。
- すべての対象でMFAを有効にする。今日中に実施します。
- DMARCレポートがあれば監査し、なければ収集を始める。
- SPFの末尾が
-allで、ルックアップ制限を超えていないことを確認する。 - サーバー側で外部への自動転送をブロックする。
- 必要になる前に緊急用アカウントを作成する。
セキュリティは、魔法のような製品を購入することではありません。基本を正しく設定し、維持することです。DNSを構成し、MFAを必須にし、パスワードの共有をやめてください。これらを組み合わせることで、企業を実際に狙う攻撃の多くを防げます。
ゼロから始める場合、TrekMailはDNSウィザードを通じてDKIMとSPFの設定を自動管理し、設計方針としてPOP3を無効にしています。定額制なので、利用者を分離する費用も抑えられます。14日間無料でお試しください。
