メールボックスがクラウドに移った今、社内に残る悩みは、機器やアプリからの通知メールをどう届けるかです。複合機、vCenter、監視ツール、業務アプリ……それぞれに制約があり、正解は1つではありません。

第10回では、Microsoft 365・Google Workspace・Amazon SESの送り方を整理し、機器ごとに向く経路を考えます。

Microsoft 365へ機器・アプリから送る4つの方法

入口は3つ、方式は4つです。同じMXでも、コネクターで認証されるかどうかで送れる相手が変わります。

Microsoftは、社内宛てだけならHVE、社外にも大量に送るならAzure Communication Services Emailを勧めています。どの方式でも、送信元のアドレスはテナントの承認済みドメインにし、SPF・DKIM・DMARCをそろえます（第5回・第6回）。

SMTP AUTHとBasic認証の廃止

SMTP AUTHクライアント送信は、機器やアプリがMicrosoft 365のメールボックスにサインインして送る方式です。問題は、ユーザー名とパスワードをそのまま送るBasic認証です。

• Exchange OnlineはPOP・IMAPなどのBasic認証を2022年に止めたが、SMTP AUTHは例外として残してきた
• 2026年1月に更新された日程では、2026年12月末に既存のテナントでも既定で無効になり（管理者は再び有効にできる）、以降に作るテナントでは既定で使えない。最終の廃止日は2027年後半に発表される予定
• 移行先はOAuth 2.0（第4回）。ただし、機器がトークンの取得と更新に対応している必要があり、古い複合機やvCenterのように対応しない製品も残る

まず、Basic認証で送っている機器・アプリを洗い出します。OAuthに対応しない機器は、この後のコネクターか社内リレーへ移します。

ダイレクト送信の現状と無効化

ダイレクト送信は、機器が自社のMX（…mail.protection.outlook.com）に25番で直接つなぎ、認証なしで送る方式です。外部のメールサーバーから届くメールと同じ扱いで、送れるのは自テナントのメールボックス宛てだけです。

• 認証がないため、第三者も同じMXに自社のドメインを名乗って送れる。2025年には、この経路を使うなりすましのフィッシングが報告された
• 対策として、受信コネクターで認証されない、自社ドメインを名乗る匿名メールを拒否する設定（RejectDirectSend）が追加された

PS> Connect-ExchangeOnline
PS> Get-OrganizationConfig | Format-List RejectDirectSend
PS> Set-OrganizationConfig -RejectDirectSend $true

（拒否された送信側に返る応答の例）
550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources

有効にする前に、ダイレクト送信を使っている複合機や外部サービスを洗い出し、受信コネクター（証明書またはIP）で認証させるか、別の方式へ移します。Microsoftの手順書は「多くの顧客にダイレクト送信は不要」とし、既定で無効にする選択肢を準備中としています。

コネクターを使うSMTPリレー

SMTPリレーは、機器やオンプレのメールサーバーが「組織のメールサーバー」としてMicrosoft 365に送り、Microsoft 365が社内外へ配送する方式です。

• Exchange管理センターで、接続元を「組織のメールサーバー」とする受信コネクターを作り、送信元の確かめ方を選ぶ
• 推奨は、TLSの証明書のSubjectかSANに承認済みドメインが入っていることで確かめる方法。できなければ、他の組織と共有しない固定のグローバルIPを使う（動的IPは不可）
• 機器の送信先は自社のMXの25番で、TLS 1.2以上を使う。メールボックスは不要で、承認済みドメインの任意のアドレスから送れる。ただし、Azureなど他社のクラウドからは使えない
• IPや証明書が変わると550 5.7.64 TenantAttributionで止まる。証明書の更新手順にコネクターの確認を入れておく

Exchange Onlineの送信の上限とHigh Volume Email

通知メールは1日の量が少なくても、障害のときに一斉に出ると毎分30通に当たります。監視の通知を1つのメールボックスに集めている場合は注意が必要です。社内への大量配信はHVE、社外への大量配信はAzure Communication Services EmailやAmazon SESに分けます。

Google Workspaceから送る

• SMTPリレーサービス：管理コンソールのGmail ＞ ルーティングで設定し、機器はsmtp-relay.gmail.comへ送る。ポートは25・465・587
• 送信元の確かめ方は、許可するIPアドレスかSMTP認証（TLSが必須）から選ぶ。「TLS暗号化を必須にする」も選べる
• 送信者は「ドメインの登録済みユーザーのみ」「ドメイン内のアドレス」「すべてのアドレス（非推奨）」から選ぶ。機器の送信元が自社ドメインでないと拒否される
• 上限は1ユーザーあたり1日10,000宛先、1回のトランザクションで100宛先。Gmailの通常の送信上限とは別に数える
• EHLOにはlocalhostではなく、機器ごとに一意な名前を名乗らせる
• 安全性の低いアプリ（パスワードだけのアクセス）は、2025年3月14日から段階的に止まり、5月1日で対応を終えた（Google の告知）。smtp.gmail.comへSMTP AUTHで送るには、OAuth 2.0か、2段階認証プロセスを有効にしたアカウントのアプリ パスワードが必要

Googleは、機器を買い替えるときはOAuthで送れる機種を選ぶよう勧めています。アプリ パスワードは、Basic認証と同じく機器に保存される長期の秘密なので、使う場合は専用のアカウントに限り、SMTPリレーサービス（IPで許可）を優先します。

Amazon SESの基本

Amazon SESは、AWSのメール送信サービスです。利用者のメールボックスは持たない、送るだけの部品です。

APIでもSMTPでも送れるので、アプリはAPI、既存の機器やPostfixはSMTP、と使い分けます（Postfixの設定例は第8回）。AWS全体での位置づけは、連載「クラウド入門」第14回を参照してください。

バウンス・苦情の処理とVirtual Deliverability Manager

• SESはアカウントごとに、バウンス率（ハードバウンスの割合）と苦情率（受信者が迷惑メールと報告した割合）を見ている
• バウンス率5%以上か苦情率0.1%以上で審査中になり、10%以上か0.5%以上で送信が一時停止されることがある。共有のIPの評判を守るための措置
• 設定セット（configuration set）のイベントの送信先（SNS、EventBridge、CloudWatch、Data Firehose）で、バウンス・苦情・配信を受け取り、アプリの宛先リストから外す
• アカウントレベルの抑制リストを有効にすると、ハードバウンスや苦情のあったアドレスが登録され、以後は送られない
• Virtual Deliverability Manager（VDM）は、ISPごとの到達率や開封率のダッシュボードと、DKIM・DMARCなどの設定の改善を勧める「アドバイザー」を提供する（月額の有料の機能）
• 大量に送る場合は、専用IP（マネージド型を含む）と、送信量を少しずつ増やすウォームアップも検討する（第7回）

Gmail・Yahooの送信者ガイドラインは迷惑メール率0.3%未満を求めていますが（第6回）、SESの基準はそれより厳しいため、バウンスと苦情を自動で処理する仕組みは、送り始める前に作っておきます。

EC2の25番の制限と解除申請

• EC2インスタンスと、VPCに接続したLambdaからの外向きの25番は、既定で制限されている（2020年1月から）
• 解除は「Request to remove email sending limitations」のフォームで、リージョンごとに申請する。用途と、迷惑メールを出さないための対策を書く。処理には最大48時間ほどかかる
• 同じフォームでEIPの逆引き（PTR）も依頼できる。先に正引きのAレコード（例：mail.example.jp → そのEIP）を登録しておく
• SESのSMTPへは、587・465・2587・2465を使えば申請なしで送れる。VPCエンドポイントでもSESのSMTPに接続できる
• Azureも、Enterprise Agreement（MCA-Eを含む）以外の多くのサブスクリプションで、仮想マシンから外向きの25番を遮断している

$ nc -vz -w 5 mx.example.com 25                          # 制限中はタイムアウトする
$ nc -vz -w 5 email-smtp.ap-northeast-1.amazonaws.com 587
PS> Test-NetConnection email-smtp.ap-northeast-1.amazonaws.com -Port 587
（TcpTestSucceeded : True なら TCP の接続まではできている）

アプリ・機器からの通知メールの送り方

ここまでを踏まえて、送り手ごとに向く経路を整理します。

機器は「メールを作る」ことはできても、配送のやり直しやキューの管理は苦手です。社内リレーに集めると、機器の設定は宛先を変えるだけで済み、ログも1か所で追えます。Microsoftも、オンプレにメールサーバーがあればリレーに使うよう勧めています。ただし、Windows ServerのIISのSMTPサービスは、Microsoft 365へのリレーには使えません（第8回）。

vCenterのメール通知の設定

冒頭の「vCenterのアラームメール」の答えです。

• 設定の場所は、vSphere ClientのvCenter ＞ 構成 ＞ 設定 ＞ 全般 ＞ 編集の「メール」。メールサーバー（名前またはIP）と、メール送信者（ドメインを含む完全なアドレス）を入れる
• SMTP認証はvSphere 7.0 Update 1以降で、詳細設定のmail.smtp.username・mail.smtp.password・mail.smtp.port（587）に入れる。対象はMicrosoft 365（旧Office 365）のメールボックスで、サーバーはIPではなくsmtp.office365.comと名前で指定する。パスワードは詳細設定の画面に見えるため、専用のアカウントを使う
• OAuth 2.0には非対応（vCenter 8.x・9.x、Broadcom KB 428447）。Microsoft 365のBasic認証が無効になると送れなくなる
• 送信は内部のSendmailが担う。相手がSTARTTLSを示せば暗号化し、証明書の検証に失敗しても送信は続ける（ログは第11回）

（詳細設定の例：Microsoft 365 へ SMTP 認証で送る場合）
mail.smtp.server   = smtp.office365.com
mail.smtp.port     = 587
mail.smtp.username = vcsa-alert@example.jp
mail.smtp.password = ********
mail.sender        = vcsa-alert@example.jp

推奨は、社内リレーへ認証なしで送り、リレー側でvCenterのIPだけを許可する構成です。vCenterは宛先を変えるだけで、認証の問題はリレー側で引き受けます。

メール基盤の冗長（要点）

• 受信（25番）は、MXに複数のサーバーを登録すれば、送信側が順に試し、つながらなければキューに残して再送するため、MXだけでも冗長にできる
• 利用者のメールソフトや機器は、設定した1つのサーバー名にしか接続せず、失敗しても別のサーバーを試さない。そのため、投稿（587番）や社内リレーには、ロードバランサー（TCPのまま転送）や仮想IPで、1つの名前の後ろに複数台を置く仕組みが要る
• SPFとPTRに登録するのは、実際に外へ送るIP（NATの出口など）
• 自前で持つ範囲が広すぎるなら、送信はSES、メールボックスはSaaSに任せる

考えてみよう

1. 職場で通知メールを送っている機器やアプリを挙げてください。それぞれ、どの方式（SMTP AUTH、コネクター、ダイレクト送信、社内リレー）で送っていて、Basic認証を使っていませんか。
2. Microsoft 365でダイレクト送信を拒否する設定を有効にすると、何が止まる可能性がありますか。有効にする前に何を確かめますか。
3. EC2上のアプリから会員へメールを送ることになりました。EC2から直接送る場合とSESを使う場合で、事前に必要な申請とDNSの設定を比べてください。

ヒント：問1は4つの方法の表と送り手ごとの表、問2は「MXに認証なしで送っているもの」をダイレクト送信の図の考え方で探す、問3はSESの基本とEC2の25番の制限（サンドボックス、25番、PTR、DKIM、MAIL FROM）から考えてみてください。

まとめ

• Microsoft 365への送り方はSMTP AUTH・コネクター・ダイレクト送信・HVEの4つ。送れる相手が違う
• SMTP AUTHのBasic認証は2026年12月末に既定で無効。まず使っている機器を棚卸しする
• ダイレクト送信はなりすましの経路にもなる。RejectDirectSendの前に利用者を洗い出す
• コネクターは証明書（推奨）か固定IPで認証。変わると550 5.7.64で止まる
• GoogleもパスワードだけのSMTPは終了。SMTPリレーサービスかOAuth
• SESはサンドボックスの解除・DKIM・MAIL FROMをそろえ、バウンスと苦情を自動で処理する
• OAuthに対応しない機器は社内リレーに集める。vCenterもリレーへ匿名で

次回は、「メールが届かない」ときの切り分けの手順と、よくあるエラーをまとめます。

連載「メール入門」全12回

1. メールが届くまで
2. SMTPのやり取り
3. メッセージの構造
4. ポートと暗号化・認証
5. 送信ドメイン認証 前編
6. 送信ドメイン認証 後編
7. 迷惑メール対策と配信
8. MTAの運用
9. コマンドで調べる
10. クラウドと現代のメール（この記事）
11. メールのトラブルシュート
12. メールの設計演習