Azure Communication Services（ACS）Email / Email Communication Services を使っていて、カスタムドメインはすべて Verified なのに Mail From の「追加」ボタンだけがグレーアウトして押せない……という問い合わせが急増しています。本記事では、この現象の正体と、無料のクォータ増枠申請による根本解決手順、あわせて CLI から Mail From を追加する方法や運用ベストプラクティスまで、実務目線で詳しく解説します。
Azure Communication Services Email と Mail From の基礎整理
まずは問題の整理の前に、ACS Email の用語と構造を簡単におさらいしておきます。
ACS Email / Email Communication Services とは
Azure Communication Services Email（ポータル上では「Email Communication Services」）は、アプリケーションからの通知メールやトランザクションメールを高いスループットで送信できるマネージドサービスです。
Azure 管理ドメイン（xxxx.azurecomm.net）だけでなく、自社のドメイン（notify.contoso.com など）のカスタムドメインからも送信できます。
- Azure 管理ドメイン：テスト向け。送信数・送信頻度に厳しめの制限。
- カスタムドメイン：本番向け。自社ドメインで SPF / DKIM / DMARC を設定して送信。
Mail From（P1）と From（P2）の違い
ACS Email には「Mail From アドレス」を登録する画面がありますが、これは SMTP 的には P1 の送信者（Envelope From） を指します。
- Mail From（P1）：Envelope From。SMTP での実際の送信元。SPF 判定に使われる。
- From（P2）：メールクライアントに表示される From。いわゆる「差出人」。
ACS Email では、この Mail From に相当する「Sender Username」 を複数登録できます。たとえば：
[email protected]（システム通知）[email protected]（請求書メール）[email protected]（サポート窓口）
DNS 検証（Domain / SPF / DKIM / DKIM2）がすべて Verified であること
カスタムドメインを ACS Email で使う場合、ポータルの 「Provision domains」 からドメインを追加し、次の DNS レコードを設定します。
- Domain（TXT）
- SPF（通常は TXT）
- DKIM / DKIM2（CNAME）
これらがすべて Verified になっていることが Mail From 追加の絶対条件です。どれか 1 つでも Unverified の状態だと、そもそも Mail From の「追加」を押してもエラーになったり、UI が有効化されないケースがあります。
| 項目 | 役割 | Verified にならない典型例 |
|---|---|---|
| Domain | ドメイン所有者の確認 | TXT レコードのタイプミス / TTL が長すぎる |
| SPF | どのサーバーから送信が許可されているか | ~all などソフトフェイル設定での検証失敗など |
| DKIM / DKIM2 | 署名による改ざん防止 | ホスト名をそのまま貼らずに書き換えてしまう 等 |
ここまでは通常の「カスタムドメインを使ったメール送信」の前提ですが、今回の「追加ボタンが無効」問題は、それらをクリアしていても発生します。
症状：Mail From の「追加」ボタンがグレーアウトする
典型的な再現パターンは次のとおりです。
- Azure ポータルで Email Communication Services（ECS）リソースを開く。
- 左メニューの 「Provision domains」 からカスタムドメインを選択。
- 「Email Services > Mail From addresses」を開く。
- 既定の
DoNotReply@yourdomainは表示されるが、「Add」ボタンがグレーアウトして押せない。
DNS も権限も問題なさそうなのに、ポータル上で Mail From を追加できない ― これが今回の話題の核心です。
原因：既定の送信上限（Sending Limits / Throttling Tier）が低いままだと Mail From を追加できない
この現象については、Microsoft サポートの回答として以下のような内容が共有されています。
- 新しい ECS リソースは 初期スロットル tier（デフォルトの送信上限） に置かれる。
- この tier のままでは、以下の操作が 制限 される：
- ユーザーエンゲージメントトラッキングの有効化
- 新しい Mail From（Sender Username）の追加（ポータル / API / CLI 含む）
- そのため、既定の送信上限を引き上げる（quota increase）までは Mail From が 1 件固定（DoNotReply@…） という挙動になる。
これは 2024 年以降に導入された比較的新しい仕様で、公式ドキュメント側も段階的に更新されている状況です。ACS Email のサービス制限のページでも、初期の送信レート制限からスタートし、必要に応じてサポートに依頼して引き上げる という運用が前提であることが明記されています。
なぜ送信上限と Mail From が紐づくのか
この設計になっている理由は、大きく次の 2 点です。
- スパム・濫用対策
新規テナントがいきなり大量の Mail From を作って大量配信してしまうと、スパム判定・IP レピュテーションの悪化につながります。そこで、ある程度の正常な送信実績と良好な失敗率（1% 未満など） が確認できるまでは、Mail From の追加を制限しようという考え方です。 - サポート側での事前審査（レピュテーションチェック）
送信上限のクォータ増枠申請では、ビジネス内容や送信ボリューム、バウンス率などをもとに審査が行われます。 そのプロセスを通過したテナントに対して、複数 Mail From を使った高ボリューム送信を開放する、という流れになっています。
つまり、Mail From の「追加」ボタンが無効なのは、ほぼ「あなたの ECS がまだ初期送信 tier のままです」というサインだと捉えるのが実務上は分かりやすいです。
解決策①：送信上限（Sending Limits）のクォータ増枠をサポートに申請する【推奨】
もっとも確実で、Microsoft 公式の推奨パスが 無料のクォータ増枠申請 です。
公式の「Quota increase for email domains」記事でも、デフォルト送信上限はあくまでスタート地点であり、本番利用ではサポートに依頼して上限を引き上げる 手順が案内されています。
クォータ増枠申請の全体像
| 項目 | 設定値 / 内容 |
|---|---|
| Issue type | Service and subscription limits (quotas) |
| Quota type | Azure Communication Services Email: Sending Limits |
| 対象スコープ | 該当のサブスクリプション / リソースグループ / ECS の Email ドメインリソース |
| 申請内容 | 希望する新しい送信上限（tier enum：200, 225, 250, 275, 300 …） |
| 費用 | クォータ増枠自体は無償（サポートプランは別途） |
ここでいう tier 値（例：200, 225…）は、実際の「1 時間あたり何通まで送れるか」に対応した内部的なプラン番号です。詳細なマッピングは公開されていませんが、初期値より大きな tier を指定することで、メール送信レートと Mail From 追加の制限が段階的に緩和されます。
ステップバイステップ：サポートリクエストの作成手順
- Azure ポータルで 「Help + support（ヘルプとサポート）」 を開く。
- 「Create a support request（サポート リクエストの作成）」 をクリック。
- Issue type に 「Service and subscription limits (quotas)」 を選択。
- 該当の Subscription を選択。
- Quota type =「Azure Communication Services Email: Sending Limits」 を選択。
- もしドロップダウンにこの項目が出てこない場合は、ポータルの旧 UI に切り替えるか、「説明」欄に手入力するよう案内されている事例もあります。
- Additional details タブで、次を入力：
- Location（リージョン）
- Resource Group
- 対象の Email Communication Services ドメインリソース
- New Email sending limit（tier enum：200, 225, 250, 275, 300…）
- 確認用に同じ tier 値を再入力
- 同じ画面で、質問票テンプレート（テキストファイル） を添付。
- 内容を確認してサポート リクエストを作成。
Developer プランを含むすべてのサポートプランで、クォータ増枠自体は無償であると案内されています。
質問票テンプレートのサンプル
公式ドキュメントでは、メール送信の用途やボリューム、レピュテーションに関する質問票をテキストファイルにして添付することが推奨されています。
そのエッセンスを含んだサンプルを、以下のように用意しておくとスムーズです。
【Customer Information】
Company name:
Company website:
Business description:
- どのようなサービスで ACS Email を利用しますか？
- 送信するメールの種類（例：注文確認、パスワードリセットなど）
【Email Service Information】
Subscription ID:
ACS Resource Name:
ECS Resource Name:
Custom domain:
- 既に本番トラフィックで利用していますか？（Yes/No）
- 1 日あたり / 1 時間あたりの想定送信通数:
- 現在のバウンス率・スパム報告率（概算）:
【Quota Request】
Current sending tier (if known):
Requested sending tier (e.g. 250):
Reason for increase:
- どの程度の期間でどのくらいの増加を見込んでいるか
- 今後の運用ポリシー（オプトイン、配信停止リンク等）
もちろん、英語での回答が基本ですが、日本語で下書きしてから翻訳する方が記載漏れを防げます。
クォータ増枠申請後に確認すべきこと
サポートから「送信上限を引き上げました」といった連絡を受け取ったら、次の確認を行います。
- 一度ポータルからサインアウトし、ブラウザをリロードして再サインインする。
- 対象の ECS リソース > Provision domains > カスタムドメイン > Mail From addresses を開き、「Add」ボタンが有効化されているかを確認。
- まだ無効な場合は：
- 選択しているのが Azure 管理ドメインではなくカスタムドメインになっているか。
- 別サブスクリプション / 別リージョンの ECS を見ていないか。
- ロール／権限に問題がないか（後述）。
解決策②：CLI / PowerShell から Mail From（Sender Username）を追加する
ポータル UI の「Add」がグレーアウトしていても、CLI や管理 SDK から Mail From を追加できるケースがあります。実際、Microsoft 公式ドキュメントやコミュニティ記事でも、UI はグレーアウトだが CLI で Sender Username を作成している例 が紹介されています。
一方で、Microsoft サポートの回答では「初期送信 tier のままではポータル・API・CLI のいずれからも Mail From を追加できない」という説明もあり、実際の挙動はタイミングやリージョンによって揺れがあります。
そのため、根本的な対処としてはクォータ増枠申請が必須であり、CLI / PowerShell はあくまで「UI が直らないときの迂回手段」程度に捉えておくのが安全です。
Azure CLI で Sender Username（Mail From）を追加する
Azure CLI には az communication email 拡張機能があり、その中の domain sender-username コマンドで Mail From を管理できます。
前提
- 最新の Azure CLI がインストール済み
communication拡張を追加済み：
az extension add --name communication
- Azure にログイン済み：
az login
Sender Username 作成コマンドの例
以下は [email protected] という Mail From を追加したいケースの例です。
az communication email domain sender-username create \
--email-service-name "my-ecs-name" \
--resource-group "rg-mail" \
--domain-name "example.com" \
--sender-username "support" \
--username "support" \
--display-name "Example Support"
--sender-username：ローカルパート（support）--username：同じ値で問題ありません（ユーザー識別用）--display-name：メールクライアントに表示される差出人名
このコマンドが成功すると、ポータルの Mail From 一覧にも新しいアドレスが表示されます。
ただし、初期送信 tier のままの場合は 403 Forbidden などで失敗する可能性があります。その場合は、やはりクォータ増枠申請が先決です。
PowerShell から追加するパターン
現時点では、PowerShell 専用の「Mail From 追加」コマンドレットは限定的で、多くの場合は次のどちらかのアプローチを取ります。
- PowerShell からそのまま
azCLI を呼び出す（運用がシンプル） - .NET 用の ACS 管理 SDK を PowerShell から利用して ARM リソースとして Sender Username を作成する
簡易的には、以下のように PowerShell スクリプトから CLI を呼び出すだけでも十分です。
$domain = "example.com"
$ecs = "my-ecs-name"
$rg = "rg-mail"
$user = "support"
$name = "Example Support"
az communication email domain sender-username create `
--email-service-name $ecs `
--resource-group $rg `
--domain-name $domain `
--sender-username $user `
--username $user `
--display-name $name
CI/CD パイプライン（GitHub Actions / Azure DevOps 等）に組み込む場合も同じコマンドを利用できるので、本番環境構築の自動化にも向いています。
権限・ロールまわりの確認ポイント
Mail From の追加やクォータ増枠申請では、Azure RBAC の権限不足が原因で操作ができないケースもあります。最低限、次のロールを押さえておきましょう。
| 用途 | 推奨ロール | 備考 |
|---|---|---|
| サポートリクエストの作成 | Support Request Contributor 以上 | サブスクリプションスコープで付与されていること |
| ECS / ACS リソース操作（Mail From 追加など） | Contributor 以上 | 少なくとも対象リソースグループに対する Contributor 権限 |
権限に問題がある場合は、ポータル上でボタンがグレーアウトしたり、CLI で Authorization エラーが返ってきます。その場合は、テナント管理者に RBAC の見直しを依頼しましょう。
チェックリスト：『追加』ボタンが無効なときに見るべき項目
ここまでの内容を、原因切り分けのためのチェックリストにまとめます。
| チェック項目 | 確認場所 | OK な状態 |
|---|---|---|
| ドメイン DNS 検証 | ECS > Provision domains 画面 | Domain / SPF / DKIM / DKIM2 がすべて Verified |
| Azure 管理ドメインではないか | 同上 | xxxx.azurecomm.net ではなく、自社のカスタムドメインを選択している |
| RBAC 権限 | Access control (IAM) | Subscription / RG / ECS に Contributor 以上 + Support Request Contributor |
| 送信上限 tier | サポート回答 or ドキュメント | 初期 tier から必要な tier に引き上げ済み（サポートへ確認） |
| ポータルのキャッシュ | – | ブラウザのリロード・シークレットウィンドウで確認 |
| CLI での挙動 | Azure CLI | 403 が出る場合は tier 制限の可能性が高い |
複数 Mail From を使うときの設計・運用ベストプラクティス
無事にクォータ増枠が完了し、Mail From の「追加」ボタンが有効になったら、次は「どう設計するか」です。いきあたりばったりで Mail From を増やすと管理しづらくなるので、最初にルールを決めておくのがおすすめです。
用途ごとに Mail From を分ける
no-reply@：ログイン通知、パスワードリセット、システムアラートなど。transaction@：注文確認、出荷通知、請求書などのトランザクションメール。marketing@：キャンペーン情報、ニュースレターなど（別サービスに分離することも検討）。support@：問い合わせ返信・サポート窓口。
From（P2）の表示名も合わせて設計しておくと、受信者側の混乱を防げます。
環境（開発 / 検証 / 本番）でドメインやサブドメインを分離する
- 本番：
@notify.example.com - ステージング：
@stg-notify.example.com - 開発：
@dev-notify.example.com
これにより、本番ドメインのレピュテーションに悪影響を与えずにテストできます。クォータ増枠も、本番とステージングで分けて申請する戦略が取りやすくなります。
Exchange Online 側のテナント送信制限との棲み分け
Microsoft 365 / Exchange Online では、新しい「Tenant Outbound Email Limits（TERRL）」により、1 日あたりの外部送信数にテナント単位の上限が導入されています。上限を超えると、それ以上外部にメールを送れなくなります。
大量配信が必要なシナリオでは、ユーザーのメールボックスから送るのではなく ACS Email を使う ことが推奨されており、Mail From を適切に設計して ACS から配信することで、TERRL 制限の影響を受けずに高ボリュームの送信が可能になります。
よくある質問（FAQ）
Q. カスタムドメインは いくつまで接続できますか？
A. 1 つの Communication Services リソースに対して、最大 100 個のカスタムドメイン をリンクできると公式ドキュメントに記載されています。
それぞれのドメインに対して Mail From を複数定義できますが、極端に大量のアドレスを登録する場合はサポートに相談した方が安全です。
Q. Azure 管理ドメイン（xxxx.azurecomm.net）だけ使っている場合も増枠できますか？
A. メールクォータ増枠の公式ドキュメントでは、本番利用と上限引き上げにはカスタムドメインの利用が必須とされています。Azure 管理ドメインはあくまで試用目的で、送信数や頻度に強い制限が残ります。
Q. 最終的にどのくらいの送信上限まで上げられますか？
A. 具体的な上限値はケースバイケースですが、サービス制限のページでは 1–2 百万通/時の高スループットもサポート可能 と記載されています。
ただし、そこまでの上限を得るには、低い失敗率（1% 未満）と良好なドメインレピュテーション が条件になります。
Q. Mail From の「追加」ボタンが有効にならないままです。
A. 次の順で確認してください。
- カスタムドメインの DNS がすべて Verified か。
- Azure 管理ドメインではなく、目的のカスタムドメインを選んでいるか。
- RBAC で Contributor 以上の権限があるか。
- クォータ増枠申請が承認済みか（サポートからのメールを確認）。
- 別ブラウザ／シークレットウィンドウで開き直してもダメか。
- CLI の
sender-username createコマンドで 403 / 429 以外のエラーになっていないか。
それでも解決しない場合は、サポートチケットに上記の状況を追記して再問い合わせするのが近道です。
まとめ：『追加』ボタンが無効なら、まずは送信上限を疑う
本記事のポイントを最後に整理します。
- Mail From の「追加」ボタンがグレーアウトしている場合、DNS 検証済みでも、初期送信 tier のままだと追加が制限される仕様になっています。
- 根本解決には、「Service and subscription limits (quotas)」>「Azure Communication Services Email: Sending Limits」 でサポートにクォータ増枠を申請します（増枠自体は無償）。
- CLI / PowerShell からの Mail From 追加も可能ですが、tier によっては CLI でもブロックされるため、最終的にはクォータ増枠が不可欠です。
- 複数 Mail From を設計するときは、「用途（通知 / トランザクション / サポート）」「環境（本番 / ステージング / 開発）」「レピュテーション保護」を意識してドメインとアドレスを整理しましょう。
「DNS もコードも正しいのに Mail From が増やせない」というときは、ACS Email 側の送信上限がボトルネックになっていないかをまず疑い、早めにクォータ増枠申請を行うことが、トラブルシューティングとスケールアウトの近道になります。
コメント