メールエイリアス転送の SPF・DMARC 障害と対策

メールエイリアスの転送を設定し、contact@yourdomain.com 宛てのメールを Gmail で受け取っています。何か月も問題ありませんでした。ところが、顧客から署名済みの契約書について送られたメールが見当たりません。三週間後に気付いたときには、商談の機会を失っていました。

自分には配送エラーの通知がなく、迷惑メールフォルダーにもありません。メールが届かず、機会を逃したことだけが残ります。

エイリアスと転送の組み合わせが厳格な DMARC ポリシーに遭遇すると、このような問題が起こる場合があります。受信者が失敗に気付けないこともあります。プロトコルを理解すれば、原因の調査やリスクの軽減に役立ちます。このガイドでは、問題の発生箇所、ログで探すエラーコード、転送メールの認証を改善する二つの仕組みを説明します。配送を保証するものではありません。

基本設定から確認したい場合は、メール転送の設定とトラブル対処ガイドを先にご覧ください。ここでは障害の仕組みを扱います。

メールエイリアスの転送は何をしているのか

メールエイリアスは配送先を示すルールで、独自の受信箱、ログイン、保存容量はありません。sales@yourdomain.com に届いたメールをサーバーが受信し、別の宛先、通常は個人の Gmail や Outlook に配送します。小規模企業の業務窓口でよく使われますが、見えにくい配送障害を招くことがあります。

外部へのエイリアス転送では、新しい SMTP 接続を開いて宛先へ送ります。この段階で認証上の問題が生じる場合があります。自社サーバーが、別の送信者から届いたメールを元の送信者の認証情報を伴って送り直すためです。

メールの二つの層

メールには、普段は意識されない二つの異なる層があります。この区別が、転送で認証が失敗する理由を理解する鍵です。

client@bank.com がエイリアス sales@yourdomain.com に送信すると、bank.com のサーバーがメールを送ります。この例では、bank.com が自社の送信 IP を許可しているため SPF が成功します。

自社サーバーが founder@gmail.com に転送すると、新しい SMTP 接続が開かれます。接続元 IP は自社サーバーになりますが、エンベロープの送信者は元のままの場合があります。ヘッダーにも client@bank.com が残ります。

Gmail が bank.com の SPF を確認すると、そのドメインで許可されていない自社サーバーの IP が見え、SPF が失敗することがあります。bank.com が p=reject を公開し、整合した DKIM 検証にも成功しなければ、Gmail は受信側の方針に従って拒否する場合があります。エラー通知が元の送信者に戻り、自分には届かないこともありますが、必ず無通知で削除されるわけではありません。

エイリアス転送で起こる三つの問題

転送の問題は複数の層で発生します。それぞれ症状と対処が異なります。

1. SPF の失敗

SPF は、接続元サーバーの IP がエンベロープ送信者のドメインの DNS レコードで許可されているかを確認します。転送後の接続では、元の送信者の IP ではなく自社サーバーの IP が使われます。元のエンベロープ送信者を保持し、自社 IP が許可されていなければ、転送先で SPF が失敗することがあります。

2. DMARC による拒否

DMARC は、SPF または DKIM が成功し、かつ From: ドメインと整合することを求めます。SPF が失敗しても、有効で整合した DKIM があれば DMARC は成功できます。しかし、フッターの追加や署名対象ヘッダーの書き換えなどは DKIM を無効にする場合があります。整合した検証がどちらも成功しなければ、p=quarantine は隔離を、p=reject は拒否を要求します。適用方法は受信システムが決定します。

3. 受信者への通知がない消失

最悪のケースは、宛先が NDR、つまり配送不能レポートを返さずにメールを破棄することです。ただし、DMARC の失敗が必ずそうなるわけではなく、SMTP での拒否なら送信者に通知されることもあります。エイリアスの受信者には何も見えない場合があり、障害を発見しにくくなります。

SMTP ログで探すエラーコード

転送メールが見当たらない場合は SMTP ログを調べるか、事業者に NDR の記録を問い合わせてください。次の三つのコードは調査の手掛かりですが、文脈と合わせて原因を確認する必要があります。

Microsoft 365 のブロック（5.7.520）

Exchange Online はテナントのポリシーで外部への自動転送をブロックする場合があります。データ持ち出しを防ぐ設定が、正当な転送も止めることがあります。実際の設定と現在の案内を確認してください。

550 5.7.520 Access denied, Your organization does not allow external forwarding.

対処：権限を持つ管理者がリスクを評価したうえで、Microsoft 365 の管理画面の送信スパム対策ポリシーに例外を設けるか検討します。リダイレクトルールなら必ず回避できると考えず、テナントで許可される転送方法を確認してください。

配送ループ（5.4.14 / 5.4.6）

二つのエイリアスが互いに転送したり、キャッチオールの転送先が元のドメインへメールを戻したりすると、ループが生じる場合があります。

554 5.4.14 Hop count exceeded - possible mail loop

対処：転送ルールを点検します。たとえば、*@yourdomain.com のキャッチオールが、すべてのメールに自動応答するアドレスへ転送していないか確認します。不在通知だけで必ずループになるわけではありませんが、循環する配送経路や防止策の不足は原因になり得ます。

DMARC 認証の失敗（550 5.7.1）

この例では、転送されたメールを宛先サーバーが DMARC 認証の問題により拒否しています。

550-5.7.1 Unauthenticated email from bank.com is not accepted due to domain's DMARC policy.

転送時に見られる DMARC エラーの例ですが、コードだけで転送が原因とは断定できません。SPF と DKIM の結果を調べてください。サーバー側の SRS と ARC は対策になり得ますが、保証ではなく、正しい DNS 設定も必要です。

対策となる SRS と ARC

受信サーバーにポリシーの例外を強制することはできません。SRS と ARC は外部転送に使う補完的な仕組みで、MTA、つまりメール転送サーバーで実装します。自分でサーバーを管理していない場合は、事業者に対応状況と適用方法を確認してください。

SRS（Sender Rewriting Scheme）

SRS は、Return-Path に記録されるエンベロープ送信者を、転送サーバーのドメインに書き換えます。そのドメインの SPF レコードがサーバーを適切に許可し、その他の検証条件も満たせば、転送先で SPF が成功できます。

SRS なし：
エンベロープ送信者：client@bank.com
送信 IP：自社の転送サーバー
SPF 結果：この例では FAIL。bank.com が自社 IP を許可していないため

SRS あり：
エンベロープ送信者：SRS0=Hash=TT=bank.com=client@yourdomain.com
送信 IP：自社の転送サーバー
SPF 結果：この例では PASS。yourdomain.com が自社 IP を許可しているため

SRS の書き換えアドレスにはハッシュと時刻情報も含まれ、妥当性の確認と悪用の制限に使われます。有効期限は通常、日単位で設定され、実装によります。アドレスの収集やあらゆる再利用を防げるわけではありません。

ARC（Authenticated Received Chain）

SRS は転送先の SPF を改善できますが、SPF の DMARC ドメイン整合を単独で復元しません。DMARC は From: ドメイン（bank.com）を認証されたドメインと比較します。SRS 後のエンベロープは yourdomain.com で、From: は bank.com のままなので一致しません。ただし、有効で整合した DKIM があれば DMARC は成功できます。

ARC は RFC 8617 で定義され、各段階で確認した認証結果を署名付きの連鎖として記録します。転送サーバーはメールと記録した結果にシールを付けます。SPF と DKIM が必ず成功していたと宣言するのではなく、実際に観測した結果を示します。

対応する構成の Gmail や Outlook などの受信システムは、ARC と転送元の評判を判断材料にできます。有効なシールがあっても信頼や配送は強制されません。ARC は DMARC のドメイン整合そのものを変更しません。

どちらも単なる DNS 設定ではありません。SRS 書き換えと ARC シールには配送層の対応が必要です。厳格な DMARC の下で外部転送する場合も、正しい DNS、損なわれていない DKIM、受信側の方針が重要です。

運用上の二つの落とし穴

SRS と ARC があっても、よくある二つの構成で問題が生じる場合があります。

返信時の個人アドレス露出

転送は受信を扱い、送信元を自動設定するものではありません。別の差出人を設定せず Gmail で返信すると、From が founder@gmail.com になり、sales@yourdomain.com にはならないことがあります。顧客には個人アドレスが見えます。

対策の一つは、現在の Gmail のアカウント設定で「他のメールアドレスを追加」を使い、エイリアスとドメインで許可された SMTP 認証情報を設定することです。対応する送信方法では Gmail がそのサーバーを使います。返信元の表示も確認してください。接続情報は TrekMail の管理型 SMTP 設定を参照してください。

この方法は利用できますが、原文の手順ではアカウントごとに三つの設定工程が増えます。SMTP パスワードを変更すると、Gmail 側の更新も必要になる場合があります。

キャッチオールの外部転送

キャッチオール（*@yourdomain.com）の外部転送は避けましょう。迷惑メール送信者は、既知のドメインで billing@、admin@、noreply12345@ などのローカル部を試します。キャッチオールはそれらを受信し、フィルターを通過した迷惑メールも転送する可能性があります。

大量の迷惑メールを転送すると、サーバー IP の評判が悪化する場合があります。実際のメールボックスから送るものも含め、正当なメールが迷惑メール扱いされるおそれがあります。評判の回復には時間がかかることがありますが、必ずそうなるわけでも、期間が固定されているわけでもありません。

キャッチオールが必要なら、独立したローカル受信箱に配送し、手動で確認する方法を勧めます。TrekMail のメールボックス転送の説明を参考に、迷惑メールの転送を不要に増やさない構成を検討してください。

エイリアス転送と実際のメールボックスの選び方

詳しい選択基準は、独自ドメインのメールエイリアスとメールボックスの比較ガイドをご覧ください。転送に関する要点は次のとおりです。

費用だけを理由に、エイリアス転送を実際のメールボックスの恒久的な代替にするのは避けましょう。ユーザー単位の料金では魅力的に見えても、追加設定、例外処理、認証リスクを含めて評価する必要があります。

TrekMail の転送方式

SRS と ARC を自分で管理するには、配送設定、Postfix との連携、ARC 署名鍵の管理とローテーションが必要です。詳細はシステムによります。これはサーバー管理の作業であり、単純なエイリアス変更ではありません。

原文では、TrekMail の Pro と Agency のメールボックス転送が OpenARC 対応の配送層を使い、転送メールに ARC シールを自動付与すると説明されています。宛先はダッシュボードで設定するモデルです。現在の対応状況、制限、動作は文書で確認してください。この説明だけでは SRS 対応は確認できず、配送も保証されません。ドメインの DNS 認証は別途正しく設定する必要があります。

多くの場合、転送を使わず専用メールボックスにする方が単純です。原文の TrekMail 定額モデルでは、ユーザーやメールボックスごとの追加料金はありません。support@yourdomain.com に一人がログインするか十人かだけでは料金は変わらないというモデルですが、制限と対応するアクセス方式に従う必要があります。現在の条件とセキュリティ要件を確認して選んでください。

• 中小企業：support@ に専用 IMAP ログインを用意し、送信には SMTP を設定します。直接アクセスにより差出人の分離が簡単になり、外部サービスの送信元設定を更新する手間を減らせます。
• 代理店：個人用のチームアカウントへの転送ではなく、顧客の業務窓口に専用メールボックスを作成します。適切な権限とクライアント設定により、チームは所定の業務用アドレスから返信できます。

ドメインの SPF、DKIM、DMARC も最初から設定する場合は、企業向けメールセキュリティの基本設定に認証の主要要素をまとめています。

まとめ

メールエイリアスの転送は、重要度の低い用途では使える場合があります。特に次のリスクを確認してください。

1. 元の送信者が厳格な DMARC（p=quarantine または p=reject）を使い、整合した認証が有効なまま残らない
2. 転送サーバーに SRS がなく、転送先で元の SPF が失敗する場合がある
3. 転送サーバーに ARC がなく、そのサーバーが観測した過去の結果を署名付き ARC 記録として渡せない。SRS だけでは SPF は DMARC と整合しないが、整合した DKIM で成功できる場合がある
4. キャッチオールを外部転送し、迷惑メールを増幅する可能性がある
5. エイリアスから返信したいが、転送は送信元を自動設定しない

必要に応じた SRS と ARC を含む適切なプロトコル対応を事業者に求めるか、直接ログインできるメールボックスに置き換えます。ユーザー単位の料金では転送が魅力的でも、原文の TrekMail 定額プランでは制限内のメールボックスに追加ライセンスは発生しないとされています。

原文では TrekMail Pro は $10/月からで、最大 100 ドメイン、ARC シール付きのメールボックス転送、制限内でのメールボックス単位の追加料金なしとされています。また、14 日間の無料トライアルにはクレジットカードが必要で、Nano には不要と説明されています。現在の料金と条件を確認してください。