Azure Communication Services Email（以下、ACS Email）は、アプリケーションから大規模にメールを送信できる強力なサービスですが、「MailFrom（エンベロープ From）の追加ができない」「Exchange Online に送信メールが残らない」といったつまずきポイントも多いサービスです。本記事では、この2つのよくある悩みを、Azure ポータルの具体的な操作イメージや設計パターンを交えながら、実務レベルで解決できるように詳しく解説します。
Azure Communication Services Email とは
まず前提として、ACS Email がどのようなサービスなのかを整理しておきます。
ACS Email は、Azure 上のアプリケーションやバッチ処理、SaaS 製品などからメールを送信するためのサービスです。いわゆる「メールサーバー」や「Exchange Online」の代わりに、クラウドネイティブなメール送信基盤として利用できます。
代表的な利用シナリオは次の通りです。
- Web アプリからのユーザー登録完了メール、パスワードリセットメール
- 定期的なお知らせメールやステータス通知メール
- 業務システムからの自動通知（ワークフロー完了、エラー通知など）
- マーケティング系の一斉メール（ニュースレターなど）
ここで重要なのは、ACS Email は Exchange Online と別系統のサービスであり、メールボックスや送信済みアイテムとは直接つながっていないという点です。この違いが、「送信メールが Outlook の送信済みに残らない」「ジャーナルや DLP が効かない」といった疑問につながります。
ACS Email と Exchange Online の違い
| 項目 | ACS Email | Exchange Online |
|---|---|---|
| 用途 | アプリ／システムからの大量メール送信 | ユーザーごとのメールボックス＋コラボレーション |
| 送信経路 | ACS 独自の送信基盤 | Exchange Online 経由 |
| 送信済みアイテム | なし（メールボックスを持たない） | ユーザーの送信済みフォルダーに自動保存 |
| ジャーナリング / 監査 / DLP | Exchange ポリシーは適用されない | ポリシーと統合される |
| 送信者 | MailFrom / From をアプリ側で制御 | ユーザーアカウントや共有メールボックス |
この構造の違いを理解しておくと、後述する「MailFrom が追加できない」「送信メールが残らない」という挙動も納得しやすくなります。
MailFrom（エンベロープ From）とは何か
ACS Email で議論になる「MailFrom」は、SMTP のエンベロープ From を指します。一般的な「From（送信者）」ヘッダーと混同しやすいので、簡単に整理します。
| 種類 | 役割 | ユーザーに見えるか |
|---|---|---|
| MailFrom（エンベロープ From） | バウンス（配信不能通知）や SPF 評価などに使われる技術的な送信者 | 通常のメーラーでは見えない |
| From ヘッダー | 受信者に表示される送信者メールアドレス | Outlook や各メーラーに表示される |
DMARC や SPF、配信到達性（Deliverability）をしっかり設計したい場合、MailFrom をドメイン認証済みのアドレスで適切に制御することが重要です。そのため ACS Email では、独自ドメインを検証した上で MailFrom アドレスを追加し、用途ごとに使い分ける運用が推奨されます。
MailFrom の「追加」ボタンがグレーアウトする原因
質問として非常に多いのが、次のようなケースです。
- 独自ドメインはすでに検証済み
- 既定の MailFrom（初期設定）ではメール送信できている
- しかしポータルの「MailFrom アドレス」の [追加] ボタンがグレーアウトして押せない
この現象の主な原因は、ACS Email の送信数上限（クォータ）が既定のままで、拡張申請が行われていない点にあります。既定の上限状態では、MailFrom の追加機能がロックされており、クォータの引き上げが行われると [追加] ボタンが有効化される仕様になっています。
つまり、「ドメインが検証済みなのに MailFrom が追加できない」という場合は、ドメイン設定の問題ではなく、送信上限の引き上げが未対応であることがほとんどです。
MailFrom 追加を有効化するためのクォータ引き上げ手順
ここからは、Azure ポータルで実際に行う手順を具体的に整理します。
- Azure ポータルにサインインします。
- 画面右上の「?」アイコン、または「ヘルプとサポート」から [サポート リクエストの作成] を開きます。
- サポートリクエストの種類で、[Service and subscription limits (quotas)]（サービスとサブスクリプションの制限） を選択します。
- 対象のサブスクリプションとリソースグループ、ACS Email リソースを選択します。
- クォータの種類として 「Azure Communication Services Email: Sending Limits」 を選択します。
- もしこの選択肢が表示されない場合は、クォータの種類を「Other requests（その他の要求）」などに設定し、
リクエスト本文で 「ACS Email の送信数上限の引き上げを希望」 する旨を明示します。
- もしこの選択肢が表示されない場合は、クォータの種類を「Other requests（その他の要求）」などに設定し、
- 希望する送信上限（例：1 日あたりの送信通数、Tier レベルなど）と、想定される利用用途・送信ボリュームをできるだけ具体的に記載します。
- サポートリクエストを送信し、サポート側からの確認・承認を待ちます。
- 承認・反映後、ACS Email リソースの「メールドメイン」設定画面に戻り、MailFrom の [追加] ボタンが有効化されていることを確認します。
ACS Email では、最初は比較的低い送信上限が設定されていることが多く、開発環境のまま本番運用に突入すると、すぐに上限に達してしまうケースもあります。MailFrom を追加できるようにする目的だけでなく、安定した本番運用のためにも早めに上限引き上げを申請しておくことをおすすめします。
CLI / PowerShell から MailFrom を扱う場合
MailFrom の追加自体は、Azure ポータルだけでなく Azure CLI や PowerShell、Bicep/ARM テンプレートからも構成可能です。ただし、クォータ引き上げを行わない限り、API レベルであっても新たな MailFrom の登録が制限される点は同じです。
そのため、IaC（Infrastructure as Code）で ACS Email を構成する場合は、事前にクォータ引き上げ申請を完了させた上で、MailFrom を含む設定をデプロイするフローを設計しておくとスムーズです。
MailFrom 運用設計のベストプラクティス
MailFrom が追加できるようになったら、いくつかの観点で運用設計を行うと、後のトラブルを防ぎやすくなります。
用途ごとに MailFrom を分ける
例えば、次のように用途ごとに MailFrom を分けておくと、トラブルシュートや配信制御がしやすくなります。
| 用途 | MailFrom 例 | 補足 |
|---|---|---|
| システム通知（障害、エラー） | [email protected] | 運用担当者向けの技術的なお知らせ用 |
| ユーザー向けトランザクションメール | [email protected] | パスワードリセットや登録完了メールなど |
| マーケティングメール | [email protected] | 解除リンクや配信停止機能とセットで運用 |
DNS レコード（SPF / DKIM / DMARC）との整合性
MailFrom を独自ドメインで運用する際は、次のポイントに注意します。
- MailFrom のドメインが SPF レコードで ACS の送信元を許可しているか
- DKIM の署名ドメインと MailFrom ドメインの整合性（Alignment）
- DMARC ポリシー（p=none / quarantine / reject）の設計と検証フェーズ
特に DMARC を厳格に設定している環境では、MailFrom を安易に変更すると配信エラーが増える可能性があります。検証環境やテストドメインで配信状況を確認しながら、本番段階的に切り替えていくと安全です。
ACS Email はなぜ送信済みアイテムに残らないのか
次に、もうひとつの大きな悩みである「送信メールの保存・追跡」について詳しく見ていきます。
ACS Email は先述の通り、Exchange Online を経由しない独立した送信基盤です。そのため、送信したメールは Exchange Online の「送信済みアイテム」やジャーナル、監査ログ、DLP ポリシーの対象にはなりません。
言い換えると、ACS Email だけで運用している場合、次のような要件はそのままでは満たせません。
- ユーザーごとの送信済みメールを Outlook から検索・確認したい
- 監査やコンプライアンス上、すべての送信メールをジャーナリング対象としたい
- DLP（情報漏えい防止）ポリシーで送信内容をチェックしたい
もちろん、ACS 側のログやメトリックで「何件送信したか」「成功したか／失敗したか」といった情報は追えますが、実際に送信されたメール本文を Exchange Online 側で完全に保存・追跡することはできません。
ACS Email で送信したメールを「残す」ための選択肢
ここからは、目的別に検討できる代表的な対処パターンを整理します。
最小コストで送信内容の控えを残す：Bcc 運用
もっともシンプルな方法は、アプリ側で Bcc を付与し、監視用の Exchange Online メールボックスに自動的にコピーを送る方式です。
- アプリケーションが ACS Email 経由でメール送信する際、特定のアドレス（例：[email protected]）を Bcc に追加する
- そのアドレスを Exchange Online の共有メールボックスやアーカイブ用メールボックスとして運用
- 必要に応じて、そのメールボックスに対して保持ポリシーやアクセス権を設定
| 観点 | メリット | 注意点 |
|---|---|---|
| 実装コスト | アプリ側の Bcc 設定だけで実現可能 | アプリごとの実装漏れに注意 |
| 運用 | 監視用メールボックスを 1 つ用意すればよい | メールボックス容量・保持ポリシーを計画的に設定する必要あり |
| コンプライアンス | 最低限の「送信メールの控え」として利用可能 | 正式なジャーナリングとは異なり、監査要件によっては不十分 |
「とりあえず送信したメールのコピーがどこかにまとまって残っていてほしい」というレベルであれば、まずはこの Bcc パターンから検討するとよいでしょう。
Exchange Online にきちんと残す：Graph API / SMTP AUTH（OAuth）経由
一方で、法令遵守や社内規程などで、正式な監査・ジャーナリング・DLP の対象にしたい場合は、そもそも Exchange Online を経由する送信方式に寄せるのが王道です。代表的な方法は次の 2 つです。
1. Microsoft Graph API（/sendMail）で送信する
Microsoft Graph の /sendMail エンドポイントを利用すると、Exchange Online のメールボックスを通じてメールを送信できます。このとき、リクエストで saveToSentItems = true を指定することで、送信者の「送信済みアイテム」にメールを保存できます。
POST https://graph.microsoft.com/v1.0/users/{user-id}/sendMail
{
"message": {
"subject": "サンプル通知",
"body": {
"contentType": "HTML",
"content": "<p>これは Graph 経由の送信例です。</p>"
},
"toRecipients": [
{ "emailAddress": { "address": "[email protected]" } }
]
},
"saveToSentItems": true
}
Graph API を利用する場合のポイントは次の通りです。
- Azure AD（Microsoft Entra ID）にアプリケーションを登録し、Mail.Send 権限を付与する
- 委任（ユーザーとして）送信するか、アプリケーション権限（アプリとして）で送信するかを要件に応じて選択
- 送信者アドレスをどのユーザー／共有メールボックスにするかを設計する
- Exchange Online を経由するため、ジャーナリング／監査／DLP ポリシーの対象になる
「送信済みアイテムに絶対に残したい」「eDiscovery で検索対象にしたい」などの要件がある場合は、Graph API による送信が非常に相性の良い選択肢です。
2. SMTP AUTH（OAuth 認証）で Exchange Online リレー
もうひとつの選択肢が、SMTP AUTH（OAuth 認証）を使って Exchange Online をメールリレーとして利用する方法です。従来の基本認証（ユーザー名／パスワード）ではなく、OAuth 認証を構成することで、セキュアにアプリケーションからメールを送信できます。
この場合も、最終的には Exchange Online のメールボックスからメールが送信されるため、次のようなメリットがあります。
- 送信済みアイテムにメールが保存される（構成による）
- ジャーナリング／監査／DLP ポリシーが適用される
- 既存のメールインフラとの統合がしやすい
一方で、次のような点に注意が必要です。
- アプリケーションからの大量送信の場合、スロットリング（スループット制限）に注意
- 送信元の From アドレスをどこまで自由に変えられるか（「送信者のなりすまし」にならないよう権限設計が必要）
- SMTP プロトコル自体の実装・エラー処理が必要になる
サードパーティリレー／アーカイブ製品との組み合わせ
すでにサードパーティのメールセキュリティ／アーカイブ製品を利用している場合、ACS Email からの送信を一度リレーに通し、強制 Bcc やアーカイブ機能を利用してから Exchange Online に配送する構成も考えられます。
この方式の特徴は次の通りです。
- 既存のアーカイブ・コンプライアンス基盤をそのまま活用できる
- ACS Email → リレー → Exchange Online / インターネット という多段構成となるため、設計と運用の難易度はやや高くなる
- メール遅延や障害時の影響範囲を事前に評価しておく必要がある
要件別のおすすめパターン
ここまでの内容を踏まえ、「どの方式を選べばよいか」を要件別に整理します。
| 要件 | おすすめ方式 | コメント |
|---|---|---|
| 最低限、送信メールのコピーがあればよい | ACS Email + Bcc 監視メールボックス | 実装が簡単で、開発コストが低い |
| 送信メールをユーザーの送信済みアイテムに残したい | Microsoft Graph /sendMail（saveToSentItems=true） | Exchange Online 経由となり、ユーザーからも確認しやすい |
| 正式なジャーナリング・監査・DLP の対象にしたい | Graph または SMTP AUTH（OAuth）で Exchange 経由 | コンプライアンス要件が強い場合はこのルートが推奨 |
| 既存のアーカイブ製品と統合したい | サードパーティリレー＋アーカイブ | 既存運用を最大限活用できるが、設計は慎重に |
| とにかく大量高速に送信したい（システム通知中心） | ACS Email をメインに利用（必要なら Bcc） | 配信性能重視。コンプライアンス要件次第で追加策を検討 |
ACS Email と Exchange Online をどう使い分けるか
実務では、「すべて ACS Email に寄せる」または「すべて Graph / Exchange に寄せる」のではなく、次のような使い分けをするケースが多く見られます。
- システム的なステータス通知や監視向け：ACS Email（必要に応じて Bcc）
- ユーザーアクションに紐づく重要な通知（契約や法的な案内など）：Graph / Exchange Online 経由
- マーケティング系一斉配信：専用のドメイン・MailFrom を設定した ACS Email
ポイントは、配信性能・コスト・コンプライアンス・検索性のバランスをとりながら、用途ごとに適切な経路を選ぶことです。
よくある落とし穴と対処ポイント
落とし穴 1：検証ドメインは OK だが MailFrom が増やせない
最初に紹介した通り、これはほぼ確実に クォータ引き上げ未対応です。ドメイン設定を何度見直しても解決しないため、早い段階でサポートリクエストを起票しておきましょう。
落とし穴 2：開発環境では問題なく送れるが、本番で配信エラーが増える
本番ドメインで DMARC を厳格に設定している場合、MailFrom や From ドメインの整合性が崩れると、一気に配信エラーや迷惑メール判定が増えることがあります。検証ドメインでの動作確認だけで満足せず、本番ドメインと同じレベルの DNS 設定を用意したステージング環境でテストしておくと安心です。
落とし穴 3：送信メールの控えがなく、ユーザーからの問い合わせに答えられない
「システムからの自動メールだから大丈夫」と考えて控えの仕組みを入れないと、「本当にそのメールが送信されているのか」「どの内容で送られたのか」を後から確認できないという事態になりがちです。
最低限、次のどれかは導入しておくことをおすすめします。
- ACS Email の送信ログを別途ストレージ（例：Azure Table / Cosmos DB / Application Insights）に記録
- Bcc 監視メールボックスへのコピー
- Graph / Exchange 経由の送信（送信済みアイテムに保存）
すぐにやることチェックリスト（実践版）
最後に、本記事の内容を踏まえてすぐに取り組めるタスクを整理します。
- ACS Email のクォータを確認し、必要であれば引き上げを申請する
- MailFrom が追加できない場合は特に優先度高
- 将来の送信量を見積もり、余裕のある上限を申請する
- MailFrom アドレスを用途ごとに整理し、命名ルールを決める
- 例：[email protected]、[email protected] など
- DNS・認証設定と合わせて運用設計を文書化する
- 送信メールの保存・追跡要件を整理する
- 監査義務の有無、保存期間、検索方法
- ユーザーの送信済みに残す必要があるか、控えとして残ればよいか
- Bcc 運用で足りるか評価する
- 足りる場合：Bcc 先のメールボックス設計と保持ポリシーを決める
- 足りない場合：Graph / SMTP OAuth / アーカイブ製品との連携を検討する
- 将来的な拡張を見据えたアーキテクチャを整理する
- ACS Email と Graph のハイブリッド運用パターン
- 監査／セキュリティチームとの合意形成
まとめ：MailFrom と送信メール保存のポイントを押さえて ACS Email を本番投入する
本記事で解説したポイントを改めて整理すると、次のようになります。
- MailFrom の [追加] がグレーアウトしている場合、多くは「送信数上限（クォータ）の未引き上げ」が原因
- Azure サポートに無償でクォータ引き上げを申請することで解決可能
- 承認後、ポータルや CLI から複数の MailFrom を登録できるようになる
- ACS Email は Exchange Online を経由しないため、送信済みアイテムやジャーナリング、DLP はそのままでは効かない
- 「控え」が欲しいだけなら Bcc 運用がシンプル
- コンプライアンス要件が厳しい場合は、Graph や SMTP OAuth で Exchange 経由に寄せる
- 用途ごとに MailFrom を分け、DNS（SPF/DKIM/DMARC）と整合させることで、配信到達性とトラブルシュート性が向上する
- ACS Email と Exchange Online（Graph / SMTP）をうまく使い分けることで、パフォーマンス・コスト・コンプライアンスのバランスが取れたメール基盤を構築できる
「MailFrom が追加できない」「送信メールが残らない」といった悩みは、ACS Email を本番運用しようとするとほぼ必ずぶつかるポイントです。しかし、仕様と設計パターンさえ理解してしまえば、Azure 上で安全かつ拡張性の高いメール送信基盤を構築することができます。ぜひ、本記事の内容を参考に、自社の要件に合った最適なアーキテクチャを検討してみてください。
コメント