独自ドメインのメールエイリアス：五つの設定問題と対処法

例えば、独自ドメインのメールエイリアスを設定し、sales@yourcompany.com は自分の受信トレイへ、support@ はサポート窓口へ届くようにしたとします。管理画面では問題なさそうでした。ところが問い合わせが減り、顧客からメールが戻ってきたと言われ、さらに自分が三週間も個人アドレスから返信していたことに気付きます。

ドメインのメールエイリアスが機能しない原因は、単なる入力ミスとは限りません。従来のルーティングと、SPF、DKIM、DMARC といった現在の認証の仕組みが衝突していることがあります。設定時には説明されなかった落とし穴です。

550 5.7.520 や 554 5.4.14 が表示される、あるいはサーバーが 250 OK を返したのにメールが見当たらない場合は、順序立てて調べましょう。この記事では、よくある五つの設定問題と代表的なエラーコード、対応する確認・修正方法を紹介します。

まずエイリアスとメールボックスの違いから理解したい場合は、ドメインのメールエイリアスとメールボックスの比較を先にお読みください。

メールエイリアスの不具合を切り分ける

エイリアスの問題には、よくある五つのパターンがあります。症状とエラーコードを手掛かりに、調べる範囲を絞れます。DNS、ルーティング、管理ポリシーを変更する前に、表のどの行に当てはまるか確認してください。ただし、コードだけで原因が一意に決まるとは限りません。

エイリアスで問題が起きる理由：二つの送信者アドレス

メールには複数の送信者情報があり、ここでは二つが重要です。エンベロープ送信者（RFC 5321 MAIL FROM）は配送エラー通知の宛先として使われ、SPF はそのドメインまたは適用される HELO の識別名を検査します。ヘッダー送信者（RFC 5322 From:）は Gmail や Outlook で受信者に見えるアドレスです。DMARC には SPF または DKIM の少なくとも一方が成功し、その認証ドメインがこの From と整合することが必要です。

同じサーバー内で sales@ から bob@ へ配送するだけなら、エイリアス展開が認証を損なうとは限りません。一方、外部転送では、受信サーバーから見える接続元が転送サーバーの IP になります。元のエンベロープ送信者を保ったまま、その IP が当該ドメインで許可されていなければ、SPF は失敗する可能性があります。元の DMARC ポリシーが p=reject で、整合する有効な DKIM も残っていない場合、受信側は拒否することがあります。拒否、隔離、エラー通知の有無は各サーバーの動作次第で、必ず無言で破棄されるわけではありません。

設定問題 1：SRS なしの外部転送

ドメインのエイリアスから Gmail、Yahoo、個人用 Outlook.com へ転送すると、SPF が失敗する場合があります。ほかに整合する認証結果がなければ、厳格な DMARC ポリシーによって配送リスクが高まります。2025-2026 の状況を考える際にも、送信者が p=reject を使っているケースは重要な確認対象です。

例えば、顧客の alice@bank.com が contact@yourdomain.com に送信し、あなたのサーバーが you@gmail.com へ転送するとします。Gmail は bank.com の SPF を調べますが、転送サーバーの IP は許可されていないため、SPF が失敗する可能性があります。銀行のポリシーが p=reject で、整合する DKIM がなければ、Gmail は拒否することがあります。あなたのサーバーが先に返した 250 OK は、そのサーバーが受け付けたという意味にすぎません。最終配送を保証せず、後からエラー通知が発生する可能性も残ります。

対策の一つ：Sender Rewriting Scheme（SRS）。SRS は転送前にエンベロープ送信者を自分のドメインへ書き換えます。

元のエンベロープアドレス：alice@bank.com
SRS による書き換え後：SRS0=hash=TT=bank.com=alice@yourdomain.com

Gmail が SPF を調べる対象は yourdomain.com になります。このドメインでサーバーが許可されていれば、SPF を通過できます。SRS はホスティング事業者やメール管理者がサーバー側で有効にします。Postfix と Exim には SRS の連携手段があります。

重要な注意点として、SRS は新しいエンベロープドメインの SPF を通過させる助けにはなりますが、元の DMARC 整合性を復元しません。DMARC の整合性は、元の From ドメインと整合する有効な DKIM 署名が保持されていれば満たせる場合があります。ARC（Authenticated Received Chain）は、チェーンが有効で、確認済みの署名仲介サービスを受信側が信頼する場合の追加情報です。利用は受信側の裁量であり、それ自体は整合性を作りません。別ドメインの DKIM 署名を付け直しても、この不整合は解消しません。

より単純な構成：可能なら外部転送をやめ、自分のドメインの IMAP メールボックスをモバイルクライアントから直接使います。外部転送は 2012 頃から広く使われてきた形ですが、現在の認証環境では慎重な設定が必要です。すべての外部転送が使えないという意味ではありません。

設定問題 2：Microsoft 365 が外部転送をブロックする

エイリアスから外部へ転送していて、送信者に 550 5.7.520 Access denied が返る場合は、Microsoft のポリシーを確認してください。Exchange Online の送信スパムフィルターで既定の「Automatic - System-controlled」を使うと、自動外部転送はブロックされます。これはデータ流出などを防ぐための制限で、ほかのポリシーも結果に影響する場合があります。

管理ポータルでの変更方法：

1. Microsoft 365 Defender ポータルを開く
2. 次の順に進む：Email & collaboration → Policies & rules → Threat policies → Anti-spam
3. Anti-spam outbound policy (Default) を確認する。変更は組織全体に及ぶため、承認済みアカウントに限定したポリシーを優先する
4. 承認されたポリシーでのみ「Automatic forwarding rules」を On - Forwarding is enabled に変更する

必要な管理権限と承認を得たうえで、承認済みのアカウントだけに転送を許可してください。対象アカウントに限定した送信ポリシーを作る方法が適しています。次の PowerShell コマンドは組織全体の既定値を変更するため、実行前にセキュリティ要件と追加の制限を確認してください。

PowerShell を使う方法：

Connect-ExchangeOnline
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode On

設定問題 3：ルーティングループ

ルーティングループによって 554 5.4.14 Hop Count Exceeded が返ることがあります。メールがアドレス間を往復し、サーバーに設定されたホップ数の上限に達すると配送が止まります。ある環境では 15-20 ホップという例も考えられますが、これは一般的な固定上限ではありません。その後、元の送信者に配送エラー通知が届く場合がある一方、あなたのメールボックスには届きません。

よくある原因は、転送先メールボックスに残っている、忘れられた受信ルールです。

サーバーのエイリアス：info@ → admin@
admin@ のメールボックスルール：保存用にすべてを info@ へ転送
結果：ホップ数の上限に達するまでループする

二年前に設定した休暇用自動応答や、忘れられた「すべてを info@ に転送して保存する」ルールも確認しましょう。これらは考えられる原因の例です。サーバー側のエイリアスとクライアントの受信トレイルールの両方が対象です。Exchange では管理センターの Transport Rules を、Google Workspace では各対象アカウントの「Filters and Blocked Addresses」を確認します。

構造的な対策は、同じエイリアスが繰り返し処理されないようにすることです。エイリアス展開とユーザーの受信ルールがどの段階で実行されるか調べてください。元の受信者情報を保つリダイレクトは、構成によっては同じエイリアスを再び起動します。明確な最終配送経路を設け、動作を検証しましょう。「redirect」や「deliver to」という操作名だけで判断しないことが大切です。

設定問題 4：「Send As」で意図しない送信者が表示される

受信専用のエイリアスだけでは、用途によっては不十分です。sales@yourcompany.com 宛てのメールに返信したとき、相手の From 欄に bob.smith@yourcompany.com が表示されるなら、営業窓口として使いたかったアドレスで送れていません。自分の画面では気付きにくい問題です。

Google Workspace での確認：

1. User Settings → Accounts →「Send mail as」を開く
2. エイリアスアドレスを追加する
3. 「Treat as an alias」はアドレスの用途に合わせて選ぶ。自分の別アドレスなら適切な場合がありますが、独立した送信者として使いたい場合は別の扱いが必要になることがあります。チェックを外せば主アドレスが必ず隠れるわけではありません。テストメールで From、Reply-To、ヘッダー全体を確認してください。

Microsoft 365 での確認：

M365 では、メールボックスのエイリアスからの送信、「Send As」権限、「Send on behalf」権限は別の機能です。「Bob が Sales に代わって送信」のような表示は権限とクライアントの動作によって変わります。エイリアスからの送信を許可するには、管理者が次の組織設定を有効にできます。

Connect-ExchangeOnline
Set-OrganizationConfig -SendFromAliasEnabled $true

これは Exchange Online の設定で、オンプレミスの Exchange には適用されません。「Send As」権限の代わりにはならず、すべての代理送信表示を消す万能な対策でもありません。使用クライアントの対応も確認が必要です。

設定問題 5：キャッチオールとの競合

キャッチオール（*@domain.com）は、個別の宛先に一致しないアドレスのメールを受け取る仕組みです。ルーティングの実装が個別ルールより先に包括的なルールを選ぶと、明確なエラーなしに別のメールボックスへ届くことがあります。

Postfix のインデックス型 virtual_alias_maps は通常、完全なアドレスを先に検索し、その後でドメインのキャッチオールを検索します。ファイルを単純に上から順に評価するわけではありません。次の並びは見やすく示した例です。

# /etc/postfix/virtual
billing@yourdomain.com    finance@yourdomain.com
support@yourdomain.com   helpdesk@yourdomain.com
@yourdomain.com          catchall@yourdomain.com

postmap /etc/postfix/virtual && postfix reload

この例でキャッチオールを最後に置くのは、理解しやすくするためであり、普遍的な優先順位の決まりではありません。順序評価する PCRE マップでは並びが重要ですが、MySQL テーブルでは実際のクエリと検索方式が優先順位を決めます。完全一致のアドレスが優先されることを確認してください。マップの再構築と再読み込みは、権限を持つ管理者がバックアップを取り、既存のマップを保持し、対応するマップ形式、検索結果、設定をテストしてから行います。

詳しい調査：元のヘッダーを読む

エラー通知が見当たらないままメールが消えた場合は、迷惑メールフォルダーなどに届いたメールの元のヘッダーを調べます。Authentication-Results には、その受信サーバーが判断した認証結果が記載されています。配送ログや隔離状況も併せて確認しましょう。

Gmail では、メールを開く → 三点メニュー →「Show original」の順に進み、認証結果のブロックを探します。

失敗例 - SRS がない場合：

Authentication-Results: mx.google.com;
  spf=softfail (domain of transition does not designate
    192.0.2.1 as permitted sender) smtp.mailfrom=alice@bank.com;
  dmarc=fail action=quarantine header.from=bank.com;

smtp.mailfrom はまだ alice@bank.com です。この IP があなたの転送サーバーのものなら、この経路では SRS によるエンベロープ送信者の書き換えが行われていません。

成功例 - SRS が有効な場合：

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=SRS0=HHH=TT=bank.com=alice@yourdomain.com;
  dmarc=pass header.from=bank.com;

エンベロープアドレスが書き換えられ、yourdomain.com の SPF は通過しています。ただし、ここに示された DMARC の成功には、元の From ドメインと整合する有効な DKIM が保持されているなど、別の整合した認証結果が必要です。この省略されたヘッダーにはその署名が示されておらず、SRS だけで DMARC の成功を説明することはできません。

エイリアスアドレスを SMTP で受け付けるか確認するには、swaks を使えます。次のコマンドはテストメールを送信する場合があります。仮の値は、使用を許可され、自分で管理するアドレスとサーバーに置き換え、第三者の送信者情報を使わないでください。

swaks --to sales@yourdomain.com --from test@external.com --server mx.yourdomain.com

250 OK が受信者コマンドへの応答なら、その宛先を受け付けたことだけを示します。DATA 後のメッセージ全体の最終受け付け、エイリアスの存在、最終配送を証明するものではありません。550 User Unknown はその受信者が拒否されたことを示します。エイリアスマップと受信者検証の設定を確認してください。

予防策：ルーティングを単純にし、ホップを減らす

構成を単純にすれば、エイリアスの設定問題を減らせます。次の二つの方針が、よくある故障点を減らす助けになります。

方針 1：外部転送をできるだけ避ける。業務メールは業務ドメインのメールボックスに置き、スマートフォンから IMAP で直接利用できます。外部転送には、SPF が失敗する可能性、第三者の設備を通るデータ、追加の送信者設定といった負担があります。利便性とリスクを比較して判断しましょう。

方針 2：エイリアスの連鎖を一回の転送にまとめる。

ホップが増えるたびに、ループ、ヘッダー変更、認証失敗の起こる箇所も増えます。直接配送を目指すのは有効ですが、すべてのシステムを厳密に一ホップにできるとは限りません。

期間限定やキャンペーン用のアドレスには、新しいエイリアスの代わりに bob+newsletter@domain.com のようなプラスアドレスを検討できます。TrekMail、Gmail、Exchange での対応状況や設定の要否は、事業者とアカウント設定によって異なるため、最新の説明を確認してください。また、一部の Web フォームは + を受け付けないので、どこでも使える方法ではありません。

エイリアスと転送の利点・欠点については、メールエイリアスの転送で詳しく説明しています。

料金体系が複雑な構成を生んでいる場合

ユーザー単位の料金では、独立したメールボックスを増やす費用が気になることがあります。追加ライセンスを節約するためにエイリアスを作り、その結果、SRS ヘッダーや PowerShell の転送ポリシーの調査に何時間も費やすかもしれません。これは考えられるトレードオフであり、すべてのエイリアス構成の理由ではありません。部署のアドレスに必ず追加ライセンスが必要なわけではなく、エイリアス、グループ、共有メールボックスの条件も確認してください。

TrekMail はアカウントのプランを用い、一律に個別ドメインやメールボックスごとに課金する方式ではありません。過去の Starter の例（$3.50/月）では、sales@、support@、billing@ をプランの範囲内で個別のログインと送信アドレスを持つ IMAP メールボックスにできます。アカウント共有容量に加えて個別の容量制限もあり得るため、現在の上限と機能を確認してください。クライアント設定は引き続き必要です。説明した Nano の構成でのみ、返信を含むすべての送信に自分の SMTP が必要で、有料プランの管理型送信は実際の権限に依存します。

代理店向けの過去の例では、Pro プラン（$10/月）で 100 ドメインを扱う想定です。現在の上限と機能を確認してください。利用可能な IMAP ツールで Gmail や cPanel のメールをコピーするには、承認済みのアクセスと互換性の確認が必要です。バックアップ、フォルダー、メールを検証し、DNS 切り替え前に最後の差分を同期します。連絡先と予定表は別の移行計画が必要で、稼働中の環境への影響がないとは保証できません。

初めてドメインのメールを設定する場合は、独自ドメインでメールを作成する方法が一連の手順を案内します。アカウントプランの最新の条件はTrekMail の料金ページで確認してください。元記事にあるクレジットカードが必要な 14 日間の有料プラン試用も、現行条件を保証するものではありません。

まとめ

よくある問題は、SRS なしの外部転送に伴う SPF の失敗、Microsoft 365 のポリシー制限、忘れたルールによるルーティングループ、送信者アドレスの設定ミス、キャッチオールとの競合です。エラーコードは手掛かりになりますが、対処方法は経路、認証結果、受信側のポリシーによって変わります。

同じ問題が繰り返されるなら、設定だけでなく構成と料金体系も見直してみてください。ユーザー単位の費用を避けるための複雑な回避策より、独立したメールボックスの方が用途に合うかもしれません。

転送の構成とトラブルシューティングを広く理解するには、メール転送の設定と修正方法からお読みください。