「複合機のスキャンtoメールは、Microsoft 365にどうつなげばいいですか？」
「vCenterのアラームメール、年末以降も届きますか？」
メールボックスがクラウドに移った今、社内に残る悩みは、機器やアプリからの通知メールをどう届けるかです。複合機、vCenter、監視ツール、業務アプリ……それぞれに制約があり、正解は1つではありません。
第10回では、Microsoft 365・Google Workspace・Amazon SESの送り方を整理し、機器ごとに向く経路を考えます。
Microsoft 365へ機器・アプリから送る4つの方法
| 方式 | 接続先と認証 | 送れる相手 | 注意点 |
|---|---|---|---|
| SMTP AUTH クライアント送信 | smtp.office365.com:587（または25）、メールボックスの資格情報。OAuth 2.0 を推奨 | 社内・社外 | Basic 認証は2026年12月末に既定で無効。1メールボックスで1日1万宛先・毎分30通。TLS 1.2 以上が必須 |
| SMTP リレー（コネクター） | 自社の MX（<ドメイン>.mail.protection.outlook.com）:25。受信コネクターで証明書または固定 IP を確かめる | 社内・社外 | メールボックス不要。他社と共有しない固定のグローバル IP か証明書が必要 |
| ダイレクト送信（Direct Send） | 自社の MX:25、認証なし | 自テナントのメールボックスだけ | インターネットからの匿名メールと同じ扱い。無効にする設定がある |
| High Volume Email（HVE） | smtp.hve.mx.microsoft:587、HVE アカウント（OAuth または Basic 認証） | 社内だけ | 2026年4月に一般提供、6月から従量課金。1通50宛先まで |
入口は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メールボックスの宛先数（24時間） | 10,000（移動する24時間の枠。引き上げ不可） | 24時間以内の宛先数が下回るまで送れない |
| 1メールボックスの送信数 | 毎分30通 | 超えた分は後へ回される。SMTP AUTH では拒否され、再送が必要 |
| 1通の宛先数 | 既定500（1〜1000で変更可） | NDR で返る |
| テナント全体の社外宛先数（TERRL） | ライセンス数に応じて自動で決まる（試用は1日5,000） | 550 5.7.233 |
| onmicrosoft.com ドメインからの社外宛て | テナント全体で1日100宛先 | 550 5.7.236 |
| HVE | 宛先数・送信数の上限なし、1通50宛先、10MB、社内宛てのみ、1テナント100アカウント | 1宛先あたり0.000042ドル（100万宛先で42ドル） |
通知メールは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のメール送信サービスです。利用者のメールボックスは持たない、送るだけの部品です。
| 項目 | 内容 | 注意 |
|---|---|---|
| サンドボックス | 新しいアカウントはリージョンごとにサンドボックス。宛先は検証済みのみ、1日200通、毎秒1通 | 本番アクセスを申請して解除する。用途とバウンスの処理方法を説明する |
| ID の検証 | 送信に使うドメインまたはアドレスを検証する | 解除後も From・Return-Path に使う ID は検証が必要 |
| 送信の上限 | 24時間の送信数と毎秒の送信レート（宛先数で数える） | 実績に応じて引き上げを申請する |
| Easy DKIM | CNAME を3つ登録すると SES が署名する。既定は RSA 2048 ビット | CNAME を消すと署名が検証できなくなる |
| カスタム MAIL FROM | エンベロープの送信者を bounce.example.jp などの自社のサブドメインにする（MX と SPF の TXT を登録） | SPF のアラインメントがそろう。MX が見つからないときに既定のドメインで送るか拒否するかを選ぶ |
| SMTP インターフェイス | email-smtp.<リージョン>.amazonaws.com。STARTTLS は25・587・2587、TLS ラッパーは465・2465 | SMTP の資格情報は IAM から作る（アクセスキーとは別）。TLS が必須 |
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 の接続まではできている）アプリ・機器からの通知メールの送り方
ここまでを踏まえて、送り手ごとに向く経路を整理します。
| 送り手 | よくある制約 | 向く送り方 | 確認すること |
|---|---|---|---|
| 複合機（スキャン to メール） | 古い機種は TLS 1.2・OAuth に非対応。添付が大きい | 新しい機種は OAuth、古い機種は社内リレー | ファームウェアの版、添付のサイズ上限 |
| vCenter（アラームの通知） | 認証は Basic 認証だけ（OAuth 非対応） | 社内リレーへ匿名で送る（リレーは IP で許可） | Broadcom の対応状況 |
| 監視ツール（Zabbix など） | 障害のときに一斉に大量に出る | 社内リレー、または OAuth 対応の版で直接 | 送信の上限、メール以外の通知経路 |
| 業務アプリ（自社開発） | コードを変えられる | Microsoft Graph の sendMail、SES の API | 資格情報の保管（シークレットの管理） |
| クラウド上のシステム | Microsoft 365 の SMTP リレーは他社のクラウドから使えない | SES、Azure Communication Services、SMTP AUTH（OAuth） | 25番の制限 |
| 社内リレーサーバー（Postfix） | 自分たちで運用する | 機器の送信を集め、Microsoft 365（コネクター）や SES へ中継 | オープンリレーにしない（第8回）、冗長 |
機器は「メールを作る」ことはできても、配送のやり直しやキューの管理は苦手です。社内リレーに集めると、機器の設定は宛先を変えるだけで済み、ログも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に任せる
考えてみよう
- 職場で通知メールを送っている機器やアプリを挙げてください。それぞれ、どの方式（SMTP AUTH、コネクター、ダイレクト送信、社内リレー）で送っていて、Basic認証を使っていませんか。
- Microsoft 365でダイレクト送信を拒否する設定を有効にすると、何が止まる可能性がありますか。有効にする前に何を確かめますか。
- 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回
- メールが届くまで
- SMTPのやり取り
- メッセージの構造
- ポートと暗号化・認証
- 送信ドメイン認証 前編
- 送信ドメイン認証 後編
- 迷惑メール対策と配信
- MTAの運用
- コマンドで調べる
- クラウドと現代のメール（この記事）
- メールのトラブルシュート
- メールの設計演習
コメント