メール転送が機能しないときの6つの確認手順

メール転送が動かず、メッセージが見当たりません。送信者にもエラーが届かず、確認した管理画面ではルールが正しく見えます。見えるエラーがないと、原因の特定は特に難しくなります。

メール転送が動かない原因には、ルール、認証、受信者側の方針があります。転送では別のサーバーが元の送信者に代わって送り、SPF が失敗する場合があります。ただし、受け入れ、保留、拒否、迷惑メールへの振り分けは DKIM、DMARC、受信側の判断にも左右されます。数秒で拒否されることはありますが、通知がないだけでは無言の削除とは断定できません。

DNS を変更する前に、この順番で確認しましょう。SPF に転送が与える影響と SRS、ARC の役割は、メール転送の設定と修正の詳しいガイドで説明しています。ここでは現在の障害を切り分けます。

転送エラーが見えないことがある理由

受信側の問題は、転送サーバーの問題とは異なる形で通知される場合があります。SMTP 拒否で不達通知が生じたり、受け入れ後にフィルター処理されたり、通知が転送者や書き換えた戻り先へ届いたりします。通知が見えないだけでは、配信成功も送信数秒後の削除も証明できません。

ルールが有効なのにメールが見つからない場合、ヘッダー、不達通知、ログが手掛かりになります。次の六項目は実務上の確認順です。迷惑メールを調べず DNS から始めると、例えば 45 分を誤った問題に費やす場合があります。

60 秒の切り分け：まず症状を分類する

設定を変える前に 60 秒で症状を整理します。次の四パターンは調査の方向を示しますが、それだけで原因は確定しません。

メール転送の不具合チェックリスト

手順 1 と手順 2 は迷惑メールと不達通知という、確認しやすい情報を提供します。無関係な DNS 修正に例えば 45 分使う前に調べましょう。原因を十分に絞れるまで順に確認します。

手順 1：宛先の迷惑メールを調べる

優先度：最初に確認  |  症状：メールも不達通知もない

見当たらないメールは宛先の迷惑メールにある場合があります。転送は SPF が確認する送信経路を変えます。client@gmail.com から you@outlook.com への転送では、Outlook が元の SPF で認められない転送サーバーの IP を見る場合があります。評価には影響し得ますが、必ず迷惑メールになるわけではなく、保持された整合済み DKIM や他の受信側情報も関係します。

操作：最終宛先にログインして迷惑メールを確認します。

対処：正当なメールなら必要に応じて“迷惑メールではない”とします。Sender Rewriting Scheme（SRS）はエンベロープ送信者を書き換え、転送者ドメインで SPF を成功させる助けになります。元の From との整合や以後の配信は保証しません。SRS がなくても Gmail、Yahoo、Outlook への転送がすべて不可能になるわけではありません。

手順 2：不達通知と NDR コードを読む

優先度：通知がある場合  |  症状：送信者に“配信不能”が届く

SMTP コードと詳細な説明が診断を助けます。対象サーバーとアドレスも確認し、件名だけで推測しないでください。同じようなコードでも、設定や方針の原因が異なる場合があります。

手順 3：DMARC の整合を確認する

対象：Gmail、Yahoo、Outlook など  |  症状：メールがない、または拒否

DMARC は転送に影響する場合がありますが、常に原因とは限りません。p=reject でも、SRS や ARC のない単純転送が 100% 失敗するとは言えません。元の DKIM 署名が保持され、検証に成功して表示上の From と整合すれば、DMARC を成功させられる場合があります。整合した SPF または DKIM の成功が必要で、両方が必須ではありません。処理は受信側の判断にもよります。

元の送信ドメインの DMARC 方針を端末で調べます。

dig _dmarc.originalsender.com TXT +short

p=reject があるだけでは、特定メールの拒否を証明できません。SPF の成功と表示上の From との整合、DKIM の成功と署名ドメインを確認します。エンベロープ送信者が DKIM ドメインと一致する必要はなく、少なくとも成功した一方式が From と整合する必要があります。

対処：適切なサーバー転送はSRS 対応の中継と ARC（Authenticated Received Chain）を使える場合があります。ARC は以前の認証結果を検証可能な形で保持しますが、チェーンと仲介者への信頼は受信側が決めます。Gmail フィルターや Outlook ルールの処理は製品によって異なり、cPanel の転送はサーバー側です。実際の MTA と SRS、ARC の対応を確認してください。

手順 4：Microsoft 365 の外部転送方針を確認する

対象：Office 365 と該当コード  |  症状：550 5.7.520 NDR

Microsoft 365 は自動外部転送を方針で禁止する場合があります。侵害されたアカウントからの情報流出を減らす目的もあります。ユーザールールは組織の制限を上書きできません。例外は権限のある管理者が確認して承認し、可能な限り対象を限定します。テナント全体で不用意に有効化しないでください。

1. 必要な権限で Microsoft 365 Defender にログインし、現行画面を確認します。
2. メール & コラボレーション → ポリシー & ルール → 脅威ポリシー → 迷惑メール対策へ進みます。
3. 送信スパム対策ポリシー（既定）を含む有効な方針を確認し、例外には限定した対象を優先します。
4. 必要な権限と承認がある場合に保護設定の編集を選びます。
5. 自動転送ルールをオン：転送を有効化にするのは承認範囲だけとし、他の制限も確認します。

項目が無効なら、権限や組織方針が原因の場合があります。ユーザー設定では迂回できません。担当テナント管理者に有効な制限を確認してもらい、独断で保護を弱めないでください。

手順 5：循環する転送経路を確認する

対象：ループの兆候  |  症状：5.4.14 エラーや重複コピー

サーバー A が B に転送し、B が A に戻すとループになります。ホップ数上限や他のループ防止が働くまで繰り返される場合があります。例えばドメイン A の catch-all が B へ送り、B の一部アドレスのルールが A に戻す構成です。

遅延や重複メールのヘッダーで次を確認します。

• X-Loop
• X-MS-Exchange-Inbox-Rules-Loop
• Delivered-To が同じアドレスで複数回現れるか。

ドメイン catch-all の経路ガイドは構成を説明します。各転送には最終メールボックスまで記録された経路が必要です。他の別名や中継を通っても構いませんが、検証済みで循環しないことが条件です。

手順 6：Gmail の転送先確認を調べる

対象：まだ無効なルール  |  症状：ルールはあるが転送されない

個人 Gmail では転送先の確認漏れで有効化できない場合があります。Google はこの転送機能の宛先確認を求めます。確認後に、自動転送や該当フィルターが実際に有効かも調べます。

操作：宛先で“Gmail Team”の確認メールを探し、迷惑メールも確認します。自分が開始し、確かめた依頼だけを承認してください。メールが未着や期限切れなら Gmail 設定 → メール転送と POP/IMAP から再度依頼し、転送の有効化も確認します。

メールヘッダーで転送障害を診断する

迷惑メールへの到着はメッセージが届いたことを示しますが、分類には複数の原因があります。Authentication-Resultsは検証サーバーの認証結果であり、すべての転送障害を完全に説明するものではありません。信頼できる結果を経路とログに合わせて確認します。

ヘッダーの表示方法：

• Gmail：メールを開く → 三点メニュー → “メッセージのソースを表示”。
• Outlook：ファイル → プロパティ → インターネットヘッダー。製品バージョンを確認してください。

SRS と ARC を含む説明用の例です。簡略化した行は完全な標準構文の見本ではありません。

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sender.com;
  spf=pass (google.com: domain of SRS0=ABCD=XY=sender.com@forwarder.com
            designates 1.2.3.4 as permitted sender)
  dmarc=pass (p=REJECT) dis=NONE header.from=sender.com
  arc=pass (i=1 spf=pass dkim=pass)

SRS0= が Return-Path にあれば SRS 書き換えの手掛かりになりますが、正しい構成や From との整合を単独で証明しません。接頭辞がなくても書き換えの不在や DMARC 失敗を断定できません。実際の経路と認証を確認します。Google の 2024 年以降の要件は特定の送信状況を対象とし、すべての業務ドメインが同じ方針である証拠ではありません。

転送障害が業務に影響するとき

顧客メール、契約、サポート依頼の未着は、相手が再度連絡するまで気づかない場合があります。重要な配信経路を記録し、不達通知がないだけで成功と判断しないでください。

複数ドメインでは単発の手動診断が負担になります。新しいメールボックスや送信者方針の変更で再検証が必要になる場合があります。Google Postmaster Toolsは権限、メール量、データの有無に応じて Gmail の集計情報を提供します。すべての転送をリアルタイムに示すものではありません。認証失敗とユーザーの迷惑メール報告は別の信号として調べます。

個別障害だけでなく繰り返す原因に対処する

繰り返す問題には、適切な SRS と ARC を扱う構成を検討します。認証問題の軽減を支えますが、継続監視や以後の診断を不要にするわけではありません。

ルール中心の方法：Gmail や cPanel で転送を作り、実際のサーバー処理、各ドメインの認証、M365 の方針を確認する。

TrekMail のモデル：画面で経路を定め、MTA で利用できる SRS 書き換えと ARC 処理を確認する。受け入れは受信側が決める。

TrekMail は Postfix レベルでの転送と、再配信前の SRS、ARC 処理を説明しています。現行実装、署名の保持、受信結果を調べてください。ARC は以前の認証結果を保持しますが、元の DKIM の代わりではなく、署名保持や Gmail、Outlook、Yahoo による受け入れも保証しません。

数十の顧客ドメインでは集中設定で管理が簡単になる場合があります。例えば 30 の個別画面を開く代わりに経路を一か所で保守できても、ドメイン別の検証は必要です。顧客メール管理ガイドは複数ドメインの経路と手順 5 の A→B→A ループを扱います。

過去の価格例では月 $10 の Proに 100 ドメインと 50GB、月 $23.25 の Agencyに 1,000+ ドメインが示されています。また 14 日試用が説明されています。現行料金、上限、カード要件、試用権限、ARC/SRS の対応を確認してから計画します。trekmail.net/pricing でプランを比較してください。

繰り返す転送障害には検証済みの運用手順が必要です。適切な SRS と ARC を扱う基盤を確認しましょう。