Azure Communication Services の Email 機能で独自ドメインを設定すると、「MailFrom（送信者ユーザー名）」をブランドやシステムごとに分けて運用したくなります。しかし実際にやろうとすると、ポータルの［追加］ボタンがグレーアウトしていて一切押せない――という状況に陥ることがあります。本記事では、その原因と実務レベルの回避策・恒久対策を、Azure CLI の具体的なコマンド例とサポート申請のテンプレート付きで詳しく解説します。
Azure Communication Services EmailでMailFromが追加できない現象とは
まず、問題の状況を整理します。
- Azure Communication Services（以下 ACS）で Email Communication Service リソースを作成
- 独自ドメイン（custom domain）を追加し、SPF・DKIM・CNAME なども含めて「検証済み」状態になっている
- 既定の MailFrom（例：
[email protected]）からメール送信はできている - ポータルの「MailFrom アドレス」画面で新しい送信者ユーザー名（MailFrom）を追加しようとすると、［追加］ボタンが常にグレーアウトしたままで押せない
DNS や SPF の設定などを見直しても変化がなく、Azure ポータル側の問題なのか、サービス仕様なのかが分かりにくいケースです。実はこの現象は、サービスの送信制限（スロットリング tier）と UI の制約が組み合わさって発生していることが多く、正しい切り分けと対処をすれば解決できます。
MailFromの［追加］ボタンがグレーアウトする主な原因
原因1：既定送信制限（デフォルト tier）による仕様制限
最も多いのが、「既定の送信制限（例：Mercury tier）」にとどまっており、新しい MailFrom（送信者ユーザー名）が作成できない状態になっているケースです。
最近の更新により、以下のような仕様が導入されています。
- 既定 tier（デフォルト送信制限）の ACS Email リソースでは、新しい MailFrom / Sender Username を作成できない
- Azure 管理ドメイン（
*.azurecomm.netなど）だけでなく、カスタムドメインでも同様に制限される場合がある - この状態ではポータルの［追加］ボタンが無効化され、場合によっては API や CLI での作成もブロックされる
Microsoft の Q&A やコミュニティでも、デフォルト tier（Mercury）では MailFrom 追加が禁止されており、サポートに依頼して tier を上げる必要があると案内されています。
また、公式ドキュメントの「複数の送信者アドレスを追加する」クイックスタートでも、送信者ユーザー名を作成する前提条件として「既定より高い送信制限に引き上げられたカスタムドメイン」が必要と明記されています。
つまり、MailFrom の［追加］が押せない場合、単なる UI バグではなく、「まだそのドメイン／リソースに対して MailFrom を増やしてよい評価（レピュテーション）・送信レベルに達していない」というサービス側の判断でブロックされている可能性が高いということです。
原因2：Azureポータル UI 側のみの不具合・遅延
もう一つ比較的よく報告されるのが、Azure ポータル上だけで MailFrom の追加ができないが、Azure CLI または SDK では作成できるというパターンです。
ブログや技術記事、コミュニティ投稿でも「ポータルでは［追加］ボタンがグレーアウトしているが、az communication email domain sender-username create を実行すると MailFrom が作成され、数分後にポータル側にも表示される」といった事例が共有されています。
この場合は、
- 裏側の API / サービスは正常だが、ポータル UI 側が tier 判定や制限情報を取り扱えていない
- UI のデプロイやキャッシュが追いついておらず、一時的に「押せない」見た目になっている
といった UI 起因の問題である可能性が高くなります。
原因3：権限（RBAC）不足による UI 無効化
Azure のほかのリソースと同じく、Email Communication Service や関連リソースに対して十分な RBAC 権限がない場合、ポータルのボタンが表示されていても 押せない / 保存できない 状態になることがあります。
特に確認したいロールは次のとおりです。
- 対象の Subscription / Resource Group に対して Owner または Contributor ロールが付与されているか
- リソースレベルでのカスタムロールや、より細かい制限が設定されていないか
- Azure AD 側の条件付きアクセスやポリシーでポータルの操作が制限されていないか
権限不足の場合、CLI でも同様のエラー（AuthorizationFailed など）が発生しますので、まずは自分のロールを確認し、必要に応じて管理者に付与を依頼しましょう。
原因4：データロケーション不一致・クォータ制限など
ややレアケースですが、以下のような要因で MailFrom 追加が失敗するケースもあります。
- ACS リソースと Email ドメインの データロケーションが一致していない
- メール送信クォータ（1日あたりの通数など）が既に上限に近く、新規 MailFrom の作成が保留されている
Microsoft Q&A では、これらの要因が疑われる場合はサポートで「メールクォータの増加」を依頼することで解決した事例も紹介されています。
原因別のチェックポイント一覧
| 想定原因 | 主な症状 | 確認方法 | 対処 |
|---|---|---|---|
| 既定送信制限（デフォルト tier） | ポータルの［追加］が常にグレーアウト、既定 MailFrom しか存在しない | サポートに tier / sending limit を確認してもらう | メール送信実績を積み、送信制限の引き上げ（quota increase）を申請 |
| ポータル UI の不具合 | CLI では MailFrom 作成成功、数分後に UI に反映される | CLI の sender-username list で一覧確認 | 暫定的に CLI で運用し、ポータルの修正を待つ |
| 権限不足 | ボタンは押せるが保存でエラー、またはボタン自体が無効 | 自分のロールを Azure Portal / Azure CLI で確認 | Owner / Contributor 以上のロールを付与してもらう |
| ロケーション不一致・クォータ制限 | CLI でもエラー、メッセージに Location / Quota に関する記述 | Azure サポートでリソースの詳細を確認 | 適切なリージョンで作り直す、またはクォータ増加を依頼 |
まずは即効性重視：Azure CLIで MailFrom（送信者ユーザー名）を作成する
業務で「今すぐ MailFrom を分けないと困る」というケースでは、まず Azure CLI から MailFrom を直接作成してしまう方法が有効です。ポータルがグレーアウトしていても、CLI では作成できるケースが多数確認されています。
前提条件の確認
CLI で MailFrom（送信者ユーザー名）を作成する前に、次の状態になっていることを確認します。
- Azure CLI がローカルまたは Cloud Shell にインストールされている
- ACS Email Communication Service リソースが既に作成済み
- 対象のカスタムドメインが「検証済み（Verified）」状態
- 自分のアカウントが、対象リソースに対して Contributor 以上の権限を持っている
問題のリソースにログインするには、以下のように az login を実行します。
az login
az account set --subscription <サブスクリプションIDまたは名前>
communication拡張モジュールの導入
初めて ACS Email を CLI から操作する場合は、communication 拡張を追加します。
az extension add -n communication
このコマンドは、Azure CLI の communication email コマンド群を利用できるようにするものです。拡張のドキュメントでも、この拡張が sender-username 関連のコマンドを提供することが案内されています。
sender-username createでMailFromを作成する
MailFrom（送信者ユーザー名）を新規作成するためのコマンドの基本形は次のとおりです。
az communication email domain sender-username create \
--resource-group <リソースグループ名> \
--email-service-name <Emailサービスのリソース名> \
--domain-name <検証済みドメイン（例: contoso.com）> \
--sender-username <ユーザー名（ローカル部）> \
--username <ユーザー名（通常は sender-username と同じ）> \
--display-name "<送信表示名>"
具体例として、[email protected] という MailFrom を作成したい場合は、次のようになります。
az communication email domain sender-username create \
--resource-group Contoso-RG \
--email-service-name Contoso-EmailService \
--domain-name contoso.com \
--sender-username support \
--username support \
--display-name "Contoso サポート窓口"
--sender-username と --username の値は同じにしておくのが無難です（多くのドキュメントやサンプルでも同値が推奨されています）。
作成したMailFromの確認
作成に成功したら、次のコマンドでドメインに紐づく MailFrom（送信者ユーザー名）の一覧を確認できます。
az communication email domain sender-username list \
--resource-group Contoso-RG \
--email-service-name Contoso-EmailService \
--domain-name contoso.com
個別の MailFrom を詳細表示するには、show コマンドを使います。
az communication email domain sender-username show \
--resource-group Contoso-RG \
--email-service-name Contoso-EmailService \
--domain-name contoso.com \
--name support
ここまで実施して問題なく作成・表示できるにもかかわらず、ポータルの［追加］ボタンはグレーアウトしたままというケースもあります。その場合は、ポータル UI の不具合または仕様ラグと割り切り、CLI を主とした運用に切り替えるのが現実的です。
長期的な解決策：送信制限（メールクォータ）の引き上げをサポートに申請する
前述のとおり、MailFrom 追加の根本的な制約は「送信制限（Email sending limit）」が既定 tier に留まっていることが原因である場合が多いです。この tier は、Azure サポートに依頼して引き上げてもらう「クォータ増加リクエスト（quota increase）」で変更できます。
Microsoft の公式ドキュメントでも、ACS Email で大量送信や複数 MailFrom を使う場合には「既定の送信制限を引き上げるために、サポートリクエストを作成すること」が案内されています。
どのようなときに送信制限の引き上げを申請するべきか
次のような状況に当てはまる場合は、送信制限引き上げを前向きに検討すべきです。
- ブランド・システム・用途ごとに MailFrom を分けたい（例：
info@,support@,alert@など） - トランザクションメール（パスワードリセット、注文確認など）とマーケティングメールを明確に分離したい
- 今後、毎日〜毎月数万通〜数十万通のメール送信が見込まれている
- ポータルの［追加］ボタンがグレーアウトしたままで、CLI や SDK でも
quotaやthrottling tierに関するエラーが出る
サポートチケットに記載すると通りが良い情報
Azure サポートへの依頼内容は、できるだけ具体的に書いた方が審査がスムーズになります。以下は、そのままコピーして使えるテンプレート例です（必要に応じて書き換えてください）。
■目的
Azure Communication Services Email において、
MailFrom（Sender Username）を用途ごとに複数追加して運用したい。
■サブスクリプション ID
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
■リソース グループ／リソース名
リソース グループ: <ResourceGroupName>
Email Communication Service: <EmailServiceName>
■対象ドメイン（検証済み）
<contoso.com など>
■リージョン
Japan East / Japan West / <その他>
■現象
・Azure Portal の MailFrom アドレス画面にて、［追加］ボタンがグレーアウトしており押下できない。
・既定の MailFrom（DoNotReply@<domain>）からの送信は正常に行えている。
・Azure CLI では Sender Username の作成可否が <成功／失敗>。エラーメッセージ: <あれば記載>
■希望内容
・既定送信制限（Default Tier）から、MailFrom を複数作成可能な tier へのアップグレードを希望。
・Sender Username を 100 件以上作成可能な送信制限への引き上げを希望（具体的な数は相談可）。
■ユースケース
・サービス／ブランドごとに MailFrom を分離（例: info@, support@, alert@, billing@ など）。
・トランザクションメール（注文通知、パスワードリセット）と一斉通知（メンテナンス案内）を送信元で区別。
・社内システム（監視アラート）と対外向けシステム（会員通知）を MailFrom で区別したい。
■想定される送信ボリューム
・平常時：1日あたり <XXX> 通程度
・ピーク時：1時間あたり <YYY> 通程度
■影響度・期日
・新規サービスリリースのため、YYYY/MM/DD までの対応を希望。
・MailFrom を分けられない場合、ユーザーにとってメールの判別が難しくなるため、
認証メールの見落とし・誤削除のリスクが高まる。
■連絡先
・担当者名／メールアドレス／電話番号
このように、「何のために MailFrom を増やしたいのか」「どれくらいの送信を見込んでいるのか」を具体的に書いておくと、単なる制限解除ではなくビジネス要件として理解してもらいやすくなります。
運用・設計の観点から見る MailFrom（送信者ユーザー名）のベストプラクティス
せっかくサポートに依頼して MailFrom を追加できるようにするのであれば、設計段階である程度ルールを決めておくことをおすすめします。
用途ごとにMailFromを分ける
よくあるパターンとして、次のような分類があります。
- 認証・セキュリティ系：
[email protected]/[email protected] - トランザクションメール：
[email protected]/[email protected] - サポート窓口：
[email protected] - 監視・アラート：
[email protected]/[email protected]
このように用途ごとに分けておくと、ユーザー側でのフィルタリングや管理側のログ分析が行いやすくなり、どの種類のメールがどれくらい送信されているかを簡単に把握できます。
ブランド別・システム別にMailFromを設計する
複数ブランドや複数 SaaS を運営している場合、ブランドごとに MailFrom を切り分けることも有効です。
- ブランドA：
[email protected],[email protected] - ブランドB：
[email protected],[email protected]
こういった設計を踏まえると、「MailFrom は最大何件必要になるのか」が見えてきます。この見積もりをサポートへのクォータ引き上げ依頼に含めておくことで、一度の申請で十分な上限を確保しやすくなるというメリットがあります。
実務で役立つ切り分けフロー
実際に MailFrom の［追加］ボタンがグレーアウトしている場合に、現場でどう切り分けていけばよいかをフローとしてまとめます。
ステップ1：ドメイン状態の確認
- Azure Portal の Email ドメイン画面で、対象ドメインが 「検証済み（Verified）」 になっているか
- DNS に設定した TXT / MX / CNAME / SPF / DKIM レコードに誤りがないか
DNS が未反映や誤設定の場合、そもそも MailFrom 追加画面に進めないこともあります。ただし、本記事のテーマである「［追加］ボタンがグレーアウト」は、DNS が正しくても発生しうる点に注意してください。
ステップ2：権限（RBAC）の確認
- 対象の Subscription / Resource Group / Email Service に対して自分に Contributor 以上 のロールがあるか
- カスタムロールや制限付きロールになっていないか
必要に応じて、管理者から一時的に広めの権限を付与してもらい、それでも再現するかを確認します。
ステップ3：CLIでMailFromが作れるかを検証
前述のコマンドで MailFrom の作成を試してみます。
az communication email domain sender-username create ...
- CLI で作成成功 → ポータル UI の問題、または tier の判定ロジックが UI に反映されていない可能性が高い
- CLI でも permissions / quota / throttling などのエラー → 送信制限やクォータが原因の可能性が高い
ステップ4：サポートで tier / sending limit を確認し、必要に応じて引き上げ依頼
CLI 実行結果を含めてサポートに問い合わせ、
- 現状の tier（Mercury などのデフォルト tier）
- 1日あたり・1時間あたりの送信制限（メールクォータ）
- MailFrom / Sender Username の最大数
を確認します。必要であれば前述テンプレートをベースに、送信制限の引き上げ（quota increase）を依頼しましょう。
ステップ5：運用ルールの整理とドキュメント化
最後に、MailFrom をどのように使い分けるか、社内の運用ルールを簡単に文書化しておくと、次のようなメリットがあります。
- 担当者が増えたときに「どの MailFrom を使うべきか」が一目で分かる
- 誤った MailFrom で大規模な一斉メールを送ってしまう事故を防ぎやすい
- 今後さらに MailFrom を追加したいときに「なぜ必要なのか」を説明しやすい
よくある疑問・トラブルシューティング FAQ
Q. DNS設定（SPF/DKIM）を直せば［追加］ボタンは押せるようになりますか？
A. 多くの場合、DNS 設定は「ボタンがグレーアウトする」直接の原因ではありません。 DNS や SPF/DKIM は主にメールの 到達性・評価・スパム判定 に関わる要素であり、MailFrom 追加 UI の有効/無効は、どちらかといえば tier（送信制限）やポータル UI のロジック に左右されます。
もちろん DNS の誤設定があれば別途修正すべきですが、「ボタンが押せない」問題は送信制限周りを疑った方が近道です。
Q. 「550 5.3.5 Email sender’s username is invalid」というエラーが出るのですが？
A. これは主に、SMTP Relay 経由で送信する際に MailFrom / Sender Username が ACS 側に登録されていない 場合に発生するエラーです。Blog 記事などでも、ACS の SMTP Relay を試す際にこのエラーに遭遇した例が紹介されています。
このエラーが出る場合は、
- SMTP で指定している送信者アドレス（
MAIL FROM）が、ACS に登録済みの MailFrom と完全一致しているか - ドメイン名やローカル部の大文字・小文字、スペースなどに余計な違いがないか
を確認し、必要に応じて CLI から該当の MailFrom を登録してから再送信してください。
Q. コミュニティで「カスタムドメインはデフォルトで約100件まで作れる」と聞きましたが本当ですか？
A. 一部のブログや経験談では「カスタムドメインでは 100 件程度まで Sender Username を作成できた」といった報告がありますが、これは時期やリソース、地域、送信レピュテーションなどによって変動しうる値です。
最新かつ自分のテナント固有の上限値を知りたい場合は、最終的には Azure サポートに確認してもらうのが最も確実です。
短期はCLIで回避、長期はサポートで上限引き上げという二段構えが現実的
ここまでの内容をまとめると、Azure Communication Services Email において MailFrom（送信者ユーザー名）の［追加］ボタンがグレーアウトしている場合、主なシナリオは次の2つです。
- サービス仕様（既定送信制限 / tier）によるブロック
- Azure ポータル UI 上の不具合・制約
そして、それぞれに対する現実的な対策は次のように整理できます。
- 短期的な回避策：ポータルの状態に依存せず、Azure CLI や SDK から MailFrom を作成する
- 長期的な恒久対策：Azure サポートに 送信制限（メールクォータ）の引き上げを依頼し、正式に複数 MailFrom を運用できる tier にアップグレードしてもらう
実務的には、まず CLI で必要な MailFrom を確保して業務影響を抑え、その裏でクォータ増加を申請する、という二段構えで進めるのが最も堅実です。
これから Azure Communication Services Email を本格的に業務で利用する方は、MailFrom の設計と送信制限の引き上げをセットで検討しておくと、後々のトラブルや手戻りを大きく減らすことができます。
コメント