Azure Communication Services Email でカスタムドメインをプロビジョニング済みなのに、MailFrom アドレス追加の「＋ 追加」ボタンがグレーアウトして押せない──。実はこれは権限不足ではなく、送信上限クォータが既定のままだから起こることが多いです。原因と、最短で解決する手順をまとめます。
現象：MailFrom の「＋ 追加」がグレーアウトしたまま
Azure Communication Services Email（以下、ACS Email）でカスタムドメインを用意し、状態が「Provisioned（プロビジョニング済み）」になっているのに、ポータルの MailFrom Addresses 画面で 「＋ 追加」ボタンが押せないことがあります。
このとき多くの人が「ロール（権限）が足りないのでは？」と疑いますが、サブスクリプションの所有者（Owner）であっても同じ症状が出るため、権限だけを追いかけると時間を溶かしがちです。
そもそも MailFrom とは何か
MailFrom はメール送信時のエンベロープ From（SMTP の MAIL FROM）に相当する設定で、いわゆるバウンス（不達）通知の戻り先として扱われます。受信者が通常目にするヘッダーの From:（表示名や差出人アドレス）とは別概念です。
ACS Email のポータルにある MailFrom Addresses は、ドメイン配下で利用可能な「送信元ユーザー名（Sender username）」を追加・管理する画面、と理解すると迷いません。
結論：送信上限（Email sending limit）のクォータ増加が前提
「＋ 追加」ボタンが無効な主因は、既定のメール送信上限（Sending Limits）が引き上がっていないことです。ポータル上で MailFrom（Sender username）を増やすには、既定より高い送信上限が適用されたカスタムドメインである必要があります。
重要なポイントは次の2つです。
- Azure Managed Domain（Azure が管理する試用用ドメイン）では、送信上限に関係なく Sender username が有効化できません。
- カスタムドメインであっても、送信上限が既定のままだとポータルの追加ボタンが有効になりません。
なぜそんな仕様なのか（運用目線での背景）
メールは「送れること」以上に「迷惑メール扱いされず届くこと」が重要です。ACS Email は高スループットを想定した設計ですが、いきなり大量配信・多様な差出人を許可すると、ドメイン評判（レピュテーション）や失敗率が悪化した場合の影響が大きくなります。そのため初期状態では送信上限を低くし、段階的に増やす運用を推奨しています。
最初に確認したいチェックリスト
「クォータ増加」だけが原因とは限らないので、まずは状態確認を一度だけ行っておくと、無駄な行き戻りが減ります。
| 確認ポイント | OKの目安 | 確認方法（例） | NGのときの典型症状 |
|---|---|---|---|
| ドメイン種別 | Verified / Provisioned のカスタムドメイン | Email Communication Service の Domains で該当ドメインを開く | Azure Managed Domain だと Sender username が使えない |
| 送信上限 | 既定より高い Sending Limits が適用済み | クォータ増加（Support request）後に反映を確認 | MailFrom の「＋ 追加」ボタンが無効のまま |
| 権限（RBAC） | 少なくとも対象リソースに変更権限がある | サブスクリプション / RG / ドメインリソースの IAM を確認 | ボタンは押せるが保存でエラー、または画面自体が見えない |
| ディレクトリ | 正しい Azure AD テナントで操作している | ポータル右上のアカウント→ディレクトリ切替 | 同じ名前のサブスクリプションが見える／設定が反映されない |
推奨解決策：送信上限クォータの増加を申請してボタンを有効化する
いちばん確実で、長期的にも無駄がないのは送信上限（Sending Limits）のクォータ増加を申請する方法です。承認されるとポータルで MailFrom を追加できるようになります。申請自体は無料で進められるケースが一般的です。
申請の流れ（ポータル）
- サポートリクエストの作成を開く
- Azure ポータルで Help + support（ヘルプ + サポート） → サポート リクエストの作成 を選びます。
- 画面上部の検索や入力欄に quota と入力して進むと、クォータ系の導線に乗りやすいです。
- 要求種別を選ぶ
- Issue type（問題の種類）：Service and subscription limits (quotas)
- Quota type：Azure Communication Services Email: Sending Limits
- 追加情報（Additional details）を入力する
- 対象のリージョン、リソース グループ、ACS Email のドメイン リソースを選択します。
- 希望する新しい送信上限値を指定します（例：200 / 225 / 250 / 275 / 300 など）。
- 値を選んだあとに 確認用の入力（tier enum の再入力）が求められることがあります。
- テンプレートに沿ったテキストを作り、添付して送信する
- Microsoft Learn の「Quota increase for email domains」にあるテンプレート（会社情報や送信形態の質問）をテキストファイルに貼り付け、回答を追記します。
- できあがった
.txtを Additional details のファイル添付欄からアップロードします。
- 内容を確認して作成する
- 送信後、自動返信メールが届くことがあります。
- 審査は自動承認ではなく、送信者評判などを踏まえて判断されます。
添付テキスト（.txt）で聞かれやすい項目と、書き方のコツ
審査では「どんな事業が、どんな宛先に、どんな目的で送るのか」が重要視されます。テンプレートの設問に対して、次の観点を意識すると通りやすくなります。
| 項目 | 何を見られているか | 記載例（考え方） |
|---|---|---|
| 会社情報（会社名 / Webサイト） | 実在性・透明性 | 公式サイトURL、法人名、事業内容を短く |
| 送信内容の概要 | トランザクションかマーケティングか | 例：アカウント通知、請求書、サポート返信など |
| 宛先リストの取得元 | オプトイン（同意）の有無 | 会員登録時の同意、購入者への通知など具体化 |
| 配信停止（Unsubscribe）や抑制 | 苦情率・スパム扱いの抑制 | 配信停止フォーム、サプレッションリスト運用 |
| バウンス管理 | 失敗率の低減 | 不達の監視、無効アドレスの除外フロー |
送信上限を申請する前にやっておくと良いこと
- MX レコードを設定する：ACS Email はアウトバウンド専用でも、MX が無いドメインは受信側に不自然に見えることがあり、スパム判定の一因になります。
- 送信量を段階的に増やす：急激な増加は評判を落としやすいので、数週間かけて増やす運用が推奨されています。
- 失敗率（Failure rate）を下げる：高い上限を有効化するには、失敗率が一定以下であることが要件になる場合があります。
クォータ増加が反映されたら：ポータルで MailFrom を追加する
承認・反映後に Email Communication Service のドメインを開き、MailFrom Addresses へ移動すると「＋ 追加」が有効になっているはずです。そこで Display name（表示名） と MailFrom（送信元ユーザー名）を追加して保存します。
既定の donotreply を理解しておく
ACS Email では、ドメインをプロビジョニングすると既定の MailFrom が自動で作られます。たとえば Azure が管理するドメインでは donotreply@<GUID>.azurecomm.net のような形式になり、カスタムドメインを構成した場合は donotreply@<your-domain> の形式で追加されます。
実運用でおすすめの MailFrom 命名パターン
差出人を増やす目的は「分かりやすさ」と「運用分離」です。部署や用途ごとに分けると、問い合わせ導線や障害時の切り分けが楽になります。
| MailFrom（例） | 用途 | 運用上のメリット | 注意点 |
|---|---|---|---|
| support@your-domain | 問い合わせ返信、チケット通知 | サポート系の返信率が上がりやすい | 返信先（Reply-To）設計も合わせる |
| billing@your-domain | 請求書・支払い関連 | 請求通知の見落としを減らせる | 誤配信が致命的なので宛先検証を強化 |
| security@your-domain | ログイン通知、二要素、警告 | セキュリティ通知の信頼感が高い | 短時間に集中送信しがちなのでレート管理 |
| no-reply@your-domain | 返信不要の自動通知 | 運用窓口を分離できる | 完全に返信不可にするなら文面に代替窓口 |
代替手段：Azure CLI / PowerShell で MailFrom（Sender username）を追加する
「どうしても今すぐ追加したい」「ポータルがまだ有効にならない」といった状況では、Azure CLI や PowerShell から Sender username（MailFrom）を作成できます。
ただし、既定の送信上限は小さく、結局クォータ増加が必要になるケースが多いので、根本解決としてはクォータ申請を優先するのがおすすめです。
Azure CLI の例
Azure CLI では az communication email domain sender-username create を利用します。必要に応じて communication 拡張が導入されます。
az communication email domain sender-username create \
--domain-name <DOMAIN_RESOURCE_NAME> \
--email-service-name <EMAIL_SERVICE_RESOURCE_NAME> \
-g <RESOURCE_GROUP_NAME> \
--sender-username <USERNAME> \
--username <USERNAME> \
--display-name "Support Team"ポイントは –sender-username と –username を同じ値にすることです。
PowerShell の例
PowerShell は Az.Communication モジュールの New-AzEmailServiceSenderUsername を利用します。プレビュー扱いのモジュール／コマンドである点は、運用ポリシーに合わせて評価してください。
New-AzEmailServiceSenderUsername `
-SenderUsername "support" `
-Username "support" `
-DomainName "<DOMAIN_NAME>" `
-EmailServiceName "<EMAIL_SERVICE_NAME>" `
-ResourceGroupName "<RESOURCE_GROUP_NAME>" `
-DisplayName "Support Team"ポータルとCLI/PowerShell、どちらを使うべきか
| 方法 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| ポータル（MailFrom Addresses の「＋ 追加」） | 運用標準に沿って管理したい | GUIで分かりやすい／属人化しにくい | 送信上限クォータ増加が前提 |
| Azure CLI | 自動化したい／手元で即時に作りたい | CI/CDやスクリプトに組み込みやすい | 拡張機能やコマンドのプレビュー扱いに注意 |
| PowerShell | Windows運用／Azモジュールで統一したい | 既存のAz運用資産を流用できる | プレビュー扱いの範囲や更新頻度を把握する |
よくあるハマりどころと対処
送信上限が上がったのに、ボタンが有効にならない
- 見ているドメインが違う：複数のドメインをプロビジョニングしている場合、クォータ増加が適用されたドメインリソースを開いているか確認します。
- ディレクトリ/サブスクリプションが違う：ブラウザで複数テナントを行き来していると反映が見えないことがあります。いったんサインアウト→サインイン、または別ブラウザで確認します。
- 反映待ち：審査が通っても、ポータル表示に若干のタイムラグが出ることがあります。
そもそも送信上限（既定値）がどれくらい低いのか
カスタムドメインでも、最初は「スモールスタート」用のレート制限が設定されています。たとえば送信は 1分あたり 30通、1時間あたり 100通（サブスクリプション単位）といった制限があり、上限の引き上げが可能です。
一方で Azure Managed Domain は、さらに低い制限で、上限引き上げの対象外です。テストはできても本番運用に乗せづらいため、早い段階でカスタムドメインへ移行しておくのが現実的です。
MailFrom を増やす前に押さえたい運用ルール
- 用途ごとに差出人を分け、文面テンプレートも分ける：障害時の切り分けと、問い合わせ導線の最適化につながります。
- 配信停止とサプレッション（抑制）を必ず実装する：苦情率が上がると上限増加が通りにくくなり、最悪の場合は制限強化のリスクもあります。
- バウンス（不達）を放置しない：無効な宛先へ送り続けると失敗率が上がります。失敗率の管理は高クォータの前提条件になり得ます。
まとめ：原因は権限ではなく「送信上限クォータ」
- MailFrom の「＋ 追加」ボタンが押せない主因は、送信上限（Sending Limits）が既定のままであることです。
- Service and subscription limits (quotas) → Azure Communication Services Email: Sending Limits でクォータ増加を申請し、承認されるとポータルから追加できるようになります。
- 急ぎの場合は CLI / PowerShell で追加も可能ですが、実運用では送信上限がボトルネックになりやすいため、クォータ増加を前提に設計するのがおすすめです。
コメント