別のアドレスへのメール転送: 認証と障害診断

転送ルールを設定し、テストメールを送ります。正常に届いたので、ほかの作業に戻ります。

ところが後日、顧客から返信が届いていないと連絡が来ます。手元にはバウンスも NDR もありません。メールがサーバー間で消えたように見えますが、原因の特定には配送ログの確認が必要です。

メールを別のアドレスへ転送すると、転送サーバーは宛先へ新しい SMTP 接続を開きます。宛先は元の送信サーバーではなく、転送サーバーの IP で SPF を確認します。その IP が元のエンベロープ送信者ドメインで許可されていなければ、SPF は失敗する可能性があります。表示上の From ドメインと整合する有効な DKIM 署名も残っていなければ、DMARC も失敗します。p=reject は拒否を要求するポリシーですが、実際の拒否、フィルタリング、通知の有無は受信側の判断によります。

設定の入力ミスとは限りません。転送の仕組みと現代の認証方式が衝突している可能性があります。メール転送の設定と修正の総合ガイドでは各種シナリオを扱っています。この記事では認証に絞り、障害の種類、エラーコード、対処方法を説明します。

メール転送で認証が失敗することがある理由

受信 MTA は転送サーバーの IP で SPF を確認します。メールには異なる送信者識別情報があり、転送によってそれらの整合性が失われることがあります。SPF はエンベロープ送信者を検証します。DMARC が成功するには、表示上の From ドメインと整合する SPF または DKIM の成功が必要です。両方ともなければ DMARC は失敗し、その後の扱いは受信側のポリシーに従います。

経路は、サーバー A から転送サーバー B、そして新しい TCP 接続で宛先 C へ、という形になります。C が見るのは B の IP です。SPF は元のエンベロープドメインの DNS に基づき、"この IP はこのドメインからの送信を許可されているか"を確認します。B が許可されていなければ SPF は失敗する可能性があります。よくある問題ですが、すべての転送で必ず失敗するわけではありません。

DMARC には、整合する SPF または DKIM の成功が一つあれば十分です。元の From ドメインの DKIM 署名が有効なまま残っていれば、転送後も DMARC を通過できます。重要なのは署名対象のヘッダーと正規化された本文であり、変更がすべて DKIM を壊すわけではありません。両方の整合する検証結果が失われると DMARC は失敗します。p=reject は拒否を要求しますが、特定の配送結果やバウンス動作を保証しません。

よくある三つの障害

転送では、管理ポリシーによるブロック、認証の失敗、ルーティングループが起こり得ます。それぞれ原因と対処方法が異なります。すべての障害に固定の SMTP コードがあるわけではありませんが、種類を見分けると調査範囲を絞れます。

1. Microsoft 365 の送信転送ブロック (550 5.7.520)

Microsoft 365 は自動外部転送を情報流出の経路になり得るものとして扱います。有効な既定ポリシーによって、テナント外への転送が Exchange Online から出る前にブロックされる場合があります。

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

これはプロトコルのエラーではなく、ポリシーによる制限です。権限のある管理者は次の手順で対応できます。

1. Microsoft 365 Defender Portal を開きます。
2. Email & collaboration → Policies & rules → Threat policies → Anti-spam に移動します。
3. 明示的に承認されたアカウントだけを対象とする Outbound spam filter policy を作成または編集します。
4. 承認済みの限定ポリシーで、Automatic forwarding を On - Forwarding is enabled に設定します。

組織全体の既定ポリシーで一律に有効化しないでください。どれかのアカウントが侵害された場合のリスクが広がります。対象を絞ったポリシー、MFA、送信量の監視を使い、ほかの有効な転送制限も確認してください。

2. DMARC の両方の根拠が失われる

この障害は見落とされやすいものです。IP の変更で SPF が失敗しても、整合する有効な DKIM 署名があれば DMARC は成功できます。しかし、署名された内容やヘッダーの変更で DKIM も無効になることがあります。影響は署名範囲と正規化方式に依存し、変更があれば必ず失敗するわけではありません。

DKIM に影響し得る代表的な変更は次のとおりです。

• ウイルス対策ソフトが追加するフッター: "[製品名] でスキャン済み"
• 宛先ゲートウェイが件名に追加するタグ。件名が署名対象の場合: [EXT] または [EXTERNAL]
• HTML 本文に挿入する "外部送信者" の警告バナー
• メーリングリストによる署名済みヘッダーの書き換えや配信停止フッターの追加

整合する SPF の成功も、整合する有効な DKIM 署名もなければ、DMARC (RFC 7489) は FAIL になります。p=reject は送信ドメインが拒否を要求することを示します。受信側は独自のポリシーを適用でき、エラー通知を伴う拒否、隔離、その他の処理があり得ます。通知がないだけでは、通知なしで削除されたとは断定できません。

3. ルーティングループ (554 5.4.14)

サーバー同士がメールを繰り返し送り返し、ホップ数の上限に達するとループが停止します。NDR が生成されることはありますが、必ず即座に通知されるとは限りません。メールキューを圧迫し、ほかの配送を遅らせる可能性もあります。

考えられる原因は次のとおりです。

• ユーザー A が B へ転送し、B のルールが A へ送り返します。
• A から B への転送に対する不在通知が、A の転送を通って再び B に届きます。自動返信の抑止が不十分な場合は返信ループになり得ますが、必ず発生するわけではありません。
• キャッチオールがあるメールボックスへ転送し、そのボックスが同じドメインの存在しないアドレスへ転送します。ループになるかどうかはキャッチオールと経路設定によります。

554 5.4.14 Hop count exceeded - possible mail loop

本番環境で転送する前に、自動返信やキャッチオールの宛先を含めた経路全体を確認してください。

対策となる SRS と ARC

二つのサーバー側機能は転送の改善に役立ちますが、配送を保証するものではありません。SRS はエンベロープ送信者を書き換え、転送ドメインの DNS が送信 IP を許可していれば SPF の成功を可能にします。ARC は以前の認証結果を記録し、転送者を信頼する受信側が独自の判断で DMARC の例外を検討するための材料を提供します。単なるメールクライアントのルールでは、これらを実装できません。

SRS: Sender Rewriting Scheme

SRS はエンベロープ送信者 (P1) を管理下のドメインのアドレスに変更します。送信 IP が許可されていない可能性のある alice@bank.com をそのまま使用せず、転送サーバーは例えば次の返送先を生成します。

SRS0=Hash=Timestamp=bank.com=alice@your-forwarding-domain.com

SPF は転送ドメインを確認するようになります。その SPF レコードが送信 IP を許可し、ほかの SPF エラーもなければ成功できます。ただし、これだけで元の From ドメインとの DMARC 整合性が得られるわけではありません。

ハッシュとタイムスタンプは、バウンスの返送を制御するために使われます。有効な SRS アドレスを検証して元の送信者アドレスを復元し、NDR を本来の Alice へ戻すことができます。これらのアドレスには有効期限と用途の制限があります。ただし、SRS の共有シークレットを安全に管理するだけではオープンリレーを防げません。別途リレーのアクセス制御とバウンス宛先の検証が必要です。

ARC: Authenticated Received Chain

SRS は転送ドメインの SPF に役立ちますが、元の From ドメインとの整合性の差は残ります。ARC (RFC 8617) もその差を解消しません。代わりに、転送者が受信時に確認した認証状態を暗号学的に保護して記録します。つまり、"受信時にはこの結果を確認した"という記録です。

Google や Microsoft などは、信頼できる転送者の有効な ARC チェーンを配送判断に考慮する場合があります。シールを信頼するか、DMARC ポリシーの例外を認めるかは受信側が決めます。良好な IP 評価と有効な ARC チェーンは、受信の許可や受信トレイへの配送を保証しません。

ARC は受け渡しの履歴に似ています。参加する各転送段階が、その時点で観測した認証状態の署名付き記録を追加します。後段の受信者はチェーンを検証し、現在の DMARC 検証で整合する SPF または DKIM の成功が得られなくても、独自のポリシーで考慮できます。

Gmail と Microsoft 365 は一部のメールフローで ARC に対応しています。すべての経路で自動的に署名されると考えず、実際のヘッダーと最新の資料を確認してください。ARC がなければ追加の記録がありませんが、DMARC が必ず失敗するわけではありません。元の整合する有効な DKIM 署名で十分な場合もあります。

実装方法は二つ

自分で MTA を管理する方法と、対象の転送経路で SRS や利用可能な ARC を提供するプラットフォームを使う方法があります。管理型サービスでも、正しい DNS、ルール、配送テストが必要です。どちらもすべての配送障害をなくすものではありません。

方法 A: Postfix + postsrsd を自己管理する

Postfix を動かす Linux サーバーでは、postsrsd でエンベロープを書き換えられます。以下は旧来の TCP マップに対応するバージョン向けの例です。socketmap インターフェースを使うバージョンには、そのまま適用できません。導入済みバージョンと、その資料に記載された設定を確認してください。この例はここでは実行していません。

# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

この方法では次の管理が必要です。

• SRS の共有シークレットの管理。漏えいすると SRS バウンスアドレスが偽造される可能性があります。リレー制御はシークレットの安全性とは別に必要です。
• ローカルドメインの適切な除外。広すぎる書き換えは内部配送に影響することがあります。
• 送信 IP の評価管理。Gmail や Outlook の配送判断には、IP 評価とほかの要因が関わります。
• ARC の個別設定。postsrsd だけでは ARC 署名を実装できません。

適切に設定すれば運用できますが、継続的な保守が必要です。専用のメールプラットフォームに、その一部を任せることもできます。

方法 B: TrekMail の管理型転送を利用する

選択する TrekMail プランと実際の経路について、自動 SRS 書き換え、ARC 署名、管理型 SMTP リレーが現在利用できるか確認してください。これらはサーバー設定や鍵管理の負担を減らせますが、有料プランに ARC が含まれるか、対象経路でどのリレーを使うかは購入前の確認が必要です。リレーの評価だけで配送は保証されません。

個人の創業者の場合、info@yourdomain.com を個人の受信トレイへ転送するためだけにメールボックスごとに月額 $6 を払っているなら、ドメイン単位のプランと比較する価値があります。ここで示す Starter の月額 $3.50、最大 50 ドメイン、ユーザー単位の料金なしという条件は、契約前に現在の価格と転送上限を確認してください。TrekMail のメールボックス転送の仕組みも参照できます。

多くの顧客ドメインを扱う代理店では、SPF の調査コストが負担になり得ます。必要な機能が提供されていれば、転送管理の集約は運用を簡素化できます。メールエイリアス転送ガイドでは、エイリアスとメールボックスルールの違いを説明しています。

メール転送を有効にする前のチェックリスト

本番の転送ルールを有効にする前に、四つの項目を確認してください。前述の障害を調べる手掛かりになりますが、実際の送信者と受信システムを使ったテストの代わりにはなりません。

1. SRS が動作している。届いたテストメールの Return-Path を確認します。その経路で SRS を使う想定なら転送ドメインが表示されるはずです。SPF で送信 IP が許可されているかも確認します。
2. 署名された内容を保つ。DKIM に影響するフッター、件名タグ、本文の警告バナーを避けます。ウイルス対策やその他のセキュリティ検査は無効にせず、署名内容を変更しない同等の保護を使ってください。正規化と署名対象ヘッダーも確認します。
3. ループ対策。逆向きの転送、不在通知、キャッチオールの宛先、自動返信ループを抑える仕組みを確認します。
4. M365 の送信ポリシー。Exchange Online の有効な制限を確認します。自動外部転送は承認された必要なアカウントだけに限定したポリシーで許可し、全体では有効にしないでください。

転送が適さない場合

複数ドメインから一つのローカルなメールボックスへ配送したい場合、ドメインエイリアスで余分な外部転送を避けられることがあります。ただし、エイリアス自身が外部へ転送するなら SPF、DKIM、DMARC の問題はなくなりません。実際の配送経路が重要です。

ドメインメールエイリアスとメールボックスの比較で適した用途を確認できます。過去のメールを移すなら、ライブ転送より IMAP 移行ツールが適している場合があります。TrekMail のツールの現在の提供状況を確認してください。IMAP で履歴をコピーしても、新着メールの経路切り替えは別途必要です。

まとめ

外部転送では、受信側が見るのは転送サーバーの IP です。元のエンベロープドメインで許可されていなければ SPF は失敗する可能性があります。整合する有効な DKIM 署名も残っていなければ DMARC は失敗します。処理方法は受信側が決めるため、無通知での削除やバウンスがないことは必然ではありません。

対策はサーバー側で行います。SRS はエンベロープ送信者を管理下のドメインに変更し、適切な SPF 設定があれば役立ちます。ARC は以前の認証結果を記録して信頼判断の材料にしますが、DMARC の整合性を作り出すものではありません。自分で実装するか、必要な経路に対応するプラットフォームを利用できます。

SRS の鍵、ARC、SMTP リレーを自分で管理したくない場合は、TrekMail の必要な機能を確認してください。ここで示す Starter の月額 $3.50、最大 50 ドメイン、ユーザー単位の料金なしという条件は、現在のプランと転送上限に照らして確認が必要です。すべてのプランを見る。